Re: Executing script-inserted external scripts in insertion order

Jonas Sicking wrote:
> I do however agree that preserving order has other benefits. In
> particular it makes evaluation much more consistent and much less
> prone to racy behavior that depends on network speed of one vs.
> another script. 

I think the above is true for enforcing insertion order execution for external scripts.

However, rather counter-intuitively, one can construct a case where it's not true that enforcing the order of script-inserted inline and external scripts relative to each other leads to less racy behavior: Suppose a site uses a script-inserted inline script to evaluate script text in the global scope. Now suppose that code is called from an event handler. Now the behavior of that event handler differs depending on whether there's a pending external script, so the the network speed may affect results.

Also, I don't think there's much non-raciness benefit from blocking parser-inserted scripts on pending script-inserted external scripts. Especially with speculative parsing, with fast networks that Web authors use, the upcoming parser-inserted script will be ready to go by the time the <script> tag will be processed. OTOH, it's unlikely that the script that triggered a load for a script-inserted external script manages to do so much computation without yielding to the event loop that the script downloads before the script that triggered the fetch yields to the event loop. Thus, with script-inserted external scripts not blocking parser-inserted scripts, Web authors will see the case where the parser-inserted script executes before the script-inserted script so often that they will notice it and be forced to make their code work despite the potential race condition.

> This was the main reason I originally implemented
> enforced evaluation order in Firefox many years ago.

I now wish you had cloned whatever the first mover (IE) did as the default behavior. :-/

> Agreed. Whichever default we pick I think we need to make the other
> option available through some means. What means that should be
> probably depends on what we pick as the default.

I agree that executing script-inserted external scripts in order among themselves should be an option and executing script-inserted external scripts as soon as possible should be an option. Making the spec require the https://bugzilla.mozilla.org/show_bug.cgi?id=602838 behavior would provide that option--albeit in a non-capability-sniffable way.

I also agree that it makes sense to allow parser-inserted external scripts opt out of ordered execution using the async attribute.

I'm entirely unconvinced that maintaining execution order between script-inserted external scripts and parser-inserted scripts (so that the script-inserted script goes first and the parser-inserted script blocks) needs to be available at all.

I'm also doubting the necessity of having the option to make script-inserted inline scripts maintain order relative to script-inserted external scripts, even though I suggested it as part of my .ordered proposal, since if we had an explicit opt-in, providing this option would be easy. However, if we aren't doing .ordered, I'm not convinced we need to provide this option, since if a Web app wants to eval some text in the global scope after loading a set of external scripts, it can do so off the onload handler of the last one of those external scripts. The only case where value would be added is the case where the order is external, inline, external (all script-inserted that is). Seems a bit too special to me to support parallel download of the two externals here.

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

Received on Tuesday, 12 October 2010 10:37:04 UTC