RESOLVED FIXED 192290
REGRESSION(PSON): Process swapping code doesn't set DisplayID in WebContent process
https://bugs.webkit.org/show_bug.cgi?id=192290
Summary REGRESSION(PSON): Process swapping code doesn't set DisplayID in WebContent p...
Simon Fraser (smfr)
Reported 2018-12-02 11:12:13 PST
If you add logging in DisplayRefreshMonitorManager::scheduleAnimation() in the if (!client.hasDisplayID()) early return, you'll find that we early return there in PSON-launched processes when the page calls requestAnimationFrame. To repro: launch MiniBrowser, go to webkit.org, then navigate to browserbench.org (PSON navigation), and run MotionMark. You'll see lots of that logging.
Attachments
Fixes the bug (2.73 KB, patch)
2018-12-05 16:11 PST, Ryosuke Niwa
no flags
Archive of layout-test-results from ews114 for mac-sierra (1.41 MB, application/zip)
2018-12-05 16:59 PST, EWS Watchlist
no flags
Archive of layout-test-results from ews103 for mac-sierra (2.57 MB, application/zip)
2018-12-05 17:02 PST, EWS Watchlist
no flags
Patch for landing (1.45 KB, patch)
2018-12-05 19:32 PST, Ryosuke Niwa
no flags
Simon Fraser (smfr)
Comment 1 2018-12-02 11:42:59 PST
Actually log in DocumentAnimationScheduler::createDisplayRefreshMonitor(), where we pas s in a displayID of 0. This zero displayID gets to the UI process, where we call CVDisplayLinkCreateWithCGDisplay(, 0), which seems to work, but I guess it defaults to the main display. Per Arne, we need better protection against silent failures in this DisplayRefreshMonitor code.
Radar WebKit Bug Importer
Comment 2 2018-12-02 11:43:34 PST
Simon Fraser (smfr)
Comment 3 2018-12-02 11:49:17 PST
I guess WebPageProxy::finishAttachingToWebProcess() should call windowScreenDidChange() after initializeWebPage().
Ryosuke Niwa
Comment 4 2018-12-05 16:11:09 PST
Created attachment 356674 [details] Fixes the bug
EWS Watchlist
Comment 5 2018-12-05 16:59:04 PST
Comment on attachment 356674 [details] Fixes the bug Attachment 356674 [details] did not pass mac-debug-ews (mac): Output: https://webkit-queues.webkit.org/results/10284957 Number of test failures exceeded the failure limit.
EWS Watchlist
Comment 6 2018-12-05 16:59:05 PST
Created attachment 356681 [details] Archive of layout-test-results from ews114 for mac-sierra The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews114 Port: mac-sierra Platform: Mac OS X 10.12.6
EWS Watchlist
Comment 7 2018-12-05 17:02:28 PST
Comment on attachment 356674 [details] Fixes the bug Attachment 356674 [details] did not pass mac-ews (mac): Output: https://webkit-queues.webkit.org/results/10285201 New failing tests: http/tests/misc/resource-timing-resolution.html workers/bomb.html
EWS Watchlist
Comment 8 2018-12-05 17:02:29 PST
Created attachment 356682 [details] Archive of layout-test-results from ews103 for mac-sierra The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews103 Port: mac-sierra Platform: Mac OS X 10.12.6
Ryosuke Niwa
Comment 9 2018-12-05 19:32:32 PST
Created attachment 356700 [details] Patch for landing
Ryosuke Niwa
Comment 10 2018-12-05 19:32:47 PST
Landing without the assertion since NSWindow in WTR/DRT is off screen.
Ryosuke Niwa
Comment 11 2018-12-05 22:12:30 PST
Note You need to log in before you can comment on or make changes to this bug.