Netscape parsing problem

[bbruggemeyer]

Hi all

I am using an external .js file to dynamically link several more .js files into an HTML page.

The problem occurs with Netscape 4.x browsers. It seems to work fine in the majority of cases but on some pages the Netscape parser has a problem half way through the main HTML page and throws an error. In all cases the code snippet in the debug window is different to the actual code visible when you view source.

HTML page includes

<SCRIPT language=&quot;javascript&quot; src=&quot;all_code.js&quot;></SCRIPT>
<script language=&quot;javascript&quot;>
<!--
    // Page specific javascript, including...
    document.title = myTitle.toUpperCase() + &quot; - Summary&quot;;
//-->
</script>

all_code.js includes

document.writeln('<SCRIPT Language=&quot;javascript&quot; src=&quot;module1.js&quot;></SCR'+'IPT>');
document.writeln('<SCRIPT Language=&quot;javascript&quot; src=&quot;module2.js&quot;></SCR'+'IPT>');
document.writeln('<SCRIPT Language=&quot;javascript&quot; src=&quot;module3.js&quot;></SCR'+'IPT>');

example of error

unterminated string literal. 

    document.title = myTitle.toUpperCase() + " - Summ
.............................................^

Line from view source

    document.title = myTitle.toUpperCase() + " - Summary";

The actual error displayed is irrelevant as it changes depending on the amount of code which precedes it in the main HTML page. However, in all cases the type of error occurring suggests that a line-feed may have been inserted in the middle of the code. (I can move the position of the error by padding the code above it with spaces. If I push it towards a legal position (i.e. outside of a string and not in the middle of a variable or object reference) everything seems OK!

Anyway, this thing is driving me round the bend so any suggestions would be very welcome and could save my sanity.

thanks,
Bill Bruggemeyer

 

[junioro12]

I'm totally with you on this...I have tried everything to get this this error to go away and I just don't have a clue what it could be...

I've uploaded in different formats, saved in different formats included from ASP, included external JS, embedded the JS in the files...no matter what I do, the browser just arbitrarily chops lines at different places in different files for no reason whatsoever and craps out the page.

I make a fix to one page and I feel good, then other pages mysteriously begin showing similar errors in different places in the code...

IE4+, Netscape 6 have no problems with this code at all so I have to assume there are no errors in the code...

I you figure this one out, I'd love to know what the heck this is...

And I've read a bunch of things saying to keep strings short...I've done that everywhere...and I've even removed comments which stupidly seemed to make things a bit better...

Netscape 4 is a total travesty placed on the web development world...I've spent almost an entire day trying to figure this out and I have no clue what the problem is...and for IE and Netscape 6, my web app is totally finished...

I'd love to take someone to court over this!

 

[bbruggemeyer]

Just be grateful you've only spent one entire day on it!!!

Anyway, as an update, this is what I've found out.

The problem is caused by document.write() and document.writeln() statements being executed as the page is being parsed. Don't ask me how exactly. But if I have a bunch of document.writes together then at some point I will have an equivalent number of newlines inserted. HOWEVER, it appears to be tied in with some kind of timing issue which determines the location of the newlines in the HTML source.

The fact that removing comments has helped is because you have relocated the timing issue and moved the newlines elsewhere within the document. I have resorted to this ridiculous technique to minimise the impact on my site.

There's a big long thread on the TekTips javascript forum under the heading "External JS from external JS file". (Sorry, I don't know how to Xref threads). Definitely worth a read.

cheers Bill Bruggemeyer

 

[junioro12]

OK...thanks for the tip...that sounds logical...I don't know why I haven't encountered this in the millions of pages I've built before...

Anyway...its an evil bug!

 

[JacobDelfos]

I experience the same problem. Like a ghost cutting up my code at random. It only happens in NN4, so must be a bug in the program. I spent months debugging it, but now I'm giving up. I can't figure it out. Like Bill said, there is something like a 'black hole' in the document, and if it overlaps with your code.....

If any of you figure it out, please let me know....

 

[laise]

Try this may-workaround. Insert an empty script above the <script> statement that calls the external javascript file. The following works for me:

<SCRIPT TYPE=&quot;text/javascript&quot; LANGUAGE=&quot;JavaScript&quot; >
<!--
// -->
</SCRIPT>

I have no idea why this solves the problem, or whether it will work in all cases.

I discovered this workaround by accident, as follows. Originally I was using a short sniffer script to set a browser-ID variable before calling external javascript files and style sheets, selecting the appropriate style sheet for IE4, NN4, NN6,...

When I changed to server detection of the browser, using Apache's mod-rewrite, I no longer needed the sniffer script so I removed it and ran into the problem you describe above. Putting the sniffer script back made the problem go away. So I started dropping lines to try and work out which one worked the magic, and discovered that I could remove them all...

Hope this helps.

 

[bbruggemeyer]

This is precisely what I was talking about regarding the positioning of the newlines. I'd bet that the same could be achieved by replacing your script block with the equivelent number of space characters.

My big concern is that this position may also be effected by other factors such as caching and connection speed. I have no proof of this and no time to go out and prove it, but it leaves me feeling very uneasy about it.

My advice is to either drop the document.writes (if possible), drop NS4 support (wahay!), or publish with targeted warnings for NS4 users.
Bill Bruggemeyer