[whatwg] Proposal for separating script downloads and execution

[Boris Zbarsky]

On 2/22/11 3:07 PM, Kyle Simpson wrote:
> Look above at what Will says... he says "before a URL loads" in (a). I
> interpreted that to mean that if I make two requests in rapid fire
> succession, and the browser hasn't yet gotten the response headers (from
> the first request) to tell it not to cache, then it makes sense from an
> optimization standpoint that IE would see the two simultaneous URL
> requests as the same and assume to only load once instead of twice.

That's a violation of HTTP semantics, yes.  A convenient way to write 
the code, but a violation of HTTP semantics.

> Again, maybe I'm missing something, but the way Will describes it sounds
> perfectly reasonable to me. It might be slightly on the aggressive side,
> but I don't see how that, as described, is violating the HTTP caching
> semantics.

Trivially.  If it's not in your cache at all, you're supposed to make a 
request to the server!  If you're not doing that, then you're not 
implementing HTTP.

> I don't see that those semantics imply that a browser must
> wait to fully receive response-headers from a first request before
> deciding what to do with a second request of the same URL.

Right.  They just imply that you need to send the second request.  Or 
wait for the first to come and then decide whether to send it.  Or 
_something_ that looks like what HTTP is supposed to look like.

What _this_ looks like is that there's a non-HTTP cache of in-progress 
loads that can serve to coalesce said in-progress loads.  That gives 
behavior that's invalid per HTTP and inherently racy in a bad way.

>> Because it's the easy way to do it; we had to jump through some hoops
>> in Gecko to make sure an async XHR stays alive until it fires its last
>> readystate change event when no one is holding a ref to the XHR object.
>
> Right, but in that case, the XHR object has a circular reference to
> itself via the closure of the handler function (assuming it was an
> assigned anonymous or in-scope function that was assigned).

Sure.

> I was just saying that in the case of actual DOM elements, when a circular
> reference is created between the DOM element and a JS counter-part,
> through the closure of a handler assigned to the element, I assumed this
> was enough to avoid GC.

Circular references can't be enough to avoid GC.  The whole point of 
having a GC is to be able to collect entire subgraphs of the object 
graph that are not rooted.  And you have to be able to collect cyclic 
subgraphs; otherwise you might as well use reference counting instead of 
a GC.

> I recall in older IE days avoiding stuff like:
>
> var script = document.createElement("script");
> script.theobj = script;
>
> Because this created a circular reference, and thus a memory-leak, if
> you didn't forcibly unset before unload the `theobj` reference to break
> the circular ref.

Yes, that would be due to the fact that GC was used on the JS side and 
"something else" on the C++ side and the expando caused the script to be 
a GC root.  Other browsers have had similar bugs too.  Those are just 
bugs to fix.  A GC should be able to collect the above.

>> Well... no. You could grab the ref in the onreadystatechange handler.
>
> In the most rudimentary of cases, and only assuming the
> `onreadystatechange` handler actually had a closure reference to the
> script element...

|this| is the script element in the onreadystatechange handler, I would 
think.  So it _always_ has a reference to the script element.  Just like 
the XHR onreadystatechange case.

> he can't just daisy-chain off the handlers, he needs to actually have a
> reference kept for each script element, so that he can specifically
> execute each one in their proper order.

Yes, but it could just grab those references as the scripts load.  In 
any way, this is a side-issue; my main question has been answered: IE 
both shows bad memory behavior _and_ fails to implement HTTP semantics 
for script preloads done in this way.

-Boris

-Boris