[webkit-changes] [WebKit/WebKit] e74572: [UI-side compositing] [GPU Process] Emailing a web...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: e74572e8106c6580f74f5193d363810560f6b9fd
      https://github.com/WebKit/WebKit/commit/e74572e8106c6580f74f5193d363810560f6b9fd
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  Date:   2023-03-29 (Wed, 29 Mar 2023)

  Changed paths:
    M Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/GPUProcess.mm

  Log Message:
  -----------
  [UI-side compositing] [GPU Process] Emailing a webpage from Safari causes the tab to stop rendering
https://bugs.webkit.org/show_bug.cgi?id=254683
rdar://107329972

Reviewed by Simon Fraser.

When sharing a webpage via Mail, Safari first generates a web archive from the existing web view's
content, and then creates an offscreen web view *backed by the tab's existing web process*, which we
then use to load the web archive and perform reader extraction heuristics.

However, when the DOM GPU process experimental feature flag is enabled for Safari tabs, it only
affects the web view used for rendering the main page content; importantly, this related web view
does not have DOM GPUP enabled.

When subsequently loading the web archive data via this reader web view, we end up *disabling* GPUP
for DOM rendering in the original tab's web process, due to the following code:

```
bool usingGPUProcessForDOMRendering = m_shouldRenderDOMInGPUProcess && DrawingArea::supportsGPUProcessRendering(m_drawingAreaType);
WebProcess::singleton().setUseGPUProcessForDOMRendering(usingGPUProcessForDOMRendering);
```

The current implementation of GPUP for DOM rendering doesn't handle on-the-fly GPUP disablement —
and in fact, in the case where IOKit has already been blocked in the web process, it's impossible to
disable GPUP at all once a page has been created with all the relevant GPUP flags enabled.

As such, we mitigate this by simply forcing DOM GPUP to be enabled (regardless of preferences state)
for a web view, if its related web view already has DOM GPUP enabled. Once DOM GPUP is enabled by
default, this won't be an issue anyway, since all web views will be created with consistent feature
flag statuses.

Test: GPUProcess.GPUProcessForDOMRenderingCarriesOverFromRelatedPage

* Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm:
(WebKit::WebPageProxy::useGPUProcessForDOMRenderingEnabled const):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/GPUProcess.mm:
(-[NSUserDefaults swizzled_objectForKey:]):
(TestWebKitAPI::EnableUISideCompositingScope::EnableUISideCompositingScope):
(TestWebKitAPI::EnableUISideCompositingScope::~EnableUISideCompositingScope):

Add a new RAII helper class to temporarily swizzle out `-objectForKey:`, in order to forcibly enable
UI-side compositing for this test, as it's necessary to exercise the bug fix. Note that I'm using
swizzling here to avoid also enabling UI-side compositing for downstream API tests, even if the test
crashes or times out.

(TestWebKitAPI::TEST):
(convertToCGImage): Deleted.
(getPixelIndex): Deleted.
(TEST): Deleted.
(runMemoryPressureExitTest): Deleted.
(waitUntilCaptureState): Deleted.

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