94903 - External JavaScript File on Unreachable Host Stalls Page Display

Status: VERIFIED FIXED

(Core :: DOM: HTML Parser, defect, P2)

Description

[Greg K.]

Using Mozilla 2001080214 on Mac OS 9.1:

When a document contains a SCRIPT element whose SRC attribute value includes a
hostname that is inaccessible, page display stalls indefinitely.

For example, a hostname that cannot be resolved or does not acknowledge a
connection request will cause this problem. Mozilla continues to display it's
page-loading status indicators in perpetual motion until Stop is pressed, but
all content following the SCRIPT element is never displayed.

This is a different situation from a SRC attribute URI that simply cannot be
found (404). In that case, the remote host returns some HTML as a 404 error page
which causes a syntax error in the JS engine, but then proceeds to display the
rest of the page.

Guessing Parser.

Comment 1

[Greg K.]

Attachment: Minimal testcase

Comment 2

[Greg K.]

In the testcase now attached, the SRCRIPT SRC URI contains a fictional hostname,
"foo.bar," which never resolves. Mozilla fully loads the testcase HTML and
starts parsing. It displays the paragraph, "Foo," preceding the SCRIPT, but
forever stalls at the SCRIPT itself. The paragraph following the SCRIPT, "Bar,"
never displays regardless of user action.

This also occurs 1) if the protocol is not running on the hostname specified in
the SRC, and 2) if the testcase is loaded through the local filesystem and the
SRC URI is also local, but doesn't exist.

Comment 3

[harishd]

Attachment: patch v1.1 [ Make sure that the parser resumes parsing even when loading external js fails ]

Comment 4

[harishd]

Johnny, could you please sr=? thanx.

Comment 5

[Greg K.]

Attachment: Second testcase; access this file only via local filesystem

Comment 6

[Greg K.]

For verification purposes, be sure to test the second testcase as well. Save it
to your local filesystem and access it only via [File/Open File...].

Comment 7

[harishd]

The second test case works with or without my change!

Comment 8

[Greg K.]

On what platform? Give it a try under Mac OS 9.

Comment 9

[Greg K.]

When performing the second testcase, I do seem to at least sometimes see the
error, "redeclaration of const kIOServiceProgID" on the JS Console, though I
couldn't say if it's relevant at all. (Source file:
chrome://communicator/content/utilityOverlay.js)

Comment 10

[Kurt Swanson]

Attachment: Third test case: non-existent file://localhost

Comment 11

[Kurt Swanson]

Third test case shows how non-existent script referenced via file://localhost
will also block page loading.

Comment 12

[Greg K.]

Third testcase works for me, I suspect because the SCRIPT is in the HEAD. Moving
the SCRIPT to the BODY causes the behavior I described.

Comment 13

[Kurt Swanson]

Third test cast does NOT work (i.e. does NOT load) on Mozilla/5.0 (X11; U; Linux
i686; en-US; rv:0.9.3) Gecko/2001080221

Comment 14

[Greg K.]

Is it safe to mark this bug All/All?

Comment 15

[Johnny Stenback (:jst)]

sr=jst

Comment 16

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I think you need to do this for XHTML as well. Please check, and if it is
needed, apply. r=heikki

Comment 17

[Greg K.]

Do we need to be concerned with XML here? Is there a processing instruction for
associating script files with XML as there is for style sheets?

<?xml-script?> or anything like that? (Like <?xml-stylesheet?>.)

Comment 18

[harishd]

I'm not sure about XML but we should definitely be concerned about XHTML.

Comment 19

[harishd]

Attachment: patch v1.2 [ fix for xhtml document included ]

Comment 20

[harishd]

This is fixed. Marking FIXED.

Comment 21

[Moied]

Verified fixed with build 20020103 on Win2k, Linux, and Mac 
fixed checked in cvs Version 3.478