Bug 206605

Summary: Prevent infinite recursion when upgrading custom elements
Product: WebKit Reporter: Domenic Denicola <d>
Component: DOMAssignee: 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 Flags
Implements the new behavior none

Domenic Denicola
Reported 2020-01-22 11:43:11 PST
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
Attachments
Implements the new behavior (19.00 KB, patch)
2020-08-26 23:51 PDT, Ryosuke Niwa 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Ryosuke Niwa
Comment 1 2020-08-26 23:51:08 PDT
Created attachment 407380 [details] Implements the new behavior
Antti Koivisto
Comment 2 2020-08-27 09:59:49 PDT
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.
Ryosuke Niwa
Comment 3 2020-08-27 19:53:18 PDT
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.
Ryosuke Niwa
Comment 4 2020-08-27 19:55:22 PDT
Comment on attachment 407380 [details] Implements the new behavior Clearing flags on attachment: 407380 Committed r266269: <https://trac.webkit.org/changeset/266269>
Ryosuke Niwa
Comment 5 2020-08-27 19:55:24 PDT
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 6 2020-08-27 19:56:14 PDT
<rdar://problem/67914221>
Note You need to log in before you can comment on or make changes to this bug.