The HTML parser synchronously creates custom elements

The HTML parser synchronously creates custom elements

This starts to make element creation match the HTML spec's "create an element for a token" steps <https://html.spec.whatwg.org/#create-an-element-for-the-token>; In particular, it starts running custom element constructors synchronously.

This changes the relationship between CustomElementsRegistry and V0CustomElementRegistrationContext. These objects have references to one another to prevent competing definitions in V0 and V1. CustomElementsRegistry have affinity to a window; V0CustomElementRegistrationContexts have affinity to documents. Previously the relationship between CustomElementsRegistry and V0CustomElementsRegistrationContext was 1:1, but that is inaccurate, because a window may replace its document. Now it is 1:M.

For the same reason this adds a pointer from the CustomElementsRegistry back to its owner LocalDOMWindow, instead of holding onto the window's document directly. Consequently CustomElementsRegistryTests have all become DummyPageHolder browser tests because they need windows.

BUG=594918
Committed: https://crrev.com/5ec3e5c806702bd96aad3920f02b9dddc997e41e
Cr-Commit-Position: refs/heads/master@{#411941}

[dominicc (has gone to gerrit), 2016-08-04 07:19:12]

The CQ bit was checked by dominicc@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-04 07:19:24]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-04 08:02:55]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-04 08:02:56]

Dry run: Try jobs failed on following builders:
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[dominicc (has gone to gerrit), 2016-08-04 09:06:12]

The CQ bit was checked by dominicc@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-04 09:06:19]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-04 09:55:14]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-04 09:55:15]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[dominicc (has gone to gerrit), 2016-08-05 00:39:26]

The CQ bit was checked by dominicc@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-05 00:39:48]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[dominicc (has gone to gerrit), 2016-08-05 02:04:28]

Description was changed from

==========
WIP custom element parser creation.

BUG=594918
==========

to

==========
The HTML parser synchronously creates custom elements

This tries to make element creation match the HTML spec's "create an element for
a token" steps <https://html.spec.whatwg.org/#create-an-element-for-the-token>
In particular, it starts running custom element constructors synchronously.

BUG=594918
==========

[dominicc (has gone to gerrit), 2016-08-05 02:04:28]

dominicc@chromium.org changed reviewers:
+ domenic@chromium.org, kojii@chromium.org, kouhei@chromium.org

[dominicc (has gone to gerrit), 2016-08-05 07:27:10]

The CQ bit was checked by dominicc@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-05 07:27:21]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[dominicc (has gone to gerrit), 2016-08-05 07:29:42]

PTAL

Bit concerned about perf, suggestions welcome.

kojii--custom elements stuff. We need to track the window, not the document,
because it could change as a blank iframe is navigated and we were caching it
too soon.
kouhei--parser stuff. Wonder if HTMLParserReentryPermit should be refcounted? I
tried integrating parserPauseFlag but there's some clean up of handling pending
parser blocking scripts that would need to happen first.
domenic--tests, spec conformance stuff.

This doesn't add the "block document.open, document.write" flag. But could add
that.

[dominicc (has gone to gerrit), 2016-08-05 08:12:36]

In particular, many parser perf tests use innerHTML, which doesn't go down this
path.

[domenic, 2016-08-05 08:39:51]

https://codereview.chromium.org/2200613002/diff/140001/third_party/WebKit/Lay...
File third_party/WebKit/LayoutTests/custom-elements/spec/parsing.html (right):

https://codereview.chromium.org/2200613002/diff/140001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/custom-elements/spec/parsing.html:22:
Array.prototype.forEach.call(document.querySelectorAll('iframe'), (f) => {
What does this function do? Returning from within a forEach won't do anything...
The fact this isn't breaking things might indicates problem with the test
running function :-/

https://codereview.chromium.org/2200613002/diff/140001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/custom-elements/spec/parsing.html:92: <template
data-test="remove during creation">
What is this testing? That removing works? (It's a broken test as above since
findFrameWithWindow will always return null, but I'm still a bit unsure what it
is testing.)

https://codereview.chromium.org/2200613002/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/html/parser/HTMLConstructionSite.cpp
(right):

https://codereview.chromium.org/2200613002/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/parser/HTMLConstructionSite.cpp:772: return
nullptr;
Might be good to add tests for this case too.

https://codereview.chromium.org/2200613002/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/parser/HTMLConstructionSite.cpp:778: return
nullptr;
When can this happen?

[commit-bot: I haz the power, 2016-08-05 08:43:29]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-05 08:43:30]

Dry run: This issue passed the CQ dry run.

[dominicc (has gone to gerrit), 2016-08-08 05:35:37]

The CQ bit was checked by dominicc@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-08 05:35:50]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-08 07:04:28]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-08 07:04:28]

Dry run: This issue passed the CQ dry run.

[kojii, 2016-08-08 07:47:31]

https://codereview.chromium.org/2200613002/diff/200001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/html/parser/HTMLConstructionSite.cpp
(right):

https://codereview.chromium.org/2200613002/diff/200001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/parser/HTMLConstructionSite.cpp:847: if
(!element) {
ScriptCustomElementDefinition::createElementSync, when you call without
ExceptionState, should handle this, including creating Failed element on
failure, so I think you can just DCHECK(element) here. The error reporting is
broken atm but we have a bug for it.

[dominicc (has gone to gerrit), 2016-08-08 07:58:56]

The CQ bit was checked by dominicc@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-08 07:59:06]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-08 08:07:19]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-08 08:07:20]

Dry run: Try jobs failed on following builders:
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)

[dominicc (has gone to gerrit), 2016-08-08 08:22:51]

The CQ bit was checked by dominicc@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-08 08:23:04]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-08 10:04:32]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-08 10:04:33]

Dry run: This issue passed the CQ dry run.

[dominicc (has gone to gerrit), 2016-08-15 01:30:55]

The CQ bit was checked by dominicc@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-15 01:31:07]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[dominicc (has gone to gerrit), 2016-08-15 01:33:15]

PTAL

domenic, kojii, I think all of your comments have been addressed.

https://codereview.chromium.org/2200613002/diff/140001/third_party/WebKit/Lay...
File third_party/WebKit/LayoutTests/custom-elements/spec/parsing.html (right):

https://codereview.chromium.org/2200613002/diff/140001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/custom-elements/spec/parsing.html:22:
Array.prototype.forEach.call(document.querySelectorAll('iframe'), (f) => {
On 2016/08/05 at 08:39:50, domenic wrote:
> What does this function do? Returning from within a forEach won't do
anything... The fact this isn't breaking things might indicates problem with the
test running function :-/

Oops. Fixed! :P

https://codereview.chromium.org/2200613002/diff/140001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/custom-elements/spec/parsing.html:92: <template
data-test="remove during creation">
On 2016/08/05 at 08:39:50, domenic wrote:
> What is this testing? That removing works? (It's a broken test as above since
findFrameWithWindow will always return null, but I'm still a bit unsure what it
is testing.)

I just figured this is something which could go wrong. I rewrote this so it at
least works; it's a bit involved. I'm not sure it is worth it as a spec test
now...

https://codereview.chromium.org/2200613002/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/html/parser/HTMLConstructionSite.cpp
(right):

https://codereview.chromium.org/2200613002/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/parser/HTMLConstructionSite.cpp:778: return
nullptr;
On 2016/08/05 at 08:39:50, domenic wrote:
> When can this happen?

This happens in two cases:

1. Custom elements V1 is not enabled.
2. Nothing has caused the creation of the registry yet. There can be no
definitions at this point.

https://codereview.chromium.org/2200613002/diff/200001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/html/parser/HTMLConstructionSite.cpp
(right):

https://codereview.chromium.org/2200613002/diff/200001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/parser/HTMLConstructionSite.cpp:847: if
(!element) {
On 2016/08/08 at 07:47:30, kojii wrote:
> ScriptCustomElementDefinition::createElementSync, when you call without
ExceptionState, should handle this, including creating Failed element on
failure, so I think you can just DCHECK(element) here. The error reporting is
broken atm but we have a bug for it.

Good point! Done.

[kojii, 2016-08-15 02:05:11]

lgtm

[kouhei (in TOK), 2016-08-15 02:10:31]

https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Lay...
File third_party/WebKit/LayoutTests/custom-elements/spec/parsing.html (right):

https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/custom-elements/spec/parsing.html:56: 'use
strict';
Nit: indent

https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/custom-elements/spec/parsing.html:78: return
document.documentElement;
add a comment why we are returning a documentElement here?
I suppose this is to force failure by not following "A return statement must not
appear anywhere inside the constructor body, unless it is a simple early-return
(return or return this)."

https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/custom-elements/spec/parsing.html:151: <template
data-test="non-destructive writes are not blocked">
maybe document why?
"Parser pause flag
(https://html.spec.whatwg.org/#creating-and-inserting-nodes:parser-pause-flag)"
is set to true during custom element ctor invocation

https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/custom/CustomElementsRegistry.cpp
(right):

https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/custom/CustomElementsRegistry.cpp:202: return
definition->descriptor() == desc ? definition : nullptr;
What are the cases where "definition->descriptor() != desc" happen?
Would you add a comment?

https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/custom/CustomElementsRegistry.h (right):

https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/custom/CustomElementsRegistry.h:32: class
CORE_EXPORT CustomElementsRegistry final
Optional: It would be nice if the object graph change here is documented in the
CL desc.

https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/custom/CustomElementsRegistryTest.cpp
(left):

https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/custom/CustomElementsRegistryTest.cpp:72:
CustomElementsRegistryTestBase::SetUp();
Would you note about this change in CL desc?
I suppose this is because v1 requires browsing context?

https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/html/parser/HTMLConstructionSite.cpp
(right):

https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/parser/HTMLConstructionSite.cpp:766: // and
HTML element creation is unified.
mention in a TODO about step 1?

https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/html/parser/HTMLParserReentryPermit.h
(right):

https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/parser/HTMLParserReentryPermit.h:37: class
HTMLParserReentryPermit final : public GarbageCollected<HTMLParserReentryPermit>
{
I really appreciate this refactoring!
I slightly prefer HTMLParserReentryPermit to not be Oilpan obj. I will try to
create a refactoring CL if the idea works out

[commit-bot: I haz the power, 2016-08-15 02:48:34]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-15 02:48:36]

Dry run: This issue passed the CQ dry run.

[dominicc (has gone to gerrit), 2016-08-15 04:12:36]

Description was changed from

==========
The HTML parser synchronously creates custom elements

This tries to make element creation match the HTML spec's "create an element for
a token" steps <https://html.spec.whatwg.org/#create-an-element-for-the-token>
In particular, it starts running custom element constructors synchronously.

BUG=594918
==========

to

==========
The HTML parser synchronously creates custom elements

This starts to make element creation match the HTML spec's "create an element
for a token" steps
<https://html.spec.whatwg.org/#create-an-element-for-the-token> In particular,
it starts running custom element constructors synchronously.

This changes the relationship between CustomElementsRegistry and
V0CustomElementRegistrationContext. These objects have references to one another
to prevent competing definitions in V0 and V1. CustomElementsRegistry have
affinity to a window; V0CustomElementRegistrationContexts have affinity to
documents. Previously the relationship between CustomElementsRegistry and
V0CustomElementsRegistrationContext was 1:1, but that is inaccurate, because a
window may replace its document. Now it is 1:M.

For the same reason this adds a pointer from the CustomElementsRegistry back to
its owner LocalDOMWindow, instead of holding onto the window's document
directly.

BUG=594918
==========

[dominicc (has gone to gerrit), 2016-08-15 04:14:11]

Description was changed from

==========
The HTML parser synchronously creates custom elements

This starts to make element creation match the HTML spec's "create an element
for a token" steps
<https://html.spec.whatwg.org/#create-an-element-for-the-token> In particular,
it starts running custom element constructors synchronously.

This changes the relationship between CustomElementsRegistry and
V0CustomElementRegistrationContext. These objects have references to one another
to prevent competing definitions in V0 and V1. CustomElementsRegistry have
affinity to a window; V0CustomElementRegistrationContexts have affinity to
documents. Previously the relationship between CustomElementsRegistry and
V0CustomElementsRegistrationContext was 1:1, but that is inaccurate, because a
window may replace its document. Now it is 1:M.

For the same reason this adds a pointer from the CustomElementsRegistry back to
its owner LocalDOMWindow, instead of holding onto the window's document
directly.

BUG=594918
==========

to

==========
The HTML parser synchronously creates custom elements

This starts to make element creation match the HTML spec's "create an element
for a token" steps
<https://html.spec.whatwg.org/#create-an-element-for-the-token> In particular,
it starts running custom element constructors synchronously.

This changes the relationship between CustomElementsRegistry and
V0CustomElementRegistrationContext. These objects have references to one another
to prevent competing definitions in V0 and V1. CustomElementsRegistry have
affinity to a window; V0CustomElementRegistrationContexts have affinity to
documents. Previously the relationship between CustomElementsRegistry and
V0CustomElementsRegistrationContext was 1:1, but that is inaccurate, because a
window may replace its document. Now it is 1:M.

For the same reason this adds a pointer from the CustomElementsRegistry back to
its owner LocalDOMWindow, instead of holding onto the window's document
directly. Consequently CustomElementsRegistryTests have all become
DummyPageHolder browser tests because they need windows.

BUG=594918
==========

[dominicc (has gone to gerrit), 2016-08-15 04:37:20]

The CQ bit was checked by dominicc@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-15 04:37:28]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[dominicc (has gone to gerrit), 2016-08-15 04:42:56]

The CQ bit was checked by dominicc@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-15 04:43:08]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[dominicc (has gone to gerrit), 2016-08-15 04:51:52]

Thanks for the feedback. All done--PTAL. A couple of comments inline.

On 2016/08/15 at 02:10:31, kouhei wrote:
>
https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Lay...
> File third_party/WebKit/LayoutTests/custom-elements/spec/parsing.html (right):
> 
>
https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Lay...
> third_party/WebKit/LayoutTests/custom-elements/spec/parsing.html:56: 'use
strict';
> Nit: indent
> 
>
https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Lay...
> third_party/WebKit/LayoutTests/custom-elements/spec/parsing.html:78: return
document.documentElement;
> add a comment why we are returning a documentElement here?
> I suppose this is to force failure by not following "A return statement must
not appear anywhere inside the constructor body, unless it is a simple
early-return (return or return this)."
> 
>
https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Lay...
> third_party/WebKit/LayoutTests/custom-elements/spec/parsing.html:151:
<template data-test="non-destructive writes are not blocked">
> maybe document why?
> "Parser pause flag
(https://html.spec.whatwg.org/#creating-and-inserting-nodes:parser-pause-flag)"
is set to true during custom element ctor invocation
> 
>
https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Sou...
> File third_party/WebKit/Source/core/dom/custom/CustomElementsRegistry.cpp
(right):
> 
>
https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Sou...
> third_party/WebKit/Source/core/dom/custom/CustomElementsRegistry.cpp:202:
return definition->descriptor() == desc ? definition : nullptr;
> What are the cases where "definition->descriptor() != desc" happen?
> Would you add a comment?
> 
>
https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Sou...
> File third_party/WebKit/Source/core/dom/custom/CustomElementsRegistry.h
(right):
> 
>
https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Sou...
> third_party/WebKit/Source/core/dom/custom/CustomElementsRegistry.h:32: class
CORE_EXPORT CustomElementsRegistry final
> Optional: It would be nice if the object graph change here is documented in
the CL desc.
> 
>
https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Sou...
> File third_party/WebKit/Source/core/dom/custom/CustomElementsRegistryTest.cpp
(left):
> 
>
https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Sou...
> third_party/WebKit/Source/core/dom/custom/CustomElementsRegistryTest.cpp:72:
CustomElementsRegistryTestBase::SetUp();
> Would you note about this change in CL desc?
> I suppose this is because v1 requires browsing context?
> 
>
https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Sou...
> File third_party/WebKit/Source/core/html/parser/HTMLConstructionSite.cpp
(right):
> 
>
https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Sou...
> third_party/WebKit/Source/core/html/parser/HTMLConstructionSite.cpp:766: //
and HTML element creation is unified.
> mention in a TODO about step 1?

There's an old FIXME about this and I ended up adding TODOs in a couple of
places about it too. I've put the TODOs together. Here's how the next steps
could go; I'm not 100% sure how to break this up:

- Add an interface for form associated elements. Make HTMLImageElement and
FormAssociatedElement implement that. Parser calls it.
- Existing FormAssociatedElement can be renamed ListedElement, or maybe split
into two parts: form-associated/listed.
- Remove the "form" parameter from HTMLElement creation; it's not used any more.
- Put the foreign and HTML element creation code paths together the way they are
in the spec.
- Implement customized built-in elements <button is="x-foo"> <-- lot of other
work blocking this, eg bindings constructors

>
https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Sou...
> File third_party/WebKit/Source/core/html/parser/HTMLParserReentryPermit.h
(right):
> 
>
https://codereview.chromium.org/2200613002/diff/240001/third_party/WebKit/Sou...
> third_party/WebKit/Source/core/html/parser/HTMLParserReentryPermit.h:37: class
HTMLParserReentryPermit final : public GarbageCollected<HTMLParserReentryPermit>
{
> I really appreciate this refactoring!
> I slightly prefer HTMLParserReentryPermit to not be Oilpan obj. I will try to
create a refactoring CL if the idea works out

I've made this RefCounted. I think the script runner can outlive the parser when
it is finishing up, so they need to share ownership.

This reentry permit needs to be integrated more, but we can do it with small
patches. In particular, how Blink handles finishing up scripts and pending
parsing blocking scripts has some obvious/minor differences to the spec and I
think we can start there.

[kouhei (in TOK), 2016-08-15 04:55:20]

lgtm

[commit-bot: I haz the power, 2016-08-15 05:50:51]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-15 05:50:51]

Dry run: This issue passed the CQ dry run.

[dominicc (has gone to gerrit), 2016-08-15 05:54:19]

The CQ bit was checked by dominicc@chromium.org

[dominicc (has gone to gerrit), 2016-08-15 05:54:25]

The patchset sent to the CQ was uploaded after l-g-t-m from kojii@chromium.org
Link to the patchset: https://codereview.chromium.org/2200613002/#ps300001
(title: "Eliminate redundant TODOs.")

[commit-bot: I haz the power, 2016-08-15 05:54:32]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-15 06:07:13]

Committed patchset #16 (id:300001)

[commit-bot: I haz the power, 2016-08-15 06:09:18]

Description was changed from

==========
The HTML parser synchronously creates custom elements

This starts to make element creation match the HTML spec's "create an element
for a token" steps
<https://html.spec.whatwg.org/#create-an-element-for-the-token> In particular,
it starts running custom element constructors synchronously.

This changes the relationship between CustomElementsRegistry and
V0CustomElementRegistrationContext. These objects have references to one another
to prevent competing definitions in V0 and V1. CustomElementsRegistry have
affinity to a window; V0CustomElementRegistrationContexts have affinity to
documents. Previously the relationship between CustomElementsRegistry and
V0CustomElementsRegistrationContext was 1:1, but that is inaccurate, because a
window may replace its document. Now it is 1:M.

For the same reason this adds a pointer from the CustomElementsRegistry back to
its owner LocalDOMWindow, instead of holding onto the window's document
directly. Consequently CustomElementsRegistryTests have all become
DummyPageHolder browser tests because they need windows.

BUG=594918
==========

to

==========
The HTML parser synchronously creates custom elements

This starts to make element creation match the HTML spec's "create an element
for a token" steps
<https://html.spec.whatwg.org/#create-an-element-for-the-token> In particular,
it starts running custom element constructors synchronously.

This changes the relationship between CustomElementsRegistry and
V0CustomElementRegistrationContext. These objects have references to one another
to prevent competing definitions in V0 and V1. CustomElementsRegistry have
affinity to a window; V0CustomElementRegistrationContexts have affinity to
documents. Previously the relationship between CustomElementsRegistry and
V0CustomElementsRegistrationContext was 1:1, but that is inaccurate, because a
window may replace its document. Now it is 1:M.

For the same reason this adds a pointer from the CustomElementsRegistry back to
its owner LocalDOMWindow, instead of holding onto the window's document
directly. Consequently CustomElementsRegistryTests have all become
DummyPageHolder browser tests because they need windows.

BUG=594918

Committed: https://crrev.com/5ec3e5c806702bd96aad3920f02b9dddc997e41e
Cr-Commit-Position: refs/heads/master@{#411941}
==========

[commit-bot: I haz the power, 2016-08-15 06:09:19]

Patchset 16 (id:??) landed as
https://crrev.com/5ec3e5c806702bd96aad3920f02b9dddc997e41e
Cr-Commit-Position: refs/heads/master@{#411941}