70906 - Page fails to load zero-length files when using type="text/javascript"

Status: RESOLVED DUPLICATE of bug 61229

(Core :: DOM: HTML Parser, defect)

Description

[Olav Vitters]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-ac7 i686; en-US; 0.9) Gecko/20010303
BuildID:    2001030321

When using script src= and type=text/javascript the page will fail to load.
Changing type=text/javascript into type=text/x-javascript will correct the problem

Reproducible: Always
Steps to Reproduce:
1. Load the URL http://gathering.tweakers.net/preferences.php

Actual Results:  Page fails to load. The displayed page is transparent.

Expected Results:  The page should load (as it does when text=text/x-javascript
is used).

The source of the given URL is hard to read. I've made a testcase consisting of
two files that demonstrate the problem.

I have filed the bug under 'JavaScript Engine'. This is probaly wrong, but I
couldn't find a better component.

Some bugs that could be helpful:
 * #62485 (script type="text/ecmascript" is not recognised)
 * #65428 (language="javascript" should be type="application/x-javascript")

Comment 1

[Olav Vitters]

Attachment: Testcase, requires attachment empty.js.

Comment 2

[Olav Vitters]

Attachment: Better testcase. Zipfile contains two files for the testcase.

Comment 3

[Olav Vitters]

The file empty.js is 0 bytes. I could not attach this file so I have put both
files in a .zip. Please ignore the first attachment.

Steps to Reproduce:
1. Unzip the 2nd attachment
2 [details] [diff] [review]. Load testcase.html

Comment 4

[Olav Vitters]

I have found another workaround. Please note that the original empty.js is 0 bytes.

Workaround:
1. Edit the empty.js file
2. Press enter
3. Save the file as empty.js
4. Reload the file testcase.html

This workaround is not needed when using type=text/x-javascript instead of the
current type=text/javascript.

Comment 5

[Olav Vitters]

I can reproduce the problem on Windows using Build ID 2001030205.

Changed OS to All.

Comment 6

[Boris Zbarsky [:bzbarsky]]

So is this only a problem with loading zero-length files with
type="text/javascript"?

Comment 7

[Olav Vitters]

Yes, this is only a problem with zero-length files using type="text/javascript"
. For some strange reason the mentioned site (gathering.tweakers.net) uses this.

I've changed the Summary to make this more clear.

Bug #5569 explains why the transparent window occurs. I don't think this bug is
a duplicate of bug #5569, because type="text/x-javascript" does work.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Well... type="text/javascript" is what's supposed to be used for external JS
scripts.  As far as I can tell after a bit of experimentation, files loaded with
type="text/x-javascript" are not executed at all.  They may even not be loaded.
 This would explain why setting that works....

Comment 9

[Phil Schwartau]

Browser, not engine. Not sure of correct component; reassigning to Parser
for further triage -

Comment 10

[Richard Brodie]

We already have a report, bug 61229, for problems with loading HTML with 
Content-Length: 0. If Boris' supposition is correct, and that type=text/x-
javascript files are not loaded at all it would be consistent with a generic 
HTTP problem.

Comment 11

[Richard Brodie]

Further to the above - you only see this problem with HTTP Keepalive enabled.

Comment 12

[Olav Vitters]

I can reproduce this bug with HTTP Keepalive and HTTP Pipelining disabled. I
also disabled 'JavaScript for Navigator' and could still reproduce the bug
(Build ID 2001030321). I can also reproduce this bug locally (see 2nd attachment).

Note: type="text/x-javascript" was an error on my part. While testing I meant to
use type="application/x-javascript", but I did not and confused myself.

Comment 13

[Fabian Guisset]

CC'ing timeless and myself. Timeless, you've been messing with javascript type,
anything to add to this discussion? What would be the correct component btw?

Comment 14

[timeless]

yes i already knew about this bug, i had nothing to add because i agreed w/ 
bz's analysis. I also agree with Richard Brodie <[e-mail]>'s 
analysis.

*** This bug has been marked as a duplicate of 61229 ***