Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 6dd3a73e5aa2eae8951508f3b66d2014078a65aa
https://github.com/WebKit/WebKit/commit/6dd3a73e5aa2eae8951508f3b66d2014078a65aa
Author: Alex Christensen <[email protected]>
Date: 2023-03-03 (Fri, 03 Mar 2023)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkProcess.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/CookiePrivateBrowsing.mm
Log Message:
-----------
REGRESSION(255420@main) Embed-loading PDFs from newly opened about:blank
terminates web process
https://bugs.webkit.org/show_bug.cgi?id=253285
rdar://105201326
Reviewed by J Pascoe.
In 255420@main I introduced checks in the network process to make sure that
firstPartyForCookies
is an allowed domain for that process. There are a few places in WebKit where
we still have
about:blank or a null firstPartyForCookies, which is fine most of the time
because
ResourceRequest::allowCookies is false so it doesn't matter that there's no
firstPartyForCookies.
Sometimes, though, we have a piece of code that loads without a
firstPartyForCookies and allows
cookies. This is an existing bug and should probably be fixed, but it is not
catastrophic
because the result is that no cookie access is given. However, with
255420@main it became catastrophic
because we terminate the web content process, which I'm told is undesirable
when a user is trying to do
something like download a PDF. This change makes it no longer terminate the
web content process.
* Source/WebKit/NetworkProcess/NetworkProcess.cpp:
(WebKit::NetworkProcess::allowsFirstPartyForCookies):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/CookiePrivateBrowsing.mm:
(TEST):
Canonical link: https://commits.webkit.org/261142@main
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
