[Webkit-unassigned] [Bug 50115] New: Need different behavior for ensuring execution order of dynamically loaded scripts

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=50115

           Summary: Need different behavior for ensuring execution order
                    of dynamically loaded scripts
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
               URL: http://wiki.whatwg.org/wiki/Dynamic_Script_Execution_O
                    rder
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Page Loading
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: getify at gmail.com


Summary:

There is an informal W3C proposal being discussed for addressing a now-broken-in-Webkit use-case for dynamic script loading (in parallel) with ordered execution for dependencies. Mozilla has implemented the proposal in their nightlies (to address a recent similar breakage in FF4), and the request is that Webkit consider doing the same.


Back-story:

There is a need for dynamic script loaders (like LABjs http://labjs.com) to be able to dynamically load multiple script resources in parallel, but ensure that they execute in order (for dependency sake). For instance, for performance, one may desire to load jQuery, jQuery-UI, and all your plugins (in one file), each of these 3 files loaded in parallel, but executed in order (must be for depedencies).

Dynamic script loaders like LABjs need to be able to load such scripts on-demand (meaning later in the page lifetime, after the parser has finished), and also they need to be able to load any script that the author doesn't control (meaning they can't change the contents), and finally they need to be able to load such scripts from remote-domain locations (like CDN's). When you combine all these factors, "on-demand-parallel-load-serial-execute" becomes a pretty challenging feature.

Up until recently, LABjs has exploited some quirks of various browsers (non-HTML5 standard) to achieve this ability in all browsers. In IE and Webkit, LABjs has taken advantage of the non-standard behavior that a script-tag with an unrecognized mime-type like "script/cache" will still be loaded into cache, and the load event fired when complete, but the script wouldn't be executed. By fetching a group of scripts in parallel *only into cache* and being notified of the load events for all of them, LABjs could then wait for all scripts to load into cache, and then make a second pass through the list to load each (pratically synchronously/immediately) from the cache, by making a new script tag with the proper "text/javascript" type value.

This is obviously a big hack to get around the fact that in IE and Webkit, dynamically loaded scripts will fire as-soon-as-possible and there's no way to get the execution order to be in insertion order. In addition to being non-standard, this hack is brittle in that the resources in question must be served with proper caching headers (LOTS of javascript files on the web are not), or the hack breaks down and results in non-ordered and double-loaded behavior.

Nevertheless, it's been the only available feature for achieving parallel-load-serial-execute in IE and Webkit. Until the recent change made by Webkit nightly, which stops fetching scripts if the script-tag mime-type is unrecognized. This change essentially means that LABjs' technique is completely broken in Webkit now, and moreover, there's no way in Webkit for LABjs to achieve the desired loading functionality.

A similar breakage (although for a different reasoning) happened recently in FF4 nightlies/beta7. Working with the W3C (public-html list), and the Mozilla developers, an informal proposal has been discussed for changing the HTML5 spec to accomodate the need for this loading functionality.

You can read more about it here:

http://wiki.whatwg.org/wiki/Dynamic_Script_Execution_Order

http://hsivonen.iki.fi/script-execution/

---------------------------

So, the request is that Webkit also implement the current main (informal) proposal to the W3C in the same way that Mozilla has, to restore the ability for dynamic script loaders to serve this use-case in Webkit-based browsers.

The proposal basically preserves Webkit (and IE)'s current default behavior, but in a more formalized and flexible way, which is that any script inserted dynamically will essentially default to behaving like a parser-inserted script with `async=true`.

The requested extension is that a dynamically inserted script tag which has `async=false` set on it will go into a separate loading "queue" of sorts, in that all such scripts with `async=false` will load in parallel but will execute in insertion order.

This proposal has a sort of simple symmetry to it, in that it's basically making dynamically inserted scripts be able to have the same behaviors available to it as a parser-inserted script. By changing async to `true` or `false`, the author controls if they want "as-soon-as-possible execution" or "insertion-order execution". For parser-inserted scripts, the author already has that control (by setting or not setting `async`), so the request is that the author have the same control over script-inserted scripts as well.

By defaulting inserted scripts to having `async=true`, it is felt a greater amount of compat with previous content will be achieved (especially for existing IE/Webkit content). Moreover, by defaulting the `async` property of a dynamically inserted script to `true`, a feature-test is then obvious and possible for this new ordered execution behavior.

As stated earlier, this behavior has now been implemented in FF 4b8pre (nightlies), and LABjs 1.0.4 now takes advantage of it via the feature-test described. If Webkit were to implement the proposal as requested, such behavior would immediately be found and used, in favor of the previous hacky mime-type caching trick.

---------------------------

For the record, at the moment, LABjs (and any script loader which tries to do parallel loading of resources that have execution order dependencies) is *broken* in Webkit nightlies. The desire is to address this problem before the Webkit nightly/trunk is absorbed into a major release of any Webkit browser (Chrome, Safari, etc), which would break a lot of sites currently using such techniques via LABjs or other loaders.

I respectfully request that Webkit consider implementing the informal W3C proposal as described above.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.