| Summary: | [GPU Process] window opening tests are intermittently crashing | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Cameron McCormack (:heycam) <heycam> | ||||||
| Component: | WebKit Process Model | Assignee: | Kimmo Kinnunen <kkinnunen> | ||||||
| Status: | RESOLVED CONFIGURATION CHANGED | ||||||||
| Severity: | Normal | CC: | bart.corremans, i, jonlee, kkinnunen, ryanhaddad, simon.fraser, webkit-bug-importer, wenson_hsieh | ||||||
| Priority: | P2 | Keywords: | InRadar | ||||||
| Version: | WebKit Nightly Build | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| See Also: |
https://bugs.webkit.org/show_bug.cgi?id=231681 https://bugs.webkit.org/show_bug.cgi?id=238391 https://bugs.webkit.org/show_bug.cgi?id=238397 https://bugs.webkit.org/show_bug.cgi?id=240788 |
||||||||
| Bug Depends on: | 238504, 238516, 238608, 238618, 238622, 238676, 239399 | ||||||||
| Bug Blocks: | 233914 | ||||||||
| Attachments: |
|
||||||||
|
Description
Cameron McCormack (:heycam)
2022-03-09 14:00:53 PST
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. *** |