Bug 316114
| Summary: | [Site Isolation] Evicting a cross-site page from the back/forward cache crashes the iframe process | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Basuke Suzuki <basuke> |
| Component: | WebKit Misc. | Assignee: | Basuke Suzuki <basuke> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Basuke Suzuki
When a cross-site Site Isolation page is held in the back/forward cache via a SuspendedPageProxy, evicting that cache entry never sends ClearCachedPage to the iframe process. The entry's iframeProcesses() set (derived from m_cachedChildren) is empty for the cross-site SuspendedPageProxy path, so only the main process is cleared. The SuspendedPageProxy teardown then sends a plain Close to the iframe process, which runs WebPage::close() while its document is still in Document::InBackForwardCache state, tripping ASSERT(m_rootFrames.isEmpty()) in Page::~Page() (Source/WebCore/page/Page.cpp).
This has been latent since the Phase 3 multi-process BFCache work landed; it becomes reachable by default once MultiProcessBackForwardCacheEnabled is auto-enabled under Site Isolation (bug 314699). Reachable by any eviction (capacity, expiration, or _clearBackForwardCache).
Fix: in ~WebBackForwardCacheEntry, also clear the cached pages on the SuspendedPageProxy's subframe processes (for the matching frame item) before the Close, so the iframe leaves the back/forward cache cleanly.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Basuke Suzuki
<rdar://problem/178543188>
Basuke Suzuki
Pull request: https://github.com/WebKit/WebKit/pull/66290
EWS
Committed 314507@main (5b5081adba8f): <https://commits.webkit.org/314507@main>
Reviewed commits have been landed. Closing PR #66290 and removing active labels.