When WindowServer access is blocked in the WebContent process, we should shutdown all connections after checking in with launch services.
<rdar://problem/39613173>
Created attachment 339001 [details] Patch
Created attachment 339002 [details] Patch
Comment on attachment 339002 [details] Patch Looks great! r=me.
Created attachment 339592 [details] Patch
Comment on attachment 339592 [details] Patch r=me if the EWS bots are happy.
Comment on attachment 339592 [details] Patch Attachment 339592 [details] did not pass win-ews (win): Output: http://webkit-queues.webkit.org/results/7569434 New failing tests: http/tests/security/canvas-remote-read-remote-video-blocked-no-crossorigin.html
Created attachment 339605 [details] Archive of layout-test-results from ews206 for win-future The attached test failures were seen while running run-webkit-tests on the win-ews. Bot: ews206 Port: win-future Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit
Comment on attachment 339592 [details] Patch Thanks for reviewing!
Per Arne: Did you see this test failure: http/tests/security/canvas-remote-read-remote-video-blocked-no-crossorigin.html Is that related to this change?
(In reply to Brent Fulgham from comment #10) > Per Arne: Did you see this test failure: > > http/tests/security/canvas-remote-read-remote-video-blocked-no-crossorigin. > html > > Is that related to this change? I believe this is a flaky failure from the Windows bots.
Comment on attachment 339592 [details] Patch Clearing flags on attachment: 339592 Committed r231389: <https://trac.webkit.org/changeset/231389>