Open Bug 871719 Opened 12 years ago Updated 5 years ago

document.write of script tags after a Synchronous XHR will misplace the tags

Categories

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

14 Branch
x86
macOS
defect

Tracking

()

People

(Reporter: thanpolas, Unassigned)

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31 Steps to reproduce: As a javascript file executes synchronously, it issues 5 "document.write()" commands to load 5 different script files using the <script> tag. When the writes have performed the script continues to load another file using a Synchronous XHR call. At the callback of the XHR a final "document.write()" is performed that calls a defined callback: document.write('<script>doStuff();</script>'); Actual results: The order of the script tags has been misplaced, resulting in files 2 through 5 to load AFTER the 'doStuff' invocation and produce ReferenceError exceptions. <script src="script.js"></script> <script type="text/javascript" src="moduleA.js"></script> <script type="text/javascript">doStuff();</script> <script type="text/javascript" src="moduleB.js"></script> <script type="text/javascript" src="moduleC.js"></script> <script type="text/javascript" src="moduleD.js"></script> <script type="text/javascript" src="moduleE.js"></script> Expected results: The script tags should be in order and vars defined in files 2 through 5 available when 'doStuff()' is invoked. <script src="script.js"></script> <script type="text/javascript" src="moduleA.js"></script> <script type="text/javascript" src="moduleB.js"></script> <script type="text/javascript" src="moduleC.js"></script> <script type="text/javascript" src="moduleD.js"></script> <script type="text/javascript" src="moduleE.js"></script> <script type="text/javascript">doStuff();</script> A showcase of the issue can be found in this plunk: http://run.plnkr.co/plunks/qcgwOGHh6yDDHBPUEtVT/
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: 24 Branch → 14 Branch
At least, I can reproduce the behavior in Firefox6.0 intermittently. (It is necessary to remove the command that is not implemented in Fx6). I do not test in Firefox5 and earlier yet.
And I can also reproduce in Firefox4 and 5 intermittently. I think that you should need to add async=false in <script>. See, https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/4?redirectlocale=en-US&redirectslug=Firefox_4_for_developers#Miscellaneous_DOM_changes "<script> elements created using document.createElement() and inserted into a document now behave according to the HTML5 specification by default. Scripts with the src attribute execute as soon as available (without maintaining ordering) and scripts without the src attribute execute synchronously. To make script-inserted scripts that have the src attribute execute in the insertion order, set .async=false on them."
Component: Untriaged → HTML: Parser
Product: Firefox → Core
Thanks, invalid bug probably.
Alice "document.write()" is used, the "async" attribute is not applicable in this case.
I mean in script.js out += ' async=false src="' + pathPrefix + src + '">';
"out" is a string which is used as the argument for "document.write". The "async" attribute does not apply to this case.
I updated the script.js to use "async=false" and the case passes now. Still i believe that's an issue, the default value for async should be "false" when using document.write(), a lot of infrastructure rely on this fact. There's a distinctive difference between inserting script elements using document.createElement() at any point in time, and inserting script elements using document.write at parse time, before DomContentLoaded has fired.
(In reply to Alice0775 White from comment #6) > I mean in script.js > out += ' async=false src="' + pathPrefix + src + '">'; No, no. That sets async to true for a script given as markup. For parser-created scripts, the default is false. The dot in .async=false is not a typo. It only works as a DOM property for nodes created with document.createElement() (for which the default is true).
(In reply to thanpolas from comment #8) > I updated the script.js to use "async=false" and the case passes now. That's really weird. Maybe you ended up changing the timing. Anyway, synchronous XHR can cause all sorts of oddities. It's supported, because legacy code relies on it. Never use it when writing new code.
I removed the "async=false" so the issue gets illustrated again. > Anyway, synchronous XHR can cause all sorts of oddities. It's supported, because legacy code relies on it. Never use it when writing new code. As much as i'd like to avoid it, it is essential and required to what i do. Also, it's the first time that i learn that synchronous XHR is legacy. There is no such mention or hinting in MDN and to be frank, i'd like it to always be there. Nevertheless, the issue is there, and it only appears in Firefox, all other browsers will properly handle this.
Is this wontfix based on your comments?
Flags: needinfo?(hsivonen)
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #12) > Is this wontfix based on your comments? Low priority but not WONTFIX. That is, if someone figures out a reasonably non-invasive fix, we should probably take it. (In reply to thanpolas from comment #11) > Also, it's the first time that i learn that synchronous XHR is legacy. There is no such mention or hinting in MDN https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest#open%28%29 now says "Note: Starting with Gecko 30.0 (Firefox 30.0 / Thunderbird 30.0 / SeaMonkey 2.27), synchronous requests on the main thread have been deprecated due to the negative effects to the user experience." The spec (https://xhr.spec.whatwg.org/#the-open%28%29-method) says: "Synchronous XMLHttpRequest outside of workers is in the process of being removed from the web platform as it has detrimental effects to the end user's experience. (This is a long process that takes many years.) Developers must not pass false for the async argument when the JavaScript global environment is a document environment. User agents are strongly encouraged to warn about such usage in developer tools and may experiment with throwing an InvalidAccessError exception when it occurs. "
Flags: needinfo?(hsivonen)

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.

Severity: normal → S4
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.