Parser-created "sync" custom elements push the construction stack when they shouldn't |
||
Issue descriptionToT r439712 seems broken. The web platform test custom-elements/parser/parser-uses-constructed-element.html has other bugs, but the intent of the test seems to be that the parser uses the return value of custom element constructors and not any other element. Here's how you would reach this behavior: 1. "create an element for the token" [1] will call create element with the synchronous custom elements flag set. 2. "create element" [2] will reach step 6.1.2. Note there's no pushing and popping the construction stack on these paths. It seems we're creating the element ahead of time so we can create it in an import document. r414434 may have regressed this. [1] https://html.spec.whatwg.org/#create-an-element-for-the-token [2] https://dom.spec.whatwg.org/#concept-create-element
,
Dec 22 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/85393cb1a42b466e08b54cdb900a880c1742bb7b commit 85393cb1a42b466e08b54cdb900a880c1742bb7b Author: dominicc <dominicc@chromium.org> Date: Thu Dec 22 07:56:45 2016 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 Cr-Commit-Position: refs/heads/master@{#440358} [modify] https://crrev.com/85393cb1a42b466e08b54cdb900a880c1742bb7b/third_party/WebKit/LayoutTests/custom-elements/spec/construct.html [modify] https://crrev.com/85393cb1a42b466e08b54cdb900a880c1742bb7b/third_party/WebKit/LayoutTests/imported/wpt/custom-elements/parser/parser-uses-constructed-element-expected.txt [modify] https://crrev.com/85393cb1a42b466e08b54cdb900a880c1742bb7b/third_party/WebKit/Source/bindings/core/v8/ScriptCustomElementDefinition.cpp [modify] https://crrev.com/85393cb1a42b466e08b54cdb900a880c1742bb7b/third_party/WebKit/Source/bindings/core/v8/ScriptCustomElementDefinition.h
,
Dec 22 2016
|
||
►
Sign in to add a comment |
||
Comment 1 by dominicc@chromium.org
, Dec 21 2016