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.
<rdar://problem/90165815>
Created attachment 455788 [details] Patch
Comment on attachment 455788 [details] Patch r=mews
Not landing this until we have a resolution for bug 238391.
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
*** Bug 238297 has been marked as a duplicate of this bug. ***
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.
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
*** Bug 238865 has been marked as a duplicate of this bug. ***
Fixed by the blocking bugs.
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.
(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.
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.
(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.
(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.
*** Bug 238296 has been marked as a duplicate of this bug. ***