[webkit-changes] [WebKit/WebKit] 8d5ea3: Blank page on photoshop.adobe.com when tapping in ...

[Chris Dumez]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 8d5ea3dad3eb952a9af07e1846f1632d42475729
      https://github.com/WebKit/WebKit/commit/8d5ea3dad3eb952a9af07e1846f1632d42475729
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2025-01-31 (Fri, 31 Jan 2025)

  Changed paths:
    M Source/WebCore/loader/cache/CachedResourceLoader.cpp
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm
    M Tools/TestWebKitAPI/cocoa/HTTPServer.h
    M Tools/TestWebKitAPI/cocoa/HTTPServer.mm

  Log Message:
  -----------
  Blank page on photoshop.adobe.com when tapping in url bar, then pressing enter
https://bugs.webkit.org/show_bug.cgi?id=286771
rdar://143916165

Reviewed by Darin Adler.

photoshop.adobe.com serves the `Cross-Origin-Opener-Policy: same-origin` and
`Cross-Origin-Embedder-Policy: require-corp` HTTP headers on responses in
order because they use SharedArrayBuffer. These headers may cause us to
process-swap when receiving such a response and the origin of the source
and destination differ.

In the reproduction case, the user would first load the photoshop URL,
which would serve those headers. They would then tap the URL bar and hit
Enter. This would cause Safari to load the same URL in a *new* WKWebView
backed by the same WebProcess (thanks to the _relatedWebView SPI).
Because the same process is used, the second load would find the main
resource in the memory cache and try to revalidate it from the server
(The response has an ETag header). We would send the conditional/revalidation
request to the server and the server would repond with a bodyless 304
HTTP response, meant to allow us to reuse the cached resource. However,
the 304 response also contained the COOP & COEP headers. When seeing those
headers, we would decide to process-swap because the source origin is null
(the new WebView has not loaded anything yet) and is thus different than
the destination origin. We would spin a new WebProcess, swap to it and send
it the 304 response. Because the new WebProcess does not have the resource
in its memory cache and it is receiving a bodyless 304 response, it just
displays an empty document.

To address the issue, we no longer attempt to revalidate resources when
the load is a navigation and the cached response has a Cross-Origin-Opener-Policy
header other than "unsafe-none", since those are likely to cause a process
swap and we wouldn't know how to swap in case of 304 response.

I have verified manually on photoshop.adobe.com that this addresses the issue
and this is covered by a new API test.

* Source/WebCore/loader/cache/CachedResourceLoader.cpp:
(WebCore::CachedResourceLoader::determineRevalidationPolicy const):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm:
((ProcessSwap, COOPAndCOEPOn304Response)):
* Tools/TestWebKitAPI/cocoa/HTTPServer.h:
(TestWebKitAPI::HTTPResponse::setShouldRespondWith304ToConditionalRequests):
* Tools/TestWebKitAPI/cocoa/HTTPServer.mm:
(TestWebKitAPI::statusText):
(TestWebKitAPI::serialize304Response):
(TestWebKitAPI::HTTPServer::respondToRequests):

Canonical link: https://commits.webkit.org/289631@main



To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications