+++ This bug was initially created as a follow-up of Bug #1299363 comment# 63 +++ After reviewing the all possible cases that may trigger upgrade steps in spec again (and also apply some local WIP patches to test), - customElements.define: https://html.spec.whatwg.org/multipage/scripting.html#dom-customelementregistry-define - document.createElement: https://dom.spec.whatwg.org/#dom-document-createelement - document.createElementNS: https://dom.spec.whatwg.org/#dom-document-createelementns - document.importNode: https://dom.spec.whatwg.org/#dom-document-importnode - document.write: https://html.spec.whatwg.org/multipage/webappapis.html#dom-document-write - document.writeln: https://html.spec.whatwg.org/multipage/webappapis.html#dom-document-writeln - Element.innerHTML: https://w3c.github.io/DOM-Parsing/#dom-element-innerhtml - Node.clone: https://dom.spec.whatwg.org/#concept-node-clone - create element from parser: https://html.spec.whatwg.org/multipage/syntax.html#create-an-element-for-the-token Most of API annotated with [CEReactions], excepts - document.createElement[NS] runs upgrade steps synchronously, instead of interacting with reaction queue. - parser bit has its own ReactionsStack push/pop. So the upgrade reactions should not be scheduled to BackupQueue.
Created attachment 8919311 [details] [diff] [review] Patch, v2 https://treeherder.mozilla.org/#/jobs?repo=try&revision=2a9d640f3f48640c3d4c183eecc2559f74b3ed67
Attachment #8919225 - Attachment is obsolete: true
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/96c6513a7f56 Add assertion to CustomElementReactionsStack::Enqueue to ensure upgrade reactions aren't scheduled to BackupQueue; r=smaug
Status: NEW → RESOLVED
Last Resolved: 6 months ago
status-firefox58: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
You need to log in before you can comment on or make changes to this bug.