Closed Bug 71308 Opened 23 years ago Closed 23 years ago

This page hangs Mozilla window

Categories

(Core :: Networking, defect)

defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla0.9

People

(Reporter: Junk_HbJ, Assigned: neeti)

References

Details

(Keywords: hang, testcase)

Attachments

(1 file)

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
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?
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.
Tried changing OS to "All", but I ain't got the power... ;) Confirm on Linux
w/2k1-03-07-14.
This looks like a duplicate of bug 63048
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
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: hang, testcase
OS: Windows 98 → All
Hardware: PC → All
Blocks: 61688
Target Milestone: --- → mozilla0.9
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
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.

Attachment

General

Creator:
Created:
Updated:
Size: