Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 770818d2dcfa6528b185fda410a2be09290eb14f
https://github.com/WebKit/WebKit/commit/770818d2dcfa6528b185fda410a2be09290eb14f
Author: Matt Woodrow <[email protected]>
Date: 2025-04-29 (Tue, 29 Apr 2025)
Changed paths:
M LayoutTests/platform/mac-wk2/TestExpectations
M Source/WebCore/dom/ViewTransition.cpp
M Source/WebCore/rendering/RenderLayer.cpp
M Source/WebCore/rendering/RenderLayerBacking.cpp
M Source/WebCore/rendering/RenderLayerCompositor.cpp
M Source/WebCore/rendering/RenderObject.cpp
Log Message:
-----------
ASSERTION FAILED: !layer || !layer->hasAncestor(this) in
imported/w3c/web-platform-tests/css/css-view-transitions/transition-in-hidden-page.html.
https://bugs.webkit.org/show_bug.cgi?id=292203
<rdar://150207829>
Reviewed by Simon Fraser.
This crash happens when a view-transition captures the Document element, and
then the element gets destroyed while the transition is in progress. Normally,
running the 'handle transition frame' steps detects this and aborts the
transition. Sometimes though we attempt to update compositing layers outside of
a rendering update which triggers this crash.
The destruction of the Element and its cpatured renderer doesn't mark the
hosting ::view-transition-new's layer as needing an update and we get an
assertion from doing a partial layer update. This would get fixed in the
following rendering update, so should only affect debug.
Fix by explicitly marking the hosting layer as needing compositing connection
update when a captured renderer is destroyed.
* Source/WebCore/dom/ViewTransition.cpp:
(WebCore::ViewTransition::setupTransitionPseudoElements):
Revert 294027@main, which tried to fix this but just avoided it sometimes due
to timing changes.
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::rebuildZOrderLists):
(WebCore::RenderLayer::collectLayers):
Make sure the ::view-transition root psuedo is topmost in the z-order list by
explicitly retrieving it and appending it (as we do for top layers), rather
than expecting it to be the last normal child of the view.
Not actually the bug here, but shows up in this testcase.
* Source/WebCore/rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::childForSuperlayers const):
Same as above, lookup the root directly instead of hoping it's the last child.
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::collectViewTransitionNewContentLayers):
Safer C++ fix, and an extra assertion.
* Source/WebCore/rendering/RenderObject.cpp:
(WebCore::RenderObject::setCapturedInViewTransition):
(WebCore::RenderObject::willBeDestroyed):
Lookup the hosting ::view-transition-new pseudo and mark as needing a
compositing update when change captured state.
Ensure that destroying a renderer triggers the captured state change
explicitly.
* LayoutTests/platform/mac-wk2/TestExpectations:
Canonical link: https://commits.webkit.org/294319@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
