Bug 192461 – Remove children of ShadowRoot before deleting it

• Status: ASSIGNED
• Component: DOM

[Ryosuke Niwa]

Right now, ~ShadowRoot deletes its children but we should be deleting the children first
so that none of the descendant nodes would try to access ShadowRoot during its destruction.

<rdar://problem/44703658>

[Ryosuke Niwa]

Created attachment 356718 [details]
WIP

[Ryosuke Niwa]

Created attachment 356742 [details]
WIP - fixed non-debug builds

[Ryosuke Niwa]

Hm... this isn't quite going to solve the problem I set out to solve. It's still possible for someone to invoke ref() on ShadowRoot after m_refCount had been decremented to 0. For that matter, that could happen to Document as well inside Document::removedLastRef().

I'm actually not certain asserting that we've never reached removedLastRef() makes sense. What's the issue if someone ref's an object with m_refCount of 0 at that point? It seems to me, that might just work.

Conceptually, what we want to do is to remove all children right before the last ref goes away but deref() -> removedLastRef() might be that timing really since we can't predict when the last deref() would be called sort of adding a function like willDeref(), which will be a massive perf hit.

[Ryosuke Niwa]

Created attachment 357033 [details]
Cleanup

[EWS Watchlist]

Comment on attachment 357033 [details]
Cleanup

Attachment 357033 [details] did not pass win-ews (win):
Output: https://webkit-queues.webkit.org/results/10347736

New failing tests:
fast/frames/lots-of-objects.html

[EWS Watchlist]

Created attachment 357036 [details]
Archive of layout-test-results from ews201 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews201  Port: win-future  Platform: CYGWIN_NT-6.1-2.10.0-0.325-5-3-x86_64-64bit

[Ryosuke Niwa]

Created attachment 359073 [details]
Updated for trunk

[EWS Watchlist]

Comment on attachment 359073 [details]
Updated for trunk

Attachment 359073 [details] did not pass win-ews (win):
Output: https://webkit-queues.webkit.org/results/10749425

New failing tests:
fast/frames/lots-of-objects.html
fast/frames/lots-of-iframes.html

[EWS Watchlist]

Created attachment 359089 [details]
Archive of layout-test-results from ews202 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews202  Port: win-future  Platform: CYGWIN_NT-6.1-2.10.0-0.325-5-3-x86_64-64bit

[Maciej Stachowiak]

Comment on attachment 359073 [details]
Updated for trunk

This patch no longer applies. (Seems like a good idea otherwise,