PDA

View Full Version : Script works but page doesn't



Aensland
08-04-2008, 08:31 AM
1) Script Title: JsDOMenuBar

2) Script URL (on DD): http://www.dynamicdrive.com/dynamicindex1/jsdomenubar/index.htm

3) Describe problem:
Summary: script works when I write a quick-n-dirty html file in notepad and doubleclick on it, but fails mysteriously when I point IE at my localhost webserver to it.

Detail: I'm using a Xampp install to write some webpages. After customising JsDOMenuBar to my liking, I rename the html file to php and put it in a folder where Apache can server it. Firefox displays the page just fine, but in IE the menu bar doesn't show. If I manually open explorer and doubleclick on the html file though, IE displays everything. This isn't useful, obviously, because I need it available via webserver.

If I tell IE to display script errors, I'll get an error message about an invalid character in line 1095 -- somewhere in the javascript include files no doubt, but there's certainly nothing wrong with them... because the damn thing works if I doubleclick on the html file. It just doesn't work when I want to serve it on my webserver.

IE seems to be choking on something, somewhere, but I don't know what. I've even thrown all the files into the same folder (localhost/web2.0/): includes, images and all, and it still doesn't work. Here it is, verbatim:

Contents of: index.php


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Test page</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<link rel="stylesheet" type="text/css" href="outline.css" />
<link rel="stylesheet" type="text/css" href="office_xp.css" />
<script type="text/javascript" src="jsdomenu.js"></script>
<script type="text/javascript" src="jsdomenubar.js"></script>
<script type="text/javascript" src="webmain.inc.js"></script>
</head>
<body onload="initjsDOMenu()">

<p>
Menu bar should appear below:
</p>

<div id="staticMenuBar"></div>

<?
echo 'PHP output text.';
?>

</body>
</html>

Browser pointed at: http://localhost/web2.0/index.php. In FF, I get all the text and the menu bar in between -- in other words, this works. However, in IE, only the text appears (including the php echo text) but no menu bar, and if I have script error reporting turned on it'll complain about an invalid character in line 1095. I know this is false, however, because of the following:

If I rename the file to htm, and use windows explorer to doubleclick on it, IE displays the text (without the php bits) and also displays the menu bar. So the problem isn't just IE, but somewhere along the line where the page gets served.

I'm used to beating my head against errors but this one's too subtle for me. Anyone know what's going on?

jscheuer1
08-04-2008, 03:01 PM
Just as a wild guess, the character encoding on the local server may be different than what you expect. But that may not be it at all.

To get an accurate idea of where in which script the actual error is, you must put all of the scripts on the page (no external script tags). That way when the error is reported, you should be able to go to that line number to see what is happen either on that line, just above or below it.

If the error is in the served source, but not in the page as an HTML page, once you have all of the scripts on the page serve it as PHP and use the browser's 'view source' to see the served code. Copy that to your editor to find the line number.

It helps if you have a text editor that shows and can jump to specific line numbers. Notepad++ (a free program available on the web) is good for that, if you have nothing like that already.

One other thing worth mentioning is that localhost servers don't always accurately reflect what will happen on the web, so it would be a good idea to actually publish the page to see if it works OK on the web. If you need more help with it, you will need to do that anyway, as we cannot guess what the problem is without seeing it:

Please post a link to the page on your site that contains the problematic code so we can check it out.

Even with that, this one may be a bit of a problem if we cannot recreate the problem locally from the served files. But we will worry about that when and if we get that far, as it may be quite simple to solve once we see it. That's assuming you cannot fix it yourself, or it doesn't go away in a live implementation.

Aensland
08-05-2008, 01:42 AM
I'm 100% certain the scripts are not at fault. The css and the two jsdomenus are taken from this site. The webmain.inc.js contains my menubar definitions, and is only 30+ lines long, plus it works in FF.

I put them on a webserver (as opposed to localhost), and strangely now the menubar appears in IE as well, no problems. If you want to look, this page is at http://mainvvox.dyndns.biz/web2.0/index.php . It' s just a test page, I wanted to get the menubar working before I did anything else.

So apparently there's something about localhost which IE doesn't like. This morning when I ran the thing I only get an "object expected" error message at line 13, i.e. the "body onload=" tag. Mind you, this is when I point the browser at localhost. If I use the hardcoded local path (c:\xampp\htdocs\web2.0\index.php) then it works.

Tried searching but other than some vague warnings not to use "onload" because it 'may not work as expected', I haven't found anything useful.

jscheuer1
08-05-2008, 02:47 AM
That's pretty much your answer then. If the live page works, unless I am missing something, I don't see a problem. Just chalk it up to the limitations of your local host simulation program.

Aensland
08-05-2008, 05:16 AM
Yeah, it works on the live version, and for localhost developing work I can view the pages on FF... but this is just ignoring the problem ;) Both localhost and the webserver are using Apache 2.x iirc.

Oh well, chalk another one up for the x-files. Thanks for your help!

jscheuer1
08-05-2008, 08:27 AM
If you want to continue trying to figure this out, remove the body onload, point your IE at the local host. Once the page is loaded paste this into the address bar:


javascript:void(initjsDOMenu())

Hit Enter. If it works, then it is the body onload. There are other types of onload methods, if the above 'solves it' we can try one or more of those as an alternative to see if we can make IE happy on the local host.

Aensland
08-06-2008, 04:38 AM
Hmm, removing the "onload" call from the body tag gives the same errors -- the script one, plus an "Object Expected" error when I paste javascript:void(initjsDOMenu()).

With the body onload event on, the Object Expected error originates from line 13, i.e. the body tag. If I remove onload and paste your line in the browser, I get the same Object Expected error when I paste it (the page loads fine, with the usual line 1095 error which I think can be ignored), and this time it says it's from line 1, presumably the address bar. So I guess IE doesn't like the function call somehow when done through localhost. I'll see what happens if I do this on FF.

Update: on FF it works just as you intended; the page loads without the menu bar, and when I paste the call in the address bar, the menubar appears. Same thing happens if I load it on the live webserver and use IE. So it's just the combination of localhost and IE that it doesn't work on.

jscheuer1
08-06-2008, 05:00 AM
I wouldn't discount the error on 'line 1095'. By making all the scripts internal to the page, the true line may be able to be discovered, and I think it may very well be as I initially guessed - a problem with character encoding/mime type.

However, as long as it works live, I wouldn't worry about it, especially considering the work involved in troubleshooting it, with no guarantee of a successful outcome. If it were me, I would have to be both pretty bored and pretty annoyed to bother with it.

blm126
08-06-2008, 05:17 PM
This sounds like a mime type problem. I seem to remember from somewhere that IE is very particular about the mime type of Javascript files. Ok, a quick Google search turned up this.

http://annevankesteren.nl/2005/02/javascript-mime-type

Are you setting the type attribute of the script tag? If you aren't IE could be resorting to the Apache provided mime type, which it doesn't know how to handle.

Aensland
08-07-2008, 09:49 AM
Yeah, as pasted above, I'm setting the type to "text/javascript".

I ignored the problem yesterday, but after reading your response today, out of idle curiosity I pointed IE at the page again through localhost (having touched nothing)... and this time the menubar appears, no error.

Huh.

On a whim, I changed the type to "application/javascript"... and it bombed out like before. Changing it back to text fixed it again.

*scratches head*

Well, I'm not complaining that it works now, but I didn't do anything with it (I've been working on an unrelated set of php files since yesterday), and I haven't updated or installed or removed anything.

Edit: just realised that images on other pages are broken. Force reloading the page (shift-reload) doesn't really work on IE: I went to tools-> delete files, and checked delete offline content. Now the images show up, and guess what, the menubar is broken in localhost again, with the same error.

So the cache is also tripping me up. Screw IE, I'm just gonna have to live working with FF. Problem is, in FF, the submenus that drop down from the menubar appear on the TOP part of the browser window, instead of being vertically offset by how further down the page the menubar is at. Grrr.

Edit: okay, fixed that offset problem, posted here: http://www.dynamicdrive.com/forums/showthread.php?t=35277

-
For what it's worth, every time I close the IE browser after viewing the page when the menubar works (i.e. after viewing it on the webserver, where my page works correctly), I'll get an error message from IE saying it needs to close, something about offset 013b137b. I'm sure it means nothing to anyone except maybe the IE coders, probably something messed up about the install in my particular system. I'm getting a new pc at work soon (hurrah), I'll check this out again and post here whether I still get the error or not.