[Bug 24658] [imports]: The fetch readiness shouldn't block fetching.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24658

--- Comment #4 from Gabor Krizsanits <gkrizsanits@mozilla.com> ---
(In reply to Morrita Hajime from comment #2)
> Assuming all imports are written in this style and we don't block on imports
> (only block on <script>), we can fetch subimports as soon as we receive
> imports bytestream and started parsing them. We could possibly request all
> requested imports and stylesheets without blocking any. This maximizes the
> concurrency and minimizes the delay.

Just one thing... If imports look like this those scripts will be executed even
if the sub imports are failed to be loaded... If you want to hook up an onload
function on the import link element, the definition of that onload function
should be in a script before the subimports in the DOM.

<head>
<script>function runMe(){..}</script>
<link rel=import ... onload="runme()">

But I might be overlooking something trivial...

> But there are strong demand to make this fast. After all, speed is one of
> the justification why we want HTML Imports.
> 
> So let's make it work somehow.

I very much agree with all this, that's why I brought up this idea, it just
made my head exploded a bit yesterday to think over all the edge cases :) But,
yes, let's try to make this work.

> In my understanding, <script> behaves like that way because the script
> execution should be completely serialized and the order should be
> deterministic. <link rel=stylesheet>, on the other hand, behaves
> differently. There is no loader ordering constraint for stylesheet, so it is
> loaded as it is available.
> 
> HTML import is a mix of these two. As long as parser doesn't see <script>,
> there is no order constraint. Once it sees any script, it blocks until the
> newly introduced order constraint is resolved.

Thanks for this explanation, I think I need to read up on this a bit more.

> At the same time, it might be clearer to make it explicit that when we
> recompute the readiness and unblock parsers. As you are suggesting, it would
> be when each import finished loading.

Yes, exactly this is my point. So if I understand correctly we want to
guarantee a sane script execution order, and block only things that really
needs to be blocked for it. So how about this:

Script execution can be blocked in an import two ways, either internally during
parsing it when a script or an import tag is found, or externally, before even
we begin parsing it, because there is another import in the tree that has to be
finished first. This later what we really have to define and deal with more
now, since the parser will take care of the other first kind of blocking.

Instead of that list we could just build up this tree of links whose imports
might be blocking an external import (a link that is not in their sub import
tree). So when an import is finished loading we remove it from this tree, and
check if the left most leaf (we call first child in this tree until we find a
leaf I mean) in this tree can/has to be unblocked. Kind of equivalent with the
list version but I find it easier to wrap my head around, so I though it worth
to be shared.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 14 February 2014 19:03:58 UTC