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>
Created attachment 370565 [details] Fixes the bug
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?
Comment on attachment 370565 [details] Fixes the bug Clearing flags on attachment: 370565 Committed r245746: <https://trac.webkit.org/changeset/245746>
All reviewed patches have been landed. Closing bug.
<rdar://problem/51109894>
(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.