Closed
Bug 71308
Opened 23 years ago
Closed 23 years ago
This page hangs Mozilla window
Categories
(Core :: Networking, defect)
Core
Networking
Tracking
()
VERIFIED
FIXED
mozilla0.9
People
(Reporter: Junk_HbJ, Assigned: neeti)
References
Details
(Keywords: hang, testcase)
Attachments
(1 file)
913 bytes,
text/html
|
Details |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; 0.8.1) Gecko/20010307 BuildID: 2001030704 The following code hangs the Mozilla window which loads that code, causing the following symptoms: - Screen content is not redrawn (only menubars, but not the actual browser window) - <Ctrl-N> is still working and all other Mozilla windows are unaffected. Reproducible: Always Steps to Reproduce: 1.) Load the code from the attachment Actual Results: Hang Expected Results: Error message
Comment 2•23 years ago
|
||
Well, the testcase isn't very useful since the JS files are included via the "script src". Can you put the javascript within the code and re-submit the testase? Right now all it does is generate a "parse_parameters not defined" JS error (unless that's what you're talking about and I'm just not seeing the hang in Linux). Please clarify.
Sorry, I should have been more specific: Mozilla hangs with "read \\js\default.js" in the statusbar, leaving the browser window unresponding. Therefore, I assumed that this *could* be a problem with the javascript implementation. The point is: Mozilla doesn't recognize that the applet can't be loaded (as it isn't there :-). Because I don't know how Mozilla handles javascripts (loading <==), could you *please* assign the bug to the right department?
Comment 4•23 years ago
|
||
OK. I see the problem now. Clarification: The problem only occurs on the local HDD when Mozilla times out trying to read the non-existing included JS script. Over the web the server returns a 404-page, which generates a JS error when Mozilla is trying to parse it. On the local HDD just a black screen is displayed. This is a JS-engine error, I believe. It should not be trying to parse whatever the output of a <script src="">, but check whether the return code has been a 200/success (or whatever it is on the local machine) and only then try to parse the document.
Comment 5•23 years ago
|
||
Tried changing OS to "All", but I ain't got the power... ;) Confirm on Linux w/2k1-03-07-14.
It's not a duplicate, and it's not the JS engine. The problem here seems to be that we guess the MIME type as text/javascript when we see the file URL ending in ".js", but when we generate the error we don't change the MIME type back to match what we output. (If this happens over the web, it's a server-configuration error: given a MIME type from the server, or from the script tag, we _must_ treat the content as that type, regardless of HTTP result code. Unless we're guessing the MIME type based solely on the extension, and ignoring the return from the server, in which case we should be summarily shot.) Moving this to networking, whose bug it more likely is.
Assignee: rogerl → neeti
Component: Javascript Engine → Networking
QA Contact: pschwartau → tever
Comment 8•23 years ago
|
||
Marking NEW.
URL: Not applicable
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 98 → All
Hardware: PC → All
I am able to load the code from the attachment on both windows and linux and the error page loads. We no longer hang.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 10•23 years ago
|
||
VERIFIED: mozilla 0.9 all plats. Page displays an error about how "/start.html" could not be found.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•