Closed
Bug 597345
Opened 14 years ago
Closed 14 years ago
Discard script preload if the charset doesn't match
Categories
(Core :: DOM: Core & HTML, defect, P1)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla2.0b8
| Tracking | Status | |
|---|---|---|
| blocking2.0 | --- | betaN+ |
People
(Reporter: hsivonen, Assigned: bzbarsky)
Details
Attachments
(1 file, 1 obsolete file)
|
4.85 KB,
patch
|
Details | Diff | Splinter Review |
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•14 years ago
|
||
Nominating as a blocker per bug 591981 comment 35.
blocking2.0: --- → ?
|
|
Reporter | |
Updated•14 years ago
|
Component: Document Navigation → DOM
QA Contact: docshell → general
|
Assignee | |
Comment 3•14 years ago
|
||
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 | |
Updated•14 years ago
|
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.
Attachment #495578 -
Flags: review?(jonas) → review+
|
|
Assignee | |
Comment 5•14 years ago
|
||
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.
|
|
Assignee | |
Comment 7•14 years ago
|
||
> 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...
|
|
Assignee | |
Updated•14 years ago
|
Attachment #495578 -
Attachment is obsolete: true
|
|
Assignee | |
Comment 8•14 years ago
|
||
|
|
Assignee | |
Updated•14 years ago
|
Whiteboard: [need review] → [need landing]
|
|
Assignee | |
Comment 9•14 years ago
|
||
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [need landing]
Target Milestone: --- → mozilla2.0b8
|
||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•