Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 66173572487e9a21a85e599a47aa040b25a08497
https://github.com/WebKit/WebKit/commit/66173572487e9a21a85e599a47aa040b25a08497
Author: Anne van Kesteren <[email protected]>
Date: 2026-10-13 (Tue, 13 Oct 2026)
Changed paths:
A LayoutTests/contentfiltering/blocked-page-opaque-origin-expected.txt
A LayoutTests/contentfiltering/blocked-page-opaque-origin.html
M Source/WebCore/loader/ContentFilter.cpp
Log Message:
-----------
Content filter blocked pages should have an opaque origin
https://bugs.webkit.org/show_bug.cgi?id=327376
rdar://189889453
Reviewed by Charlie Wolfe.
When a content filter blocks a document, ContentFilter loads the filter's
replacement page as substitute data at the file: URL of an empty
ContentFilterBlockedPage.html in WebCore's bundle. The page took that file's
origin, and as substitute data for an unreachable URL it got neither a
navigation nor a response decision, so it also missed the agent cluster
assignment that 323290@main gives other documents.
The page replaces the blocked document's contents, so give it an opaque
origin instead: its response now has opaque tainting, which
Document::initSecurityContext() turns into an opaque origin. The response
also carries the page's URL, as DocumentLoader replaces a substitute data
response that has none.
Tests: contentfiltering/blocked-page-opaque-origin.html
Canonical link: https://commits.webkit.org/323689@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
