Custom element constructor 'requirements' are checked too late for parser-created elements |
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3047.0 Safari/537.36 Steps to reproduce the problem: 1. Use an inline script to synchronously define an element with a constructor that adds a promise resolution callback (`then`) to a resolved promise and sets an attribute on itself in this callback. 2. Use that element in the page somewhere after the definition. What is the expected behavior? The element is constructed successfully and the attribute is set on the element in a microtask after the constructor. What went wrong? An error is thrown at some point after both the constructor has completed and the microtask which sets the attribute on the element. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 59.0.3047.0 Channel: canary OS Version: OS X 10.12.3 Flash Version: This only seems to apply to elements that are being created by the parser that are both not a result of any script and are being constructed at the time they are created (i.e. not upgraded). For example, setting some other element's `innerHTML` to a string containing a defined custom element of the kind mentioned in the repro steps does not exhibit this issue.
,
Mar 22 2017
Thanks for filing this. Step 6.4 of https://dom.spec.whatwg.org/#concept-create-element is what generates this error. We implement this in CustomElementDefinition::checkConstructorResult. FWIW I did not see Safari report an error there. I think the questions here are: 1. Is Blink running the Promise job queue at the right time, or should it be later? 2. If Blink is running the Promise job queue at the right time, should the author requirements be changed to mention not just constructors but all the work they entail before returning? Either way it would be nice to have a web platform test for this. It's just not clear to me what it should assert.
,
Mar 22 2017
Domenic, do you know precisely when Promise.resolve().then in a custom element constructor should run?
,
Mar 22 2017
,
Mar 23 2017
During parsing, I believe it will run either the next time a custom element is encountered, due to step 6.2 of https://html.spec.whatwg.org/#create-an-element-for-the-token, or once the custom element callbacks happen for the being-parsed element, which is at step 9.2 of https://html.spec.whatwg.org/#create-an-element-for-the-token. (The latter is via https://html.spec.whatwg.org/#invoke-custom-element-reactions step 2 calling into https://heycam.github.io/webidl/#es-invoking-callback-functions whose step 18.2 calls into https://html.spec.whatwg.org/#clean-up-after-running-script whose step 4 will run the microtask checkpoint.) This seems a little strange to me; Blink's behavior might be more correct than the spec. In particular I think we should be running the microtask checkpoint after step 6.2 of https://dom.spec.whatwg.org/#concept-create-element. I would not be surprised if Blink had some mechanism for doing this automatically which is getting triggered.
,
Mar 23 2017
This actually ties into a spec discussion we were having recently, but I did not realize was related: https://github.com/whatwg/html/issues/2381#issuecomment-288613108 So I think this is a spec bug and Blink is working as intended. We should fix the spec and write tests (which Blink will pass). We could also make a note about it in custom element conformance.
,
Mar 31 2017
This has been fixed on the spec side, with no change in Blink (working as intended). We have submitted a web platform test so hopefully Safari will follow soon.
,
Aug 2
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by bickne...@google.com
, Mar 21 2017