Bug 187708 – The WebContent process does not suspend when MiniBrowser is minimized.

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit Misc.

[Per Arne Vollan]

To preserve energy, the WebContent process should sleep when the window is not visible.

[Per Arne Vollan]

Created attachment 345116 [details]
Patch

[Per Arne Vollan]

rdar://problem/37789026

[Chris Dumez]

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.

[Alexey Proskuryakov]

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?

[Per Arne Vollan]

(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!

[Per Arne Vollan]

Created attachment 345119 [details]
Patch

[Per Arne Vollan]

Created attachment 345148 [details]
Patch

[EWS Watchlist]

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

[EWS Watchlist]

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

[Per Arne Vollan]

Created attachment 345152 [details]
Patch

[Per Arne Vollan]

Created attachment 345153 [details]
Patch

[Chris Dumez]

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.

[Per Arne Vollan]

Created attachment 345158 [details]
Patch

[Chris Dumez]

Comment on attachment 345158 [details]
Patch

r=me

[Per Arne Vollan]

(In reply to Chris Dumez from comment #14)
> Comment on attachment 345158 [details]
> Patch
> 
> r=me

Thanks!

[Per Arne Vollan]

Created attachment 345251 [details]
Patch

[Per Arne Vollan]

Created attachment 345252 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 345252 [details]
Patch

Clearing flags on attachment: 345252

Committed r233932: <https://trac.webkit.org/changeset/233932>

[Daniel Bates]

Marking RESOLVED FIXED as per comment #18.