Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 3be92fd3eef631ec25d1bc9444f1ba3295b2266a
https://github.com/WebKit/WebKit/commit/3be92fd3eef631ec25d1bc9444f1ba3295b2266a
Author: Sihui Liu <[email protected]>
Date: 2026-03-05 (Thu, 05 Mar 2026)
Changed paths:
M Source/WebKit/Shared/WebErrors.cpp
M Source/WebKit/Shared/WebErrors.h
M Source/WebKit/UIProcess/FrameLoadState.cpp
M Source/WebKit/UIProcess/PageLoadState.cpp
M Source/WebKit/UIProcess/ProvisionalPageProxy.cpp
M Source/WebKit/UIProcess/ProvisionalPageProxy.h
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
Log Message:
-----------
[Site Isolation] Fix ContentFiltering.LoadAlternateAfterAddDataWK2
rdar://171539019
https://bugs.webkit.org/show_bug.cgi?id=308989
Reviewed by Per Arne Vollan.
TestWebKitAPI.ContentFiltering.LoadAlternateAfterAddDataWK2 currently fails
under Site Isolation as the test expects
`_loadAlternateHTMLString` in navigation delegate callback
`didFailProvisionalNavigation` will not overwrite the content
filter error page (the error page shows 'blocked' while the alternate HTML is
'FAIL').
This patch makes a few fixes:
1. The content filter error page load is never committed with current
implementation, because under Site Isolation,
provisional page is discarded after provisional load failure
(`WebPageProxy::m_provisionalPage` is cleared in
`didFailProvisionalLoadForFrameShared`), even when `willContinueLoading` is
`WillContinueLoading::Yes`, meaning the page
is going to continue loading error page.
To fix this, make sure `m_provisionalPage` is not set to null in
`didFailProvisionalLoadForFrameShared`, just like
non-Site Isolation case. However, `m_provisionalPage` was set to null in
295474@main, and the purpose was to make UI
process won't re-use the failed provsional page's process to continue loading
in navigation coordinated by UI process.
To keep that behavior, the patch adds a new flag
`ProvisionalPageProxy::m_didFailProvisionalLoad`, and makes sure the
flag is checked when deciding process for navigation.
2. In `WebPageProxy::loadAlternateHTML`, the load request is always sent to
`WebPageProxy::m_legacyMainFrameProcess`.
The test works without Site Isolation because because it happens to not swap
process when Site Isolation is off. There's
a check in loading web process to make sure alternate HTML load won't replace
loaded content filter error page
(`PolicyChecker::checkNavigationPolicy` =>
`ContentFilter::continueAfterSubstituteDataRequest`) -- when the process is
not swapped, the process is used for both provisional load (which is then
turned into content filter error page load)
and alternate HTML load, so that web process knows to ignore the alternate HTML
load. With Site Isolation, the test will
swap process (because different sites are visited in the redirect chain), and
`WebPageProxy::m_legacyMainFrameProcess`
does not know about the failure (as the failure happens in process of
`WebPageProxy::m_provisionalPage`), so it will
commit the load of alternate HTML.
To fix this, this patch introduces
`WebPageProxy::m_allowsLoadingAlternateHTMLForFailingProvisionalLoadURL`, which
kinds
of moving the web process check of
`ContentFilter::continueAfterSubstituteDataRequest` to UI process under Site
Isolation. If the provisonal load is failing for content filter, the failing
process intends to continue loading content
filter error page, and the alternate HTML is used to replace the failing load,
then `WebPageProxy::loadAlternateHTML`
will ignore the load.
3. With the two fixes above, the test starts to hit debug assertions in
`PageLoadState` and `FrameLoadState`. This is
because they set the `m_provisionalURL` to null and `m_state` to
`State::Finished` after provisional load failure; and
they validate the these members in `didCommitLoad` and other functions.
However, in the case of "content filter blocked
error", the failed load could be turned into a committed load (or another
provisional load) since the failing process
would just continue to load replacment data received from content filter (or
alternate HTML data received from client
under non-Site Isolation).
To fix this, this patch updates the assertions accordingly.
This fixes 3 ContentFiltering API tests under Site Isolation:
- ContentFiltering.LoadAlternateAfterAddDataWK2
- ContentFiltering.LoadAlternateAfterFinishedAddingDataWK2
- ContentFiltering.LoadAlternateAfterResponseWK2
* Source/WebKit/Shared/WebErrors.cpp:
(WebKit::isBlockedByContentFilterError):
* Source/WebKit/Shared/WebErrors.h:
* Source/WebKit/UIProcess/FrameLoadState.cpp:
(WebKit::FrameLoadState::didCommitLoad):
* Source/WebKit/UIProcess/PageLoadState.cpp:
(WebKit::PageLoadState::didCommitLoad):
* Source/WebKit/UIProcess/ProvisionalPageProxy.cpp:
(WebKit::ProvisionalPageProxy::didFailProvisionalLoadForFrame):
* Source/WebKit/UIProcess/ProvisionalPageProxy.h:
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::loadAlternateHTML):
(WebKit::WebPageProxy::receivedNavigationActionPolicyDecision):
(WebKit::WebPageProxy::didFailProvisionalLoadForFrameShared):
* Source/WebKit/UIProcess/WebPageProxy.h:
Canonical link: https://commits.webkit.org/308778@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
