Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 2b001c8573b2c63a1341c7d58ee0d0e07c6d1d62
https://github.com/WebKit/WebKit/commit/2b001c8573b2c63a1341c7d58ee0d0e07c6d1d62
Author: Sihui Liu <[email protected]>
Date: 2026-09-08 (Tue, 08 Sep 2026)
Changed paths:
M
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm
Log Message:
-----------
[Site Isolation] Adopt the root compositing layer when swapping drawing areas
https://bugs.webkit.org/show_bug.cgi?id=323633
rdar://186864659
Reviewed by Per Arne Vollan.
320565@main addressed a cross-origin iframe not rendering after a back
navigation. On a multi-process back/forward cache
restore, committing the provisional page recreates the page's DrawingAreaProxy,
RemotePageProxy::setDrawingArea()
re-sends CreateWebPage to each iframe process, and
WebPage::reinitializeWebPage() swaps in a new drawing area. That
change froze the layer tree during the restore, on the premise that doing so
defers the root compositing layer
attachment until the new drawing area is in place.
However, the premise does not hold. The freeze gates the drawing area's
rendering update, not WebCore's compositing
update, and the attachment happens during the latter: the restore runs a
compositing update, ensureRootLayer() attaches,
and the root layer lands on the outgoing drawing area. setIsInWindow() then
bails out while m_rootLayerAttachment is
set, so the new drawing area never receives it. The layers are registered in
the new context but unreachable from its
root layer, and recursiveBuildTransaction() walks down from the root, so
nothing is committed.
The test added in 320565@main did not catch this because its iframe was a bare
link. With nothing to composite,
usesCompositing() stays false, setIsInWindow() returns at its first gate, and
the attachment is deferred past the swap.
Give that iframe a composited layer and it will always fail. Its assertion
needs replacing as well: "(layer bounds"
appears for every layer in the dump, so it passed on the main frame's layers
whether or not the iframe contributed
anything.
Rather than trying to keep the compositing update and the attachment from
happening before the swap, make the attachment
transferable. adoptLayersFromDrawingArea() now takes the content layer and view
overlay layer over from the outgoing
drawing area; a detach and re-attach would only add the
rootLayerAttachmentChanged() side effects, since nothing about
the attachment has changed from WebCore's point of view. It also carries the
root layer's size over, which comes from
mainFrameContentSizeChanged() and need not be produced again by a restore, and
triggers a rendering update the way
setRootCompositingLayer() does after the same updateRootLayers().
The layer tree freeze from 320565@main is left in place even though it has no
bearing on the attachment. Removing it
belongs in a separate change: a rare rAF-assertion failure in this test were
only ever seen with the freeze removed, but
at roughly 2 in 100 runs against none in 80 the comparison is not conclusive
either way. That looks like an unrelated
rendering-update scheduling problem and deserves its own investigation.
Test: Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm
*
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm:
(WebKit::RemoteLayerTreeDrawingArea::adoptLayersFromDrawingArea):
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm:
(TestWebKitAPI::(SiteIsolation,
MultiProcessBFCacheIframeRendersAfterBackNavigation)):
Canonical link: https://commits.webkit.org/320658@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
