To preserve energy, the WebContent process should sleep when the window is not visible.
Created attachment 345116 [details] Patch
rdar://problem/37789026
Comment on attachment 345116 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=345116&action=review > Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm:321 > + dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 5 * NSEC_PER_SEC), dispatch_get_main_queue(), ^{ This looks odd / fragile? Why this 5 seconds delay? By now call it now? Why not on a 0-delay? Also, the comment above makes little sense since the process has clearly started by now. platformInitializeProcess() gets called at a result of a InitializeProcess IPC from the UIProcess, shortly after process start up.
Comment on attachment 345116 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=345116&action=review > Source/WebKit/Configurations/WebContentService.xcconfig:64 > -RUNLOOP_TYPE_MACOS_SINCE_1014 = NSRunLoop; > +RUNLOOP_TYPE_MACOS_SINCE_1014 = _WebKit; Do we need this in other services, not just WebContent?
(In reply to Alexey Proskuryakov from comment #4) > Comment on attachment 345116 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=345116&action=review > > > Source/WebKit/Configurations/WebContentService.xcconfig:64 > > -RUNLOOP_TYPE_MACOS_SINCE_1014 = NSRunLoop; > > +RUNLOOP_TYPE_MACOS_SINCE_1014 = _WebKit; > > Do we need this in other services, not just WebContent? It is not strictly necessary, I believe. But I think it could be useful for performance reasons. Thanks for reviewing, all!
Created attachment 345119 [details] Patch
Created attachment 345148 [details] Patch
Comment on attachment 345148 [details] Patch Attachment 345148 [details] did not pass win-ews (win): Output: https://webkit-queues.webkit.org/results/8560368 New failing tests: http/tests/security/canvas-remote-read-remote-video-blocked-no-crossorigin.html
Created attachment 345149 [details] Archive of layout-test-results from ews200 for win-future The attached test failures were seen while running run-webkit-tests on the win-ews. Bot: ews200 Port: win-future Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit
Created attachment 345152 [details] Patch
Created attachment 345153 [details] Patch
Comment on attachment 345153 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=345153&action=review > Source/WebKit/WebProcess/WebPage/WebPage.cpp:682 > + if (!pageSuppressed) { Shouldn't this be before the call to m_userActivityHysteresis.start(); above? m_userActivityHysteresis.start(); Will take a UserActivity preventing AppNap so I feel like AppNap should be enabled before then. For example, you could imagine that the UserActivity would be a no-op if AppNap is disabled, then App Nap gets enabled and we're not holding a valid user activity to prevent app nap.
Created attachment 345158 [details] Patch
Comment on attachment 345158 [details] Patch r=me
(In reply to Chris Dumez from comment #14) > Comment on attachment 345158 [details] > Patch > > r=me Thanks!
Created attachment 345251 [details] Patch
Created attachment 345252 [details] Patch
Comment on attachment 345252 [details] Patch Clearing flags on attachment: 345252 Committed r233932: <https://trac.webkit.org/changeset/233932>
Marking RESOLVED FIXED as per comment #18.