nephele
/
haikuwebkit
1
0
Fork 0
Code Issues Releases Activity
haikuwebkit/LayoutTests/fast/misc/{testProcessIncomingSyncMes...

12 lines
319 B
HTML
Raw Permalink Normal View History

Avoid UI Process hangs when the WebContent process is showing JS prompts / alerts https://bugs.webkit.org/show_bug.cgi?id=200107 <rdar://problem/53034592> Reviewed by Geoffrey Garen. Source/WebCore: Add testing infrastructure for SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply. Test: fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply.html * page/ChromeClient.h: * testing/Internals.cpp: (WebCore::Internals::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * testing/Internals.h: * testing/Internals.idl: Source/WebKit: * Platform/IPC/Connection.cpp: (IPC::Connection::SyncMessageState::incrementProcessIncomingSyncMessagesWhenWaitingForSyncReplyCount): (IPC::Connection::SyncMessageState::decrementProcessIncomingSyncMessagesWhenWaitingForSyncReplyCount): (IPC::Connection::SyncMessageState::processIncomingMessage): (IPC::Connection::sendSyncMessage): * Platform/IPC/Connection.h: Add support for new SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply flag to allow processing incoming sync messages while sending a particular sync IPC. This is the default behavior in all processes except in the WebContent process, where we try to avoid re-entering to prevent bugs. This flag allows the WebContent process to change its default behavior for some specific IPCs, where we know it is safe to re-enter and where it benefits performance to re-renter. * NetworkProcess/NetworkConnectionToWebProcess.cpp: (WebKit::NetworkConnectionToWebProcess::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * NetworkProcess/NetworkConnectionToWebProcess.h: * NetworkProcess/NetworkConnectionToWebProcess.messages.in: * UIProcess/Network/NetworkProcessProxy.cpp: (WebKit::NetworkProcessProxy::didReceiveSyncMessage): (WebKit::NetworkProcessProxy::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * UIProcess/Network/NetworkProcessProxy.h: * UIProcess/Network/NetworkProcessProxy.messages.in: * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * WebProcess/WebCoreSupport/WebChromeClient.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * WebProcess/WebPage/WebPage.h: (WebKit::WebPage::sendSyncWithDelayedReply): * WebProcess/WebPage/WebPage.messages.in: SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply Add testing infrastructure for SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply flag. * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::runJavaScriptAlert): (WebKit::WebChromeClient::runJavaScriptConfirm): (WebKit::WebChromeClient::runJavaScriptPrompt): Use new SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply flag when sending the synchronous IPC for JS alerts / prompt / confirm. This allows the WebProcess to process incoming synchronous IPC for other processes (in particular the UIProcess) while it is blocked on those synchronous IPCs. It is safe to re-enter the WebContent process on these sync IPCs since they are triggered by JS and we return to JS right after. This should avoid UIProcess hangs when the UIProcess is sending a sync IPC to the WebContent process, which is itself stuck on the sync IPC to show a JS alert. LayoutTests: Add layout test coverage for SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply. Without the flag on the sendSync from the WebContent process of the NetworkConnectionToWebProcess::TestProcessIncomingSyncMessagesWhenWaitingForSyncReply IPC, the test would hang. This is because the WebContent process sends a sync IPC to the network process, which in turns sends one to the UIProcess, which itself sends one back to the WebContent process. This would attempt to re-enter the WebContent process which is currently sending a sync IPC, which is not allowed by default. * fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply-expected.txt: Added. * fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply.html: Added. Canonical link: https://commits.webkit.org/213945@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247822 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-07-25 15:42:11 +00:00
<!DOCTYPE html>
<html>
<body>
<script src="../../resources/js-test.js"></script>
<script>
[iOS] WebPage::TouchEventSync() & WebPage::GetPositionInformation() sync IPC causes UIProcess hangs https://bugs.webkit.org/show_bug.cgi?id=200138 <rdar://problem/52698157> Reviewed by Geoffrey Garen. Source/WebKit: Revert most of r247822 and use an alternative approach to address hangs. In this patch, the proposal is to add a SendSyncOption::ForceDispatchWhenDestinationIsWaitingForUnboundedSyncReply flag on the WebPage::TouchEventSync() & WebPage::GetPositionInformation() sendSync() calls in the UIProcess. Those will cause this IPCs to get dispatched right away in the WebContent process, even if the WebContent process is itself currently stuck on unbounded (i.e. potentially slow) synchronous IPC (JS alerts / prompts & sync XHR). Because re-entering WebCore on sync IPC is generally unsafe, this patch also updates the WebPage::getPositionInformation() & WebPage::touchEventSync() to return early (i.e. cancelled) if they get called while the WebContent process is stuck on a slow sendSync. This approach should address the UIProcess hangs caused by the WebPage::TouchEventSync() and WebPage::GetPositionInformation() sync IPC messages when the WebContent process is busy on a slow XHR or a JS prompt / alert. It should be safe because we do not re-enter WebCore. The only drawback is that those IPCs will be cancelled (early return with default value) when the WebContent process is busy. However, I am being told that this is likely acceptable in practice. * Platform/IPC/Connection.cpp: (IPC::Connection::SyncMessageState::processIncomingMessage): (IPC::Connection::sendMessage): (IPC::Connection::sendSyncMessage): (IPC::Connection::dispatchMessage): * Platform/IPC/Connection.h: (IPC::UnboundedSynchronousIPCScope::UnboundedSynchronousIPCScope): (IPC::UnboundedSynchronousIPCScope::~UnboundedSynchronousIPCScope): (IPC::UnboundedSynchronousIPCScope::hasOngoingUnboundedSyncIPC): * Platform/IPC/Decoder.cpp: (IPC::Decoder::shouldDispatchMessageWhenWaitingForSyncReply const): * Platform/IPC/Decoder.h: * Platform/IPC/Encoder.cpp: (IPC::Encoder::shouldDispatchMessageWhenWaitingForSyncReply const): (IPC::Encoder::setShouldDispatchMessageWhenWaitingForSyncReply): (IPC::Encoder::wrapForTesting): * Platform/IPC/Encoder.h: * Platform/IPC/MessageFlags.h: * UIProcess/Network/NetworkProcessProxy.cpp: (WebKit::NetworkProcessProxy::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::handleTouchEventSynchronously): * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView ensurePositionInformationIsUpToDate:]): * WebProcess/Network/WebLoaderStrategy.cpp: (WebKit::WebLoaderStrategy::loadResourceSynchronously): * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): (WebKit::WebChromeClient::runJavaScriptAlert): (WebKit::WebChromeClient::runJavaScriptConfirm): (WebKit::WebChromeClient::runJavaScriptPrompt): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::layerVolatilityTimerFired): (WebKit::WebPage::markLayersVolatile): (WebKit::WebPage::cancelMarkLayersVolatile): (WebKit::WebPage::touchEventSync): (WebKit::WebPage::didCompletePageTransition): (WebKit::WebPage::updatePreferences): (WebKit::WebPage::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * WebProcess/WebPage/WebPage.h: (WebKit::WebPage::sendSyncWithDelayedReply): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::getPositionInformation): LayoutTests: Update existing layout test accordingly. * fast/misc/{testProcessIncomingSyncMessagesWhenWaitingForUnboundedReply-expected.txt: Renamed from LayoutTests/fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply-expected.txt. * fast/misc/{testProcessIncomingSyncMessagesWhenWaitingForUnboundedReply.html: Renamed from LayoutTests/fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply.html. Canonical link: https://commits.webkit.org/213985@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247868 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-07-26 18:27:28 +00:00
description("Test for the SendSyncOption::ForceDispatchWhenDestinationIsWaitingForUnboundedSyncReply sendSync flag");
Avoid UI Process hangs when the WebContent process is showing JS prompts / alerts https://bugs.webkit.org/show_bug.cgi?id=200107 <rdar://problem/53034592> Reviewed by Geoffrey Garen. Source/WebCore: Add testing infrastructure for SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply. Test: fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply.html * page/ChromeClient.h: * testing/Internals.cpp: (WebCore::Internals::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * testing/Internals.h: * testing/Internals.idl: Source/WebKit: * Platform/IPC/Connection.cpp: (IPC::Connection::SyncMessageState::incrementProcessIncomingSyncMessagesWhenWaitingForSyncReplyCount): (IPC::Connection::SyncMessageState::decrementProcessIncomingSyncMessagesWhenWaitingForSyncReplyCount): (IPC::Connection::SyncMessageState::processIncomingMessage): (IPC::Connection::sendSyncMessage): * Platform/IPC/Connection.h: Add support for new SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply flag to allow processing incoming sync messages while sending a particular sync IPC. This is the default behavior in all processes except in the WebContent process, where we try to avoid re-entering to prevent bugs. This flag allows the WebContent process to change its default behavior for some specific IPCs, where we know it is safe to re-enter and where it benefits performance to re-renter. * NetworkProcess/NetworkConnectionToWebProcess.cpp: (WebKit::NetworkConnectionToWebProcess::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * NetworkProcess/NetworkConnectionToWebProcess.h: * NetworkProcess/NetworkConnectionToWebProcess.messages.in: * UIProcess/Network/NetworkProcessProxy.cpp: (WebKit::NetworkProcessProxy::didReceiveSyncMessage): (WebKit::NetworkProcessProxy::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * UIProcess/Network/NetworkProcessProxy.h: * UIProcess/Network/NetworkProcessProxy.messages.in: * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * WebProcess/WebCoreSupport/WebChromeClient.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * WebProcess/WebPage/WebPage.h: (WebKit::WebPage::sendSyncWithDelayedReply): * WebProcess/WebPage/WebPage.messages.in: SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply Add testing infrastructure for SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply flag. * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::runJavaScriptAlert): (WebKit::WebChromeClient::runJavaScriptConfirm): (WebKit::WebChromeClient::runJavaScriptPrompt): Use new SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply flag when sending the synchronous IPC for JS alerts / prompt / confirm. This allows the WebProcess to process incoming synchronous IPC for other processes (in particular the UIProcess) while it is blocked on those synchronous IPCs. It is safe to re-enter the WebContent process on these sync IPCs since they are triggered by JS and we return to JS right after. This should avoid UIProcess hangs when the UIProcess is sending a sync IPC to the WebContent process, which is itself stuck on the sync IPC to show a JS alert. LayoutTests: Add layout test coverage for SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply. Without the flag on the sendSync from the WebContent process of the NetworkConnectionToWebProcess::TestProcessIncomingSyncMessagesWhenWaitingForSyncReply IPC, the test would hang. This is because the WebContent process sends a sync IPC to the network process, which in turns sends one to the UIProcess, which itself sends one back to the WebContent process. This would attempt to re-enter the WebContent process which is currently sending a sync IPC, which is not allowed by default. * fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply-expected.txt: Added. * fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply.html: Added. Canonical link: https://commits.webkit.org/213945@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247822 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-07-25 15:42:11 +00:00
shouldBeTrue("internals.testProcessIncomingSyncMessagesWhenWaitingForSyncReply()");
</script>
</body>
</html>