WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
206605
Prevent infinite recursion when upgrading custom elements
https://bugs.webkit.org/show_bug.cgi?id=206605
Summary
Prevent infinite recursion when upgrading custom elements
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
Details
Formatted Diff
Diff
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.
Top of Page
Format For Printing
XML
Clone This Bug