Do not push the custom element construction stack in some cases.

Do not push the custom element construction stack in some cases.

The custom element construction stack arranges rendezvous between an
existing element and the super() call in a custom element constructor,
for example when doing "upgrade".

Blink had been pushing the construction stack as a way to get imports
created in the right (import) document, even when that element is
created by createElement or by the parser in "synchronous custom
elements" mode (for example, parsing import documents, not fragments).

This caused us to fail the spirit of the
imported/wpt/custom-elements/parser/parser-uses-constructed-element.html
tests. Note that test is itself buggy; I am fixing that upstream in
https://github.com/w3c/web-platform-tests/pull/4373

Unfortunately, there's still the question of what to do for elements
in import documents. For now I have left the behavior unchanged by
special casing imports, which means elements in import documents will
keep the subtly non-compliant behavior in recursive creation cases.
Another possible approach would be to create the elements in the main
document but then adopt them into the import document. This would at
least be "explained" by the adoptedCallback.

This change is covered by our tests in
custom-elements/spec/construct.html

BUG=676232
Committed: https://crrev.com/85393cb1a42b466e08b54cdb900a880c1742bb7b
Cr-Commit-Position: refs/heads/master@{#440358}

[dominicc (has gone to gerrit), 2016-12-21 06:17:54]

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

[commit-bot: I haz the power, 2016-12-21 06:18: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-12-21 06:18:26]

dominicc@chromium.org changed reviewers:
+ blink-reviews-bindings@chromium.org, kojii@chromium.org

[dominicc (has gone to gerrit), 2016-12-21 06:18:27]

blink-reviews-bindings: PTAL bindings/...
kojii: PTAL

[commit-bot: I haz the power, 2016-12-21 07:40:14]

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

[commit-bot: I haz the power, 2016-12-21 07:40:15]

Dry run: This issue passed the CQ dry run.

[haraken, 2016-12-21 07:43:57]

haraken@chromium.org changed reviewers:
+ haraken@chromium.org

[haraken, 2016-12-21 07:43:57]

bindings/ LGTM

https://codereview.chromium.org/2589383002/diff/1/third_party/WebKit/Source/b...
File
third_party/WebKit/Source/bindings/core/v8/ScriptCustomElementDefinition.cpp
(right):

https://codereview.chromium.org/2589383002/diff/1/third_party/WebKit/Source/b...
third_party/WebKit/Source/bindings/core/v8/ScriptCustomElementDefinition.cpp:206:
{

This clause looks redundant.

[dominicc (has gone to gerrit), 2016-12-22 03:47:57]

Remove redundant scope and rebase.

[dominicc (has gone to gerrit), 2016-12-22 03:48:01]

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

[commit-bot: I haz the power, 2016-12-22 03:48:18]

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

[kojii, 2016-12-22 04:31:08]

lgtm, the rniwa's test breaking our assumption is interesting ;)

[commit-bot: I haz the power, 2016-12-22 05:44:42]

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

[commit-bot: I haz the power, 2016-12-22 05:44:43]

Dry run: This issue passed the CQ dry run.

[dominicc (has gone to gerrit), 2016-12-22 07:53:22]

The CQ bit was checked by dominicc@chromium.org

[dominicc (has gone to gerrit), 2016-12-22 07:53:23]

The patchset sent to the CQ was uploaded after l-g-t-m from haraken@chromium.org
Link to the patchset: https://codereview.chromium.org/2589383002/#ps20001
(title: "Remove redundant scope and rebase.")

[commit-bot: I haz the power, 2016-12-22 07:53:38]

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-12-22 07:56:48]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1482393202514980,
"parent_rev": "65d86e54b787ef581ecdb5133d783adca5892c9c", "commit_rev":
"145b42b88b4bf29a2457224f426e994c52f2a7d0"}

[commit-bot: I haz the power, 2016-12-22 07:57:14]

Description was changed from

==========
Do not push the custom element construction stack in some cases.

The custom element construction stack arranges rendezvous between an
existing element and the super() call in a custom element constructor,
for example when doing "upgrade".

Blink had been pushing the construction stack as a way to get imports
created in the right (import) document, even when that element is
created by createElement or by the parser in "synchronous custom
elements" mode (for example, parsing import documents, not fragments).

This caused us to fail the spirit of the
imported/wpt/custom-elements/parser/parser-uses-constructed-element.html
tests. Note that test is itself buggy; I am fixing that upstream in
https://github.com/w3c/web-platform-tests/pull/4373

Unfortunately, there's still the question of what to do for elements
in import documents. For now I have left the behavior unchanged by
special casing imports, which means elements in import documents will
keep the subtly non-compliant behavior in recursive creation cases.
Another possible approach would be to create the elements in the main
document but then adopt them into the import document. This would at
least be "explained" by the adoptedCallback.

This change is covered by our tests in
custom-elements/spec/construct.html

BUG=676232
==========

to

==========
Do not push the custom element construction stack in some cases.

The custom element construction stack arranges rendezvous between an
existing element and the super() call in a custom element constructor,
for example when doing "upgrade".

Blink had been pushing the construction stack as a way to get imports
created in the right (import) document, even when that element is
created by createElement or by the parser in "synchronous custom
elements" mode (for example, parsing import documents, not fragments).

This caused us to fail the spirit of the
imported/wpt/custom-elements/parser/parser-uses-constructed-element.html
tests. Note that test is itself buggy; I am fixing that upstream in
https://github.com/w3c/web-platform-tests/pull/4373

Unfortunately, there's still the question of what to do for elements
in import documents. For now I have left the behavior unchanged by
special casing imports, which means elements in import documents will
keep the subtly non-compliant behavior in recursive creation cases.
Another possible approach would be to create the elements in the main
document but then adopt them into the import document. This would at
least be "explained" by the adoptedCallback.

This change is covered by our tests in
custom-elements/spec/construct.html

BUG=676232

Review-Url: https://codereview.chromium.org/2589383002
==========

[commit-bot: I haz the power, 2016-12-22 07:57:15]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-12-22 07:59:33]

Description was changed from

==========
Do not push the custom element construction stack in some cases.

The custom element construction stack arranges rendezvous between an
existing element and the super() call in a custom element constructor,
for example when doing "upgrade".

Blink had been pushing the construction stack as a way to get imports
created in the right (import) document, even when that element is
created by createElement or by the parser in "synchronous custom
elements" mode (for example, parsing import documents, not fragments).

This caused us to fail the spirit of the
imported/wpt/custom-elements/parser/parser-uses-constructed-element.html
tests. Note that test is itself buggy; I am fixing that upstream in
https://github.com/w3c/web-platform-tests/pull/4373

Unfortunately, there's still the question of what to do for elements
in import documents. For now I have left the behavior unchanged by
special casing imports, which means elements in import documents will
keep the subtly non-compliant behavior in recursive creation cases.
Another possible approach would be to create the elements in the main
document but then adopt them into the import document. This would at
least be "explained" by the adoptedCallback.

This change is covered by our tests in
custom-elements/spec/construct.html

BUG=676232

Review-Url: https://codereview.chromium.org/2589383002
==========

to

==========
Do not push the custom element construction stack in some cases.

The custom element construction stack arranges rendezvous between an
existing element and the super() call in a custom element constructor,
for example when doing "upgrade".

Blink had been pushing the construction stack as a way to get imports
created in the right (import) document, even when that element is
created by createElement or by the parser in "synchronous custom
elements" mode (for example, parsing import documents, not fragments).

This caused us to fail the spirit of the
imported/wpt/custom-elements/parser/parser-uses-constructed-element.html
tests. Note that test is itself buggy; I am fixing that upstream in
https://github.com/w3c/web-platform-tests/pull/4373

Unfortunately, there's still the question of what to do for elements
in import documents. For now I have left the behavior unchanged by
special casing imports, which means elements in import documents will
keep the subtly non-compliant behavior in recursive creation cases.
Another possible approach would be to create the elements in the main
document but then adopt them into the import document. This would at
least be "explained" by the adoptedCallback.

This change is covered by our tests in
custom-elements/spec/construct.html

BUG=676232

Committed: https://crrev.com/85393cb1a42b466e08b54cdb900a880c1742bb7b
Cr-Commit-Position: refs/heads/master@{#440358}
==========

[commit-bot: I haz the power, 2016-12-22 07:59:34]

Patchset 2 (id:??) landed as
https://crrev.com/85393cb1a42b466e08b54cdb900a880c1742bb7b
Cr-Commit-Position: refs/heads/master@{#440358}