[Webkit-unassigned] [Bug 222720] REGRESSION(r272900): Nullptr crash in ComposedTreeIterator::traverseNextInShadowTree() via ShadowRoot::hostChildElementDidChange

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=222720

--- Comment #18 from Carlos Garcia Campos <cgarcia at igalia.com> ---
I was adding the assert we agreed on slack to ensure the nullptr item in the slot is the only item left, but it turns out it's not. I debugged this further and I'm no longer sure this was the right fix. This is what happens. We have a composed tree like this:

details
   slot 0x7f6c280f7730
    summary (shadow root) 0x7f6c280f7b60
      div 0x7f6c280f7cd0
      slot 0x7f6c280f7d50
  slot 0x7f6c280f7a80
    #text 0x7f6c280f7b00

then the test starts and first x4.click() causes on_details_click() to be called that prepends a new node in details and we end up with:

details
   slot 0x7f6c280f7730
    summary (shadow root) 0x7f6c280f7b60
      div 0x7f6c280f7cd0
      slot 0x7f6c280f7d50
        #text 0x7f6c280f7dd0
  slot 0x7f6c280f7a80
    #text 0x7f6c29a30010
    #text 0x7f6c280f7b00

and now x4.innerText = "PASS"; that creates a new node and removes all its children in replaceAllChildrenWithNewText(). It collects 3 children to be removed: #text 0x7f6c29a30010, #text 0x7f6c280f7b00 and summary (shadow root) 0x7f6c280f7b60. When dispatchChildRemovalEvents() is called for the summary element, the DOMNodeRemoved is dispatched and on_details_click() is called again, prepending a new node. This new node inserted while deleting children is he one becoming nullptr in the assigned nodes list. At this point the list of assigned nodes for slot 0x7f6c280f7a80 contains the three elements. 
Now the actual child removal happens, that includes the newly added node that is the first one to be removed. The main difference is that the new node added is destroyed when removed, while the others are kept alive while a bit longer. When the summary is removed ShadowRoot::hostChildElementDidChange() is called and the assigned node list is: nullptr, #text 0x7f6c29a30010, #text 0x7f6c280f7b00. When removeAllChildrenWithScriptAssertion finishes the rest of the nodes are destroyed too.

So, I think the fix is to keep the newly node alive too until removeAllChildrenWithScriptAssertion() finishes. I wonder if adding new nodes while removing children is allowed, though.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210315/76799c56/attachment-0001.htm>