Bug 187708

Summary:

The WebContent process does not suspend when MiniBrowser is minimized.

Product:

WebKit

Reporter:

Per Arne Vollan <pvollan>

Component:

WebKit Misc.

Assignee:

Per Arne Vollan <pvollan>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

bfulgham, cdumez, commit-queue, dbates, ews-watchlist, ggaren, rniwa, webkit-bug-importer

Priority:

Keywords:

InRadar

Version:

WebKit Nightly Build

Hardware:

Unspecified

OS:

Unspecified

Attachments:

Description	Flags
Patch	none
Patch	none
Patch	none
Archive of layout-test-results from ews200 for win-future	none
Patch	none
Patch	none
Patch	cdumez: review+
Patch	none
Patch	none

Per Arne Vollan

Reported 2018-07-16 13:00:20 PDT

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

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
Show Obsolete (7) View All Add attachment proposed patch, testcase, etc.

Per Arne Vollan

Comment 1 2018-07-16 13:13:27 PDT

Created attachment 345116 [details] Patch

Per Arne Vollan

Comment 2 2018-07-16 13:14:25 PDT

rdar://problem/37789026

Chris Dumez

Comment 3 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.

Alexey Proskuryakov

Comment 4 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?

Per Arne Vollan

Comment 5 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!

Per Arne Vollan

Comment 6 2018-07-16 14:44:30 PDT

Created attachment 345119 [details] Patch

Per Arne Vollan

Comment 7 2018-07-16 20:39:49 PDT

Created attachment 345148 [details] Patch

EWS Watchlist

Comment 8 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

EWS Watchlist

Comment 9 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

Per Arne Vollan

Comment 10 2018-07-17 07:48:39 PDT

Created attachment 345152 [details] Patch

Per Arne Vollan

Comment 11 2018-07-17 08:20:47 PDT

Created attachment 345153 [details] Patch

Chris Dumez

Comment 12 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.

Per Arne Vollan

Comment 13 2018-07-17 09:35:06 PDT

Created attachment 345158 [details] Patch

Chris Dumez

Comment 14 2018-07-17 09:35:51 PDT

Comment on attachment 345158 [details] Patch r=me

Per Arne Vollan

Comment 15 2018-07-17 09:42:37 PDT

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

Per Arne Vollan

Comment 16 2018-07-18 09:10:30 PDT

Created attachment 345251 [details] Patch