| Summary: | Prevent infinite recursion when upgrading custom elements | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Domenic Denicola <d> | ||||
| Component: | DOM | Assignee: | Ryosuke Niwa <rniwa> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | cdumez, cmarcelo, esprehn+autocc, ews-watchlist, kangil.han, koivisto, rniwa, webkit-bug-importer, wenson_hsieh | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | Safari Technology Preview | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=221652 | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 154907 | ||||||
| Attachments: |
|
||||||
|
Description
Domenic Denicola
2020-01-22 11:43:11 PST
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. |