haikuwebkit/LayoutTests/fast/block/crash-when-subtree-is-still...

PASS if
no crash.
foobar
[RenderTreeBuilder] REGRESSION(r228238) Detach renderer before destroying its subtree. https://bugs.webkit.org/show_bug.cgi?id=182908 <rdar://problem/37619394> Reviewed by Antti Koivisto. Source/WebCore: Prior to r228238 we first detached the to-be-destroyed renderer and then started nuking its descendants. r228238 changed the order and now the descendants are destroyed while they are still attached to the tree. Apparently some of the takeChild() normalization logic gets triggered now that the renderers still have access to their previous/next siblings. This is unexpected and it shouldn't matter whether the subtree is still attached. Let's revert it to the original order for now (see webkit.org/b/182909). Test: fast/block/crash-when-subtree-is-still-attached.html * rendering/RenderElement.cpp: (WebCore::RenderElement::removeAndDestroyChild): LayoutTests: * fast/block/crash-when-subtree-is-still-attached-expected.txt: Added. * fast/block/crash-when-subtree-is-still-attached.html: Added. Canonical link: https://commits.webkit.org/198664@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@228606 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-02-18 18:44:34 +00:00			`PASS if`
			`no crash.`
Folding anonymous blocks should not result in deleting content. https://bugs.webkit.org/show_bug.cgi?id=184339 <rdar://problem/37327428> Reviewed by Antti Koivisto. Source/WebCore: While folding multiple anonymous blocks (moving the children from next sibling over to previous sibling) we should ensure that the block we are about to destroy does not gain new descendants. In case of 4 sibling anonymous blocks (A B C D), while destroying B 1. we move C's children to A and destroy C. 2. While destroying C, we notice B and C as sibling anonymous blocks and we move D's children over to B (even though B is going to be destroyed as we climb back on the stack). In this patch, B is detached from the tree before we start moving renderers around so that a subsequent folding won't find B anymore as a candidate. Test: fast/block/crash-while-folding-anonymous-blocks.html * rendering/updating/RenderTreeBuilderBlock.cpp: (WebCore::RenderTreeBuilder::Block::detach): LayoutTests: * fast/block/crash-when-subtree-is-still-attached-expected.txt: Progressing. This test does not intend to remove "foobar" text at all. * fast/block/crash-while-folding-anonymous-blocks-expected.txt: Added. * fast/block/crash-while-folding-anonymous-blocks.html: Added. Canonical link: https://commits.webkit.org/199896@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230313 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-04-05 21:14:31 +00:00			`foobar`
[RenderTreeBuilder] REGRESSION(r228238) Detach renderer before destroying its subtree. https://bugs.webkit.org/show_bug.cgi?id=182908 <rdar://problem/37619394> Reviewed by Antti Koivisto. Source/WebCore: Prior to r228238 we first detached the to-be-destroyed renderer and then started nuking its descendants. r228238 changed the order and now the descendants are destroyed while they are still attached to the tree. Apparently some of the takeChild() normalization logic gets triggered now that the renderers still have access to their previous/next siblings. This is unexpected and it shouldn't matter whether the subtree is still attached. Let's revert it to the original order for now (see webkit.org/b/182909). Test: fast/block/crash-when-subtree-is-still-attached.html * rendering/RenderElement.cpp: (WebCore::RenderElement::removeAndDestroyChild): LayoutTests: * fast/block/crash-when-subtree-is-still-attached-expected.txt: Added. * fast/block/crash-when-subtree-is-still-attached.html: Added. Canonical link: https://commits.webkit.org/198664@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@228606 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2018-02-18 18:44:34 +00:00