Bug 198216 – Asssertion failure in dispatchSubtreeModifiedEvent due to TextFieldInputType updating UA shadow tree inside Element::removedFromAncestor

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Ryosuke Niwa]

We hit the assertion in Node::dispatchSubtreeModifiedEvent
when a datalist element is removed right after the input element's type is changed.

<rdar://problem/50021640>

[Ryosuke Niwa]

Created attachment 370565 [details]
Fixes the bug

[Brent Fulgham]

Comment on attachment 370565 [details]
Fixes the bug

View in context: https://bugs.webkit.org/attachment.cgi?id=370565&action=review

r=me

> Source/WebCore/html/shadow/DataListButtonElement.cpp:-52
> -    setPseudo(AtomicString("-webkit-list-button", AtomicString::ConstructFromLiteral));

Why do we prefer to call 'setPseudo' on the result of this constructed object, rather than during construction here? It seems like it would be easy to forget to do this work, wouldn't it?

[WebKit Commit Bot]

Comment on attachment 370565 [details]
Fixes the bug

Clearing flags on attachment: 370565

Committed r245746: <https://trac.webkit.org/changeset/245746>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/51109894>

[Ryosuke Niwa]

(In reply to Brent Fulgham from comment #2)
> Comment on attachment 370565 [details]
> Fixes the bug
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=370565&action=review
> 
> r=me
> 
> > Source/WebCore/html/shadow/DataListButtonElement.cpp:-52
> > -    setPseudo(AtomicString("-webkit-list-button", AtomicString::ConstructFromLiteral));
> 
> Why do we prefer to call 'setPseudo' on the result of this constructed
> object, rather than during construction here? It seems like it would be easy
> to forget to do this work, wouldn't it?

In general, it's a bad practice to add an attribute in an element constructor. A content attribute should be something the users of an element should be specifying, not the element itself.

In this particular case, setting the content attribute triggers DOMSubtreeModifiedEvent and which ends up hitting the same assertion because the disabling of the assertion will only take effect after this element had been inserted into the shadow tree.