Re: Executing script-inserted external scripts in insertion order

Getify wrote:
> ?Update:
> Several sites are reporting breakage (not at all related to LABjs) in
> the
> FF4 nightlies related to this issue.

More precisely: There are *two* known cases of breakage: Hotmail account registration and Wikia.

Wikia is sniffing for Opera and Firefox and is relying on Opera and Firefox evaluating script-inserted external scripts in the insertion order. I'm planning on contacting Wikia once https://bugzilla.mozilla.org/show_bug.cgi?id=602838 has landed.

In the Hotmail case, it's not clear what exactly happens, but Hotmail is known to browser-sniff. Hotmail engineers have been contacted already.

The good news is that both Hotmail and Wikia are actively maintained top sites. I'd be more worried if there were a bunch of failing long tail sites.

> Should we move this forward to some sort of compromise decision and
> officially propose it as a change to the spec?

I think there isn't enough data to decide on how exactly this problem should be solved. I think the best way forward with insufficient data is to make .async=false make script-inserted external scripts execute in the insertion order, use the working assumption that .async will default to true but defer the actual decision on which way .async should default until there's more data.

> Would like some guidance on what any interested parties think we
> should do next?

I think the next steps are:
 * Review and land *both* patches attached to https://bugzilla.mozilla.org/show_bug.cgi?id=602838
 * Ship Firefox beta 7 and see how much breakage gets reported

The second step is likely to happen before the first step, which is not ideal, but beta 7 has been delayed enough already.

Those steps are the next steps from the Firefox point of view (per discussion with the reviewer in charge), but I think they should be the next steps from the HTML WG point of view as well. That is, I think the beta exposure of Firefox 4 beta 7 is the best way for the WG to obtain more data about the feasibility of the unordered default.

If it turns out that Firefox ends up having to default to .async=false for script-created scripts (while making .async=false external scripts execute in order and .async=true execute ASAP) due to legacy being too great, it would be bad to introduce *another* ordering mechanism, so, at this time, I'm categorically opposed to introducing ordering mechanisms that don't depend on the state of .async.

(Also, to manage expectations: Firefox 4 is now feature-frozen. While it's possible to introduce new functionality in order to address a regression, one shouldn't expect addressing regression to work as an excuse for adding something that's big and feature-y. I'm inclined to think the <scriptgroup> element proposal is too big and feature-y.)

- -

To be precise, here's the delta-spec (I was too shy to overwrite the wiki because it talks about "My Solution" but feel free to copy this text there):

When a script element node is created, if it is being flagged as parser-inserted, set its force-async flag to false. Otherwise, set its force-async flag to true. (Note that createContextualFragment, innerHTML and XSLTProcessor::transformToFragment-created scripts are not flagged as parser-inserted.) This flag setting happens before any attributes (even parser-set ones) are set on the node.

When a previously-created script element node loses its parser-insertedness, if the element doesn't have the async content attribute, set the force-async flag to true and false otherwise.

When a script element node obtains the async content attribute (via setAttribute, setAttributeNode, setAttributeNS, by the fragment parser or the XSLTProcessor adding the attribute, etc.), set the force-async flag to false. (Note that calling removeAttribute("async") doesn't modify the force-async flag.)

The async IDL attribute must behave as follows:
 * Upon setting, set the force-async flag to false and then reflect the async content attribute.
 * Upon getting, if the force-async flag is true, return true. Otherwise, reflect the async content attribute.

In step 13. of http://www.whatwg.org/specs/web-apps/current-work/#running-a-script before the case "If the element has a src attribute" add a case:
If the script has a src attribute and the async IDL property getter returns false,
The element must be added to the queue of ordered script-inserted external scripts of the Document of the script element at the time the running a script algorithm started.

The task that the networking task source places on the task queue once the fetching algorithm has completed must run these steps:
 1) If the queue of ordered script-inserted external scripts is empty or the first script in the queue of ordered script-inserted external scripts has not been fetched yet, abort these steps.
 2) Execute the first script in the queue of ordered script-inserted external scripts.
 3) Remove the first script from queue of ordered script-inserted external scripts.
 4) Goto step #1.

Modify step 5 of  http://www.whatwg.org/specs/web-apps/current-work/#the-end to say:
Spin the event loop until the set of scripts that will execute as soon as possible is empty and the queue of ordered script-inserted external scripts is empty.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 9 November 2010 09:42:43 UTC