Bug 24042 - [imports]: Parser should not wait on external resources inside imports
Summary: [imports]: Parser should not wait on external resources inside imports
Status: RESOLVED MOVED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on: 24808
Blocks: 23278
  Show dependency treegraph
 
Reported: 2013-12-09 22:49 UTC by Elliott Sprehn
Modified: 2015-07-06 08:08 UTC (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Elliott Sprehn 2013-12-09 22:49:17 UTC
The HTML parser should continue tree building inside an import even if blocked on an external resource.

As a result document.write() should also throw when the currentScript is inside an import since the location of the write is arbitrary.

The result of this is that given:

<link rel="import" href="1.html">
<script src="slow.js"></script>
<link rel="import" href="2.html">
<link rel="import" href="3.html">
<x-foo></x-foo>
<script>
  console.log(1);
</script>

While slow.js is being downloaded the entire import tree (1.html, 2.html and 3.html) can be processed and constructed into DOM trees. When it finishes loading the scripts that were queued while tree building these nested imports and the top level import with the console.log should be executed in order. This is conceptually similar to defer@ or async@ on <script>.
Comment 1 Boris Zbarsky 2013-12-10 02:53:10 UTC
It's not just document.write, is it?

When slow.js runs, can it tell whether 2.html has been loaded?  If so, it'll see a somewhat non-deterministic view of the DOM...

I guess @async scripts have some of that behavior too, though.
Comment 2 Elliott Sprehn 2013-12-10 03:00:30 UTC
(In reply to Boris Zbarsky from comment #1)
> It's not just document.write, is it?
> 
> When slow.js runs, can it tell whether 2.html has been loaded?  If so, it'll
> see a somewhat non-deterministic view of the DOM...
> 
> I guess @async scripts have some of that behavior too, though.

Yes, @async already has this behavior.

You will always have a non-deterministic view of the main document from an import since it doesn't block the parser as we treat imports like stylesheets not script when parsing. We're extending that behavior to the entire import tree.

The reason to throw in document.write() is that it prevents depending on the tokens being inserted in any particular place. I'm not sure why <script async> doesn't throw when you document.write(), we probably should have made it do so.
Comment 3 Boris Zbarsky 2013-12-10 03:09:11 UTC
> I'm not sure why <script async> doesn't throw when you document.write()

It just silently does nothing instead, presumably because that's less likely to totally break preexisting scripts that someone asyncfiies.

Which is also what document.write() does on a random document that's not being shown, actually.

The only case right now in which document.write() throws is if the document is XML.
Comment 4 Elliott Sprehn 2013-12-10 03:43:25 UTC
(In reply to Boris Zbarsky from comment #3)
> > I'm not sure why <script async> doesn't throw when you document.write()
> 
> It just silently does nothing instead, presumably because that's less likely
> to totally break preexisting scripts that someone asyncfiies.
> 

I'm fine if we make this a no-op in imports to match that.
Comment 5 Morrita Hajime 2014-02-11 01:03:38 UTC
Renaming the subject to reflect the discussion, and land the fix.

https://github.com/w3c/webcomponents/commit/3a2ac114606bb80df5aa5aae047ae3342cc06339
Comment 6 Anne 2014-02-11 13:14:42 UTC
Please file bugs https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WHATWG&component=HTML to make sure this gets properly integrated and reviewed by the editor of the HTML specification. Monkey patching without actually involving Ian is not the right way to go about this.
Comment 7 Anne 2014-02-11 13:16:00 UTC
Also, your fix seems wrong. What if I had changed currentScript to throw on getting?
Comment 8 Morrita Hajime 2014-02-11 19:32:24 UTC
(In reply to Anne from comment #6)
> Please file bugs
> https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WHATWG&component=HTML
> to make sure this gets properly integrated and reviewed by the editor of the
> HTML specification. Monkey patching without actually involving Ian is not
> the right way to go about this.

(In reply to Anne from comment #7)
> Also, your fix seems wrong. What if I had changed currentScript to throw on
> getting?

Thanks for the catch. Will file a bug.
The discussion will lead the right way to spec this.
Would you mind to drop some link to the bug which asks this kind of thing?
I'd like to learn how to discuss monkey patch in HTML land.
Comment 9 Anne 2014-02-12 11:22:05 UTC
I see you filed the bug yourself, thanks!

In general we should avoid monkey patching. 1) A specification may not be aware of the patches being applied and invalidate them. 2) Readers of a specification may not be aware of the patches being applied and write code that turns out to be wrong due to patches. 3) If patches start getting applied from multiple sources the mental model quickly becomes too hard and mistakes start creeping in all over.
Comment 10 Morrita Hajime 2014-02-12 18:33:41 UTC
(In reply to Anne from comment #9)

> In general we should avoid monkey patching. 1) A specification may not be
> aware of the patches being applied and invalidate them. 2) Readers of a
> specification may not be aware of the patches being applied and write code
> that turns out to be wrong due to patches. 3) If patches start getting
> applied from multiple sources the mental model quickly becomes too hard and
> mistakes start creeping in all over.

Agreed.

We have some more monkey patches in the import spec.
I filed Bug 24632 to track these.
Although I'm not sure if we can completely get rid of them,
it will be good idea to make these glitches visible.
Comment 11 Adam Klein 2014-02-14 23:09:43 UTC
http://www.whatwg.org/specs/web-apps/current-work/#execute-the-script-block step 2.3 seems like the thing that needs to be fixed (the ignore-destructive-writes-counter needs to be incremented for imported scripts).
Comment 12 Morrita Hajime 2014-02-25 18:46:25 UTC
Recovering the original summary line.
Will file new one for document.write() thing.
Comment 13 Morrita Hajime 2014-04-15 18:16:55 UTC
Moving this to future considerations. 

The source of incompatibility risk (Bug 24808) is killed, 
so it's safe to postpone this.
Comment 14 Hayato Ito 2015-07-06 08:08:09 UTC
Moved to https://github.com/w3c/webcomponents/issues/221