Discard script preload if the charset doesn't match

RESOLVED FIXED in mozilla2.0b8

Status

()

Core
DOM
P1
normal
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: hsivonen, Assigned: bz)

Tracking

Trunk
mozilla2.0b8
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

8 years ago
Currently, Gecko doesn't check that the charset used fro a script preload matches the charset specified at the time of using the preload as if it were a real load.

The script loader should be changed to discard the preload if there's a mismatch.
(Reporter)

Comment 1

8 years ago
Nominating as a blocker per bug 591981 comment 35.
blocking2.0: --- → ?
(Reporter)

Updated

8 years ago
Component: Document Navigation → DOM
QA Contact: docshell → general
Blocking.
blocking2.0: ? → betaN+
Created attachment 495578 [details] [diff] [review]
Discard script preloads if the charset doesn't match.

I have no idea how to write a test for this... I did verify that http://stevesouders.com/cuzillion/?ex=3&title=IE8+Parallel+Script+Loading loads in about 4.5s with and without this patch, and loads in closer to 9s if I add |&& 0| to that if condition.
Attachment #495578 - Flags: review?(jonas)
Assignee: nobody → bzbarsky
Priority: -- → P1
Whiteboard: [need review]
You could possibly test this using something like:

<html>
<script src="1.js"></script>
<script charset="ISO-8859-1" src="2.js"></script>
-->
</html>


1.js:
document.write("<script charset='utf-8' src='2.js'></scr"+"ipt><!--");

2.js:
document.write("Räksmörgås");

And make sure 2.js is utf8 encoded.
Hmm.  I need to guarantee that the preload for 2.js is actually kicked off before 1.js is loaded and runs, right?  Do we have some examples of that in the tree already?
You don't technically have to guarantee it. If it doesn't your test would go randomly green in error conditions, rather than randomly orange in success conditions, which IMHO is somewhat ok.

To reduce your greenness-under-error ratio you can put a short delay on making 1.js return a response.

If you want to eliminate it completely you can make 2.js check for a server-side state variable before returning, and make 1.js set that. But do make sure that it handles the case when 2.js is requested before 1.js, otherwise you'll get "real" rando-orange.
> To reduce your greenness-under-error ratio you can put a short delay on making
> 1.js return a response.

That's what I was thinking of, yes.  Do you know of examples that do this, offhand?  If not, I'll dig...
Attachment #495578 - Attachment is obsolete: true
Whiteboard: [need review] → [need landing]
Pushed http://hg.mozilla.org/mozilla-central/rev/dfb20f820e92
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [need landing]
Target Milestone: --- → mozilla2.0b8
You need to log in before you can comment on or make changes to this bug.