Bug 237674 – [GPU Process] window opening tests are intermittently crashing

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: WebKit Process Model

[Cameron McCormack (:heycam)]

imported/w3c/web-platform-tests/html/semantics/links/links-created-by-a-and-area-elements/target_blank_implicit_noopener.html [ Crash Pass ]
imported/w3c/web-platform-tests/html/semantics/links/links-created-by-a-and-area-elements/target_blank_implicit_noopener_base.html [ Crash Pass ]
imported/w3c/web-platform-tests/webstorage/storage_session_window_open.window.html [ Crash Pass ]

With a debug build, we're hitting the assertion in IPC::MessageReceiveQueueMap::addImpl in the GPU process.

[Radar WebKit Bug Importer]

<rdar://problem/90165815>

[Simon Fraser (smfr)]

Created attachment 455788 [details]
Patch

[Wenson Hsieh]

Comment on attachment 455788 [details]
Patch

r=mews

[Simon Fraser (smfr)]

Not landing this until we have a resolution for bug 238391.

[Simon Fraser (smfr)]

Also:

fast/animation/request-animation-frame-during-modal.html
fast/dom/Geolocation/window-close-crash.html
fast/dom/intersection-observer-document-leak.html
fast/dom/Window/Location/set-location-after-close.html
fast/dom/Window/a-rel-noopener.html
fast/dom/Window/area-rel-noopener.html
fast/dom/Window/closure-access-after-navigation-window.html
fast/dom/Window/dom-access-from-closure-window-with-gc.html
fast/dom/Window/dom-access-from-closure-window.html
fast/dom/lazy-image-loading-document-leak.html
fast/dom/open-and-close-by-DOM.html
fast/events/before-unload-navigate-different-window.html
fast/events/before-unload-open-window.html
fast/events/ios/tab-cycle.html
fast/files/domurl-script-execution-context-crash.html

[Simon Fraser (smfr)]

*** Bug 238297 has been marked as a duplicate of this bug. ***

[Kimmo Kinnunen]

Comment on attachment 455788 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=455788&action=review

> Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.cpp:111
> +    // the same sequence as RemoteRenderingBackend messages. m_placeholderDisplayListStreamBufferID is necessary to make this receiver unique per IPC::Connection.

I don't think the placeholder is used anywhere?
This would amount to the same effect as removing the catch-all altogether.

[Kimmo Kinnunen]

run-webkit-tests --no-build --no-show-results  --child-processes=1 --experimental-feature=UseGPUProcessForDOMRenderingEnabled=true --iterations=100 --force --simulator imported/w3c/web-platform-tests/html/semantics/links/links-created-by-a-and-area-elements/target_blank_implicit_noopener.html

[Kimmo Kinnunen]

*** Bug 238865 has been marked as a duplicate of this bug. ***

[Kimmo Kinnunen]

Fixed by the blocking bugs.

[Bart Corremans]

Is there a known workaround for this issue? Our team is running into https://bugs.webkit.org/show_bug.cgi?id=238865 and face having to tell our customers to avoid using Safari with our product until this fix lands in the release version.

[Kimmo Kinnunen]

(In reply to Bart Corremans from comment #11)
> Is there a known workaround for this issue? Our team is running into
> https://bugs.webkit.org/show_bug.cgi?id=238865 and face having to tell our
> customers to avoid using Safari with our product until this fix lands in the
> release version.

Unfortunately for the current shipping versions, the only workaround is to prevent direct cross-window communication, e.g. to use noopener.

[Bart Corremans]

Created attachment 459579 [details]
Freeze closing pdf rendered in non active tab

To reproduce:
- Open index.html
- Click the button. Return to the first tab before the pdf loads.
- Click the button again and remain on this new tab.
- When the inactive tab finishes loading the PDF, close it without making it active. This can be either before or after the PDF in the current tab finishes loading.
- Notice how current and original tabs are frozen.

[Bart Corremans]

(In reply to Kimmo Kinnunen from comment #12)
> (In reply to Bart Corremans from comment #11)
> > Is there a known workaround for this issue? Our team is running into
> > https://bugs.webkit.org/show_bug.cgi?id=238865 and face having to tell our
> > customers to avoid using Safari with our product until this fix lands in the
> > release version.
> 
> Unfortunately for the current shipping versions, the only workaround is to
> prevent direct cross-window communication, e.g. to use noopener.

Understood. I can confirm that in the current Technology Preview (17614.1.11.6), we experience no issues opening a window with a canvas and communicating cross-window.

However, in this build, I still experience issues when closing a non-focused tab where a pdf is rendered. This is resolved with noopener, but I am unsure whether this is a new issue, or if it is caused by this one (and the Technology Preview build does not contain the fix for this issue yet - implying our canvas issue was resolved in another way).

I have attached a repro above.

Apologies if this is unrelated - in that case I can create a new issue. I did not find existing issues mentioning a similar scenario.

[Kimmo Kinnunen]

(In reply to Bart Corremans from comment #14)
> However, in this build, I still experience issues when closing a non-focused
> tab where a pdf is rendered. This is resolved with noopener, but I am unsure

Thanks for the report.

I've filed bug 240788 for this, let's continue that analysis there.

[Brent Fulgham]

*** Bug 238296 has been marked as a duplicate of this bug. ***