[whatwg] Script preloading

[Jonas Sicking]

On Mon, Jul 22, 2013 at 4:01 PM, Kyle Simpson <getify at gmail.com> wrote:
>> Do you have a link to your preload proposal?
>
> My main `<script preload>` proposal (skip the first section of this LONG email, proposal starts at "Summary:" several paragraphs down):
>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-July/039973.html
>
> Then proposal slightly amended here:
>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-July/039974.html
>
>
>
>> Either way, I agree about the concern with onload. I personally have a
>> hard time telling if it'll be confusing.
>>
>> Having the load event anytime we are done with a network request also
>> seems beneficial. Rather than having most APIs use "load" whereas this
>> would use "preload".
>
> FWIW, I believe script loaders, at least as I envision them, would use BOTH the `onpreload` AND the `onload` events, since marking a script as ready-to-execute, however that's done, is unlikely to be a synchronouse event, so the script loader would still want to listen for when it finished running (hopefully pretty soon after being told it's OK to run!? :)

In the noexecute proposal I believe that .execute() would be a
synchronous operation. Though we could change it to be an asynchronous
operation if that's desired. In which case I agree that we need some
sort of notification once the script has run.

>> There are three opportunities to fire "error stuff" here:
>>
>> 1. Failed network request
>> 2. Failed JS compilation
>> 3. Exception thrown from execution
>>
>> And there are two error reporting mechanisms in play
>>
>> A. Fire an "error" event on the <script> element.
>> B. Fire the window.onerror callback (like an event, but not exactly the same).
>
> Agreed. `window.onerror` serves fine case #3. What we don't seem to have as consistent cross-browser behavior, or even terribly well defined in the spec, is #1 and #2, especially #1. Various older browsers had different interpretations as to which network conditions constituted "load complete" or not.
>
> Obviously, the 200 (and several other 2xx's) should be success. And I'd think it would be obvious that any of the 4xx and 5xx codes were error.
>
> But perhaps it should just be: did the network request result in a non-empty payload?
>
> Now, for #2, to my non-implementor eye, that seems pretty well definable too. But again, cross-browser mayhem was bad with this. IIRC, Opera fired the onerror in the case of bad compilation, but none of the others did. Or maybe it was vice versa. Been awhile since I looked specifically. Just for sure recall inconsistency here.

Given that compatibility with existing content is the main issue here.
I think finding out where different UAs are consistent, and where they
are not is the first step here.

>> I'm not sure if that includes firing
>> both A and B in current browsers?
>
> They do not seem to fire `window.onerror` in either #1 or #2 IIRC, but they do in #3.
>
> If I could have it my way, I'd have all three errors firing on the script.onerror, and not involve window.onerror. The reason is because `window.onerror` is notoriously hijacked by various RUM libraries and such, to do remote logging of errors, so a script loader attaching to window.onerror and catch is not terribly reliable in my experience.

Well, a script loader shouldn't really care about #3, should it? At
that point the script loader has fulfilled its responsibility.

Having #1 and #2 cause A to happen, and #3 cause B to happen, then I
think that's a pretty good state of affairs.


>> Indeed. Though we're only talking about the A mechanism about, right?
>
> Correct. Although in an ideal world (for me), B would be more reliable, as noted above.

I thought the above asked for A to be more reliable? Also, "more
reliable" probably is in the eye of the beholder. So rather than
talking about what's "more reliable" and "less reliable" it's better
to talk about specific behaviors.

>> I.e. the following would cause both a "load" event to be fired on the
>> <script>, and window.onerror to be triggered?
>>
>> <script src="data:text/plain,throw new Error();"></script>
>
> Sure. Though as noted, script loaders may have limited utility of window.onerror when they run in unfamiliar/hostile pages which already hijack that error.

Ideally they can always call window.addEventListener("error", ...),
but apparently that doesn't always work. Not sure what specs say
though.

/ Jonas