Title: [251589] trunk/Source/WebKit
- Revision
- 251589
- Author
- cdu...@apple.com
- Date
- 2019-10-25 06:01:05 -0700 (Fri, 25 Oct 2019)
Log Message
[iOS] Regression(r251067) WebProcesses with service workers no longer keep their network process alive
https://bugs.webkit.org/show_bug.cgi?id=203388
<rdar://problem/56600074>
Reviewed by Geoffrey Garen.
Historically, WebProcessProxy::didSetAssertionState() used to return early for service worker processes
because we did not want service worker processes to prevent the network process from suspending. The
WebProcesses using the service worker process would prevent the network process from suspending when
they are visible, so it would work fine.
However, after r251067, there is no longer a concept of service worker process per se. Service workers
will now sometimes run in regular WebProcesses where we have pages. In such cases, didSetAssertionState()
would still return early and fail to keep its network process alive, even when the page(s) in this process
are visible on screen.
To address the issue, we now only return early if the process has a service worker but no page.
This should restore pre-existing behavior.
Note that this was causing hangs such as <rdar://problem/56245136> because the WebProcess would be
stuck on sync IPC to a suspended network process.
* UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::didSetAssertionState):
Modified Paths
Diff
Modified: trunk/Source/WebKit/ChangeLog (251588 => 251589)
--- trunk/Source/WebKit/ChangeLog 2019-10-25 12:09:06 UTC (rev 251588)
+++ trunk/Source/WebKit/ChangeLog 2019-10-25 13:01:05 UTC (rev 251589)
@@ -1,5 +1,32 @@
2019-10-25 Chris Dumez <cdu...@apple.com>
+ [iOS] Regression(r251067) WebProcesses with service workers no longer keep their network process alive
+ https://bugs.webkit.org/show_bug.cgi?id=203388
+ <rdar://problem/56600074>
+
+ Reviewed by Geoffrey Garen.
+
+ Historically, WebProcessProxy::didSetAssertionState() used to return early for service worker processes
+ because we did not want service worker processes to prevent the network process from suspending. The
+ WebProcesses using the service worker process would prevent the network process from suspending when
+ they are visible, so it would work fine.
+
+ However, after r251067, there is no longer a concept of service worker process per se. Service workers
+ will now sometimes run in regular WebProcesses where we have pages. In such cases, didSetAssertionState()
+ would still return early and fail to keep its network process alive, even when the page(s) in this process
+ are visible on screen.
+
+ To address the issue, we now only return early if the process has a service worker but no page.
+ This should restore pre-existing behavior.
+
+ Note that this was causing hangs such as <rdar://problem/56245136> because the WebProcess would be
+ stuck on sync IPC to a suspended network process.
+
+ * UIProcess/WebProcessProxy.cpp:
+ (WebKit::WebProcessProxy::didSetAssertionState):
+
+2019-10-25 Chris Dumez <cdu...@apple.com>
+
Standardize "PageID=" vs "pageID =" in release logging
https://bugs.webkit.org/show_bug.cgi?id=203002
Modified: trunk/Source/WebKit/UIProcess/WebProcessProxy.cpp (251588 => 251589)
--- trunk/Source/WebKit/UIProcess/WebProcessProxy.cpp 2019-10-25 12:09:06 UTC (rev 251588)
+++ trunk/Source/WebKit/UIProcess/WebProcessProxy.cpp 2019-10-25 13:01:05 UTC (rev 251589)
@@ -1237,8 +1237,14 @@
void WebProcessProxy::didSetAssertionState(AssertionState state)
{
#if PLATFORM(IOS_FAMILY)
- if (isRunningServiceWorkers())
+ RELEASE_LOG(ProcessSuspension, "%p - WebProcessProxy::didSetAssertionState(%u)", this, state);
+
+ if (isRunningServiceWorkers() && !pageCount()) {
+ RELEASE_LOG(ProcessSuspension, "%p - WebProcessProxy::didSetAssertionState() release all assertions for network process because this is a service worker process without page", this);
+ m_foregroundToken = nullptr;
+ m_backgroundToken = nullptr;
return;
+ }
ASSERT(!m_backgroundToken || !m_foregroundToken);
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
