This happens because we leave accelerated compositing mode when a rendering update is scheduled in RenderingUpdateScheduler. The threaded compositor display refresh monitor is destroyed without completing the frame, so that the RenderingUpdateScheduler is left scheduled forever, ignoring any new schedule request. We need to ensure we complete the frame request before destrying the display refresh monitor to leave the RenderingUpdateScheduler in a consistent state.
Created attachment 370932 [details] Patch
Comment on attachment 370932 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=370932&action=review Nice catch! > Source/WebKit/ChangeLog:9 > + RenderingUpdateScheduler. The threaded compositor display refresh monitor is destroyed without completing the Mind replacing "threaded compositor display refresh monitor" by ThreadedDisplayRefreshMonitor ? The former is a bit difficult to read. > Source/WebKit/ChangeLog:11 > + need to ensure we complete the frame request before destrying the display refresh monitor to leave the Nit: destrying -> destroying > Source/WebKit/Shared/CoordinatedGraphics/threadedcompositor/ThreadedDisplayRefreshMonitor.cpp:94 > + DisplayRefreshMonitor::handleDisplayRefreshedNotificationOnMainThread(this); Looks like DisplayReferehMonitor already protects client notifications so it should be safe to call this even when the object is about to be destroyed. Could you confirm that?
(In reply to Sergio Villar Senin from comment #2) > Comment on attachment 370932 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=370932&action=review > > Nice catch! Thanks. > > Source/WebKit/ChangeLog:9 > > + RenderingUpdateScheduler. The threaded compositor display refresh monitor is destroyed without completing the > > Mind replacing "threaded compositor display refresh monitor" by > ThreadedDisplayRefreshMonitor ? The former is a bit difficult to read. Sure. > > Source/WebKit/ChangeLog:11 > > + need to ensure we complete the frame request before destrying the display refresh monitor to leave the > > Nit: destrying -> destroying Oops > > Source/WebKit/Shared/CoordinatedGraphics/threadedcompositor/ThreadedDisplayRefreshMonitor.cpp:94 > > + DisplayRefreshMonitor::handleDisplayRefreshedNotificationOnMainThread(this); > > Looks like DisplayReferehMonitor already protects client notifications so it > should be safe to call this even when the object is about to be destroyed. > Could you confirm that? That's right.
Comment on attachment 370932 [details] Patch Attachment 370932 [details] did not pass mac-wk2-ews (mac-wk2): Output: https://webkit-queues.webkit.org/results/12333587 New failing tests: http/wpt/service-workers/useragent.https.html
Created attachment 371008 [details] Archive of layout-test-results from ews104 for mac-highsierra-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews104 Port: mac-highsierra-wk2 Platform: Mac OS X 10.13.6
Committed r245954: <https://trac.webkit.org/changeset/245954>