Bug 187708 - The WebContent process does not suspend when MiniBrowser is minimized.
Summary: The WebContent process does not suspend when MiniBrowser is minimized.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Per Arne Vollan
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-07-16 13:00 PDT by Per Arne Vollan
Modified: 2018-08-10 14:56 PDT (History)
8 users (show)

See Also:


Attachments
Patch (3.72 KB, patch)
2018-07-16 13:13 PDT, Per Arne Vollan
no flags Details | Formatted Diff | Diff
Patch (3.77 KB, patch)
2018-07-16 14:44 PDT, Per Arne Vollan
no flags Details | Formatted Diff | Diff
Patch (3.74 KB, patch)
2018-07-16 20:39 PDT, Per Arne Vollan
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from ews200 for win-future (12.92 MB, application/zip)
2018-07-16 22:23 PDT, EWS Watchlist
no flags Details
Patch (4.25 KB, patch)
2018-07-17 07:48 PDT, Per Arne Vollan
no flags Details | Formatted Diff | Diff
Patch (4.27 KB, patch)
2018-07-17 08:20 PDT, Per Arne Vollan
no flags Details | Formatted Diff | Diff
Patch (4.61 KB, patch)
2018-07-17 09:35 PDT, Per Arne Vollan
cdumez: review+
Details | Formatted Diff | Diff
Patch (6.19 KB, patch)
2018-07-18 09:10 PDT, Per Arne Vollan
no flags Details | Formatted Diff | Diff
Patch (6.19 KB, patch)
2018-07-18 09:16 PDT, Per Arne Vollan
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Per Arne Vollan 2018-07-16 13:00:20 PDT
To preserve energy, the WebContent process should sleep when the window is not visible.
Comment 1 Per Arne Vollan 2018-07-16 13:13:27 PDT
Created attachment 345116 [details]
Patch
Comment 2 Per Arne Vollan 2018-07-16 13:14:25 PDT
rdar://problem/37789026
Comment 3 Chris Dumez 2018-07-16 13:26:26 PDT
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 4 Alexey Proskuryakov 2018-07-16 13:43:56 PDT
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?
Comment 5 Per Arne Vollan 2018-07-16 14:40:56 PDT
(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!
Comment 6 Per Arne Vollan 2018-07-16 14:44:30 PDT
Created attachment 345119 [details]
Patch
Comment 7 Per Arne Vollan 2018-07-16 20:39:49 PDT
Created attachment 345148 [details]
Patch
Comment 8 EWS Watchlist 2018-07-16 22:23:22 PDT
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
Comment 9 EWS Watchlist 2018-07-16 22:23:34 PDT
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
Comment 10 Per Arne Vollan 2018-07-17 07:48:39 PDT
Created attachment 345152 [details]
Patch
Comment 11 Per Arne Vollan 2018-07-17 08:20:47 PDT
Created attachment 345153 [details]
Patch
Comment 12 Chris Dumez 2018-07-17 08:38:06 PDT
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.
Comment 13 Per Arne Vollan 2018-07-17 09:35:06 PDT
Created attachment 345158 [details]
Patch
Comment 14 Chris Dumez 2018-07-17 09:35:51 PDT
Comment on attachment 345158 [details]
Patch

r=me
Comment 15 Per Arne Vollan 2018-07-17 09:42:37 PDT
(In reply to Chris Dumez from comment #14)
> Comment on attachment 345158 [details]
> Patch
> 
> r=me

Thanks!
Comment 16 Per Arne Vollan 2018-07-18 09:10:30 PDT
Created attachment 345251 [details]
Patch
Comment 17 Per Arne Vollan 2018-07-18 09:16:34 PDT
Created attachment 345252 [details]
Patch
Comment 18 WebKit Commit Bot 2018-07-18 14:50:07 PDT
Comment on attachment 345252 [details]
Patch

Clearing flags on attachment: 345252

Committed r233932: <https://trac.webkit.org/changeset/233932>
Comment 19 Daniel Bates 2018-08-10 14:56:21 PDT
Marking RESOLVED FIXED as per comment #18.