We recently discovered a bug where certain strange patterns of author code could cause infinite recursion in the spec algorithms and in all browsers. Blink has fixed this and Gecko has a bug on file, so here's one for WebKit. Spec fix: https://github.com/whatwg/html/pull/5126 Tests: https://github.com/web-platform-tests/wpt/pull/20465 Live tests: https://wpt.fyi/results/custom-elements/upgrading.html?label=master&label=experimental&aligned
Created attachment 407380 [details] Implements the new behavior
Comment on attachment 407380 [details] Implements the new behavior View in context: https://bugs.webkit.org/attachment.cgi?id=407380&action=review > Source/WebCore/bindings/js/JSCustomElementInterface.cpp:203 > + // Unlike spec, set element's custom element state to "failed" after enqueueing post-upgrade reactions > + // to avoid hitting debug assertions in enqueuePostUpgradeReactions. > + element.setIsFailedCustomElementWithoutClearingReactionQueue(); Isn't this confusing? Wouldn't it be better to change the asserts? > Source/WebCore/dom/Element.cpp:2468 > +#if ASSERT_ENABLED > + if (isFailedCustomElement()) { > + auto* queue = elementRareData()->customElementReactionQueue(); > + ASSERT(queue); > + ASSERT(queue->isEmpty() || queue->hasJustUpgradeReaction()); > + } else > + ASSERT(isDefinedCustomElement() || isCustomElementUpgradeCandidate()); > +#endif Alternatively you could factor the validity tests into a boolean returning function and ASSERT that.
Thanks for the review. (In reply to Antti Koivisto from comment #2) > Comment on attachment 407380 [details] > Implements the new behavior > > View in context: > https://bugs.webkit.org/attachment.cgi?id=407380&action=review > > > Source/WebCore/bindings/js/JSCustomElementInterface.cpp:203 > > + // Unlike spec, set element's custom element state to "failed" after enqueueing post-upgrade reactions > > + // to avoid hitting debug assertions in enqueuePostUpgradeReactions. > > + element.setIsFailedCustomElementWithoutClearingReactionQueue(); > > Isn't this confusing? Wouldn't it be better to change the asserts? I don't think so. enqueuePostUpgradeReactions asserts that the element is isCustomElementUpgradeCandidate. It would be weird to assert that it's a "failed" custom element since that could occur when the custom element had actually failed to upgrade. > > Source/WebCore/dom/Element.cpp:2468 > > +#if ASSERT_ENABLED > > + if (isFailedCustomElement()) { > > + auto* queue = elementRareData()->customElementReactionQueue(); > > + ASSERT(queue); > > + ASSERT(queue->isEmpty() || queue->hasJustUpgradeReaction()); > > + } else > > + ASSERT(isDefinedCustomElement() || isCustomElementUpgradeCandidate()); > > +#endif > > Alternatively you could factor the validity tests into a boolean returning > function and ASSERT that. Hm... that would make it less obvious which condition had failed when one of these debug assertions hit so I'd keep it as is.
Comment on attachment 407380 [details] Implements the new behavior Clearing flags on attachment: 407380 Committed r266269: <https://trac.webkit.org/changeset/266269>
All reviewed patches have been landed. Closing bug.
<rdar://problem/67914221>