Closed Bug 118404 Opened 23 years ago Closed 23 years ago

External JS files not loading; fixed by making new Profile

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla0.9.9

People

(Reporter: d_king, Assigned: harishd)

References

(
URL
)

Details

(Keywords: regression, relnote, Whiteboard: [driver:brendan])

Attachments

(8 files)

prefs.js where JavaScript SRC loads don't work
12.09 KB, text/plain
Details
Minimal HTML for JavaScript 2nd example (Wordsmith)
223 bytes, text/plain
Details
Cache of profile with problem
27.58 KB, application/x-zip-compressed
Details
HTTP.LOG as requested
494.46 KB, text/plain
Details
HTTP.LOG from Petco site I described in bug 119541
574.86 KB, application/octet-stream
Details
Test case: HTML, JS, and 2 JPEG's
2.93 KB, application/x-zip-compressed
Details
<SCRIPT SRC=this file>
7.09 KB, text/plain
Details
patch with both fixes
1.52 KB, patch
harishd
: review+
jst
: superreview+
brendan
: approval+
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/4.79 [en] (Win98; U)
BuildID:    2002010403

The JavaScript that creates a menu list on the left side of the page isn't 
working. It does work under Netscape 6.2.1 and I recall it worked under Mozilla 
0.9.7 (although I haven't retested that yet).

Reproducible: Always
Steps to Reproduce:
1. Open page


Actual Results:  No Menu List

Expected Results:  Menu list on this page, and on 
https://teldrug.healthcare.cigna.com/healthcare/teldrug/app/public/PrescriptionC
enter.jsp?n=11130 which is accessed via the "Customer Service" link.
works for me; 2002010506/linux. sure you've enabled all the appropriate js
thingies in edit/pref/advanced/scripts&windows ?

WFM, win98SE, 2002010403
My Edit-Pref settings are as follows.

Under Advanced - "Enable Java" is set, and "Enable JavaScript for Mail &
Newsgroups" is not set.

Under Scripts & Windows - Everything is set except for "Open windows by themselves".

Just in case, I just uninstalled and reinstalled 2002010403. No luck.

However, on the JavaScript Console I am seeing lots of warnings, and two errors,
one about "init" not being defined and one about "leftnav" not being defined.

Based on my limited JavaScript skills, I would think this means that the <SCRIPT
SRC> isn't pulling in the remote source files.

hmm, for the record, I'm not seeing any js errors.
It seems we've been having trouble loading external JS files recently.
See bug 117827 - creating a new Profile seems to fix the problem.

David: could you try the site with a new profile? To do this, launch
Mozilla from the command line as follows:
 
       [(path to Mozilla)] ./mozilla.exe -profilemanager


When the Profile Manager comes up, there's a button called "Create Profile".
I'll bet that with the new profile, the problem goes away, as with bug 117827.

In the meantime, reassigning to Browser-General : this is not a problem
with the JavaScript Engine. If anyone knows a bug for the problem of 
external JS files not loading, please post it here - thanks.
Assignee: rogerl → asa
Status: UNCONFIRMED → NEW
Component: Javascript Engine → Browser-General
Ever confirmed: true
QA Contact: pschwartau → doronr
Creating a new profile did fix the problem. Now, to ask the same question as was
asked in bug 117827, WHY?

From reading that bug, it looks like it's something in prefs.js, I'm attaching
my old 'broken' one in case someone can spot the problem.
David: thanks for verifying this so quickly.

Asa: we have a major problem on our hands. As evidenced by this bug
and bug 117827, recent builds can fail to load external JS files
unless the user creates a new Profile.

Is this perhaps related to the new Preferences we've recently added?
(Edit > Preferences > Advanced > Scripts and Windows)
Summary: JavaScript Menu list doesn't work → External JS files not loading; fixed by making new Profile
One of the files in my old profile directory is causing the problem. So far I've
ruled out prefs.js and a few others. I'm currently going through a process of
elimination to find which file is breaking it.

The reason I'm doing this is once I found that a new profile fixed the problem,
I copied all the files from the old profile, and it broke again. So, which file
was it.....well I hope to know soon.
OK, I going to say it's a caching problem. I copied all files, one by one, from
the  old profile to the new one, and everything was fine. But, when I copied the
cache directory from the old profile, the problem was back.

So, either my cache is corrupt (which I doubt as I cleared it via Prefs less
than 12 hours ago) or the new JavaScript options don't work well with existing
cache files.

Well, that's it from me...
David: thanks again!

As a result of David's findings, reassigning to Networking:Cache 
for further analysis. cc'ing Asa so he can continue to follow this -
Assignee: asa → gordon
Component: Browser-General → Networking: Cache
QA Contact: doronr → tever
More info, this time not very good...

If you take a look at http://www.metrocast.net/~dgk/ (my horrible home page) you
will see is has some JavaScript SRC as well.

<script src="http://wordsmith.org/words/word.js"></script>

Which doesn't seem to work, even with a new profile. I verified the origin file
using Netscape 4.79 which ran it fine.

Is this a different problem (as it appears within a <TABLE></TABLE>)?
Note: such problems can be caused by a missing tag of some sort,
tolerated in NN4.7 but not in Mozilla. When I tried to validate 
http://www.metrocast.net/~dgk/ via http://validator.w3.org/,
I was unable to because the validator says there is no <DOCTYPE>. 

David: would you be able to add a <DOCTYPE> and see if your page
passes the HTML validator? If it should pass, would you be able to make
a copy of the page and reduce it to the smallest possible HTML that
shows the bug? Then you can attach it to this bug; that would be great - 
Oops - the validator allows you to select a doctype and a charset.
When I select HTML 4.01 Transitional and iso-8859-1, errors are detected:

http://validator.w3.org/check?uri=http%3A%2F%2Fwww.metrocast.net%2F%7Edgk%2F&charset=iso-8859-1+%28Western+Europe%29&doctype=HTML+4.01+Transitional
Note this comment by the validator:

Line 121, column 6: 

          </p>
             ^

Error: end tag for element "P" which is not open; try removing the end tag
or check for improper nesting of elements

It's that last bit that's suggestive...
I tried

https://teldrug.healthcare.cigna.com/healthcare/teldrug/app/public/PrescriptionCenter.jsp?n=11130

with

Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.7+) Gecko/20020110

and got the error instantly.

I have experienced lately in multiple different cases an unreliability in
loading content of all kinds, even accompanied by crashes.
Maybe I get more of this because my computer is rather slow.

So far, only in one case have I been able to produce a testcase from any of
those failures:

Refer to bug 114827, which appears to me simple and critical enough to suggest
that others such as this might depend on it.
I'm still working on getting a minimal piece of HTML for test purposes of my
second problem/example. However, my cable modem conection is very very slow
tonight, and providers tech support have a 3 hour wait time before responding
(they're rather busy apparantly).

Once things are back to normal, I'll also take a look at bug 114827 for
similarities.

By the way, to BHT, hi from a fellow NZ'er.
I've added a new attachment with minimal HTML to demonstrate the problem I
describe in #13 as requested in #14.

validator.w3.org complains about two items in this HTML. An empty <HEAD> (no pun
intended), and the <SCRIPT> doesn't have a TYPE specified.
I've confirmed that my attachment works as expected in Netscape 6.2.1, but
doesn't work in Mozilla 2002011103. 

As the test case removes frame info, I don't think it is related to bug 114827
which is related to frames and seems to be a FRAME SRC using JavaScript problem
rather than a SCRIPT SRC not being loaded problem (sorry BHT).
*** Bug 119541 has been marked as a duplicate of this bug. ***
Note: in the duplicate bug 119541 we tried the following experiment:

1. Bring up Mozilla with the bad profile
2. Go to Edit | Preferences | Advanced | Cache
3. Hit "Clear Memory Cache" and "Clear Disk Cache"
4. Hit OK
5. Close Mozilla
6. Bring up Mozilla with the bad profile again
7. Load the URL

But that did NOT solve the problem -
I think this is highly unlikely that it's a problem with the cache.  Phil, are
you able to reproduce this?
No - I've never been able to reproduce this. Our contributors report
that making a new Profile fixes this. I got the idea that it might be 
Networking:Cache from the work David did in Comment #10, Comment #11.

But I'm not sure what's doing this -
I'm still seeing this once in a while, and replacing my cache files fixes it.

When one clears the disk cache, do the following files remain? :-
_CACHE_001_
_CACHE_002_
_CACHE_003_
_CACHE_MAP_

I figure these are index files to the various cache files. What does Clear Disk
Cache do to these files? Is that the problem?
Those files are normally present after the disk cache has been cleared.  They
contain an index and metadata, but there are reinitialized when the cache is
cleared.  They may not get physically smaller however.

The comments from #10 and #11 simply indicate there may be a document in the
cache that is causing problems, not that the cache service has a bug in it or
even that the disk cache is corrupt.

It might be interesting to get zip archive of the cache directory when it's in
that state.  We might be able to analyse it for problems.
I believe this is the cache directory for the profile that has the problem I
reported in Bug 119541.
I've created two zip archives, one with the "bad" cache files, and one with the
"good" cache files. I couldn't upload one of them due to its size, so I've put
them on my web page at :-

http://www.metrocast.net/~dgk/badcachefiles.zip

http://www.metrocast.net/~dgk/goodcachefiles.zip

I hope these are of help.
I've just tested using the "bad" cache files under Mozilla 0.9.7 and things work
as expected. As such, I see this as a regression that will need to be fixed for
0.9.8.
Keywords: regression
I see the problem when I use the "bad" profile in both 0.9.7 (2001122106) and
0.9.7+.
I just double-checked on 0.9.7 with win98SE

I deleted the contents of the cache folder.
I unzipped badcachefiles.zip into that folder
I went to http://www.teldrug.com

The menus on the left side of the screen appear as they should.
That *really* makes it sound like this isn't a cached problem.  The format of
the cache files has not changed since 0.9.7, so there isn't any difference in
how they are presented to the cache client (http, imglib, etc.).  Something
higher up is interpreting the data differently.
A thought...which may be pure rubbish...but I'll say it anyway.

If the file specified in the <SCRIPT SRC=***> code was cached, would the
JavaScript engine retrieve it from cache, or get it from the server again?

Several assumptions being made there, but I thought it might help sort out this
problem.

This problem also seems to affect the Bugzilla quick search feature.  When I use
the bad profile, Quick Search reports

 Error
 
The bug number is invalid. If you are trying to use QuickSearch, you need to
enable JavaScript in your browser. To help us fix this limitation, look here.

The JavaScript console reports:
Error: QuickSearch is not defined
Target Milestone: --- → mozilla0.9.9
Linking to 0.9.8's tracking bug, and wondering if Phil or anyone nearby can
reproduce the problem so it can be debugged?

Cc'ing jst.

/be
Blocks: 115520
More info:

The file specified in <SCRIPT SRC=> is, in fact, being downloaded. I can tell
this by finding the file in the cache, deleting that file, and reloading the
page. No, I didn't modify the index files.

So, once in cache, is the JavaScript engine not reading it from there?
More info:

The file specified in <SCRIPT SRC=> is, in fact, being downloaded. I can tell
this by finding the file in the cache, deleting that file, and reloading the
page. No, I didn't modify the index files.

So, once in cache, is the JavaScript engine not reading it from there?
Hmmm, #37 and #38 are dups.....now I wonder how I managed that?
The code that reads the JS files that are referenced on HTML pages doesn't know
the first thing about the cache, it just tells necko to open the URI and feed
back the data. If the data isn't loaded it would indicate that this is a necko
problem to me.
OK, so why are the JavaScript files cached? Seems like a wasted effort if the
code isn't going to use the cache.

Also, if it's a necko problem, when why does creating a new profile fix the
problem? Or, to be more specific, why does replacing the cache directory in the
profile fix the problem?


Just because the code that loads the JS files doesn't know anything about the
cache doesn't mean that the files never come from the cache. The cache is a
transparent layer AFA this necko client is concerned. If necko caches the files,
then they should be loaded from the cache, but the code that loads them doesn't
know, nor care, if that's what really happens or if the files come off the
network again.
cc'ing darin.  Something seems to be getting lost between the cache and js. 
Darin, take a look at comment #32.
Javascript not executed even though it is loaded?

That sounds tricky but familiar.

Maybe a handy testcase can help that has JavaScript that is definitely loaded
but does not get executed even when loaded from a local filesystem (until a
browser resize):

<HTML>
<HEAD>
</HEAD>
<FRAMESET cols="30%,*,30%">
    <FRAME src="javascript:'<BODY bgcolor=blue>'">
    <FRAME src="javascript:'<BODY bgcolor=black>'" scrolling=no marginwidth=1>
    <FRAME src="javascript:'<BODY bgcolor=black>'" scrolling=no marginwidth=1>
</FRAMESET>
</HTML>

The case started failing at about the same time when this bug was reported.
I am suggesting to include something similar in a build QA check such as the
smoketest. Please excuse my ignorance. I have only heard about this term. I am
not familiar with the smoketest.
bht, is there a bug filed on that frame src="javascript:'foo'" regression yet? 
It may be a dup or related, but it should be reported separately.

/be
The frameset problem is filed as bug 114827, and that's unrelated to this
problem. In that case the JS does get executed, but the browser doesn't react to
the background in the <body> until a resize reflow.
I just made some tests that confirm jst's statements.
Whiteboard: [driver:brendan]
it would be a great help if someone able to reproduce this bug could generate
and attach a HTTP log file.  this is done by setting the following environment
variables.

under win98:

1) open up a DOS prompt
2) type the following:

    set NSPR_LOG_MODULES=nsHttp:5
    set NSPR_LOG_FILE=http.log
    cd \path\to\mozilla\installation
    .\mozilla.exe

3) reproduce the bug
4) you should find a file called http.log in the current directory which will
contain a juicy log of what you did from the perspective of the networking code.

from this log file we should be able to determine if anything funny is happening
in the networking code.
I don't know if this sheds any light or not, but when this happened to me, I was
working only with documents using the "file" scheme.  No real networking
involved at all.  I can't reproduce the error, however, because I stupidly
replaced my profile instead of just making a new one.

--scole
Attached file HTTP.LOG as requested — 
Here is a http.log file as per instructions.

This should demonstrate both problems I've reported. One with Wordsmith.org and
one with www.teldrug.com
If this bug occurs with the file: scheme, then it has nothing to do with the
cache whatsoever.  The file: protocol doesn't use the cache.
some interesting things from the log file:

the toplevel document (http://www.teldrug.com/) contains:

<HEAD>

<SCRIPT LANGUAGE="JavaScript">
window.location = "http://www.cigna.com/consumer/services/pharmacy/tel_drug.html";
</SCRIPT>

and while the document's nsHttpChannel is calling the parser's OnDataAvailable,
the channel is canceled with NS_BINDING_ABORTED, and the parser is returning
NS_ERROR_HTMLPARSER_STOPPARSING from OnDataAvailable.

i'm not sure if this is related to the problem, but hopefully someone in the
parser group can investigate this further.  i doubt this is a networking bug.

-> parser
Assignee: gordon → harishd
Component: Networking: Cache → Parser
QA Contact: tever → moied
>while the document's nsHttpChannel is calling the parser's OnDataAvailable,
>the channel is canceled with NS_BINDING_ABORTED, and the parser is returning
>NS_ERROR_HTMLPARSER_STOPPARSING from OnDataAvailable.

What we need to find out here is why the channel is getting canceled. If a
document load is stopped abruptly then the parser has to stop parsing. Darin, do
you think that it's a bad idea to propagate error messages from the parser? 

FYI: I'm not able to reproduce the problem ( probably because I don't have a bad
profile ) what so ever. David ( reporter ), I need a good testcase to
investigate the bug further. 



harish:

necko is designed to allow error codes to result from OnStartRequest and
OnDataAvailable -- these just result in canceling the channel.  error codes
resulting from OnStopRequest generally get ignored.  in this case, it appears
that the channel has been canceled already by the time STOPPARSING results from
OnDataAvailable.  the original cancel appears to be with a status of
NS_BINDING_ABORTED, which is unfortunately used in many different contexts. 
but, this is the error code that actually causes the cancelation.  the
STOPPARSING error is ignored.

so, you might check to see if there are any parser conditions that result in
both an explicit Cancel with NS_BINDING_ABORTED and OnDataAvailable returning
NS_ERROR_HTMLPARSER_STOPPARSING.
Unfortunately, it is not so easy to find out the condition without a
reproducable testcase.

It's reproducible on my computer.  I'll be happy to send any files or run any
tests you want.
Matt, this sounds very promising.
Could you please attach a .js file and a master HTML in that order to this bug
in such a way that the error reproduces for you on this server without reference
to local files or URLs on other servers?

I would suggest that as many people as possible report their test results,
together with CPU speed, estimated connection bandwidth, network latency and
possibly other relevant qualified information. Maybe there is a pattern which we
wouldn't find without such information gathering.

At the very least this would help to eliminate losing the testing environment of
the original "offending" site due to a potential update.
personally, my guess is that the bug is cache related (hence the new profile 
fix) assuming that's the case, we'd probably need info from about:cache .. i'm 
not sure who can explain what bits we'd need.
Harish,

You asked for more info from me, based on subsequent messages, do you still need
this. At this stage, I would point you to #29 which gives you a set of cache
files to duplicate the problem at www.teldrug.com.
I do not know how to create "a .js file and a master HTML".  However, I can
reproduce the same bug on the mozilla.org server by using the Bugzilla
QuickSearch feature: 

OS:  Windows NT 4 SP6a
Build: 2002012203

Steps to reproduce:
1.  Go to http://bugzilla.mozilla.org/
2.  Enter "testing" in the field labelled  "Enter a bug # or some search terms:"
3.  Click the "Show" button

Actual results:  The following error is displayed:

 Error
 
The bug number is invalid. If you are trying to use QuickSearch, you need to
enable JavaScript in your browser. To help us fix this limitation, look here.

Expected results:  A list of bugs containing the term "testing"

Additional information:
The JavaScript console reports:
    Error: QuickSearch is not defined


Additional information:

I have found that this problem does not occur on milestone build 0.9.7 with the
same profile.  Further, if I run build 0.9.7, and then run a recent 0.9.7+
build, such as 2002012203, the problem with Bugzilla QuickSearch disappears. 
The Bugzilla problem will not return even if I reboot.  However, if I uninstall
the 0.9.7+ build and install a new 0.9.7+ build in a new directory, the Bugzilla
problem will return again until I run build 0.9.7 again, at which point the
problem again disappears.

Even more oddly, even though the Bugzilla problem disappears after running
0.9.7, the Petco problem I reported in bug 119541 persists regardless of whether
I have run 0.9.7 or not.
Matt,

I was driving myself crazy trying to duplicate the problem on a different
machine which had 0.9.7, and I upgraded to 2002012304, and I couldn't get
www.teldrug.com to fail.

At this point, I have to agree that it isn't solely a cache problem (yes, I
know, others have already told me this). However, you just saved me lots of time
trying to figure out how to dup the problem.
Matt: I followed the steps described in #61, with build 2002012203, but did not
see any JS error. The resulting page displayed 29 bugs. Do I still need a bad
profile to reproduce the problem?
teldrug fails for me with build ID 2002011604, Win95, 200MHz CPU speed, 28800
bps modem, ca 1s network latency.
It fails also when I run the teldrug files from a local http server.
This bug needs a testcase. The HTML is so convoluted and messy that it could
well be that the issue is simply an application problem.
It would take me a whole day to make a testcase for this.
Although I have done this many times for Mozilla I don't have the time right now.
Just in case: A testcase for this issue should be minimal, just a few lines of
code without all the anchors and images and generated style sheet code etc.
Example of an unrelated testcase that fails in Mozilla:

<HTML>
<HEAD>
<SCRIPT>
function handler(t,u,n){
    alert("handler.caller = " + handler.caller);
}

window.onerror = handler;

noSuchFunction();

</SCRIPT>

</HEAD>
</HTML>

The error shows in the JavaScript console.
The testcase is already 1 level too complicated because it tests window.onerror
AND Function.caller. Only Function.caller is the problem here.
Yes, you need a bad profile.  My good profile works fine.

I just downloaded and tried 2002012304.  I can no longer reproduce the Bugzilla
QuickSearch problem using the bad profile with this build.  However, using the
bad profile, I can still reproduce the Petco problem, and I can reproduce a
problem with the Bugzilla Helper:

1.  Go to http://www.mozilla.org/quality/help/bugzilla-helper.html
2.  In the field labelled "Search Bugzilla" enter "testing"
3.  Click the "Search" button

Results:  I am returned to the top of the Bugzilla Helper page

JavaScript console
Error: SearchForBugs is not defined
Error: PrefillBugInfoForm is not defined
Attachment #66175 - Attachment mime type: application/octet-stream → application/x-zip-compressed
Does it come down to Edit | Preferences | Advanced | Scripts and Windows | Allow
JavaScript to Change Images? My test case attachment seems to say that it is.

Change Images doesn't fix www.teldrug.com for me.
Andrew (comment #68),
Your testcase may introduce a new issue that we may not want to cover here.
Proof: I can reproduce teldrug.com with that option turned on.
If you find that a fresh profile gets generated with this option turned off then
you may want to file a new bug for this.

Someone needs to reduce the teldrug.com files to a rock-solid testcase.

I think there is probably an infinite number of testcases that produce results
like Andrew's testcase. Maybe one of them even solves the problem ...??? :)

Has anybody seriously analysed the teldrug.com code?
Maybe after all Mozilla's behaviour is just a fair response to flaky JavaScript
coding and this issue cannot even be considered a bug.

The profile thing should IMHO be looked at only after it is established what the
offending issue is.
Attached file <SCRIPT SRC=this file> — 
This attachment is the external file (as retrieved from my cache directory)
called commonnav.js which I think is the one that is meant to give us the left
side menu.

This is in response the question about if the JS code is valid. My JS skills
are minimal, so someone else will need to take a look at this.
*** Bug 121804 has been marked as a duplicate of this bug. ***
I noticed that in attachment 63775 [details] there exists the line
user_pref("intl.charset.default", "");
Note the empty string value.

I ran into some problems before when I had this line in my prefs.js - for
instance, the url of links would not show up in the status bar when I moused
over them, and occasionally external JS files would not load.  Deleting that
line cleared them up.  I haven't tried the urls supplied here with that pref in,
so I could be wrong, but it may be related.

Could those who are seeing this bug check for this line in their prefs.js and
try deleting it please.
What Jason describes in Comment #73 sounds like the discussion following
http://bugzilla.mozilla.org/show_bug.cgi?id=120060#c8
Jason,

Your theory was correct.  May "bad" profile contained the following "intl." lines:

     user_pref("intl.charset.default", "");
     user_pref("intl.charset.detector", "");
     user_pref("intl.charsetmenu.browser.cache", "us-ascii, windows-1251,
windows-1252, UTF-8, x-mac-roman");
     user_pref("intl.charsetmenu.browser.static", "ISO-8859-1, x-user-defined");

The only "intl." line my "good" profile contained was:

     user_pref("intl.charsetmenu.browser.cache", "ISO-8859-1");

Commenting out the "intl.charset.default" line in the bad file allowed me to see
the Petco popup I described in bug 119541.
You beauty...

I removed the line in my prefs.js as suggested in #73 (note, I left all my other
"intl" settings alone). It fixed my original problem with
http://www.teldrug.com, and with the problem mentioned in #13.

I can't tell if this is the same issue as mentioned in #74, I haven't had any
coffee yet, so I'll leave that to the more informed.

A big thankyou to Jason for finding a way around this that didn't involve
creating a new profile.

I've noticed that this bug isn't marked as a blocker for 0.9.8, which I will now
accept, as long as the release notes mention the problem, and its fix as
detailed in #73.
Glad my hunch was correct!

So now that we have the cause narrowed down, can someone find where in the code
an empty string for intl.charset.default would be preventing javascript from
loading/running?  I did a quick search in lxr for that pref but with my limited
knowledge of C++ couldn't see what's going wrong.

Having the workaround now is a plus, but Mozilla should be able to handle the
empty string gracefully.  I don't know what the requirements are for release
notes; is this a candidate as David suggests?  Or is it already too late for the
0.9.8 release notes?
Jason, good catch.  Here's what happens:

1)  When the HTML document is loading it calls
    nsHTMLDocument::TryWeakDocTypeDefault as part of determining its default
    charset.
2)  This calls 
    GetLocalizedUnicharPref("intl.charset.default", getter_Copies(defCharset));
    which happily returns an empty string and a success value.
3)  This empty string is set as the document's character set, which is
    henceforward an empty string.
4)  The script loader uses the document character set if there is no charset
    specified in the <script> tag or the http headers.  It has no further
    fallbacks.  It tries to use this charset to decode the script and fails to
    get the decoder, so the script is skipped.  (see code at
http://lxr.mozilla.org/seamonkey/source/content/base/src/nsScriptLoader.cpp#687
    and on.

So possible solutions:

1)  Make the script loader fall back to ISO-8859-1 if the document charset is
    empty (or even if we just fail to get a decoder for the charset we think we
    should be using?).
2)  Fix nsHTMLDocument::TryWeakDocTypeDefault to not set an empty character set
   (it could still set a bogus one, of course).

I'd recommend both, I think...
I have a third option. Assuming it's the prefs.js that is wrong, rather than
code interpreting it wrong, an enhancement to Mozilla would be a way to verify
prefs.js settings.

As this is outside the scope of this bug, as it will include any and all
prefs.js settings, I will file a seperate bug report for this.

In any event, the two options in #78 should be done, as a prefs.js verifier
would be for 1.0.

Now, my next question. Can either of the suggestions in #78 be done in time for
0.9.8? I think the first one would be a quick hack that shouldn't cause too many
problems (but I'm not a C programmer so read that with a large grain of salt).

This is not going to get fixed for 0.9.8, but I added the relnote keyword, and
Asa is cc'd -- so it should get release-noted.

This bug should get fixed in 0.9.9, it seems easy enough to do both of the
winning robustitude things that Boris suggests.

Harish, should this be your bug still?  Or jst's?  Or both?

/be
Keywords: relnote
This fixes the site in the URL field (and yes, I made sure I set the bogus
pref)
Comment on attachment 67458 [details] [diff] [review]
patch with both fixes

sr=jst

I'm fine with taking this bug if bz or harishd doesn't want it on their plate.
Thanks everyone who helped track this down!
Attachment #67458 - Flags: superreview+
Comment on attachment 67458 [details] [diff] [review]
patch with both fixes

r=harishd
Attachment #67458 - Flags: review+
checked into trunk.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 120955 has been marked as a duplicate of this bug. ***
Comment on attachment 67458 [details] [diff] [review]
patch with both fixes

bz, can you please check these two into the MOZILLA_0_9_8_BRANCH.  (I believe
these files are unmodified from their branch points on the branch.)

a=brendan@mozilla.org for drivers, and thanks.

/be
Attachment #67458 - Flags: approval+
checked into branch
*** Bug 123051 has been marked as a duplicate of this bug. ***
Perhaps related (or not) is bug 105636. There, with the following pref, the
reporter gets multiple POST DATA warnings when entering a form:

user_pref("intl.charset.detector", "ja_parallel_state_machine");

Any ideas?
Re #89

I don't think this is the same for two reasons.

1/ If you are using 0.9.8 (or later builds) you shouldn't see the problem.

2/ The problem in this bug was due to an empty string "", rather than yours
where the value has been set.

Of course, if you're not using 0.9.8 or later, I suggest you do so.
> 1/ If you are using 0.9.8 (or later builds) you shouldn't see the problem.

Sure you should.  We just fixed the empty string.  Other bogus values could
still cause this.  Is the value in question non-bogus?  Why's it set?


If other settings in prefs.js could cause the behaviour described in this bug,
then why is this bug marked FIXED? If only a temporary patch has been applied,
then the bug should still be open until a permanent solution is found.
Because the only way to tell that a value is "causing this bug" is to fail to
get a Unicode decoder in the script loader.  As I said, we _could_ fall back to
ISO-8859-1 but we should think about that carefully (in a bug filed specifically
on that issue).  Maybe we just can't decode it because it really _is_ served
with a charset we don't support?  Should we decode it as ISO-8859-1 then?  That
could lead to some wacky behavior.... (possibly worse than what exists).
OK, I understand now. (mental note to self - learn more about
internationalisation issues).

So, back to the comment/question in #89, is this a dup?
No.  The problem is likely the same and comments to that effect could help that
bug out.  But the real questions in that bug should be why is the pref set to
that value (it looks like a decoder name...) and why do we not have that decoder?
Spam: Related future problems could be prevented by work in bug 123027 (verifier
for prefs.js).
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: