2019-04-19 Kocsen Chung Cherry-pick r244458. rdar://problem/50041560 YouTube and Twitter embeds don't load in News https://bugs.webkit.org/show_bug.cgi?id=197111 Reviewed by Timothy Hatcher. * WebProcess/com.apple.WebProcess.sb.in: Adjust this sandbox exception to include both platforms. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@244458 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-04-19 Tim Horton YouTube and Twitter embeds don't load in News https://bugs.webkit.org/show_bug.cgi?id=197111 Reviewed by Timothy Hatcher. * WebProcess/com.apple.WebProcess.sb.in: Adjust this sandbox exception to include both platforms. 2019-04-14 Babak Shafiei Cherry-pick r243487. rdar://problem/49788895 Do not terminate the NetworkProcess if a third party application sends a NSCredential with a SecIdentityRef https://bugs.webkit.org/show_bug.cgi?id=196213 Patch by Alex Christensen on 2019-03-25 Reviewed by Geoff Garen. Source/WebKit: A release assertion added in r230225 was reachable. I reached it in a unit test that responds to a challenge with a SecIdentityRef wrapped in an NSCredential. * Shared/cf/ArgumentCodersCF.cpp: (IPC::decode): Tools: * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKitCocoa/Challenge.mm: Added. (credentialWithIdentityAndKeychainPath): (-[ChallengeDelegate webView:didFinishNavigation:]): (-[ChallengeDelegate webView:didReceiveAuthenticationChallenge:completionHandler:]): (TestWebKitAPI::TEST): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@243487 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-25 Alex Christensen Do not terminate the NetworkProcess if a third party application sends a NSCredential with a SecIdentityRef https://bugs.webkit.org/show_bug.cgi?id=196213 Reviewed by Geoff Garen. A release assertion added in r230225 was reachable. I reached it in a unit test that responds to a challenge with a SecIdentityRef wrapped in an NSCredential. * Shared/cf/ArgumentCodersCF.cpp: (IPC::decode): 2019-04-11 Kocsen Chung Revert r244165. rdar://problem/49788895 2019-04-11 Alan Coon Apply patch. rdar://problem/49788956 2019-04-11 Chris Dumez WebProcessCache should keep track of processes being added https://bugs.webkit.org/show_bug.cgi?id=195538 Reviewed by Geoffrey Garen. WebProcessCache should keep track of processes being added, while they are being checked for responsiveness. This is useful so that: - Requests to clear the cache also clear processes being added - Requests to remove a given process from the cache (either because it crashed or because it is being used for a history navigation) actually remove the process if it is still being checked for responsiveness. - The cached process eviction timer applies to such processes in case something goes wrong with the code and the pending request does not get processed. * UIProcess/WebProcessCache.cpp: (WebKit::generateAddRequestIdentifier): (WebKit::WebProcessCache::addProcessIfPossible): (WebKit::WebProcessCache::addProcess): (WebKit::WebProcessCache::clear): (WebKit::WebProcessCache::clearAllProcessesForSession): (WebKit::WebProcessCache::removeProcess): (WebKit::WebProcessCache::CachedProcess::evictionTimerFired): (WebKit::WebProcessCache::evictProcess): Deleted. * UIProcess/WebProcessCache.h: (WebKit::WebProcessCache::size const): * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::processForNavigationInternal): * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::processDidTerminateOrFailedToLaunch): 2019-04-10 Alan Coon Cherry-pick r243841. rdar://problem/49725678 -apple-trailing-word is needed for browser detection https://bugs.webkit.org/show_bug.cgi?id=196575 Unreviewed. PerformanceTests: * MotionMark/resources/debug-runner/motionmark.css: (#intro .start-benchmark p): Source/JavaScriptCore: * Configurations/FeatureDefines.xcconfig: Source/WebCore: This is an unreviewed partial revert of r243819. Turns out there are some websites which use this property to do browser detection. So, we need to continue to parse the property, but we don't need the property to do anything. Test: fast/text/trailing-word-detection.html * Configurations/FeatureDefines.xcconfig: * css/CSSComputedStyleDeclaration.cpp: (WebCore::ComputedStyleExtractor::valueForPropertyinStyle): * css/CSSPrimitiveValueMappings.h: (WebCore::CSSPrimitiveValue::CSSPrimitiveValue): (WebCore::CSSPrimitiveValue::operator TrailingWord const): * css/CSSProperties.json: * css/CSSValueKeywords.in: * css/parser/CSSParserFastPaths.cpp: (WebCore::CSSParserFastPaths::isValidKeywordPropertyAndValue): (WebCore::CSSParserFastPaths::isKeywordPropertyID): * rendering/style/RenderStyle.h: (WebCore::RenderStyle::trailingWord const): (WebCore::RenderStyle::setTrailingWord): (WebCore::RenderStyle::initialTrailingWord): * rendering/style/RenderStyleConstants.h: Source/WebCore/PAL: * Configurations/FeatureDefines.xcconfig: Source/WebKit: * Configurations/FeatureDefines.xcconfig: Source/WebKitLegacy/mac: * Configurations/FeatureDefines.xcconfig: Tools: * TestWebKitAPI/Configurations/FeatureDefines.xcconfig: LayoutTests: * fast/text/trailing-word-detection-expected.txt: Added. * fast/text/trailing-word-detection.html: Added. * platform/gtk/TestExpectations: * platform/win/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@243841 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-04-03 Myles C. Maxfield -apple-trailing-word is needed for browser detection https://bugs.webkit.org/show_bug.cgi?id=196575 Unreviewed. * Configurations/FeatureDefines.xcconfig: 2019-04-10 Alan Coon Cherry-pick r243819. rdar://problem/49725678 Remove support for -apple-trailing-word https://bugs.webkit.org/show_bug.cgi?id=196525 Reviewed by Zalan Bujtas. This CSS property is nonstandard and not used. .: * Source/cmake/WebKitFeatures.cmake: Source/JavaScriptCore: * Configurations/FeatureDefines.xcconfig: Source/WebCore: * Configurations/FeatureDefines.xcconfig: * css/CSSComputedStyleDeclaration.cpp: (WebCore::ComputedStyleExtractor::valueForPropertyinStyle): * css/CSSPrimitiveValueMappings.h: (WebCore::CSSPrimitiveValue::operator TrailingWord const): Deleted. * css/CSSProperties.json: * css/CSSValueKeywords.in: * css/parser/CSSParserFastPaths.cpp: (WebCore::CSSParserFastPaths::isValidKeywordPropertyAndValue): (WebCore::CSSParserFastPaths::isKeywordPropertyID): * rendering/SimpleLineLayout.cpp: (WebCore::SimpleLineLayout::canUseForStyle): * rendering/SimpleLineLayoutCoverage.cpp: (WebCore::SimpleLineLayout::printReason): * rendering/SimpleLineLayoutCoverage.h: * rendering/line/BreakingContext.h: (WebCore::BreakingContext::BreakingContext): (WebCore::BreakingContext::lineBreak): (WebCore::BreakingContext::clearLineBreakIfFitsOnLine): (WebCore::BreakingContext::commitLineBreakClear): (WebCore::BreakingContext::commitLineBreakAtCurrentWidth): (WebCore::BreakingContext::handleBR): (WebCore::BreakingContext::handleFloat): (WebCore::BreakingContext::handleText): (WebCore::BreakingContext::handleEndOfLine): (WebCore::BreakingContext::InlineIteratorHistory::InlineIteratorHistory): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::push): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::update): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::renderer const): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::offset const): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::nextBreakablePosition const): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::atTextParagraphSeparator const): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::previousInSameNode const): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::get const): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::current const): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::historyLength const): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::moveTo): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::increment): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::clear): Deleted. (WebCore::BreakingContext::optimalLineBreakLocationForTrailingWord): Deleted. * rendering/style/RenderStyle.h: (WebCore::RenderStyle::trailingWord const): Deleted. (WebCore::RenderStyle::setTrailingWord): Deleted. (WebCore::RenderStyle::initialTrailingWord): Deleted. * rendering/style/RenderStyleConstants.h: * rendering/style/StyleRareInheritedData.cpp: (WebCore::StyleRareInheritedData::StyleRareInheritedData): (WebCore::StyleRareInheritedData::operator== const): * rendering/style/StyleRareInheritedData.h: Source/WebCore/PAL: * Configurations/FeatureDefines.xcconfig: Source/WebInspectorUI: * UserInterface/Models/CSSKeywordCompletions.js: Source/WebKit: * Configurations/FeatureDefines.xcconfig: Source/WebKitLegacy/mac: * Configurations/FeatureDefines.xcconfig: Tools: * Scripts/webkitperl/FeatureList.pm: * TestWebKitAPI/Configurations/FeatureDefines.xcconfig: LayoutTests: * fast/text/trailing-word-expected.html: Removed. * fast/text/trailing-word.html: Removed. * platform/gtk/TestExpectations: * platform/mac/fast/text/trailing-word-parse-expected.txt: Removed. * platform/mac/fast/text/trailing-word-parse.html: Removed. * platform/win/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@243819 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-04-03 Myles C. Maxfield Remove support for -apple-trailing-word https://bugs.webkit.org/show_bug.cgi?id=196525 Reviewed by Zalan Bujtas. This CSS property is nonstandard and not used. * Configurations/FeatureDefines.xcconfig: 2019-04-10 Alan Coon Cherry-pick r243487. rdar://problem/49788895 Do not terminate the NetworkProcess if a third party application sends a NSCredential with a SecIdentityRef https://bugs.webkit.org/show_bug.cgi?id=196213 Patch by Alex Christensen on 2019-03-25 Reviewed by Geoff Garen. Source/WebKit: A release assertion added in r230225 was reachable. I reached it in a unit test that responds to a challenge with a SecIdentityRef wrapped in an NSCredential. * Shared/cf/ArgumentCodersCF.cpp: (IPC::decode): Tools: * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKitCocoa/Challenge.mm: Added. (credentialWithIdentityAndKeychainPath): (-[ChallengeDelegate webView:didFinishNavigation:]): (-[ChallengeDelegate webView:didReceiveAuthenticationChallenge:completionHandler:]): (TestWebKitAPI::TEST): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@243487 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-25 Alex Christensen Do not terminate the NetworkProcess if a third party application sends a NSCredential with a SecIdentityRef https://bugs.webkit.org/show_bug.cgi?id=196213 Reviewed by Geoff Garen. A release assertion added in r230225 was reachable. I reached it in a unit test that responds to a challenge with a SecIdentityRef wrapped in an NSCredential. * Shared/cf/ArgumentCodersCF.cpp: (IPC::decode): 2019-04-09 Alan Coon Cherry-pick r243562. rdar://problem/49725686 [ iOS Sim ] REGRESSION (r242277) Layout Test http/tests/cookies/same-site/lax-samesite-cookie-after-cross-site-history-load.php is a flaky timeout https://bugs.webkit.org/show_bug.cgi?id=195425 Reviewed by Alex Christensen. When process-swapping on history navigation, we lookup the WebProcessProxy we'd like to use from the process identifier that is saved on the WebBackForwardListItem, to try and load the item in the process in which it was previously loaded. However, we were failing to check if the WebProcess in question was still running so we could potentially try to use a process that's already exited. * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::processForNavigationInternal): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@243562 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-27 Chris Dumez [ iOS Sim ] REGRESSION (r242277) Layout Test http/tests/cookies/same-site/lax-samesite-cookie-after-cross-site-history-load.php is a flaky timeout https://bugs.webkit.org/show_bug.cgi?id=195425 Reviewed by Alex Christensen. When process-swapping on history navigation, we lookup the WebProcessProxy we'd like to use from the process identifier that is saved on the WebBackForwardListItem, to try and load the item in the process in which it was previously loaded. However, we were failing to check if the WebProcess in question was still running so we could potentially try to use a process that's already exited. * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::processForNavigationInternal): 2019-04-09 Alan Coon Cherry-pick r243848. rdar://problem/49725697 The page's focusedFrame / frameSetLargestFrame do not get cleared on process swap or crash https://bugs.webkit.org/show_bug.cgi?id=196588 Reviewed by Ryosuke Niwa. Source/WebKit: The page's focusedFrame / frameSetLargestFrame do not get cleared on process swap or crash. This can lead to returning stale frames to the client if it asks for those. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::resetState): Tools: Add API test coverage. * TestWebKitAPI/Tests/WebKit/ReloadPageAfterCrash.cpp: (TestWebKitAPI::nullJavaScriptCallback): (TestWebKitAPI::didCrashCheckFrames): (TestWebKitAPI::TEST): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@243848 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-04-03 Chris Dumez The page's focusedFrame / frameSetLargestFrame do not get cleared on process swap or crash https://bugs.webkit.org/show_bug.cgi?id=196588 Reviewed by Ryosuke Niwa. The page's focusedFrame / frameSetLargestFrame do not get cleared on process swap or crash. This can lead to returning stale frames to the client if it asks for those. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::resetState): 2019-03-27 Alan Coon Cherry-pick r243291. rdar://problem/49307996 Fix possible memory leak when dismissing a color picker https://bugs.webkit.org/show_bug.cgi?id=196026 Reviewed by Wenson Hsieh. Fix a problem with WebPageProxy::endColorPicker where an early return could leave a color picker with a +1 reference count after dismissing it. * UIProcess/WebColorPicker.cpp: (WebKit::WebColorPicker::endPicker): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::endColorPicker): (WebKit::WebPageProxy::didEndColorPicker): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@243291 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-21 Brent Fulgham Fix possible memory leak when dismissing a color picker https://bugs.webkit.org/show_bug.cgi?id=196026 Reviewed by Wenson Hsieh. Fix a problem with WebPageProxy::endColorPicker where an early return could leave a color picker with a +1 reference count after dismissing it. * UIProcess/WebColorPicker.cpp: (WebKit::WebColorPicker::endPicker): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::endColorPicker): (WebKit::WebPageProxy::didEndColorPicker): 2019-03-27 Alan Coon Apply patch. rdar://problem/49307967 fix-radar-48878188 2019-03-14 Youenn Fablet v2: CrashTracer: MobileSafari at WebKit: WebKit::WebPageProxy::setMediaStreamCaptureMuted. rdar://problem/48878188. There are cases where we might not update correctly the stateMap in UserMediaProcessManager.cpp. One such case is: - UserMediaPermissionRequestManagerProxy registers itself at construction time in a map whose key is the page process - UserMediaPermissionRequestManagerProxy unregisters itself at destruction time by using the page process as well. - Page changed process in some cases without UserMediaPermissionRequestManagerProxy being destroyed. In Jazzkon, a new model was implemented that removed the need for this map. For F, to ensure that we do not use wrong managers, keep a Vector of WeakPtr instead of a Vector of raw pointers. Whenever getting the managers, check whether some of them are destroyed and remove them from the vector. * UIProcess/UserMediaProcessManager.cpp: (WebKit::ProcessState::managers): (WebKit::ProcessState::addRequestManager): (WebKit::ProcessState::removeRequestManager): 2019-03-18 Kocsen Chung Apply patch. rdar://problem/48839387 2019-03-18 John Wilander Resource Load Statistics: Further restrict client-side cookie persistence after cross-site navigations with link decoration (branch patch) https://bugs.webkit.org/show_bug.cgi?id=195711 Reviewed by Brent Fulgham. This patch does three things: 1) Applies the changes in https://trac.webkit.org/changeset/242288 to a branch. The only meaningful difference is the use of String instead of WebCore::RegistrableDomain. Tracked by . 2) Set the lifetime cap for client-side cookies in the call to NetworkStorageSession::setPrevalentDomainsToBlockCookiesFor(). This change makes sure that if ITP is enabled, the cap will be applied. Previously, the cap was set when WebProcessPool::ensureNetworkProcess() called WebsiteDataStore::didCreateNetworkProcess() which might fail if the website data store's m_resourceLoadStatistics object is not created yet. Tracked by . 3) Makes sure WebProcessPool::ensureNetworkProcess() calls WebsiteDataStore::didCreateNetworkProcess() also if there was an existing website data store object supplied (the withWebsiteDataStore parameter). Tracked by . * NetworkProcess/NetworkConnectionToWebProcess.cpp: (WebKit::NetworkConnectionToWebProcess::clearPageSpecificDataForResourceLoadStatistics): (WebKit::NetworkConnectionToWebProcess::removeStorageAccessForAllFramesOnPage): Deleted. * NetworkProcess/NetworkConnectionToWebProcess.h: * NetworkProcess/NetworkConnectionToWebProcess.messages.in: * NetworkProcess/NetworkProcess.cpp: (WebKit::NetworkProcess::committedCrossSiteLoadWithLinkDecoration): (WebKit::NetworkProcess::resetCrossSiteLoadsWithLinkDecorationForTesting): * NetworkProcess/NetworkProcess.h: * NetworkProcess/NetworkProcess.messages.in: * UIProcess/API/C/WKWebsiteDataStoreRef.cpp: (WKWebsiteDataStoreStatisticsResetToConsistentState): * UIProcess/Network/NetworkProcessProxy.cpp: (WebKit::NetworkProcessProxy::resetCrossSiteLoadsWithLinkDecorationForTesting): * UIProcess/Network/NetworkProcessProxy.h: * UIProcess/ResourceLoadStatisticsMemoryStore.cpp: (WebKit::ResourceLoadStatisticsMemoryStore::didCreateNetworkProcess): * UIProcess/WebPageProxy.cpp: (WebKit::isNonUniqueNavigationWithLinkDecoration): (WebKit::WebPageProxy::didCommitLoadForFrame): * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::ensureNetworkProcess): * UIProcess/WebsiteData/WebsiteDataStore.cpp: (WebKit::WebsiteDataStore::resetCrossSiteLoadsWithLinkDecorationForTesting): * UIProcess/WebsiteData/WebsiteDataStore.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::close): 2019-03-06 Kocsen Chung Cherry-pick r242554. rdar://problem/48647490 REGRESSION (r238490): YouTube.com: Returning PiP to Safari after sleeping device loses page https://bugs.webkit.org/show_bug.cgi?id=195364 Reviewed by Geoffrey Garen. Make sure we unset the LayerTreeFreezeReason::ProcessSuspended layer tree freeze reason when WebPage::applicationWillEnterForeground() is called. This restores pre-r238490 behavior and addresses the issue with PiP on youtube.com. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::applicationWillEnterForeground): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242554 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-06 Chris Dumez REGRESSION (r238490): YouTube.com: Returning PiP to Safari after sleeping device loses page https://bugs.webkit.org/show_bug.cgi?id=195364 Reviewed by Geoffrey Garen. Make sure we unset the LayerTreeFreezeReason::ProcessSuspended layer tree freeze reason when WebPage::applicationWillEnterForeground() is called. This restores pre-r238490 behavior and addresses the issue with PiP on youtube.com. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::applicationWillEnterForeground): 2019-03-13 Babak Shafiei Apply patch. rdar://problem/48839383 Cherry-pick r242230. rdar://problem/48839383 Revert r232263: it caused processes to crash because process was suspended with locked file https://bugs.webkit.org/show_bug.cgi?id=195122 Reviewed by Geoffrey Garen. * NetworkProcess/NetworkProcess.cpp: (WebKit::NetworkProcess::NetworkProcess): * NetworkProcess/NetworkProcess.h: * Shared/WebSQLiteDatabaseTracker.cpp: (WebKit::WebSQLiteDatabaseTracker::WebSQLiteDatabaseTracker): (WebKit::WebSQLiteDatabaseTracker::hysteresisUpdated): * Shared/WebSQLiteDatabaseTracker.h: * WebProcess/WebProcess.cpp: (WebKit::m_webSQLiteDatabaseTracker): (WebKit::m_nonVisibleProcessCleanupTimer): Deleted. * WebProcess/WebProcess.h: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@242230 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-13 Babak Shafiei Cherry-pick r242230. rdar://problem/48839383 Revert r232263: it caused processes to crash because process was suspended with locked file https://bugs.webkit.org/show_bug.cgi?id=195122 Reviewed by Geoffrey Garen. * NetworkProcess/NetworkProcess.cpp: (WebKit::NetworkProcess::NetworkProcess): * NetworkProcess/NetworkProcess.h: * Shared/WebSQLiteDatabaseTracker.cpp: (WebKit::WebSQLiteDatabaseTracker::WebSQLiteDatabaseTracker): (WebKit::WebSQLiteDatabaseTracker::hysteresisUpdated): * Shared/WebSQLiteDatabaseTracker.h: * WebProcess/WebProcess.cpp: (WebKit::m_webSQLiteDatabaseTracker): (WebKit::m_nonVisibleProcessCleanupTimer): Deleted. * WebProcess/WebProcess.h: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@242230 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-28 Sihui Liu Revert r232263: it caused processes to crash because process was suspended with locked file https://bugs.webkit.org/show_bug.cgi?id=195122 Reviewed by Geoffrey Garen. * NetworkProcess/NetworkProcess.cpp: (WebKit::NetworkProcess::NetworkProcess): * NetworkProcess/NetworkProcess.h: * Shared/WebSQLiteDatabaseTracker.cpp: (WebKit::WebSQLiteDatabaseTracker::WebSQLiteDatabaseTracker): (WebKit::WebSQLiteDatabaseTracker::hysteresisUpdated): * Shared/WebSQLiteDatabaseTracker.h: * WebProcess/WebProcess.cpp: (WebKit::m_webSQLiteDatabaseTracker): (WebKit::m_nonVisibleProcessCleanupTimer): Deleted. * WebProcess/WebProcess.h: 2019-03-13 Babak Shafiei Cherry-pick r242735. rdar://problem/48780112 Add a WKContentRuleList variant that uses copied memory instead of mmap'd shared memory for class A containerized apps https://bugs.webkit.org/show_bug.cgi?id=195511 Patch by Alex Christensen on 2019-03-11 Reviewed by Darin Adler. Source/WebKit: * NetworkProcess/NetworkContentRuleListManager.cpp: (WebKit::NetworkContentRuleListManager::addContentRuleLists): * NetworkProcess/NetworkContentRuleListManager.h: * NetworkProcess/cache/NetworkCacheFileSystem.cpp: (WebKit::NetworkCache::pathRegisteredAsUnsafeToMemoryMapForTesting): (WebKit::NetworkCache::registerPathAsUnsafeToMemoryMapForTesting): (WebKit::NetworkCache::isSafeToUseMemoryMapForPath): * NetworkProcess/cache/NetworkCacheFileSystem.h: * Shared/WebCompiledContentRuleList.cpp: (WebKit::WebCompiledContentRuleList::usesCopiedMemory const): (WebKit::WebCompiledContentRuleList::conditionsApplyOnlyToDomain const): (WebKit::WebCompiledContentRuleList::filtersWithoutConditionsBytecode const): (WebKit::WebCompiledContentRuleList::filtersWithConditionsBytecode const): (WebKit::WebCompiledContentRuleList::topURLFiltersBytecode const): (WebKit::WebCompiledContentRuleList::actions const): * Shared/WebCompiledContentRuleList.h: * Shared/WebCompiledContentRuleListData.cpp: (WebKit::WebCompiledContentRuleListData::size const): (WebKit::WebCompiledContentRuleListData::dataPointer const): (WebKit::WebCompiledContentRuleListData::encode const): (WebKit::WebCompiledContentRuleListData::decode): * Shared/WebCompiledContentRuleListData.h: (WebKit::WebCompiledContentRuleListData::WebCompiledContentRuleListData): * UIProcess/API/APIContentRuleList.cpp: (API::ContentRuleList::usesCopiedMemory const): * UIProcess/API/APIContentRuleList.h: * UIProcess/API/APIContentRuleListStore.cpp: (API::getData): (API::decodeContentRuleListMetaData): (API::ContentRuleListStore::readContentsOfFile): (API::MappedOrCopiedData::dataPointer const): (API::openAndMapOrCopyContentRuleList): (API::compiledToFile): (API::createExtension): (API::ContentRuleListStore::lookupContentRuleList): (API::ContentRuleListStore::compileContentRuleList): (API::ContentRuleListStore::getContentRuleListSource): (API::openAndMapContentRuleList): Deleted. * UIProcess/API/APIContentRuleListStore.h: * UIProcess/API/Cocoa/APIContentRuleListStoreCocoa.mm: (API::ContentRuleListStore::readContentsOfFile): * UIProcess/API/Cocoa/WKContentRuleListStore.mm: (+[WKContentRuleListStore _registerPathAsUnsafeToMemoryMapForTesting:]): * UIProcess/API/Cocoa/WKContentRuleListStorePrivate.h: * UIProcess/API/Cocoa/_WKUserContentFilter.mm: (-[_WKUserContentFilter usesCopiedMemory]): * UIProcess/API/Cocoa/_WKUserContentFilterPrivate.h: * WebProcess/UserContent/WebUserContentController.cpp: (WebKit::WebUserContentController::addContentRuleLists): * WebProcess/UserContent/WebUserContentController.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::m_hostFileDescriptor): Tools: * TestWebKitAPI/Tests/WebKitCocoa/WKContentExtensionStore.mm: (-[TestSchemeHandlerSubresourceShouldBeBlocked webView:startURLSchemeTask:]): (-[TestSchemeHandlerSubresourceShouldBeBlocked webView:stopURLSchemeTask:]): (TEST_F): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242735 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-11 Alex Christensen Add a WKContentRuleList variant that uses copied memory instead of mmap'd shared memory for class A containerized apps https://bugs.webkit.org/show_bug.cgi?id=195511 Reviewed by Darin Adler. * NetworkProcess/NetworkContentRuleListManager.cpp: (WebKit::NetworkContentRuleListManager::addContentRuleLists): * NetworkProcess/NetworkContentRuleListManager.h: * NetworkProcess/cache/NetworkCacheFileSystem.cpp: (WebKit::NetworkCache::pathRegisteredAsUnsafeToMemoryMapForTesting): (WebKit::NetworkCache::registerPathAsUnsafeToMemoryMapForTesting): (WebKit::NetworkCache::isSafeToUseMemoryMapForPath): * NetworkProcess/cache/NetworkCacheFileSystem.h: * Shared/WebCompiledContentRuleList.cpp: (WebKit::WebCompiledContentRuleList::usesCopiedMemory const): (WebKit::WebCompiledContentRuleList::conditionsApplyOnlyToDomain const): (WebKit::WebCompiledContentRuleList::filtersWithoutConditionsBytecode const): (WebKit::WebCompiledContentRuleList::filtersWithConditionsBytecode const): (WebKit::WebCompiledContentRuleList::topURLFiltersBytecode const): (WebKit::WebCompiledContentRuleList::actions const): * Shared/WebCompiledContentRuleList.h: * Shared/WebCompiledContentRuleListData.cpp: (WebKit::WebCompiledContentRuleListData::size const): (WebKit::WebCompiledContentRuleListData::dataPointer const): (WebKit::WebCompiledContentRuleListData::encode const): (WebKit::WebCompiledContentRuleListData::decode): * Shared/WebCompiledContentRuleListData.h: (WebKit::WebCompiledContentRuleListData::WebCompiledContentRuleListData): * UIProcess/API/APIContentRuleList.cpp: (API::ContentRuleList::usesCopiedMemory const): * UIProcess/API/APIContentRuleList.h: * UIProcess/API/APIContentRuleListStore.cpp: (API::getData): (API::decodeContentRuleListMetaData): (API::ContentRuleListStore::readContentsOfFile): (API::MappedOrCopiedData::dataPointer const): (API::openAndMapOrCopyContentRuleList): (API::compiledToFile): (API::createExtension): (API::ContentRuleListStore::lookupContentRuleList): (API::ContentRuleListStore::compileContentRuleList): (API::ContentRuleListStore::getContentRuleListSource): (API::openAndMapContentRuleList): Deleted. * UIProcess/API/APIContentRuleListStore.h: * UIProcess/API/Cocoa/APIContentRuleListStoreCocoa.mm: (API::ContentRuleListStore::readContentsOfFile): * UIProcess/API/Cocoa/WKContentRuleListStore.mm: (+[WKContentRuleListStore _registerPathAsUnsafeToMemoryMapForTesting:]): * UIProcess/API/Cocoa/WKContentRuleListStorePrivate.h: * UIProcess/API/Cocoa/_WKUserContentFilter.mm: (-[_WKUserContentFilter usesCopiedMemory]): * UIProcess/API/Cocoa/_WKUserContentFilterPrivate.h: * WebProcess/UserContent/WebUserContentController.cpp: (WebKit::WebUserContentController::addContentRuleLists): * WebProcess/UserContent/WebUserContentController.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::m_hostFileDescriptor): 2019-03-13 Babak Shafiei Cherry-pick r242587. rdar://problem/48839354 Crash when attempting to change input type while dismissing datalist suggestions https://bugs.webkit.org/show_bug.cgi?id=195384 Reviewed by Brent Fulgham. Source/WebCore: When closing a datalist suggestion menu, WebPageProxy sends a message to WebPage instructing it to tell its active datalist suggestions picker to close. However, for a myriad of reasons, the suggestions picker (kept alive by its text input type) may have already gone away by this point. To mitigate this, make WebPage weakly reference its active datalist suggestions picker. Test: fast/forms/datalist/change-input-type-after-closing-datalist-suggestions.html * platform/DataListSuggestionPicker.h: Make DataListSuggestionPicker capable of being weakly referenced. Additionally, fix some minor preexisting issues in this header (#imports instead of #includes, as well as an unnecessary include of IntRect.h). Source/WebKit: See WebCore ChangeLog for more details. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::setActiveDataListSuggestionPicker): (WebKit::WebPage::didSelectDataListOption): (WebKit::WebPage::didCloseSuggestions): * WebProcess/WebPage/WebPage.h: Turn m_activeDataListSuggestionPicker from a raw pointer into a WeakPtr. LayoutTests: Add a new layout test to exercise this scenario. * fast/forms/datalist/change-input-type-after-closing-datalist-suggestions-expected.txt: Added. * fast/forms/datalist/change-input-type-after-closing-datalist-suggestions.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242587 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-06 Wenson Hsieh Crash when attempting to change input type while dismissing datalist suggestions https://bugs.webkit.org/show_bug.cgi?id=195384 Reviewed by Brent Fulgham. See WebCore ChangeLog for more details. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::setActiveDataListSuggestionPicker): (WebKit::WebPage::didSelectDataListOption): (WebKit::WebPage::didCloseSuggestions): * WebProcess/WebPage/WebPage.h: Turn m_activeDataListSuggestionPicker from a raw pointer into a WeakPtr. 2019-03-13 Babak Shafiei Cherry-pick r241452. rdar://problem/48839390 Make WebRTCUnifiedPlanEnabled true by default https://bugs.webkit.org/show_bug.cgi?id=194595 Reviewed by Eric Carlson. * Shared/WebPreferences.yaml: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241452 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-13 Youenn Fablet Make WebRTCUnifiedPlanEnabled true by default https://bugs.webkit.org/show_bug.cgi?id=194595 Reviewed by Eric Carlson. * Shared/WebPreferences.yaml: 2019-03-13 Babak Shafiei Cherry-pick r241002. rdar://problem/48839377 UserMediaPermissionRequestManagerProxy lambdas should check for 'this' being valid https://bugs.webkit.org/show_bug.cgi?id=194246 Reviewed by Eric Carlson. With PSON enabled, the manager proxy can be destroyed. It is thus important for its callbacks to check for 'this' to be valid. * UIProcess/UserMediaPermissionRequestManagerProxy.cpp: (WebKit::UserMediaPermissionRequestManagerProxy::captureDevicesChanged): (WebKit::UserMediaPermissionRequestManagerProxy::requestUserMediaPermissionForFrame): (WebKit::UserMediaPermissionRequestManagerProxy::enumerateMediaDevicesForFrame): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241002 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-05 Youenn Fablet UserMediaPermissionRequestManagerProxy lambdas should check for 'this' being valid https://bugs.webkit.org/show_bug.cgi?id=194246 Reviewed by Eric Carlson. With PSON enabled, the manager proxy can be destroyed. It is thus important for its callbacks to check for 'this' to be valid. * UIProcess/UserMediaPermissionRequestManagerProxy.cpp: (WebKit::UserMediaPermissionRequestManagerProxy::captureDevicesChanged): (WebKit::UserMediaPermissionRequestManagerProxy::requestUserMediaPermissionForFrame): (WebKit::UserMediaPermissionRequestManagerProxy::enumerateMediaDevicesForFrame): 2019-03-12 Kocsen Chung Cherry-pick r242502. rdar://problem/48591282 Cherry-pick r242394. rdar://problem/48591281 Unreviewed build fix after r242378 * UIProcess/ios/EditableImageController.mm: (WebKit::EditableImageController::associateWithAttachment): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242394 268f45cc-cd09-0410-ab3c-d52691b4dbfc git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-607.1.40.0-branch@242502 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-05 Kocsen Chung Cherry-pick r242394. rdar://problem/48591281 Unreviewed build fix after r242378 * UIProcess/ios/EditableImageController.mm: (WebKit::EditableImageController::associateWithAttachment): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242394 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-04 Brent Fulgham Unreviewed build fix after r242378 * UIProcess/ios/EditableImageController.mm: (WebKit::EditableImageController::associateWithAttachment): 2019-03-12 Kocsen Chung Cherry-pick r242501. rdar://problem/48591282 Cherry-pick r242378. rdar://problem/48591281 Check contextIDs when handling WebContent messages https://bugs.webkit.org/show_bug.cgi?id=195289 Reviewed by Alex Christensen. The WebContent process is untrusted because it handles arbitrary markup and javascript from untrusted sources. We should handle its messages with suspicion, and make sure the arguments are valid and usable before honoring them. This patch hardens the message passing layer by performing MESSAGE_CHECK in places that had been overlooked. * UIProcess/Cocoa/PlaybackSessionManagerProxy.mm: (WebKit::PlaybackSessionManagerProxy::setUpPlaybackControlsManagerWithID): (WebKit::PlaybackSessionManagerProxy::currentTimeChanged): (WebKit::PlaybackSessionManagerProxy::bufferedTimeChanged): (WebKit::PlaybackSessionManagerProxy::seekableRangesVectorChanged): (WebKit::PlaybackSessionManagerProxy::canPlayFastReverseChanged): (WebKit::PlaybackSessionManagerProxy::audioMediaSelectionOptionsChanged): (WebKit::PlaybackSessionManagerProxy::legibleMediaSelectionOptionsChanged): (WebKit::PlaybackSessionManagerProxy::audioMediaSelectionIndexChanged): (WebKit::PlaybackSessionManagerProxy::legibleMediaSelectionIndexChanged): (WebKit::PlaybackSessionManagerProxy::externalPlaybackPropertiesChanged): (WebKit::PlaybackSessionManagerProxy::wirelessVideoPlaybackDisabledChanged): (WebKit::PlaybackSessionManagerProxy::mutedChanged): (WebKit::PlaybackSessionManagerProxy::volumeChanged): (WebKit::PlaybackSessionManagerProxy::durationChanged): (WebKit::PlaybackSessionManagerProxy::playbackStartedTimeChanged): (WebKit::PlaybackSessionManagerProxy::rateChanged): (WebKit::PlaybackSessionManagerProxy::pictureInPictureSupportedChanged): (WebKit::PlaybackSessionManagerProxy::pictureInPictureActiveChanged): (WebKit::PlaybackSessionManagerProxy::handleControlledElementIDResponse const): * UIProcess/Cocoa/UserMediaCaptureManagerProxy.cpp: (WebKit::UserMediaCaptureManagerProxy::createMediaSourceForCaptureDeviceWithConstraints): (WebKit::UserMediaCaptureManagerProxy::startProducingData): (WebKit::UserMediaCaptureManagerProxy::stopProducingData): (WebKit::UserMediaCaptureManagerProxy::end): (WebKit::UserMediaCaptureManagerProxy::capabilities): (WebKit::UserMediaCaptureManagerProxy::setMuted): (WebKit::UserMediaCaptureManagerProxy::applyConstraints): * UIProcess/Cocoa/VideoFullscreenManagerProxy.mm: (WebKit::VideoFullscreenManagerProxy::setupFullscreenWithID): (WebKit::VideoFullscreenManagerProxy::setHasVideo): (WebKit::VideoFullscreenManagerProxy::setVideoDimensions): (WebKit::VideoFullscreenManagerProxy::enterFullscreen): (WebKit::VideoFullscreenManagerProxy::exitFullscreen): (WebKit::VideoFullscreenManagerProxy::exitFullscreenWithoutAnimationToMode): (WebKit::VideoFullscreenManagerProxy::setInlineRect): (WebKit::VideoFullscreenManagerProxy::setHasVideoContentLayer): (WebKit::VideoFullscreenManagerProxy::cleanupFullscreen): (WebKit::VideoFullscreenManagerProxy::preparedToReturnToInline): (WebKit::VideoFullscreenManagerProxy::preparedToExitFullscreen): * UIProcess/ios/EditableImageController.mm: (WebKit::EditableImageController::didCreateEditableImage): (WebKit::EditableImageController::didDestroyEditableImage): (WebKit::EditableImageController::associateWithAttachment): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242378 268f45cc-cd09-0410-ab3c-d52691b4dbfc git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-607.1.40.0-branch@242501 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-05 Kocsen Chung Cherry-pick r242378. rdar://problem/48591281 Check contextIDs when handling WebContent messages https://bugs.webkit.org/show_bug.cgi?id=195289 Reviewed by Alex Christensen. The WebContent process is untrusted because it handles arbitrary markup and javascript from untrusted sources. We should handle its messages with suspicion, and make sure the arguments are valid and usable before honoring them. This patch hardens the message passing layer by performing MESSAGE_CHECK in places that had been overlooked. * UIProcess/Cocoa/PlaybackSessionManagerProxy.mm: (WebKit::PlaybackSessionManagerProxy::setUpPlaybackControlsManagerWithID): (WebKit::PlaybackSessionManagerProxy::currentTimeChanged): (WebKit::PlaybackSessionManagerProxy::bufferedTimeChanged): (WebKit::PlaybackSessionManagerProxy::seekableRangesVectorChanged): (WebKit::PlaybackSessionManagerProxy::canPlayFastReverseChanged): (WebKit::PlaybackSessionManagerProxy::audioMediaSelectionOptionsChanged): (WebKit::PlaybackSessionManagerProxy::legibleMediaSelectionOptionsChanged): (WebKit::PlaybackSessionManagerProxy::audioMediaSelectionIndexChanged): (WebKit::PlaybackSessionManagerProxy::legibleMediaSelectionIndexChanged): (WebKit::PlaybackSessionManagerProxy::externalPlaybackPropertiesChanged): (WebKit::PlaybackSessionManagerProxy::wirelessVideoPlaybackDisabledChanged): (WebKit::PlaybackSessionManagerProxy::mutedChanged): (WebKit::PlaybackSessionManagerProxy::volumeChanged): (WebKit::PlaybackSessionManagerProxy::durationChanged): (WebKit::PlaybackSessionManagerProxy::playbackStartedTimeChanged): (WebKit::PlaybackSessionManagerProxy::rateChanged): (WebKit::PlaybackSessionManagerProxy::pictureInPictureSupportedChanged): (WebKit::PlaybackSessionManagerProxy::pictureInPictureActiveChanged): (WebKit::PlaybackSessionManagerProxy::handleControlledElementIDResponse const): * UIProcess/Cocoa/UserMediaCaptureManagerProxy.cpp: (WebKit::UserMediaCaptureManagerProxy::createMediaSourceForCaptureDeviceWithConstraints): (WebKit::UserMediaCaptureManagerProxy::startProducingData): (WebKit::UserMediaCaptureManagerProxy::stopProducingData): (WebKit::UserMediaCaptureManagerProxy::end): (WebKit::UserMediaCaptureManagerProxy::capabilities): (WebKit::UserMediaCaptureManagerProxy::setMuted): (WebKit::UserMediaCaptureManagerProxy::applyConstraints): * UIProcess/Cocoa/VideoFullscreenManagerProxy.mm: (WebKit::VideoFullscreenManagerProxy::setupFullscreenWithID): (WebKit::VideoFullscreenManagerProxy::setHasVideo): (WebKit::VideoFullscreenManagerProxy::setVideoDimensions): (WebKit::VideoFullscreenManagerProxy::enterFullscreen): (WebKit::VideoFullscreenManagerProxy::exitFullscreen): (WebKit::VideoFullscreenManagerProxy::exitFullscreenWithoutAnimationToMode): (WebKit::VideoFullscreenManagerProxy::setInlineRect): (WebKit::VideoFullscreenManagerProxy::setHasVideoContentLayer): (WebKit::VideoFullscreenManagerProxy::cleanupFullscreen): (WebKit::VideoFullscreenManagerProxy::preparedToReturnToInline): (WebKit::VideoFullscreenManagerProxy::preparedToExitFullscreen): * UIProcess/ios/EditableImageController.mm: (WebKit::EditableImageController::didCreateEditableImage): (WebKit::EditableImageController::didDestroyEditableImage): (WebKit::EditableImageController::associateWithAttachment): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242378 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-04 Brent Fulgham Check contextIDs when handling WebContent messages https://bugs.webkit.org/show_bug.cgi?id=195289 Reviewed by Alex Christensen. The WebContent process is untrusted because it handles arbitrary markup and javascript from untrusted sources. We should handle its messages with suspicion, and make sure the arguments are valid and usable before honoring them. This patch hardens the message passing layer by performing MESSAGE_CHECK in places that had been overlooked. * UIProcess/Cocoa/PlaybackSessionManagerProxy.mm: (WebKit::PlaybackSessionManagerProxy::setUpPlaybackControlsManagerWithID): (WebKit::PlaybackSessionManagerProxy::currentTimeChanged): (WebKit::PlaybackSessionManagerProxy::bufferedTimeChanged): (WebKit::PlaybackSessionManagerProxy::seekableRangesVectorChanged): (WebKit::PlaybackSessionManagerProxy::canPlayFastReverseChanged): (WebKit::PlaybackSessionManagerProxy::audioMediaSelectionOptionsChanged): (WebKit::PlaybackSessionManagerProxy::legibleMediaSelectionOptionsChanged): (WebKit::PlaybackSessionManagerProxy::audioMediaSelectionIndexChanged): (WebKit::PlaybackSessionManagerProxy::legibleMediaSelectionIndexChanged): (WebKit::PlaybackSessionManagerProxy::externalPlaybackPropertiesChanged): (WebKit::PlaybackSessionManagerProxy::wirelessVideoPlaybackDisabledChanged): (WebKit::PlaybackSessionManagerProxy::mutedChanged): (WebKit::PlaybackSessionManagerProxy::volumeChanged): (WebKit::PlaybackSessionManagerProxy::durationChanged): (WebKit::PlaybackSessionManagerProxy::playbackStartedTimeChanged): (WebKit::PlaybackSessionManagerProxy::rateChanged): (WebKit::PlaybackSessionManagerProxy::pictureInPictureSupportedChanged): (WebKit::PlaybackSessionManagerProxy::pictureInPictureActiveChanged): (WebKit::PlaybackSessionManagerProxy::handleControlledElementIDResponse const): * UIProcess/Cocoa/UserMediaCaptureManagerProxy.cpp: (WebKit::UserMediaCaptureManagerProxy::createMediaSourceForCaptureDeviceWithConstraints): (WebKit::UserMediaCaptureManagerProxy::startProducingData): (WebKit::UserMediaCaptureManagerProxy::stopProducingData): (WebKit::UserMediaCaptureManagerProxy::end): (WebKit::UserMediaCaptureManagerProxy::capabilities): (WebKit::UserMediaCaptureManagerProxy::setMuted): (WebKit::UserMediaCaptureManagerProxy::applyConstraints): * UIProcess/Cocoa/VideoFullscreenManagerProxy.mm: (WebKit::VideoFullscreenManagerProxy::setupFullscreenWithID): (WebKit::VideoFullscreenManagerProxy::setHasVideo): (WebKit::VideoFullscreenManagerProxy::setVideoDimensions): (WebKit::VideoFullscreenManagerProxy::enterFullscreen): (WebKit::VideoFullscreenManagerProxy::exitFullscreen): (WebKit::VideoFullscreenManagerProxy::exitFullscreenWithoutAnimationToMode): (WebKit::VideoFullscreenManagerProxy::setInlineRect): (WebKit::VideoFullscreenManagerProxy::setHasVideoContentLayer): (WebKit::VideoFullscreenManagerProxy::cleanupFullscreen): (WebKit::VideoFullscreenManagerProxy::preparedToReturnToInline): (WebKit::VideoFullscreenManagerProxy::preparedToExitFullscreen): * UIProcess/ios/EditableImageController.mm: (WebKit::EditableImageController::didCreateEditableImage): (WebKit::EditableImageController::didDestroyEditableImage): (WebKit::EditableImageController::associateWithAttachment): 2019-03-12 Kocsen Chung Cherry-pick r242629. rdar://problem/48716552 Crash under RemoteLayerTreePropertyApplier::applyProperties https://bugs.webkit.org/show_bug.cgi?id=195448 Reviewed by Simon Fraser. * UIProcess/RemoteLayerTree/RemoteLayerTreeHost.mm: (WebKit::RemoteLayerTreeHost::updateLayerTree): Under some currently-unknown circumstances, the UI process is receiving commits referring to layers that it does not know about. One understood case of this was fixed in r241899, but there seem to be cases remaining that are not understood. Also, add a release log so that we can identify any downstream effects. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242629 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-07 Tim Horton Crash under RemoteLayerTreePropertyApplier::applyProperties https://bugs.webkit.org/show_bug.cgi?id=195448 Reviewed by Simon Fraser. * UIProcess/RemoteLayerTree/RemoteLayerTreeHost.mm: (WebKit::RemoteLayerTreeHost::updateLayerTree): Under some currently-unknown circumstances, the UI process is receiving commits referring to layers that it does not know about. One understood case of this was fixed in r241899, but there seem to be cases remaining that are not understood. Also, add a release log so that we can identify any downstream effects. 2019-03-06 Kocsen Chung Cherry-pick r242554. rdar://problem/48647490 REGRESSION (r238490): YouTube.com: Returning PiP to Safari after sleeping device loses page https://bugs.webkit.org/show_bug.cgi?id=195364 Reviewed by Geoffrey Garen. Make sure we unset the LayerTreeFreezeReason::ProcessSuspended layer tree freeze reason when WebPage::applicationWillEnterForeground() is called. This restores pre-r238490 behavior and addresses the issue with PiP on youtube.com. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::applicationWillEnterForeground): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242554 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-06 Chris Dumez REGRESSION (r238490): YouTube.com: Returning PiP to Safari after sleeping device loses page https://bugs.webkit.org/show_bug.cgi?id=195364 Reviewed by Geoffrey Garen. Make sure we unset the LayerTreeFreezeReason::ProcessSuspended layer tree freeze reason when WebPage::applicationWillEnterForeground() is called. This restores pre-r238490 behavior and addresses the issue with PiP on youtube.com. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::applicationWillEnterForeground): 2019-03-04 Kocsen Chung Cherry-pick r242302. rdar://problem/48572673 Add setters on WKWebsiteDataStore for sourceApplicationBundleIdentifier and sourceApplicationSecondaryIdentifier https://bugs.webkit.org/show_bug.cgi?id=195229 Reviewed by Chris Dumez. Source/WebKit: Just like _setBoundInterfaceIdentifier, we need a way to set these properties after instantiation of a WKWebsiteDataStore, but we need to make sure we don't set it after the parameters have been copied to the NetworkProcess. Functionality verified by manual testing. See radar. Added an API test that verifies the setter restrictions work as expected. * UIProcess/API/Cocoa/WKWebsiteDataStore.mm: (-[WKWebsiteDataStore _sourceApplicationBundleIdentifier]): (-[WKWebsiteDataStore _setSourceApplicationBundleIdentifier:]): (-[WKWebsiteDataStore _sourceApplicationSecondaryIdentifier]): (-[WKWebsiteDataStore _setSourceApplicationSecondaryIdentifier:]): * UIProcess/API/Cocoa/WKWebsiteDataStorePrivate.h: * UIProcess/ApplePay/cocoa/WebPaymentCoordinatorProxyCocoa.mm: (WebKit::toPKPaymentRequest): * UIProcess/WebsiteData/Cocoa/WebsiteDataStoreCocoa.mm: (WebKit::WebsiteDataStore::parameters): * UIProcess/WebsiteData/WebsiteDataStore.cpp: (WebKit::WebsiteDataStore::WebsiteDataStore): (WebKit::WebsiteDataStore::setSourceApplicationSecondaryIdentifier): (WebKit::WebsiteDataStore::setSourceApplicationBundleIdentifier): * UIProcess/WebsiteData/WebsiteDataStore.h: (WebKit::WebsiteDataStore::sourceApplicationBundleIdentifier): (WebKit::WebsiteDataStore::sourceApplicationSecondaryIdentifier): Tools: * TestWebKitAPI/Tests/WebKitCocoa/WebsiteDataStoreCustomPaths.mm: (TEST): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242302 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-01 Alex Christensen Add setters on WKWebsiteDataStore for sourceApplicationBundleIdentifier and sourceApplicationSecondaryIdentifier https://bugs.webkit.org/show_bug.cgi?id=195229 Reviewed by Chris Dumez. Just like _setBoundInterfaceIdentifier, we need a way to set these properties after instantiation of a WKWebsiteDataStore, but we need to make sure we don't set it after the parameters have been copied to the NetworkProcess. Functionality verified by manual testing. See radar. Added an API test that verifies the setter restrictions work as expected. * UIProcess/API/Cocoa/WKWebsiteDataStore.mm: (-[WKWebsiteDataStore _sourceApplicationBundleIdentifier]): (-[WKWebsiteDataStore _setSourceApplicationBundleIdentifier:]): (-[WKWebsiteDataStore _sourceApplicationSecondaryIdentifier]): (-[WKWebsiteDataStore _setSourceApplicationSecondaryIdentifier:]): * UIProcess/API/Cocoa/WKWebsiteDataStorePrivate.h: * UIProcess/ApplePay/cocoa/WebPaymentCoordinatorProxyCocoa.mm: (WebKit::toPKPaymentRequest): * UIProcess/WebsiteData/Cocoa/WebsiteDataStoreCocoa.mm: (WebKit::WebsiteDataStore::parameters): * UIProcess/WebsiteData/WebsiteDataStore.cpp: (WebKit::WebsiteDataStore::WebsiteDataStore): (WebKit::WebsiteDataStore::setSourceApplicationSecondaryIdentifier): (WebKit::WebsiteDataStore::setSourceApplicationBundleIdentifier): * UIProcess/WebsiteData/WebsiteDataStore.h: (WebKit::WebsiteDataStore::sourceApplicationBundleIdentifier): (WebKit::WebsiteDataStore::sourceApplicationSecondaryIdentifier): 2019-03-04 Babak Shafiei Cherry-pick r242355. rdar://problem/48563894 [iOS] Fullscreen "stay in page" option breaks video playback https://bugs.webkit.org/show_bug.cgi?id=195277 Reviewed by Eric Carlson. Source/WebCore: Add a LOG entry when playback is rejected due to media playback suspension. * html/MediaElementSession.cpp: (WebCore::MediaElementSession::playbackPermitted const): Source/WebKit: Make sure we resume media playback when the user chooses "stay in page" from the deceptive website warning dialog. * UIProcess/ios/fullscreen/WKFullScreenViewController.mm: (-[WKFullScreenViewController _showPhishingAlert]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242355 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-04 Jer Noble [iOS] Fullscreen "stay in page" option breaks video playback https://bugs.webkit.org/show_bug.cgi?id=195277 Reviewed by Eric Carlson. Make sure we resume media playback when the user chooses "stay in page" from the deceptive website warning dialog. * UIProcess/ios/fullscreen/WKFullScreenViewController.mm: (-[WKFullScreenViewController _showPhishingAlert]): 2019-02-28 Andy Estes [watchOS] Disable Parental Controls content filtering Rubber-stamped by Beth Dakin. * Configurations/FeatureDefines.xcconfig: 2019-02-27 Babak Shafiei Apply patch. rdar://problem/48429676 2019-02-27 Alex Christensen Move ephemeral local storage from WebProcess to UIProcess https://bugs.webkit.org/show_bug.cgi?id=195074 Reviewed by Geoff Garen. Before PSON, a page could navigate to another domain that navigates back and still have its local storage. Since PSON makes it unreliable to retain the state in the WebProcess, move it to the process with the rest of the local storage. If it's ephemeral, we obviously can't use the SQLite on-disk storage implementation, so use the same WebCore::StorageMap we used to in the WebProcess. * UIProcess/WebStorage/StorageManager.cpp: (WebKit::StorageManager::LocalStorageNamespace::LocalStorageNamespace): (WebKit::StorageManager::StorageManager): (WebKit::StorageManager::createLocalStorageMap): (WebKit::StorageManager::createTransientLocalStorageMap): (WebKit::StorageManager::createSessionStorageMap): (WebKit::StorageManager::destroyStorageMap): (WebKit::StorageManager::getValues): (WebKit::StorageManager::setItem): (WebKit::StorageManager::removeItem): (WebKit::StorageManager::clear): * UIProcess/WebStorage/StorageManager.h: * UIProcess/WebStorage/StorageManager.messages.in: * UIProcess/WebsiteData/WebsiteDataStore.cpp: (WebKit::WebsiteDataStore::WebsiteDataStore): * WebProcess/WebStorage/StorageAreaMap.cpp: (WebKit::StorageAreaMap::StorageAreaMap): (WebKit::StorageAreaMap::setItem): (WebKit::StorageAreaMap::removeItem): (WebKit::StorageAreaMap::clear): (WebKit::StorageAreaMap::loadValuesIfNeeded): * WebProcess/WebStorage/StorageNamespaceImpl.cpp: (WebKit::StorageNamespaceImpl::createEphemeralLocalStorageNamespace): (WebKit::StorageNamespaceImpl::storageArea): (WebKit::StorageNamespaceImpl::copy): (): Deleted. (WebKit::StorageNamespaceImpl::ephemeralLocalStorageArea): Deleted. * WebProcess/WebStorage/StorageNamespaceImpl.h: 2019-02-27 Babak Shafiei Cherry-pick r242099. rdar://problem/48429675 [iOS] Regression(PSON) Scroll position is no longer restored when navigating back to reddit.com https://bugs.webkit.org/show_bug.cgi?id=195054 Reviewed by Geoff Garen. Source/WebCore: Add MaintainMemoryCache flag to indicate that the memory cache should not get purged. * page/MemoryRelease.cpp: (WebCore::releaseNoncriticalMemory): (WebCore::releaseCriticalMemory): (WebCore::releaseMemory): * page/MemoryRelease.h: Source/WebKit: We attempt to restore the scroll position twice, on first layout and then on load completion. Before PSON, the scroll position would fail to get restored on first layout but would succeed on load completion because the view is tall enough by then. With PSON however, we would fail to restore the scroll position on load completion because the view would not be tall enough yet by this point. The reason is that the dynamic resources would not be in the memory cache and would then get reloaded abd finish loading *after* the load event. To address the issue, we now make sure to not purge the memory cache on process suspension on iOS if there is currently a SuspendedPageProxy in the UIProcess for this process. * UIProcess/SuspendedPageProxy.cpp: (WebKit::SuspendedPageProxy::SuspendedPageProxy): (WebKit::SuspendedPageProxy::~SuspendedPageProxy): * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::incrementSuspendedPageCount): (WebKit::WebProcessProxy::decrementSuspendedPageCount): * UIProcess/WebProcessProxy.h: * WebProcess/WebProcess.cpp: (WebKit::WebProcess::initializeWebProcess): (WebKit::WebProcess::setHasSuspendedPageProxy): * WebProcess/WebProcess.h: * WebProcess/WebProcess.messages.in: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242099 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-26 Chris Dumez [iOS] Regression(PSON) Scroll position is no longer restored when navigating back to reddit.com https://bugs.webkit.org/show_bug.cgi?id=195054 Reviewed by Geoff Garen. We attempt to restore the scroll position twice, on first layout and then on load completion. Before PSON, the scroll position would fail to get restored on first layout but would succeed on load completion because the view is tall enough by then. With PSON however, we would fail to restore the scroll position on load completion because the view would not be tall enough yet by this point. The reason is that the dynamic resources would not be in the memory cache and would then get reloaded abd finish loading *after* the load event. To address the issue, we now make sure to not purge the memory cache on process suspension on iOS if there is currently a SuspendedPageProxy in the UIProcess for this process. * UIProcess/SuspendedPageProxy.cpp: (WebKit::SuspendedPageProxy::SuspendedPageProxy): (WebKit::SuspendedPageProxy::~SuspendedPageProxy): * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::incrementSuspendedPageCount): (WebKit::WebProcessProxy::decrementSuspendedPageCount): * UIProcess/WebProcessProxy.h: * WebProcess/WebProcess.cpp: (WebKit::WebProcess::initializeWebProcess): (WebKit::WebProcess::setHasSuspendedPageProxy): * WebProcess/WebProcess.h: * WebProcess/WebProcess.messages.in: 2019-02-27 Babak Shafiei Cherry-pick r242089. rdar://problem/48429668 WebPageProxy should nullify m_userMediaPermissionRequestManager after resetting the media state https://bugs.webkit.org/show_bug.cgi?id=195028 Reviewed by Eric Carlson. Source/WebKit: Covered by API test. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::resetState): Tools: * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242089 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-26 Youenn Fablet WebPageProxy should nullify m_userMediaPermissionRequestManager after resetting the media state https://bugs.webkit.org/show_bug.cgi?id=195028 Reviewed by Eric Carlson. Covered by API test. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::resetState): 2019-02-27 Babak Shafiei Cherry-pick r242098. rdar://problem/48429674 [iOS] REGRESSION(r238490?): Safari sometimes shows blank page until a cross site navigation or re-opening the tab https://bugs.webkit.org/show_bug.cgi?id=195037 Reviewed by Antti Koivisto. Restore the pre-r238490 behavior of WebPage::didCompletePageTransition clearing LayerTreeFreezeReason::ProcessSuspended as this has been an issue when I was able to reproduce the issue locally. Also added release logging to help diagnose the issue in the future. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::freezeLayerTree): (WebKit::WebPage::unfreezeLayerTree): (WebKit::WebPage::didCompletePageTransition): * WebProcess/WebProcess.cpp: (WebKit::WebProcess::freezeAllLayerTrees): (WebKit::WebProcess::unfreezeAllLayerTrees): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242098 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-26 Ryosuke Niwa [iOS] REGRESSION(r238490?): Safari sometimes shows blank page until a cross site navigation or re-opening the tab https://bugs.webkit.org/show_bug.cgi?id=195037 Reviewed by Antti Koivisto. Restore the pre-r238490 behavior of WebPage::didCompletePageTransition clearing LayerTreeFreezeReason::ProcessSuspended as this has been an issue when I was able to reproduce the issue locally. Also added release logging to help diagnose the issue in the future. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::freezeLayerTree): (WebKit::WebPage::unfreezeLayerTree): (WebKit::WebPage::didCompletePageTransition): * WebProcess/WebProcess.cpp: (WebKit::WebProcess::freezeAllLayerTrees): (WebKit::WebProcess::unfreezeAllLayerTrees): 2019-02-24 Babak Shafiei Cherry-pick r241963. rdar://problem/48350367 Regression(PSON) Unable to preview password-protected documents on iCloud.com https://bugs.webkit.org/show_bug.cgi?id=194954 Reviewed by Alex Christensen. Source/WebKit: Make sure the ProvisionalPageProxy forwards to the WebPageProxy the QuickLook-related IPC on iOS. * UIProcess/ProvisionalPageProxy.cpp: (WebKit::ProvisionalPageProxy::didRequestPasswordForQuickLookDocumentInMainFrame): (WebKit::ProvisionalPageProxy::didReceiveMessage): * UIProcess/ProvisionalPageProxy.h: * UIProcess/WebPageProxy.h: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::didRequestPasswordForQuickLookDocumentInMainFrame): (WebKit::WebPageProxy::didRequestPasswordForQuickLookDocumentInMainFrameShared): Tools: Add API test coverage. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: (-[PSONNavigationDelegate _webViewDidRequestPasswordForQuickLookDocument:]): (-[PSONNavigationDelegate _webView:didStartLoadForQuickLookDocumentInMainFrameWithFileName:uti:]): (-[PSONNavigationDelegate _webView:didFinishLoadForQuickLookDocumentInMainFrame:]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241963 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-22 Chris Dumez Regression(PSON) Unable to preview password-protected documents on iCloud.com https://bugs.webkit.org/show_bug.cgi?id=194954 Reviewed by Alex Christensen. Make sure the ProvisionalPageProxy forwards to the WebPageProxy the QuickLook-related IPC on iOS. * UIProcess/ProvisionalPageProxy.cpp: (WebKit::ProvisionalPageProxy::didRequestPasswordForQuickLookDocumentInMainFrame): (WebKit::ProvisionalPageProxy::didReceiveMessage): * UIProcess/ProvisionalPageProxy.h: * UIProcess/WebPageProxy.h: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::didRequestPasswordForQuickLookDocumentInMainFrame): (WebKit::WebPageProxy::didRequestPasswordForQuickLookDocumentInMainFrameShared): 2019-02-24 Babak Shafiei Cherry-pick r241950. rdar://problem/48317455 REGRESSION(PSON) Scroll position is sometimes not restored on history navigation https://bugs.webkit.org/show_bug.cgi?id=194924 Reviewed by Geoffrey Garen. Source/WebKit: When process-swapping, we would create a new WebPage in the new process, which would call restoreSessionInternal() to restore the HistoryItems based on the UIProcess's backforward list. The issue is that this session restoring would send HistoryItem updates back to the UIProcess. Without PSON, this would be unnecessary but harmless. With PSON though, this may end up overwriting values set by the previous process, such as the scroll position. Address the issue by temporarily disabling the HistoryItem update notifications to the UIProcess while restoring a session. * UIProcess/API/Cocoa/WKBackForwardListItem.mm: (-[WKBackForwardListItem _scrollPosition]): * UIProcess/API/Cocoa/WKBackForwardListItemPrivate.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::restoreSessionInternal): Tools: Add API test coverage. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241950 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-22 Chris Dumez REGRESSION(PSON) Scroll position is sometimes not restored on history navigation https://bugs.webkit.org/show_bug.cgi?id=194924 Reviewed by Geoffrey Garen. When process-swapping, we would create a new WebPage in the new process, which would call restoreSessionInternal() to restore the HistoryItems based on the UIProcess's backforward list. The issue is that this session restoring would send HistoryItem updates back to the UIProcess. Without PSON, this would be unnecessary but harmless. With PSON though, this may end up overwriting values set by the previous process, such as the scroll position. Address the issue by temporarily disabling the HistoryItem update notifications to the UIProcess while restoring a session. * UIProcess/API/Cocoa/WKBackForwardListItem.mm: (-[WKBackForwardListItem _scrollPosition]): * UIProcess/API/Cocoa/WKBackForwardListItemPrivate.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::restoreSessionInternal): 2019-02-24 Babak Shafiei Cherry-pick r241928. rdar://problem/48317429 Discard cached processes when clearing website data store https://bugs.webkit.org/show_bug.cgi?id=194894 Reviewed by Chris Dumez. Source/WebKit: Clear the process cache when clearing the website data store so that there is no way to infer which site the user had visited by observing for which sites WebContent processes had been cached. There is one sublty in WebsiteDataStore::removeData that we have to delay the clearing of the web process cache until the next run loop because SuspendedPageProxy::~SuspendedPageProxy invokes WebProcessProxy::maybeShutDown in the next run loop. We also have to disable the process cache during this time as it would otherwise trigger the responsiveness check of WebContent process can take arbitrarily long time. * UIProcess/API/Cocoa/WKProcessPool.mm: (-[WKProcessPool _processCacheCapacity]): Added for testing. * UIProcess/API/Cocoa/WKProcessPoolPrivate.h: * UIProcess/WebProcessCache.cpp: (WebKit::WebProcessCache::addProcess): Avoid adding web processes to the cache while the suspended pages are being cleared. * UIProcess/WebProcessCache.h: (WebKit::WebProcessCache::disabled const): Added. (WebKit::WebProcessCache::setDisabled): Added. * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::handleMemoryPressureWarning): (WebKit::WebProcessPool::clearSuspendedPages): Added. * UIProcess/WebProcessPool.h: * UIProcess/WebsiteData/WebsiteDataStore.cpp: (WebKit::WebsiteDataStore::removeData): Tools: Added a test case. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: (TestWebKitAPI.ProcessSwap.NumberOfCachedProcesses): Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241928 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-21 Ryosuke Niwa Discard cached processes when clearing website data store https://bugs.webkit.org/show_bug.cgi?id=194894 Reviewed by Chris Dumez. Clear the process cache when clearing the website data store so that there is no way to infer which site the user had visited by observing for which sites WebContent processes had been cached. There is one sublty in WebsiteDataStore::removeData that we have to delay the clearing of the web process cache until the next run loop because SuspendedPageProxy::~SuspendedPageProxy invokes WebProcessProxy::maybeShutDown in the next run loop. We also have to disable the process cache during this time as it would otherwise trigger the responsiveness check of WebContent process can take arbitrarily long time. * UIProcess/API/Cocoa/WKProcessPool.mm: (-[WKProcessPool _processCacheCapacity]): Added for testing. * UIProcess/API/Cocoa/WKProcessPoolPrivate.h: * UIProcess/WebProcessCache.cpp: (WebKit::WebProcessCache::addProcess): Avoid adding web processes to the cache while the suspended pages are being cleared. * UIProcess/WebProcessCache.h: (WebKit::WebProcessCache::disabled const): Added. (WebKit::WebProcessCache::setDisabled): Added. * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::handleMemoryPressureWarning): (WebKit::WebProcessPool::clearSuspendedPages): Added. * UIProcess/WebProcessPool.h: * UIProcess/WebsiteData/WebsiteDataStore.cpp: (WebKit::WebsiteDataStore::removeData): 2019-02-24 Babak Shafiei Cherry-pick r241899. rdar://problem/48317463 Crash under RemoteLayerTreePropertyApplier::applyProperties when reattaching to old process https://bugs.webkit.org/show_bug.cgi?id=194845 Reviewed by Antti Koivisto. Source/WebKit: New test: ProcessSwap.PageOverlayLayerPersistence * Shared/RemoteLayerTree/RemoteLayerTreeTransaction.h: (WebKit::RemoteLayerTreeTransaction::LayerProperties::notePropertiesChanged): Keep track of all properties that have ever changed on a layer, so we can re-send them if a layer moves between contexts. * WebProcess/WebPage/DrawingArea.cpp: (WebKit::DrawingArea::~DrawingArea): (WebKit::DrawingArea::removeMessageReceiverIfNeeded): * WebProcess/WebPage/DrawingArea.h: (WebKit::DrawingArea::layerHostDidFlushLayers): Make it possible to tear down DrawingArea's MessageReceiver before it is destroyed, so that we can keep two DrawingAreas alive in a single process for a short time. (WebKit::DrawingArea::adoptLayersFromDrawingArea): Add adoptLayersFromDrawingArea; see below for its only useful implementation. * WebProcess/WebPage/RemoteLayerTree/GraphicsLayerCARemote.cpp: (WebKit::GraphicsLayerCARemote::GraphicsLayerCARemote): (WebKit::GraphicsLayerCARemote::~GraphicsLayerCARemote): (WebKit::GraphicsLayerCARemote::createPlatformCALayer): (WebKit::GraphicsLayerCARemote::createPlatformCALayerForEmbeddedView): (WebKit::GraphicsLayerCARemote::moveToContext): * WebProcess/WebPage/RemoteLayerTree/GraphicsLayerCARemote.h: Make it possible to move a GraphicsLayerCARemote between RemoteLayerTreeContexts. * WebProcess/WebPage/RemoteLayerTree/PlatformCALayerRemote.cpp: (WebKit::PlatformCALayerRemote::create): (WebKit::PlatformCALayerRemote::createForEmbeddedView): (WebKit::PlatformCALayerRemote::~PlatformCALayerRemote): (WebKit::PlatformCALayerRemote::moveToContext): * WebProcess/WebPage/RemoteLayerTree/PlatformCALayerRemote.h: * WebProcess/WebPage/RemoteLayerTree/PlatformCALayerRemoteCustom.mm: (WebKit::PlatformCALayerRemoteCustom::create): (WebKit::PlatformCALayerRemoteCustom::clone const): Make it possible to move a PlatformCALayerRemote between RemoteLayerTreeContexts. * WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeContext.h: * WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeContext.mm: (WebKit::RemoteLayerTreeContext::~RemoteLayerTreeContext): (WebKit::RemoteLayerTreeContext::adoptLayersFromContext): (WebKit::RemoteLayerTreeContext::layerDidEnterContext): (WebKit::RemoteLayerTreeContext::layerWillLeaveContext): (WebKit::RemoteLayerTreeContext::graphicsLayerDidEnterContext): (WebKit::RemoteLayerTreeContext::graphicsLayerWillLeaveContext): (WebKit::RemoteLayerTreeContext::layerWasCreated): Deleted. (WebKit::RemoteLayerTreeContext::layerWillBeDestroyed): Deleted. Keep track of all GraphicsLayerCARemote instances in the context, like we do for PlatformCALayerRemote, so that we can update their context backpointers if needed. Also make it possible to move all outstanding layers to a new context. * WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.h: * WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::adoptLayersFromDrawingArea): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::reinitializeWebPage): When doing a DrawingArea swap, transition all layers from the old context to the new one. In order to do this, we temporarily keep both DrawingAreas alive, but make use of the new mechanism to remove the old one's MessageReceiver before installing the new one, so that destroying the old one later doesn't remove it (avoiding re-introducing bug 189481). Tools: * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241899 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-21 Tim Horton Crash under RemoteLayerTreePropertyApplier::applyProperties when reattaching to old process https://bugs.webkit.org/show_bug.cgi?id=194845 Reviewed by Antti Koivisto. New test: ProcessSwap.PageOverlayLayerPersistence * Shared/RemoteLayerTree/RemoteLayerTreeTransaction.h: (WebKit::RemoteLayerTreeTransaction::LayerProperties::notePropertiesChanged): Keep track of all properties that have ever changed on a layer, so we can re-send them if a layer moves between contexts. * WebProcess/WebPage/DrawingArea.cpp: (WebKit::DrawingArea::~DrawingArea): (WebKit::DrawingArea::removeMessageReceiverIfNeeded): * WebProcess/WebPage/DrawingArea.h: (WebKit::DrawingArea::layerHostDidFlushLayers): Make it possible to tear down DrawingArea's MessageReceiver before it is destroyed, so that we can keep two DrawingAreas alive in a single process for a short time. (WebKit::DrawingArea::adoptLayersFromDrawingArea): Add adoptLayersFromDrawingArea; see below for its only useful implementation. * WebProcess/WebPage/RemoteLayerTree/GraphicsLayerCARemote.cpp: (WebKit::GraphicsLayerCARemote::GraphicsLayerCARemote): (WebKit::GraphicsLayerCARemote::~GraphicsLayerCARemote): (WebKit::GraphicsLayerCARemote::createPlatformCALayer): (WebKit::GraphicsLayerCARemote::createPlatformCALayerForEmbeddedView): (WebKit::GraphicsLayerCARemote::moveToContext): * WebProcess/WebPage/RemoteLayerTree/GraphicsLayerCARemote.h: Make it possible to move a GraphicsLayerCARemote between RemoteLayerTreeContexts. * WebProcess/WebPage/RemoteLayerTree/PlatformCALayerRemote.cpp: (WebKit::PlatformCALayerRemote::create): (WebKit::PlatformCALayerRemote::createForEmbeddedView): (WebKit::PlatformCALayerRemote::~PlatformCALayerRemote): (WebKit::PlatformCALayerRemote::moveToContext): * WebProcess/WebPage/RemoteLayerTree/PlatformCALayerRemote.h: * WebProcess/WebPage/RemoteLayerTree/PlatformCALayerRemoteCustom.mm: (WebKit::PlatformCALayerRemoteCustom::create): (WebKit::PlatformCALayerRemoteCustom::clone const): Make it possible to move a PlatformCALayerRemote between RemoteLayerTreeContexts. * WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeContext.h: * WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeContext.mm: (WebKit::RemoteLayerTreeContext::~RemoteLayerTreeContext): (WebKit::RemoteLayerTreeContext::adoptLayersFromContext): (WebKit::RemoteLayerTreeContext::layerDidEnterContext): (WebKit::RemoteLayerTreeContext::layerWillLeaveContext): (WebKit::RemoteLayerTreeContext::graphicsLayerDidEnterContext): (WebKit::RemoteLayerTreeContext::graphicsLayerWillLeaveContext): (WebKit::RemoteLayerTreeContext::layerWasCreated): Deleted. (WebKit::RemoteLayerTreeContext::layerWillBeDestroyed): Deleted. Keep track of all GraphicsLayerCARemote instances in the context, like we do for PlatformCALayerRemote, so that we can update their context backpointers if needed. Also make it possible to move all outstanding layers to a new context. * WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.h: * WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::adoptLayersFromDrawingArea): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::reinitializeWebPage): When doing a DrawingArea swap, transition all layers from the old context to the new one. In order to do this, we temporarily keep both DrawingAreas alive, but make use of the new mechanism to remove the old one's MessageReceiver before installing the new one, so that destroying the old one later doesn't remove it (avoiding re-introducing bug 189481). 2019-02-24 Babak Shafiei Cherry-pick r241128. rdar://problem/48317438 [macOS] API test times out after r241026 https://bugs.webkit.org/show_bug.cgi?id=194372 Reviewed by Alex Christensen. The API test TestWebKitAPI.RenderingProgress.FirstMeaningfulPaint times out after r241026. A new function pointer, layoutMilestones, is added to WKBundlePageLoaderClient, in order for clients to decide which milestones they would like to listen for. * WebProcess/InjectedBundle/API/c/WKBundlePageLoaderClient.h: * WebProcess/InjectedBundle/API/mac/WKWebProcessPlugInBrowserContextController.mm: (layoutMilestones): (setUpPageLoaderClient): * WebProcess/InjectedBundle/InjectedBundlePageLoaderClient.cpp: (WebKit::InjectedBundlePageLoaderClient::layoutMilestones const): * WebProcess/InjectedBundle/InjectedBundlePageLoaderClient.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241128 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-07 Per Arne Vollan [macOS] API test times out after r241026 https://bugs.webkit.org/show_bug.cgi?id=194372 Reviewed by Alex Christensen. The API test TestWebKitAPI.RenderingProgress.FirstMeaningfulPaint times out after r241026. A new function pointer, layoutMilestones, is added to WKBundlePageLoaderClient, in order for clients to decide which milestones they would like to listen for. * WebProcess/InjectedBundle/API/c/WKBundlePageLoaderClient.h: * WebProcess/InjectedBundle/API/mac/WKWebProcessPlugInBrowserContextController.mm: (layoutMilestones): (setUpPageLoaderClient): * WebProcess/InjectedBundle/InjectedBundlePageLoaderClient.cpp: (WebKit::InjectedBundlePageLoaderClient::layoutMilestones const): * WebProcess/InjectedBundle/InjectedBundlePageLoaderClient.h: 2019-02-24 Babak Shafiei Apply patch. rdar://problem/48317433 2019-02-24 Chris Dumez REGRESSION(PSON): Google login page refreshes repeatedly in Reeder 3 app Reviewed by Alex Christensen. When we process swap, we first call removeWebPage() on the previous process and then call addExistingWebPage() on the new one. removeWebPage() would call WebProcessPool::pageEndUsingWebsiteDataStore() and then addExistingWebPage() would call WebProcessPool::pageBeginUsingWebsiteDataStore(). This was leading to loosing session cookies because the call to WebProcessPool::pageEndUsingWebsiteDataStore() would send an IPC to the Network process to destroy the session. The later call to pageBeginUsingWebsiteDataStore() would re-construct the session but it would be too late, previous cookies would be gone. To address the issue, r238828 updated removeWebPage() / addExistingWebPage() so that they no longer call pageBeginUsingWebsiteDataStore() / pageEndUsingWebsiteDataStore() in case of a process swap. This partly fixed the issue. However, I failed to notice that pageBeginUsingWebsiteDataStore() / pageEndUsingWebsiteDataStore() also send IPC to the WebProcess to construct / destroy the session. We still want this IPC to happen in case of a process-swap or the new process will not know about the session. To address this issue, I moved the WebProcess IPC sending from WebProcessPool::pageEndUsingWebsiteDataStore() / pageEndUsingWebsiteDataStore() to WebProcessProxy::removeWebPage() / addExistingWebPage() so that it happens no matter what. It is also clearer for the WebProcessProxy to send the IPC by itself. This patch is only needed on the branch since Alex refactored the code in r239737 so that the WebSiteDataStore-related IPC to the WebProcess is no longer needed on trunk. * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::pageBeginUsingWebsiteDataStore): (WebKit::WebProcessPool::pageEndUsingWebsiteDataStore): * UIProcess/WebProcessPool.h: * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::addExistingWebPage): (WebKit::WebProcessProxy::removeWebPage): (WebKit::WebProcessProxy::hasPageUsingSession const): 2019-02-21 Alan Coon Cherry-pick r241919. rdar://problem/48267027 Fix API test crashes after r241855. Reviewed by Ryosuke Niwa. * UIProcess/WebProcessCache.cpp: (WebKit::WebProcessCache::addProcessIfPossible): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241919 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-21 Chris Dumez Fix API test crashes after r241855. Reviewed by Ryosuke Niwa. * UIProcess/WebProcessCache.cpp: (WebKit::WebProcessCache::addProcessIfPossible): 2019-02-21 Alan Coon Cherry-pick r241868. rdar://problem/48267027 Unreviewed API test fix after r241855. * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::~WebProcessProxy): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241868 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-21 Chris Dumez Unreviewed API test fix after r241855. * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::~WebProcessProxy): 2019-02-21 Alan Coon Cherry-pick r241728. rdar://problem/48243264 Disable safe browsing in WKWebView and remove its WKPreferences API https://bugs.webkit.org/show_bug.cgi?id=194723 Reviewed by Geoffrey Garen. Source/WebKit: * Shared/WebPreferences.yaml: * UIProcess/API/Cocoa/WKPreferences.h: * UIProcess/API/Cocoa/WKPreferences.mm: (-[WKPreferences setSafeBrowsingEnabled:]): Deleted. (-[WKPreferences isSafeBrowsingEnabled]): Deleted. Tools: * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: * TestWebKitAPI/Tests/WebKitCocoa/SafeBrowsing.mm: (TEST): (safeBrowsingView): Make tests use SPI instead of API. LayoutTests: * platform/mac-wk2/http/tests/navigation/keyboard-events-during-provisional-navigation-expected.txt: This test has results that depend on timing, and I need to update its results when I disable safe browsing. I've done this several times before. See r237876 for an example. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241728 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-18 Alex Christensen Disable safe browsing in WKWebView and remove its WKPreferences API https://bugs.webkit.org/show_bug.cgi?id=194723 Reviewed by Geoffrey Garen. * Shared/WebPreferences.yaml: * UIProcess/API/Cocoa/WKPreferences.h: * UIProcess/API/Cocoa/WKPreferences.mm: (-[WKPreferences setSafeBrowsingEnabled:]): Deleted. (-[WKPreferences isSafeBrowsingEnabled]): Deleted. 2019-02-21 Alan Coon Cherry-pick r241618. rdar://problem/48243264 Add SPI version of WKPreferences.safeBrowsingEnabled https://bugs.webkit.org/show_bug.cgi?id=194718 Rubber-stamped by Brady Eidson. * UIProcess/API/Cocoa/WKPreferences.mm: (-[WKPreferences _isSafeBrowsingEnabled]): (-[WKPreferences _setSafeBrowsingEnabled:]): * UIProcess/API/Cocoa/WKPreferencesPrivate.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241618 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-15 Alex Christensen Add SPI version of WKPreferences.safeBrowsingEnabled https://bugs.webkit.org/show_bug.cgi?id=194718 Rubber-stamped by Brady Eidson. * UIProcess/API/Cocoa/WKPreferences.mm: (-[WKPreferences _isSafeBrowsingEnabled]): (-[WKPreferences _setSafeBrowsingEnabled:]): * UIProcess/API/Cocoa/WKPreferencesPrivate.h: 2019-02-21 Alan Coon Cherry-pick r241855. rdar://problem/48267027 [PSON] Make sure hung processes are not kept alive by suspended pages or process caching https://bugs.webkit.org/show_bug.cgi?id=194881 Reviewed by Geoffrey Garen. After we construct a SuspendedPageProxy and before we send the IPC to the WebProcess to ask it to suspend, start a 10 seconds timer. If the process does not answer the request to suspend before the timer fires, we destroy the SuspendedPageProxy so that we do not keep a hung process around. For the WebProcessCache, we now call WebProcessProxy::isResponsive() on the process before adding it to the cache. Internally, this relies on an IPC handshake with the WebProcess. If the process is not responsive, we do not add it to the cache and we shut it down. If it is responsive then we proceed normally with adding it to the cache. * UIProcess/SuspendedPageProxy.cpp: (WebKit::SuspendedPageProxy::SuspendedPageProxy): (WebKit::SuspendedPageProxy::didProcessRequestToSuspend): (WebKit::SuspendedPageProxy::suspensionTimedOut): * UIProcess/SuspendedPageProxy.h: * UIProcess/WebProcessCache.cpp: (WebKit::WebProcessCache::addProcessIfPossible): (WebKit::WebProcessCache::addProcess): * UIProcess/WebProcessCache.h: * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::processDidTerminateOrFailedToLaunch): (WebKit::WebProcessProxy::maybeShutDown): (WebKit::WebProcessProxy::isResponsive): * UIProcess/WebProcessProxy.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241855 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-20 Chris Dumez [PSON] Make sure hung processes are not kept alive by suspended pages or process caching https://bugs.webkit.org/show_bug.cgi?id=194881 Reviewed by Geoffrey Garen. After we construct a SuspendedPageProxy and before we send the IPC to the WebProcess to ask it to suspend, start a 10 seconds timer. If the process does not answer the request to suspend before the timer fires, we destroy the SuspendedPageProxy so that we do not keep a hung process around. For the WebProcessCache, we now call WebProcessProxy::isResponsive() on the process before adding it to the cache. Internally, this relies on an IPC handshake with the WebProcess. If the process is not responsive, we do not add it to the cache and we shut it down. If it is responsive then we proceed normally with adding it to the cache. * UIProcess/SuspendedPageProxy.cpp: (WebKit::SuspendedPageProxy::SuspendedPageProxy): (WebKit::SuspendedPageProxy::didProcessRequestToSuspend): (WebKit::SuspendedPageProxy::suspensionTimedOut): * UIProcess/SuspendedPageProxy.h: * UIProcess/WebProcessCache.cpp: (WebKit::WebProcessCache::addProcessIfPossible): (WebKit::WebProcessCache::addProcess): * UIProcess/WebProcessCache.h: * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::processDidTerminateOrFailedToLaunch): (WebKit::WebProcessProxy::maybeShutDown): (WebKit::WebProcessProxy::isResponsive): * UIProcess/WebProcessProxy.h: 2019-02-21 Alan Coon Cherry-pick r241845. rdar://problem/48267029 Regression(PSON) "Reload without content extensions" does not work when the main resource is blocked https://bugs.webkit.org/show_bug.cgi?id=194872 Reviewed by Alex Christensen. Source/WebKit: [WKWebView _reloadWithoutContentBlockers] relies on a ReloadOption flag that is passed to WebCore instead of using WebsitePolicies.contentBlockersEnabled flag. If the reload causes a process swap due to PSON, then the new process does not know about this ReloadOption and fails to honor it. Since the modern way to do this is WebsitePolicies, and since WebsitePolicies are properly propagated cross-process in case of process swap, this patch updates _reloadWithoutContentBlockers to set a flag on the Navigation which we use to later set the WebsitePolicies.contentBlockersEnabled flag in WebPageProxy::receivedNavigationPolicyDecision(). * UIProcess/API/APINavigation.h: (API::Navigation::setUserContentExtensionsEnabled): (API::Navigation::userContentExtensionsEnabled const): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::reload): (WebKit::WebPageProxy::receivedNavigationPolicyDecision): Tools: Add API test coverage. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241845 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-20 Chris Dumez Regression(PSON) "Reload without content extensions" does not work when the main resource is blocked https://bugs.webkit.org/show_bug.cgi?id=194872 Reviewed by Alex Christensen. [WKWebView _reloadWithoutContentBlockers] relies on a ReloadOption flag that is passed to WebCore instead of using WebsitePolicies.contentBlockersEnabled flag. If the reload causes a process swap due to PSON, then the new process does not know about this ReloadOption and fails to honor it. Since the modern way to do this is WebsitePolicies, and since WebsitePolicies are properly propagated cross-process in case of process swap, this patch updates _reloadWithoutContentBlockers to set a flag on the Navigation which we use to later set the WebsitePolicies.contentBlockersEnabled flag in WebPageProxy::receivedNavigationPolicyDecision(). * UIProcess/API/APINavigation.h: (API::Navigation::setUserContentExtensionsEnabled): (API::Navigation::userContentExtensionsEnabled const): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::reload): (WebKit::WebPageProxy::receivedNavigationPolicyDecision): 2019-02-21 Alan Coon Cherry-pick r241853. rdar://problem/48248223 Unreviewed build fix after r241823. * UIProcess/SuspendedPageProxy.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241853 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-20 Chris Dumez Unreviewed build fix after r241823. * UIProcess/SuspendedPageProxy.h: 2019-02-21 Alan Coon Cherry-pick r241823. rdar://problem/48248223 Regression(PSON) Crash under WebKit::WebPageProxy::decidePolicyForNavigationActionSync https://bugs.webkit.org/show_bug.cgi?id=194857 Reviewed by Alex Christensen. Source/WebKit: The ProvisionalPageProxy was blindly forwarding the DecidePolicyForNavigationActionSync synchronous IPC to the WebPageProxy, without passing it the process the IPC came from. As a result, WebPageProxy::decidePolicyForNavigationActionSync() would try to look up a WebFrameProxy using the provided frameID from the wrong process and we would end up hitting a RELEASE_ASSERT(). * UIProcess/ProvisionalPageProxy.cpp: (WebKit::ProvisionalPageProxy::decidePolicyForNavigationActionSync): (WebKit::ProvisionalPageProxy::didReceiveSyncMessage): * UIProcess/ProvisionalPageProxy.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::decidePolicyForNavigationActionSync): (WebKit::WebPageProxy::decidePolicyForNavigationActionSyncShared): * UIProcess/WebPageProxy.h: Tools: Add API test coverage. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241823 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-20 Chris Dumez Regression(PSON) Crash under WebKit::WebPageProxy::decidePolicyForNavigationActionSync https://bugs.webkit.org/show_bug.cgi?id=194857 Reviewed by Alex Christensen. The ProvisionalPageProxy was blindly forwarding the DecidePolicyForNavigationActionSync synchronous IPC to the WebPageProxy, without passing it the process the IPC came from. As a result, WebPageProxy::decidePolicyForNavigationActionSync() would try to look up a WebFrameProxy using the provided frameID from the wrong process and we would end up hitting a RELEASE_ASSERT(). * UIProcess/ProvisionalPageProxy.cpp: (WebKit::ProvisionalPageProxy::decidePolicyForNavigationActionSync): (WebKit::ProvisionalPageProxy::didReceiveSyncMessage): * UIProcess/ProvisionalPageProxy.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::decidePolicyForNavigationActionSync): (WebKit::WebPageProxy::decidePolicyForNavigationActionSyncShared): * UIProcess/WebPageProxy.h: 2019-02-21 Alan Coon Apply patch. rdar://problem/48243214 REGRESSION (PSON): Can't access optumbank.com from myuhc.com https://bugs.webkit.org/show_bug.cgi?id=194797 Reviewed by Geoffrey Garen. Source/WebKit: The issue was caused by us mistakenly process-swapping for a same-site server side redirect. The reason we were getting it wrong is because the logic in WebProcessPool::processForNavigationInternal() was expecting page.process() to be the source process and page.pageLoadState().url() to be the source URL. Those assumptions are incorrect when a server-side redirect occurs in a provisional process. In such case, the source process is the ProvisionalPageProxy's process and the source URL is the provisional URL, not the committed one. * UIProcess/ProvisionalPageProxy.cpp: (WebKit::ProvisionalPageProxy::didPerformServerRedirect): (WebKit::ProvisionalPageProxy::didReceiveServerRedirectForProvisionalLoadForFrame): (WebKit::ProvisionalPageProxy::didReceiveMessage): * UIProcess/ProvisionalPageProxy.h: Make sure the provisional page forwards IPC related to server-side redirects to the page so that the client gets informed. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::receivedNavigationPolicyDecision): (WebKit::WebPageProxy::didPerformServerRedirect): (WebKit::WebPageProxy::didPerformServerRedirectShared): * UIProcess/WebPageProxy.h: * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::processForNavigation): (WebKit::WebProcessPool::processForNavigationInternal): * UIProcess/WebProcessPool.h: Tools: Add API test coverage. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@241752 268f45cc-cd09-0410-ab3c-d52691b4dbfc (cherry picked from commit 53ac6d765e577c36c5c5e02659ee3ca21f25599f) 2019-02-18 Chris Dumez REGRESSION (PSON): Can't access optumbank.com from myuhc.com https://bugs.webkit.org/show_bug.cgi?id=194797 Reviewed by Geoffrey Garen. The issue was caused by us mistakenly process-swapping for a same-site server side redirect. The reason we were getting it wrong is because the logic in WebProcessPool::processForNavigationInternal() was expecting page.process() to be the source process and page.pageLoadState().url() to be the source URL. Those assumptions are incorrect when a server-side redirect occurs in a provisional process. In such case, the source process is the ProvisionalPageProxy's process and the source URL is the provisional URL, not the committed one. * UIProcess/ProvisionalPageProxy.cpp: (WebKit::ProvisionalPageProxy::didPerformServerRedirect): (WebKit::ProvisionalPageProxy::didReceiveServerRedirectForProvisionalLoadForFrame): (WebKit::ProvisionalPageProxy::didReceiveMessage): * UIProcess/ProvisionalPageProxy.h: Make sure the provisional page forwards IPC related to server-side redirects to the page so that the client gets informed. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::receivedNavigationPolicyDecision): (WebKit::WebPageProxy::didPerformServerRedirect): (WebKit::WebPageProxy::didPerformServerRedirectShared): * UIProcess/WebPageProxy.h: * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::processForNavigation): (WebKit::WebProcessPool::processForNavigationInternal): * UIProcess/WebProcessPool.h: 2019-02-20 Alan Coon Cherry-pick r241777. rdar://problem/48248215 Remove assertion introduced in r229683 https://bugs.webkit.org/show_bug.cgi?id=194825 Reviewed by Geoffrey Garen. * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::dispatchWillSubmitForm): If we reach this code and the form's original Document's Frame has been destroyed, we have already been told to submit the form so do so, just like we do if the WebPage has been destroyed. This is a rare edge case having to do with the timing of Frame destruction and decidePolicyForNavigationAction response, which unfortunately does not reproduce with a test case unless the timing of IPC is just right. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241777 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-19 Alex Christensen Remove assertion introduced in r229683 https://bugs.webkit.org/show_bug.cgi?id=194825 Reviewed by Geoffrey Garen. * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::dispatchWillSubmitForm): If we reach this code and the form's original Document's Frame has been destroyed, we have already been told to submit the form so do so, just like we do if the WebPage has been destroyed. This is a rare edge case having to do with the timing of Frame destruction and decidePolicyForNavigationAction response, which unfortunately does not reproduce with a test case unless the timing of IPC is just right. 2019-02-20 Alan Coon Cherry-pick r241721. rdar://problem/48243376 AX: PSON: Going back from apple.com to search results, cannot interact with HTML content. Disabling Swap Processes on Cross-Site Navigation resolves the issue. https://bugs.webkit.org/show_bug.cgi?id=194742 Reviewed by Chris Dumez. Source/WebCore: With the new process model, WebProcess hits a case where it tries to send the "page loaded" notification before VoiceOver had a chance to register for any notifications. This leads to those notifications being dropped (and thus this bug). This change instead asks the UIProcess to send the notification, which we know VoiceOver has registered for, and can reliably receive notifications. It also sends the notification for "load failures," which to the VO users' perspective amounts to the same thing as a successful page load. * accessibility/mac/AXObjectCacheMac.mm: (WebCore::AXObjectCache::frameLoadingEventPlatformNotification): Source/WebKit: Re-initialize the accessibility web process tokens when swapping processes. Send page load notifications from the UIProcess instead of the WebProcess to improve reliability. * UIProcess/mac/PageClientImplMac.mm: (WebKit::PageClientImpl::didFinishLoadForMainFrame): (WebKit::PageClientImpl::didFailLoadForMainFrame): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::reinitializeWebPage): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/gtk/WebPageGtk.cpp: (WebKit::WebPage::platformReinitialize): (WebKit::WebPage::platformDetach): Deleted. (WebKit::WebPage::platformEditorState const): Deleted. (WebKit::WebPage::updateAccessibilityTree): Deleted. (WebKit::WebPage::performDefaultBehaviorForKeyEvent): Deleted. (WebKit::WebPage::platformCanHandleRequest): Deleted. (WebKit::WebPage::platformUserAgent const): Deleted. (WebKit::WebPage::getCenterForZoomGesture): Deleted. (WebKit::WebPage::setInputMethodState): Deleted. (WebKit::WebPage::collapseSelectionInFrame): Deleted. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::platformReinitialize): * WebProcess/WebPage/mac/WebPageMac.mm: (WebKit::WebPage::platformReinitialize): * WebProcess/WebPage/win/WebPageWin.cpp: (WebKit::WebPage::platformReinitialize): * WebProcess/WebPage/wpe/WebPageWPE.cpp: (WebKit::WebPage::platformReinitialize): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241721 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-18 Chris Fleizach AX: PSON: Going back from apple.com to search results, cannot interact with HTML content. Disabling Swap Processes on Cross-Site Navigation resolves the issue. https://bugs.webkit.org/show_bug.cgi?id=194742 Reviewed by Chris Dumez. Re-initialize the accessibility web process tokens when swapping processes. Send page load notifications from the UIProcess instead of the WebProcess to improve reliability. * UIProcess/mac/PageClientImplMac.mm: (WebKit::PageClientImpl::didFinishLoadForMainFrame): (WebKit::PageClientImpl::didFailLoadForMainFrame): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::reinitializeWebPage): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/gtk/WebPageGtk.cpp: (WebKit::WebPage::platformReinitialize): (WebKit::WebPage::platformDetach): Deleted. (WebKit::WebPage::platformEditorState const): Deleted. (WebKit::WebPage::updateAccessibilityTree): Deleted. (WebKit::WebPage::performDefaultBehaviorForKeyEvent): Deleted. (WebKit::WebPage::platformCanHandleRequest): Deleted. (WebKit::WebPage::platformUserAgent const): Deleted. (WebKit::WebPage::getCenterForZoomGesture): Deleted. (WebKit::WebPage::setInputMethodState): Deleted. (WebKit::WebPage::collapseSelectionInFrame): Deleted. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::platformReinitialize): * WebProcess/WebPage/mac/WebPageMac.mm: (WebKit::WebPage::platformReinitialize): * WebProcess/WebPage/win/WebPageWin.cpp: (WebKit::WebPage::platformReinitialize): * WebProcess/WebPage/wpe/WebPageWPE.cpp: (WebKit::WebPage::platformReinitialize): 2019-02-20 Alan Coon Cherry-pick r241658. rdar://problem/48243434 https://device.login.microsoftonline.com is hanging on STP75 https://bugs.webkit.org/show_bug.cgi?id=194734 Reviewed by Jiewen Tan. Make sure to only go the XPC route if SecKeyProxyStore has credentials. Tested manually by going to the above website with and without the patch. Load hangs without the patch and completes with the patch. * UIProcess/Authentication/AuthenticationChallengeProxy.cpp: (WebKit::AuthenticationChallengeProxy::AuthenticationChallengeProxy): * UIProcess/Authentication/cocoa/SecKeyProxyStore.h: * UIProcess/Authentication/cocoa/SecKeyProxyStore.mm: (WebKit::SecKeyProxyStore::initialize): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241658 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-17 Youenn Fablet https://device.login.microsoftonline.com is hanging on STP75 https://bugs.webkit.org/show_bug.cgi?id=194734 Reviewed by Jiewen Tan. Make sure to only go the XPC route if SecKeyProxyStore has credentials. Tested manually by going to the above website with and without the patch. Load hangs without the patch and completes with the patch. * UIProcess/Authentication/AuthenticationChallengeProxy.cpp: (WebKit::AuthenticationChallengeProxy::AuthenticationChallengeProxy): * UIProcess/Authentication/cocoa/SecKeyProxyStore.h: * UIProcess/Authentication/cocoa/SecKeyProxyStore.mm: (WebKit::SecKeyProxyStore::initialize): 2019-02-20 Alan Coon Cherry-pick r241606. rdar://problem/48243273 Regression(PSON) Navigating quickly back and forth can lead to getting 'about:blank' in the backforward list https://bugs.webkit.org/show_bug.cgi?id=194717 Reviewed by Brady Eidson. Source/WebKit: When the client does a history navigation, the UIProcess sends a WebPage::GoToBackForwardItem IPC to the WebProcess and the WebProcess sends a WebPageProxy::BackForwardGoToItem IPC back to the UIProcess to update the current item in the BackForwardList. This means that there is a slight delay between the point a client requests a history navigation and the point where the BackForwardList's current item gets update. This delay is pre-existing behavior and not new to PSON. However, with PSON enabled, if we decide to process-swap for the history navigation, we'll tell the previous (committed) process to ignore the load and we ask a new (provisional) process to do the history navigation. When the previous process receives the request to ignore the history navigation, it restores the History's current item to the one previous the navigation, which sends a WebPageProxy::GoToBackForwardItem IPC to the UIProcess to update the BackForwardList as well. In parallel, the new process starts the history navigation and also sends a WebPageProxy::GoToBackForwardItem to update the BackForwardList's current item as well. We end up with a race between the 2 GoToBackForwardItem IPC messages coming from the old and new process. If the old process's message loses the race, we end up with the wrong current history item getting set in the UIProcess. Later, when we commit the provisional load and try to suspend the previous page, we would save the SuspendedPage on the *wrong* BackForwardList item. If one tries to load this BackForwardList item later, we'll use its SuspendedPage and try to unsuspend it. However, because the PageCache entry is saved on another HistoryItem than the one getting loaded in the WebProcess side, we attempt to do a regular load instead of a PageCache restore. We end up failing the load because pages cannot trigger new loads while in page cache. Because the load fails, we end up loading the initial empty document and this is how we end up with 'about:blank' in the back forward list. To address the issue, update WebPageProxy::backForwardGoToItem() to ignore messages from the old/committed WebProcess when there is a pending provisional load. If the committed processes starts a legit new load, it would clear any existing pending provisional load before attempting the call backForwardGoToItem(). As a result, ignoring such messages from the old processes when there is a pending provisional load is safe. In the future, we should probably move more of the history / backForwardList management to the UIProcess to avoid this sort of issues. This would be a much larger refactoring though so I am going with this simpler fix that is easily cherry-pickable for now. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::suspendCurrentPageIfPossible): (WebKit::WebPageProxy::continueNavigationInNewProcess): (WebKit::WebPageProxy::backForwardGoToItem): Tools: Add API test coverage. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241606 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-15 Chris Dumez Regression(PSON) Navigating quickly back and forth can lead to getting 'about:blank' in the backforward list https://bugs.webkit.org/show_bug.cgi?id=194717 Reviewed by Brady Eidson. When the client does a history navigation, the UIProcess sends a WebPage::GoToBackForwardItem IPC to the WebProcess and the WebProcess sends a WebPageProxy::BackForwardGoToItem IPC back to the UIProcess to update the current item in the BackForwardList. This means that there is a slight delay between the point a client requests a history navigation and the point where the BackForwardList's current item gets update. This delay is pre-existing behavior and not new to PSON. However, with PSON enabled, if we decide to process-swap for the history navigation, we'll tell the previous (committed) process to ignore the load and we ask a new (provisional) process to do the history navigation. When the previous process receives the request to ignore the history navigation, it restores the History's current item to the one previous the navigation, which sends a WebPageProxy::GoToBackForwardItem IPC to the UIProcess to update the BackForwardList as well. In parallel, the new process starts the history navigation and also sends a WebPageProxy::GoToBackForwardItem to update the BackForwardList's current item as well. We end up with a race between the 2 GoToBackForwardItem IPC messages coming from the old and new process. If the old process's message loses the race, we end up with the wrong current history item getting set in the UIProcess. Later, when we commit the provisional load and try to suspend the previous page, we would save the SuspendedPage on the *wrong* BackForwardList item. If one tries to load this BackForwardList item later, we'll use its SuspendedPage and try to unsuspend it. However, because the PageCache entry is saved on another HistoryItem than the one getting loaded in the WebProcess side, we attempt to do a regular load instead of a PageCache restore. We end up failing the load because pages cannot trigger new loads while in page cache. Because the load fails, we end up loading the initial empty document and this is how we end up with 'about:blank' in the back forward list. To address the issue, update WebPageProxy::backForwardGoToItem() to ignore messages from the old/committed WebProcess when there is a pending provisional load. If the committed processes starts a legit new load, it would clear any existing pending provisional load before attempting the call backForwardGoToItem(). As a result, ignoring such messages from the old processes when there is a pending provisional load is safe. In the future, we should probably move more of the history / backForwardList management to the UIProcess to avoid this sort of issues. This would be a much larger refactoring though so I am going with this simpler fix that is easily cherry-pickable for now. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::suspendCurrentPageIfPossible): (WebKit::WebPageProxy::continueNavigationInNewProcess): (WebKit::WebPageProxy::backForwardGoToItem): 2019-02-20 Alan Coon Cherry-pick r241549. rdar://problem/48243406 AX: ARIA Reflection was disabled in error https://bugs.webkit.org/show_bug.cgi?id=194647 Reviewed by Ryosuke Niwa. Source/WebKit: * Shared/WebPreferences.yaml: Tools: Remove test override now that this feature should be enabled by default. * WebKitTestRunner/TestController.cpp: (WTR::TestController::resetPreferencesToConsistentValues): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241549 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-14 Chris Fleizach AX: ARIA Reflection was disabled in error https://bugs.webkit.org/show_bug.cgi?id=194647 Reviewed by Ryosuke Niwa. * Shared/WebPreferences.yaml: 2019-02-18 Babak Shafiei Cherry-pick r241635. rdar://problem/48165262 [PSON] Allow tweaking WebProcess cache parameters via user defaults https://bugs.webkit.org/show_bug.cgi?id=194731 Reviewed by Geoffrey Garen. Allow tweaking WebProcess cache parameters via user defaults like so: $ defaults write com.apple.Safari WebProcessCacheCachedProcessLifetimeInSeconds 120 -> Cached processes will be evicted after 2 minutes (instead of 30) $ defaults write com.apple.Safari WebProcessCacheClearingDelayAfterApplicationResignsActiveInSeconds 60 -> Web process cache will be cleared if Safari is no longer active for 1 minutes (instead of 5). * SourcesCocoa.txt: * UIProcess/Cocoa/WebProcessCacheCocoa.mm: Copied from Source/WebKit/UIProcess/WebProcessCache.h. (WebKit::WebProcessCache::platformInitialize): * UIProcess/WebProcessCache.cpp: (WebKit::WebProcessCache::WebProcessCache): (WebKit::WebProcessCache::platformInitialize): * UIProcess/WebProcessCache.h: * WebKit.xcodeproj/project.pbxproj: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241635 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-15 Chris Dumez [PSON] Allow tweaking WebProcess cache parameters via user defaults https://bugs.webkit.org/show_bug.cgi?id=194731 Reviewed by Geoffrey Garen. Allow tweaking WebProcess cache parameters via user defaults like so: $ defaults write com.apple.Safari WebProcessCacheCachedProcessLifetimeInSeconds 120 -> Cached processes will be evicted after 2 minutes (instead of 30) $ defaults write com.apple.Safari WebProcessCacheClearingDelayAfterApplicationResignsActiveInSeconds 60 -> Web process cache will be cleared if Safari is no longer active for 1 minutes (instead of 5). * SourcesCocoa.txt: * UIProcess/Cocoa/WebProcessCacheCocoa.mm: Copied from Source/WebKit/UIProcess/WebProcessCache.h. (WebKit::WebProcessCache::platformInitialize): * UIProcess/WebProcessCache.cpp: (WebKit::WebProcessCache::WebProcessCache): (WebKit::WebProcessCache::platformInitialize): * UIProcess/WebProcessCache.h: * WebKit.xcodeproj/project.pbxproj: 2019-02-18 Babak Shafiei Cherry-pick r241631. rdar://problem/48165260 [PSON] Disable WebContent process cache on devices with less than 3GB of RAM https://bugs.webkit.org/show_bug.cgi?id=194726 Reviewed by Geoffrey Garen. * UIProcess/WebProcessCache.cpp: (WebKit::WebProcessCache::updateCapacity): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241631 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-15 Chris Dumez [PSON] Disable WebContent process cache on devices with less than 3GB of RAM https://bugs.webkit.org/show_bug.cgi?id=194726 Reviewed by Geoffrey Garen. * UIProcess/WebProcessCache.cpp: (WebKit::WebProcessCache::updateCapacity): 2019-02-18 Babak Shafiei Cherry-pick r241584. rdar://problem/48122553 Unreviewed. Fix GTK+ build after r241556 I guess this is due to unified builds after a new file being added in r241556. Patch by Carlos Garcia Campos on 2019-02-15 * UIProcess/API/C/WKAuthenticationDecisionListener.cpp: * UIProcess/API/C/WKPage.cpp: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241584 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-15 Carlos Garcia Campos Unreviewed. Fix GTK+ build after r241556 I guess this is due to unified builds after a new file being added in r241556. * UIProcess/API/C/WKAuthenticationDecisionListener.cpp: * UIProcess/API/C/WKPage.cpp: 2019-02-18 Babak Shafiei Apply patch. rdar://problem/48122553 Introduce a WebContent Process cache https://bugs.webkit.org/show_bug.cgi?id=194594 Reviewed by Geoff Garen. Source/WebCore: Update localizable strings. * en.lproj/Localizable.strings: Source/WebKit: Introduce a WebContent Process cache to reduce the number of process launches when process swap on navigation is enabled, and to reduce the power cost of the feature. If a WebProcess loaded pages from a single registrable domain then it is eligible for the cache. When process-swapping on navigation to a new registrable domain, we now attempt to retrieve a process from the cache for the domain in question instead of always launching a new one. The WebProcess cache currently has the following attributes: - It may contains 4 processes per GB of RAM the machine has, up to 30 processes. - WebProcesses automatically get evicted from the cache after 30 minutes. - If the application is no longer the active app, then the cache will get cleared after 5 minutes. - WebProcesses that are in the cache are reported as "(Cached)" in Activity Monitor. The WebProcess cache is currently disabled by default and can by enabled by the client via SPI. * Shared/WebBackForwardListItem.cpp: (WebKit::WebBackForwardListItem::WebBackForwardListItem): * Shared/WebBackForwardListItem.h: (WebKit::WebBackForwardListItem::lastProcessIdentifier const): (WebKit::WebBackForwardListItem::setLastProcessIdentifier): Add new lastProcessIdentifier data member that reflects which process this item was last loaded in. It is normally identical to the identifier of the process that created the item but it gets overriden in case of cross-site client-side redirect, since a new process takes over the item in this case. * Sources.txt: Add new source file. * UIProcess/API/APIProcessPoolConfiguration.cpp: (API::ProcessPoolConfiguration::copy): * UIProcess/API/APIProcessPoolConfiguration.h: * UIProcess/API/C/WKContextConfigurationRef.cpp: (WKContextConfigurationUsesWebProcessCache): (WKContextConfigurationSetUsesWebProcessCache): * UIProcess/API/C/WKContextConfigurationRef.h: * UIProcess/API/Cocoa/_WKProcessPoolConfiguration.h: * UIProcess/API/Cocoa/_WKProcessPoolConfiguration.mm: (-[_WKProcessPoolConfiguration setUsesWebProcessCache:]): (-[_WKProcessPoolConfiguration usesWebProcessCache]): Add new SPI to enable the WebProcess cache. * UIProcess/API/Cocoa/WKProcessPool.mm: (-[WKProcessPool _webProcessCountIgnoringPrewarmedAndCached]): * UIProcess/API/Cocoa/WKProcessPoolPrivate.h: Add new SPI for testing which returns the number of WebProcesses ignoring both prewarmed and cached ones. * UIProcess/Cocoa/WebProcessPoolCocoa.mm: (WebKit::WebProcessPool::registerNotificationObservers): (WebKit::WebProcessPool::unregisterNotificationObservers): Add application active state observers as the WebProcess cache gets cleared when the application resigns active state for more than 5 minutes. * UIProcess/ProvisionalPageProxy.cpp: (WebKit::ProvisionalPageProxy::loadRequest): When doing a load in a new process with the BackForwardList locked (i.e. client-side redirect), make sure we update the last process identifier for the BackForwardListItem. This is important because the logic in WebProcessPool::processForNavigation() relies on this identifier to select which process to do the history navigation into, and we want to do the load in the post-redirect process, not the pre-redirect one. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared): Tell the WebProcess whenever a main frame provisional load is started, providing the URL. * UIProcess/WebProcessCache.cpp: Added. (WebKit::WebProcessCache::WebProcessCache): (WebKit::WebProcessCache::addProcess): (WebKit::WebProcessCache::takeProcess): (WebKit::WebProcessCache::updateMaximumSize): (WebKit::WebProcessCache::clear): (WebKit::WebProcessCache::setApplicationIsActive): (WebKit::WebProcessCache::evictProcess): (WebKit::WebProcessCache::CachedProcess::CachedProcess): (WebKit::WebProcessCache::CachedProcess::~CachedProcess): (WebKit::WebProcessCache::CachedProcess::takeProcess): (WebKit::WebProcessCache::CachedProcess::evictionTimerFired): * UIProcess/WebProcessCache.h: Added. (WebKit::WebProcessCache::maximumSize): (WebKit::WebProcessCache::size const): (WebKit::WebProcessCache::CachedProcess::process): Add process cache implementation. * UIProcess/WebProcessPool.cpp: (WebKit::m_webProcessCache): WebProcessCache is stored on the WebProcessPool via m_webProcessCache data member. (WebKit::WebProcessPool::~WebProcessPool): Clear the WebProcess cache in the destructor. (WebKit::WebProcessPool::setApplicationIsActive): Notify the WebProcessCache whenever the application's active state changes. (WebKit::WebProcessPool::createWebPage): If the state of PSON changes via the experimental features menu, dynamically update the WebProcessCache's size. This is needed because the cache is disabled when PSON is disabled. (WebKit::WebProcessPool::handleMemoryPressureWarning): Clear the WebProcess cache on memory pressure. (WebKit::WebProcessPool::processForNavigationInternal): Query the WebProcessCache before attempting to create a new WebProcess for a cross-site navigation. (WebKit::WebProcessPool::findReusableSuspendedPageProcess): This logic was split out of processForNavigationInternal() to reduce the size of the method. * UIProcess/WebProcessPool.h: * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::setIsInProcessCache): Update the isInProcessCache flag on the WebProcessProxy and send an IPC to the WebContent process so that it can update its name in Activity Monitor. We also need to stop holding a strong reference to the WebProcessPool whenever the process is in the cache, similarly to what we do for pre-warmed processes, given that such processes should not keep the process pool alive. (WebKit::WebProcessProxy::addExistingWebPage): Assert that we never try to add a page to a cached process, it should be taken out of the cache before use. (WebKit::WebProcessProxy::hasProvisionalPageWithID const): (WebKit::WebProcessProxy::isAllowedToUpdateBackForwardItem const): (WebKit::WebProcessProxy::updateBackForwardItem): In case of client-side redirects, the previous process would sometimes send an IPC causing the UIProcess' backforward list item to get updated with the pre-redirect URL after we've already redirected. This previously would be unlikely to occur because we do not suspend client-redirect pages and their process would normally exit before getting a chance to send the IPC. However, with the process cache, the bug became obvious as the process would stay alive and send up the "bad" IPC. To address the issue, we now only let the IPC update the item if the item's page is (still) associated with the process. In the future, we may want to update the IPC so that it gets sent to the WebPageProxy instead of the WebProcessProxy. (WebKit::WebProcessProxy::processDidTerminateOrFailedToLaunch): If a cached WebProcess crashes, remove it from the cache so that we do not attempt to use it for a load later. (WebKit::WebProcessProxy::canBeAddedToWebProcessCache const): Only cache WebProcesses that have loaded a single registrable domain. Also prevent caching for service worker and inspector processes. (WebKit::WebProcessProxy::maybeShutDown): If the process is cacheable, add it to the cache instead of shutting it down right away. (WebKit::WebProcessProxy::canTerminateAuxiliaryProcess): Make sure we do not attempt to terminate a processes that is in the cache. (WebKit::WebProcessProxy::didStartProvisionalLoadForMainFrame): Whenever a main frame provisional load starts, make sure we update the process's associated registrable domain. nullopt indicates that there is no associated domain yet. Null string indicates that the process is associated with several registrable domain and is therefore not eligible for caching. * UIProcess/WebProcessProxy.h: (WebKit::WebProcessProxy::registrableDomain const): (WebKit::WebProcessProxy::isInProcessCache const): (WebKit::WebProcessProxy::provisionalPageCount const): Add convenience getters. * WebKit.xcodeproj/project.pbxproj: Add new files to project. * WebProcess/WebProcess.cpp: (WebKit::WebProcess::setIsInProcessCache): * WebProcess/WebProcess.h: * WebProcess/WebProcess.messages.in: * WebProcess/cocoa/WebProcessCocoa.mm: (WebKit::WebProcess::updateProcessName): Update the WebProcess' name in Activity Monitor whenever it goes into or out of the WebProcess cache. Tools: Update API tests to turn on the WebContent Process cache. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@241556 268f45cc-cd09-0410-ab3c-d52691b4dbfc (cherry picked from commit dc197d35fd5d947ff4c81c2e0f5636b9cad36b3c) 2019-02-14 Chris Dumez [PSON] Introduce a WebContent Process cache https://bugs.webkit.org/show_bug.cgi?id=194594 Reviewed by Geoff Garen. Introduce a WebContent Process cache to reduce the number of process launches when process swap on navigation is enabled, and to reduce the power cost of the feature. If a WebProcess loaded pages from a single registrable domain then it is eligible for the cache. When process-swapping on navigation to a new registrable domain, we now attempt to retrieve a process from the cache for the domain in question instead of always launching a new one. The WebProcess cache currently has the following attributes: - It may contains 4 processes per GB of RAM the machine has, up to 30 processes. - WebProcesses automatically get evicted from the cache after 30 minutes. - If the application is no longer the active app, then the cache will get cleared after 5 minutes. - WebProcesses that are in the cache are reported as "(Cached)" in Activity Monitor. The WebProcess cache is currently disabled by default and can by enabled by the client via SPI. * Shared/WebBackForwardListItem.cpp: (WebKit::WebBackForwardListItem::WebBackForwardListItem): * Shared/WebBackForwardListItem.h: (WebKit::WebBackForwardListItem::lastProcessIdentifier const): (WebKit::WebBackForwardListItem::setLastProcessIdentifier): Add new lastProcessIdentifier data member that reflects which process this item was last loaded in. It is normally identical to the identifier of the process that created the item but it gets overriden in case of cross-site client-side redirect, since a new process takes over the item in this case. * Sources.txt: Add new source file. * UIProcess/API/APIProcessPoolConfiguration.cpp: (API::ProcessPoolConfiguration::copy): * UIProcess/API/APIProcessPoolConfiguration.h: * UIProcess/API/C/WKContextConfigurationRef.cpp: (WKContextConfigurationUsesWebProcessCache): (WKContextConfigurationSetUsesWebProcessCache): * UIProcess/API/C/WKContextConfigurationRef.h: * UIProcess/API/Cocoa/_WKProcessPoolConfiguration.h: * UIProcess/API/Cocoa/_WKProcessPoolConfiguration.mm: (-[_WKProcessPoolConfiguration setUsesWebProcessCache:]): (-[_WKProcessPoolConfiguration usesWebProcessCache]): Add new SPI to enable the WebProcess cache. * UIProcess/API/Cocoa/WKProcessPool.mm: (-[WKProcessPool _webProcessCountIgnoringPrewarmedAndCached]): * UIProcess/API/Cocoa/WKProcessPoolPrivate.h: Add new SPI for testing which returns the number of WebProcesses ignoring both prewarmed and cached ones. * UIProcess/Cocoa/WebProcessPoolCocoa.mm: (WebKit::WebProcessPool::registerNotificationObservers): (WebKit::WebProcessPool::unregisterNotificationObservers): Add application active state observers as the WebProcess cache gets cleared when the application resigns active state for more than 5 minutes. * UIProcess/ProvisionalPageProxy.cpp: (WebKit::ProvisionalPageProxy::loadRequest): When doing a load in a new process with the BackForwardList locked (i.e. client-side redirect), make sure we update the last process identifier for the BackForwardListItem. This is important because the logic in WebProcessPool::processForNavigation() relies on this identifier to select which process to do the history navigation into, and we want to do the load in the post-redirect process, not the pre-redirect one. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared): Tell the WebProcess whenever a main frame provisional load is started, providing the URL. * UIProcess/WebProcessCache.cpp: Added. (WebKit::WebProcessCache::WebProcessCache): (WebKit::WebProcessCache::addProcess): (WebKit::WebProcessCache::takeProcess): (WebKit::WebProcessCache::updateMaximumSize): (WebKit::WebProcessCache::clear): (WebKit::WebProcessCache::setApplicationIsActive): (WebKit::WebProcessCache::evictProcess): (WebKit::WebProcessCache::CachedProcess::CachedProcess): (WebKit::WebProcessCache::CachedProcess::~CachedProcess): (WebKit::WebProcessCache::CachedProcess::takeProcess): (WebKit::WebProcessCache::CachedProcess::evictionTimerFired): * UIProcess/WebProcessCache.h: Added. (WebKit::WebProcessCache::maximumSize): (WebKit::WebProcessCache::size const): (WebKit::WebProcessCache::CachedProcess::process): Add process cache implementation. * UIProcess/WebProcessPool.cpp: (WebKit::m_webProcessCache): WebProcessCache is stored on the WebProcessPool via m_webProcessCache data member. (WebKit::WebProcessPool::~WebProcessPool): Clear the WebProcess cache in the destructor. (WebKit::WebProcessPool::setApplicationIsActive): Notify the WebProcessCache whenever the application's active state changes. (WebKit::WebProcessPool::createWebPage): If the state of PSON changes via the experimental features menu, dynamically update the WebProcessCache's size. This is needed because the cache is disabled when PSON is disabled. (WebKit::WebProcessPool::handleMemoryPressureWarning): Clear the WebProcess cache on memory pressure. (WebKit::WebProcessPool::processForNavigationInternal): Query the WebProcessCache before attempting to create a new WebProcess for a cross-site navigation. (WebKit::WebProcessPool::findReusableSuspendedPageProcess): This logic was split out of processForNavigationInternal() to reduce the size of the method. * UIProcess/WebProcessPool.h: * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::setIsInProcessCache): Update the isInProcessCache flag on the WebProcessProxy and send an IPC to the WebContent process so that it can update its name in Activity Monitor. We also need to stop holding a strong reference to the WebProcessPool whenever the process is in the cache, similarly to what we do for pre-warmed processes, given that such processes should not keep the process pool alive. (WebKit::WebProcessProxy::addExistingWebPage): Assert that we never try to add a page to a cached process, it should be taken out of the cache before use. (WebKit::WebProcessProxy::hasProvisionalPageWithID const): (WebKit::WebProcessProxy::isAllowedToUpdateBackForwardItem const): (WebKit::WebProcessProxy::updateBackForwardItem): In case of client-side redirects, the previous process would sometimes send an IPC causing the UIProcess' backforward list item to get updated with the pre-redirect URL after we've already redirected. This previously would be unlikely to occur because we do not suspend client-redirect pages and their process would normally exit before getting a chance to send the IPC. However, with the process cache, the bug became obvious as the process would stay alive and send up the "bad" IPC. To address the issue, we now only let the IPC update the item if the item's page is (still) associated with the process. In the future, we may want to update the IPC so that it gets sent to the WebPageProxy instead of the WebProcessProxy. (WebKit::WebProcessProxy::processDidTerminateOrFailedToLaunch): If a cached WebProcess crashes, remove it from the cache so that we do not attempt to use it for a load later. (WebKit::WebProcessProxy::canBeAddedToWebProcessCache const): Only cache WebProcesses that have loaded a single registrable domain. Also prevent caching for service worker and inspector processes. (WebKit::WebProcessProxy::maybeShutDown): If the process is cacheable, add it to the cache instead of shutting it down right away. (WebKit::WebProcessProxy::canTerminateAuxiliaryProcess): Make sure we do not attempt to terminate a processes that is in the cache. (WebKit::WebProcessProxy::didStartProvisionalLoadForMainFrame): Whenever a main frame provisional load starts, make sure we update the process's associated registrable domain. nullopt indicates that there is no associated domain yet. Null string indicates that the process is associated with several registrable domain and is therefore not eligible for caching. * UIProcess/WebProcessProxy.h: (WebKit::WebProcessProxy::registrableDomain const): (WebKit::WebProcessProxy::isInProcessCache const): (WebKit::WebProcessProxy::provisionalPageCount const): Add convenience getters. * WebKit.xcodeproj/project.pbxproj: Add new files to project. * WebProcess/WebProcess.cpp: (WebKit::WebProcess::setIsInProcessCache): * WebProcess/WebProcess.h: * WebProcess/WebProcess.messages.in: * WebProcess/cocoa/WebProcessCocoa.mm: (WebKit::WebProcess::updateProcessName): Update the WebProcess' name in Activity Monitor whenever it goes into or out of the WebProcess cache. 2019-02-13 Babak Shafiei Apply patch. rdar://problem/47673836 2019-02-13 Brent Fulgham [iOS] Revert ability to set programmatic focus when hardware keyboard is attached https://bugs.webkit.org/show_bug.cgi?id=194570 Reviewed by Dan Bates. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _elementDidFocus:userIsInteracting:blurPreviousNode:changingActivityState:userObject:]): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::platformEditorState const): 2019-02-13 Babak Shafiei Cherry-pick r241500. rdar://problem/48065631 Crash in WKBundleFrameGetParentFrame when called inside didRemoveFrameFromHierarchy https://bugs.webkit.org/show_bug.cgi?id=194641 Reviewed by Geoffrey Garen. Source/WebKit: Fixed the bug by adding a null check to WebFrame::parentFrame. * WebProcess/WebPage/WebFrame.cpp: (WebKit::WebFrame::parentFrame const): Tools: Added a call to WKBundleFrameGetParentFrame to an existing test for didRemoveFrameFromHierarchy so that the test would fail without this fix. * TestWebKitAPI/Tests/WebKit/DidRemoveFrameFromHiearchyInPageCache_Bundle.cpp: (TestWebKitAPI::didRemoveFrameFromHierarchyCallback): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241500 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-13 Ryosuke Niwa Crash in WKBundleFrameGetParentFrame when called inside didRemoveFrameFromHierarchy https://bugs.webkit.org/show_bug.cgi?id=194641 Reviewed by Geoffrey Garen. Fixed the bug by adding a null check to WebFrame::parentFrame. * WebProcess/WebPage/WebFrame.cpp: (WebKit::WebFrame::parentFrame const): 2019-02-13 Babak Shafiei Cherry-pick r241481. rdar://problem/48065616 Encrypted PDFs inside or crash the Web Content process https://bugs.webkit.org/show_bug.cgi?id=194605 Reviewed by Andy Estes. Source/WebKit: * WebProcess/Plugins/PDF/PDFPlugin.mm: (WebKit::PDFPlugin::createPasswordEntryForm): Don't try to create a password form field if we can't make form fields. This means you will be left with a useless embedded PDF, but at least the Web Content process won't crash. We'll need to find an alternative implementation of PDF embedded form fields that is compatible with and if we want to support this. Currently we piggy-back off the fact that we can just insert s into the PluginDocument's DOM, but we can't do that if there is no PluginDocument, just a main document, like in the case. LayoutTests: * fast/replaced/encrypted-pdf-as-object-and-embed-expected.txt: Added. * fast/replaced/encrypted-pdf-as-object-and-embed.html: Added. * fast/replaced/resources/encrypted-image.pdf: Added. Add a test ensuring that we don't crash with encrypted PDF in or . git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241481 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-13 Tim Horton Encrypted PDFs inside or crash the Web Content process https://bugs.webkit.org/show_bug.cgi?id=194605 Reviewed by Andy Estes. * WebProcess/Plugins/PDF/PDFPlugin.mm: (WebKit::PDFPlugin::createPasswordEntryForm): Don't try to create a password form field if we can't make form fields. This means you will be left with a useless embedded PDF, but at least the Web Content process won't crash. We'll need to find an alternative implementation of PDF embedded form fields that is compatible with and if we want to support this. Currently we piggy-back off the fact that we can just insert s into the PluginDocument's DOM, but we can't do that if there is no PluginDocument, just a main document, like in the case. 2019-02-13 Babak Shafiei Cherry-pick r241480. rdar://problem/48065618 Further restricting webarchive loads https://bugs.webkit.org/show_bug.cgi?id=194567 Reviewed by Youenn Fablet. Source/WebCore: This patch futher restricts main frame webarchive loads to the followings: 1) loaded by clients; 2) loaded by drag; 3) reloaded from any of the previous two. It moves setAlwaysAllowLocalWebarchive, which is used for testing only, from Document to FrameLoader such that the option is remembered during redirections. Covered by API tests. * dom/Document.h: (WebCore::Document::setAlwaysAllowLocalWebarchive): Deleted. (WebCore::Document::alwaysAllowLocalWebarchive const): Deleted. * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::disallowWebArchive const): * loader/DocumentLoader.h: (WebCore::DocumentLoader::setAllowsWebArchiveForMainFrame): (WebCore::DocumentLoader::allowsWebArchiveForMainFrame): * loader/FrameLoadRequest.h: (WebCore::FrameLoadRequest::setIsRequestFromClientOrUserInput): (WebCore::FrameLoadRequest::isRequestFromClientOrUserInput): * loader/FrameLoader.cpp: (WebCore::FrameLoader::load): (WebCore::FrameLoader::reload): * loader/FrameLoader.h: (WebCore::FrameLoader::setAlwaysAllowLocalWebarchive): (WebCore::FrameLoader::alwaysAllowLocalWebarchive const): * page/DragController.cpp: (WebCore::DragController::performDragOperation): * testing/Internals.cpp: (WebCore::Internals::setAlwaysAllowLocalWebarchive const): * testing/Internals.h: * testing/Internals.idl: Source/WebKit: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::loadRequest): Set a flag to indicate a load is started from clients. Tools: Besides adding API tests, this patch also enhances DragAndDropSimulator to allow navigations on drop. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/mac/LoadWebArchive.mm: Added. (-[TestLoadWebArchiveNavigationDelegate webView:didFinishNavigation:]): (-[TestLoadWebArchiveNavigationDelegate webView:didFailProvisionalNavigation:withError:]): (-[TestLoadWebArchiveNavigationDelegate webView:createWebViewWithConfiguration:forNavigationAction:windowFeatures:]): (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/mac/helloworld.webarchive: Added. * TestWebKitAPI/Tests/mac/load-web-archive-1.html: Added. * TestWebKitAPI/Tests/mac/load-web-archive-2.html: Added. * TestWebKitAPI/cocoa/DragAndDropSimulator.h: * TestWebKitAPI/mac/DragAndDropSimulatorMac.mm: (-[DragAndDropSimulator initWithWebViewFrame:configuration:]): (-[DragAndDropSimulator _webView:dragDestinationActionMaskForDraggingInfo:]): LayoutTests: * platform/mac/fast/loader/webarchive-encoding-respected.html: * webarchive/loading/cache-expired-subresource.html: * webarchive/loading/javascript-url-iframe-crash.html: * webarchive/loading/mainresource-null-mimetype-crash.html: * webarchive/loading/missing-data.html: * webarchive/loading/object.html: * webarchive/loading/test-loading-archive-subresource-null-mimetype.html: * webarchive/loading/test-loading-archive-subresource.html: * webarchive/loading/test-loading-archive.html: * webarchive/loading/test-loading-top-archive.html: * webarchive/loading/video-in-webarchive.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241480 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-12 Jiewen Tan Further restricting webarchive loads https://bugs.webkit.org/show_bug.cgi?id=194567 Reviewed by Youenn Fablet. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::loadRequest): Set a flag to indicate a load is started from clients. 2019-02-13 Babak Shafiei Cherry-pick r241453. rdar://problem/48065612 Fix -Wformat warning from r241401 https://bugs.webkit.org/show_bug.cgi?id=194584 * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::setActivityState): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241453 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-13 Michael Catanzaro Fix -Wformat warning from r241401 https://bugs.webkit.org/show_bug.cgi?id=194584 * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::setActivityState): 2019-02-13 Babak Shafiei Cherry-pick r241448. rdar://problem/48065637 Crash in WebKit::CacheStorage::Engine::cachesRootPath https://bugs.webkit.org/show_bug.cgi?id=194588 Reviewed by Youenn Fablet. * NetworkProcess/cache/CacheStorageEngine.cpp: (WebKit::CacheStorage::Engine::cachesRootPath): Salt may have not been initialized yet when the Engine is destroyed. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241448 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-13 Antti Koivisto Crash in WebKit::CacheStorage::Engine::cachesRootPath https://bugs.webkit.org/show_bug.cgi?id=194588 Reviewed by Youenn Fablet. * NetworkProcess/cache/CacheStorageEngine.cpp: (WebKit::CacheStorage::Engine::cachesRootPath): Salt may have not been initialized yet when the Engine is destroyed. 2019-02-13 Babak Shafiei Cherry-pick r241401. rdar://problem/48065612 Crash in Page::setActivityState because m_page is null https://bugs.webkit.org/show_bug.cgi?id=194584 Reviewed by Antti Koivisto. Add a null check to avoid the crash. Also add a debug assertion to help diagnose this in the future. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::setActivityState): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241401 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-13 Ryosuke Niwa Crash in Page::setActivityState because m_page is null https://bugs.webkit.org/show_bug.cgi?id=194584 Reviewed by Antti Koivisto. Add a null check to avoid the crash. Also add a debug assertion to help diagnose this in the future. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::setActivityState): 2019-02-13 Babak Shafiei Cherry-pick r241349. rdar://problem/48065639 Null deref in userInterfaceLayoutDirection under ViewGestureController::handleSwipeGesture https://bugs.webkit.org/show_bug.cgi?id=194569 Reviewed by Wenson Hsieh. * UIProcess/mac/ViewGestureControllerMac.mm: (WebKit::ViewGestureController::handleSwipeGesture): It is conceivable that we could get here if the client closes the page e.g. in the callback from willEndSwipeGesture. We already guarded against this ... one line too late! Rearrange the lines so we don't call into WebPageProxy at all if we don't have a drawing area (which is a strict subset of the time that isValid would return true). This is a speculative fix, since I can no longer reproduce the crash on demand. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241349 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-12 Tim Horton Null deref in userInterfaceLayoutDirection under ViewGestureController::handleSwipeGesture https://bugs.webkit.org/show_bug.cgi?id=194569 Reviewed by Wenson Hsieh. * UIProcess/mac/ViewGestureControllerMac.mm: (WebKit::ViewGestureController::handleSwipeGesture): It is conceivable that we could get here if the client closes the page e.g. in the callback from willEndSwipeGesture. We already guarded against this ... one line too late! Rearrange the lines so we don't call into WebPageProxy at all if we don't have a drawing area (which is a strict subset of the time that isValid would return true). This is a speculative fix, since I can no longer reproduce the crash on demand. 2019-02-13 Babak Shafiei Cherry-pick r241336. rdar://problem/48065621 Regression(PSON) MESSAGE_CHECK() hit under WebPageProxy::didFailProvisionalLoadForFrameShared() https://bugs.webkit.org/show_bug.cgi?id=194568 Reviewed by Ryosuke Niwa. Source/WebKit: When the provisional process crashes, it is unsafe to call ProvisionalPageProxy::cancel() because the WebProcessProxy clears its frame map as soon as the process crashes. Calling cancel() after that would call WebPageProxy::didFailProvisionalLoadForFrameShared(), which would try to look up the frame by ID and MESSAGE_CHECK() that the frame is not null. We would fail this check since the frame has been removed from the WebProcessProxy at this point. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _provisionalWebProcessIdentifier]): * UIProcess/API/Cocoa/WKWebViewPrivate.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::didFailProvisionalLoadForFrameShared): (WebKit::WebPageProxy::provisionalProcessDidTerminate): Tools: Add API test coverage. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: (-[PSONNavigationDelegate webView:didStartProvisionalNavigation:]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241336 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-12 Chris Dumez Regression(PSON) MESSAGE_CHECK() hit under WebPageProxy::didFailProvisionalLoadForFrameShared() https://bugs.webkit.org/show_bug.cgi?id=194568 Reviewed by Ryosuke Niwa. When the provisional process crashes, it is unsafe to call ProvisionalPageProxy::cancel() because the WebProcessProxy clears its frame map as soon as the process crashes. Calling cancel() after that would call WebPageProxy::didFailProvisionalLoadForFrameShared(), which would try to look up the frame by ID and MESSAGE_CHECK() that the frame is not null. We would fail this check since the frame has been removed from the WebProcessProxy at this point. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _provisionalWebProcessIdentifier]): * UIProcess/API/Cocoa/WKWebViewPrivate.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::didFailProvisionalLoadForFrameShared): (WebKit::WebPageProxy::provisionalProcessDidTerminate): 2019-02-13 Alan Coon Apply patch. rdar://problem/40966400 2019-02-13 Brent Fulgham Branch-Only: Use Async message infrastructure for storageAccess API https://bugs.webkit.org/show_bug.cgi?id=194511 Back-port the trunk async message handling implementation of the StorageAccess API methods. The generated async message handling code does a better job of managing the bookkeeping and error handling of cross-process message passing, and gives us fewer opportunities to make coding errors that might lead to dropped messages or sending messages multiple times. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::hasStorageAccess): (WebKit::WebPageProxy::requestStorageAccess): * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::hasStorageAccess): (WebKit::WebPage::requestStorageAccess): (WebKit::nextRequestStorageAccessContextId): Deleted. (WebKit::WebPage::storageAccessResponse): Deleted. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: 2019-02-13 Alan Coon Cherry-pick r241352. rdar://problem/48038900 Release assert in PolicyCheckIdentifier::isValidFor via WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction https://bugs.webkit.org/show_bug.cgi?id=194582 Reviewed by Antti Koivisto. Source/WebCore: Check the zero-ness of m_policyCheck first so that we can differentiate process ID being wrong from the non-generated identifier being sent to us as it was the case in this failure. * loader/PolicyChecker.cpp: (WebCore::PolicyCheckIdentifier::isValidFor): Source/WebKit: The bug was caused by WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction invoking the callback with responseIdentifier even when we had failed to send the policy check IPC. Clearly, responseIdentifier is invalid in that case, and we should be using requestIdentifier instead. Unfortunately no new tests since I'm not aware of a way to make sendSync fail in this case. * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241352 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-13 Ryosuke Niwa Release assert in PolicyCheckIdentifier::isValidFor via WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction https://bugs.webkit.org/show_bug.cgi?id=194582 Reviewed by Antti Koivisto. The bug was caused by WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction invoking the callback with responseIdentifier even when we had failed to send the policy check IPC. Clearly, responseIdentifier is invalid in that case, and we should be using requestIdentifier instead. Unfortunately no new tests since I'm not aware of a way to make sendSync fail in this case. * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction): 2019-02-12 Alan Coon Apply patch. rdar://problem/48009995 2019-02-12 Alex Christensen WebPage::close needs to remove all message receivers associated with that WebPage, not WebPage::~WebPage https://bugs.webkit.org/show_bug.cgi?id=194522 Reviewed by Chris Dumez. The InjectedBundle SPI can retain the WebPage or wrapping objects (WKWebProcessPlugInBrowserContextController/WKBundlePageRef). This can make it so WebPage::close is called before WebPage::~WebPage, and if the SuspendedPageProxy is reused for a subsequent navigation to the same domain, the WebProcess is reused with a different WebPage instance with the same PageID, which causes problems when another WebPage registers message handlers and then the previous WebPage is destroyed, which removes both message handlers. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::~WebPage): (WebKit::WebPage::close): (WebKit::WebPage::mainFrameDidLayout): * WebProcess/WebPage/WebPage.h: * WebProcess/WebProcess.h: (WebKit::WebProcess::eventDispatcher): 2019-02-07 Babak Shafiei Cherry-pick r241171. rdar://problem/47908156 [iOS] Clicking links in Safari using Apple Pencil is much more difficult after r238475 https://bugs.webkit.org/show_bug.cgi?id=194415 Reviewed by Tim Horton. Source/WebKit: Fix the bug by not firing the Apple-pencil-exclusive tap gesture recognizer in the case where editable images are disabled. This gesture recognizer is only used for inserting editable images, and currently conflicts with the synthetic click gesture recognizer used to recognize clicks from generic digitizer inputs. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView gestureRecognizerShouldBegin:]): (-[WKContentView _stylusSingleTapRecognized:]): LayoutTests: Add a layout test to verify that a stylus tap dispatches clicks. * fast/events/touch/ios/pencil-tap-dispatches-click-expected.txt: Added. * fast/events/touch/ios/pencil-tap-dispatches-click.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241171 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-07 Wenson Hsieh [iOS] Clicking links in Safari using Apple Pencil is much more difficult after r238475 https://bugs.webkit.org/show_bug.cgi?id=194415 Reviewed by Tim Horton. Fix the bug by not firing the Apple-pencil-exclusive tap gesture recognizer in the case where editable images are disabled. This gesture recognizer is only used for inserting editable images, and currently conflicts with the synthetic click gesture recognizer used to recognize clicks from generic digitizer inputs. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView gestureRecognizerShouldBegin:]): (-[WKContentView _stylusSingleTapRecognized:]): 2019-02-07 Babak Shafiei Cherry-pick r241143. rdar://problem/47908161 Permit additional IOKit Properties needed by Media PlugIns on older Mac Hardware https://bugs.webkit.org/show_bug.cgi?id=194412 Reviewed by Per Arne Vollan. * PluginProcess/mac/com.apple.WebKit.plugin-common.sb.in: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241143 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-07 Brent Fulgham Permit additional IOKit Properties needed by Media PlugIns on older Mac Hardware https://bugs.webkit.org/show_bug.cgi?id=194412 Reviewed by Per Arne Vollan. * PluginProcess/mac/com.apple.WebKit.plugin-common.sb.in: 2019-02-07 Babak Shafiei Cherry-pick r241142. rdar://problem/47908158 Permit additional IOKit Properties needed by older Mac Hardware https://bugs.webkit.org/show_bug.cgi?id=194410 Reviewed by Per Arne Vollan. * WebProcess/com.apple.WebProcess.sb.in: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241142 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-07 Brent Fulgham Permit additional IOKit Properties needed by older Mac Hardware https://bugs.webkit.org/show_bug.cgi?id=194410 Reviewed by Per Arne Vollan. * WebProcess/com.apple.WebProcess.sb.in: 2019-02-07 Alan Coon Cherry-pick r241131. rdar://problem/47893578 Print backgrounds preference should be honored instead of WKWebViewConfiguration value https://bugs.webkit.org/show_bug.cgi?id=194364 Reviewed by Tim Horton. Without this patch, changing the preference for printing the background has no effect. This patch fixes that, and I verified it manually by checking "Print backgrounds" in Safari's print menu. Unfortunately, the only way to test this is actually printing because only values from WebPageProxy::preferences or WebPageProxy::configuration's preferences are exposed to the API, but values from WebPageProxy::preferencesStore are used when printing. Actually printing verifies this change fixes the bug. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _initializeWithConfiguration:]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241131 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-07 Alex Christensen Print backgrounds preference should be honored instead of WKWebViewConfiguration value https://bugs.webkit.org/show_bug.cgi?id=194364 Reviewed by Tim Horton. Without this patch, changing the preference for printing the background has no effect. This patch fixes that, and I verified it manually by checking "Print backgrounds" in Safari's print menu. Unfortunately, the only way to test this is actually printing because only values from WebPageProxy::preferences or WebPageProxy::configuration's preferences are exposed to the API, but values from WebPageProxy::preferencesStore are used when printing. Actually printing verifies this change fixes the bug. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _initializeWithConfiguration:]): 2019-02-07 Alan Coon Cherry-pick r241124. rdar://problem/47893586 Shrink and hyphenate safe browsing warning text on watchOS https://bugs.webkit.org/show_bug.cgi?id=194361 Reviewed by Geoffrey Garen. Some internationalizations use long words that didn't fit on small watches. * UIProcess/Cocoa/WKSafeBrowsingWarning.mm: (fontOfSize): (-[WKSafeBrowsingWarning addContent]): (-[WKSafeBrowsingTextView initWithAttributedString:forWarning:]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241124 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-07 Alex Christensen Shrink and hyphenate safe browsing warning text on watchOS https://bugs.webkit.org/show_bug.cgi?id=194361 Reviewed by Geoffrey Garen. Some internationalizations use long words that didn't fit on small watches. * UIProcess/Cocoa/WKSafeBrowsingWarning.mm: (fontOfSize): (-[WKSafeBrowsingWarning addContent]): (-[WKSafeBrowsingTextView initWithAttributedString:forWarning:]): 2019-02-07 Alan Coon Cherry-pick r241105. rdar://problem/47893571 [Payment Request] It should be possible to require a phonetic name for shipping contacts https://bugs.webkit.org/show_bug.cgi?id=194311 Reviewed by Alex Christensen. Source/WebCore: It should be possible to require that a shipping contact has a phonetic name in Payment Request. To accomplish this, move requiredShippingContactFields from ApplePayPaymentRequest to ApplePayRequestBase so that it can be used as part of an Apple Pay payment method data. Since required shipping contact fields can now be specified both in requiredShippingContactFields and PaymentOptions, we merge the required fields from these two sources such that, e.g., email is required if it is specified in either place. So that clients can detect this new feature, the API version number is bumped from 5 to 6. Added test cases to ApplePayRequestShippingContact.https.html and ApplePayRequestShippingContactV3.https.html. * DerivedSources.make: * Modules/applepay/ApplePayPaymentRequest.h: * Modules/applepay/ApplePayPaymentRequest.idl: * Modules/applepay/ApplePayRequestBase.cpp: (WebCore::convertAndValidate): * Modules/applepay/ApplePayRequestBase.h: * Modules/applepay/ApplePayRequestBase.idl: * Modules/applepay/ApplePaySession.cpp: (WebCore::convertAndValidate): * Modules/applepay/PaymentCoordinatorClient.cpp: Added. (WebCore::PaymentCoordinatorClient::supportsVersion): * Modules/applepay/PaymentCoordinatorClient.h: * Modules/applepay/paymentrequest/ApplePayPaymentHandler.cpp: (WebCore::mergePaymentOptions): (WebCore::ApplePayPaymentHandler::show): * SourcesCocoa.txt: * WebCore.xcodeproj/project.pbxproj: * loader/EmptyClients.cpp: * testing/MockPaymentContactFields.h: Added. (WebCore::MockPaymentContactFields::MockPaymentContactFields): * testing/MockPaymentContactFields.idl: Added. * testing/MockPaymentCoordinator.cpp: (WebCore::MockPaymentCoordinator::showPaymentUI): (WebCore::MockPaymentCoordinator::supportsVersion): Deleted. * testing/MockPaymentCoordinator.h: * testing/MockPaymentCoordinator.idl: Source/WebKit: * WebProcess/ApplePay/WebPaymentCoordinator.cpp: (WebKit::WebPaymentCoordinator::supportsVersion): Deleted. * WebProcess/ApplePay/WebPaymentCoordinator.h: Source/WebKitLegacy/mac: * WebCoreSupport/WebPaymentCoordinatorClient.h: * WebCoreSupport/WebPaymentCoordinatorClient.mm: (WebPaymentCoordinatorClient::supportsVersion): Deleted. LayoutTests: * http/tests/ssl/applepay/ApplePayRequestShippingContact.https-expected.txt: * http/tests/ssl/applepay/ApplePayRequestShippingContact.https.html: * http/tests/ssl/applepay/ApplePayRequestShippingContactV3.https-expected.txt: * http/tests/ssl/applepay/ApplePayRequestShippingContactV3.https.html: * http/tests/ssl/applepay/PaymentRequest.https-expected.txt: * http/tests/ssl/applepay/PaymentRequest.https.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241105 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-06 Andy Estes [Payment Request] It should be possible to require a phonetic name for shipping contacts https://bugs.webkit.org/show_bug.cgi?id=194311 Reviewed by Alex Christensen. * WebProcess/ApplePay/WebPaymentCoordinator.cpp: (WebKit::WebPaymentCoordinator::supportsVersion): Deleted. * WebProcess/ApplePay/WebPaymentCoordinator.h: 2019-02-07 Alan Coon Cherry-pick r241026. rdar://problem/47774548 Roll out parts of r238819 since it is a PLT performance regression. https://bugs.webkit.org/show_bug.cgi?id=194346 Unreviewed performance fix. * WebProcess/InjectedBundle/API/mac/WKWebProcessPlugInBrowserContextController.mm: (didStartProvisionalLoadForFrame): (didReceiveServerRedirectForProvisionalLoadForFrame): (didFinishLoadForFrame): (globalObjectIsAvailableForFrame): (didRemoveFrameFromHierarchy): (didCommitLoadForFrame): (didFinishDocumentLoadForFrame): (didFailProvisionalLoadWithErrorForFrame): (didFailLoadWithErrorForFrame): (didSameDocumentNavigationForFrame): (didLayoutForFrame): (didReachLayoutMilestone): (didFirstVisuallyNonEmptyLayoutForFrame): (didHandleOnloadEventsForFrame): (userAgentForURL): (setUpPageLoaderClient): (willSendRequestForFrame): (didInitiateLoadForResource): (didFinishLoadForResource): (didFailLoadForResource): (setUpResourceLoadClient): (-[WKWebProcessPlugInBrowserContextController setLoadDelegate:]): (ResourceLoadClient::ResourceLoadClient): Deleted. (ResourceLoadClient::loadDelegate const): Deleted. (ResourceLoadClient::pluginContextController const): Deleted. (PageLoaderClient::PageLoaderClient): Deleted. (PageLoaderClient::loadDelegate const): Deleted. (PageLoaderClient::pluginContextController const): Deleted. (PageLoaderClient::didStartProvisionalLoadForFrame): Deleted. (PageLoaderClient::didReceiveServerRedirectForProvisionalLoadForFrame): Deleted. (PageLoaderClient::didFinishLoadForFrame): Deleted. (PageLoaderClient::globalObjectIsAvailableForFrame): Deleted. (PageLoaderClient::didRemoveFrameFromHierarchy): Deleted. (PageLoaderClient::didCommitLoadForFrame): Deleted. (PageLoaderClient::didFinishDocumentLoadForFrame): Deleted. (PageLoaderClient::didFailProvisionalLoadWithErrorForFrame): Deleted. (PageLoaderClient::didFailLoadWithErrorForFrame): Deleted. (PageLoaderClient::didSameDocumentNavigationForFrame): Deleted. (PageLoaderClient::didLayoutForFrame): Deleted. (PageLoaderClient::didReachLayoutMilestone): Deleted. (PageLoaderClient::didFirstVisuallyNonEmptyLayoutForFrame): Deleted. (PageLoaderClient::layoutMilestones const): Deleted. (PageLoaderClient::didHandleOnloadEventsForFrame): Deleted. (PageLoaderClient::userAgentForURL const): Deleted. (ResourceLoadClient::willSendRequestForFrame): Deleted. (ResourceLoadClient::didInitiateLoadForResource): Deleted. (ResourceLoadClient::didFinishLoadForResource): Deleted. (ResourceLoadClient::didFailLoadForResource): Deleted. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241026 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-06 Per Arne Vollan Roll out parts of r238819 since it is a PLT performance regression. https://bugs.webkit.org/show_bug.cgi?id=194346 Unreviewed performance fix. * WebProcess/InjectedBundle/API/mac/WKWebProcessPlugInBrowserContextController.mm: (didStartProvisionalLoadForFrame): (didReceiveServerRedirectForProvisionalLoadForFrame): (didFinishLoadForFrame): (globalObjectIsAvailableForFrame): (didRemoveFrameFromHierarchy): (didCommitLoadForFrame): (didFinishDocumentLoadForFrame): (didFailProvisionalLoadWithErrorForFrame): (didFailLoadWithErrorForFrame): (didSameDocumentNavigationForFrame): (didLayoutForFrame): (didReachLayoutMilestone): (didFirstVisuallyNonEmptyLayoutForFrame): (didHandleOnloadEventsForFrame): (userAgentForURL): (setUpPageLoaderClient): (willSendRequestForFrame): (didInitiateLoadForResource): (didFinishLoadForResource): (didFailLoadForResource): (setUpResourceLoadClient): (-[WKWebProcessPlugInBrowserContextController setLoadDelegate:]): (ResourceLoadClient::ResourceLoadClient): Deleted. (ResourceLoadClient::loadDelegate const): Deleted. (ResourceLoadClient::pluginContextController const): Deleted. (PageLoaderClient::PageLoaderClient): Deleted. (PageLoaderClient::loadDelegate const): Deleted. (PageLoaderClient::pluginContextController const): Deleted. (PageLoaderClient::didStartProvisionalLoadForFrame): Deleted. (PageLoaderClient::didReceiveServerRedirectForProvisionalLoadForFrame): Deleted. (PageLoaderClient::didFinishLoadForFrame): Deleted. (PageLoaderClient::globalObjectIsAvailableForFrame): Deleted. (PageLoaderClient::didRemoveFrameFromHierarchy): Deleted. (PageLoaderClient::didCommitLoadForFrame): Deleted. (PageLoaderClient::didFinishDocumentLoadForFrame): Deleted. (PageLoaderClient::didFailProvisionalLoadWithErrorForFrame): Deleted. (PageLoaderClient::didFailLoadWithErrorForFrame): Deleted. (PageLoaderClient::didSameDocumentNavigationForFrame): Deleted. (PageLoaderClient::didLayoutForFrame): Deleted. (PageLoaderClient::didReachLayoutMilestone): Deleted. (PageLoaderClient::didFirstVisuallyNonEmptyLayoutForFrame): Deleted. (PageLoaderClient::layoutMilestones const): Deleted. (PageLoaderClient::didHandleOnloadEventsForFrame): Deleted. (PageLoaderClient::userAgentForURL const): Deleted. (ResourceLoadClient::willSendRequestForFrame): Deleted. (ResourceLoadClient::didInitiateLoadForResource): Deleted. (ResourceLoadClient::didFinishLoadForResource): Deleted. (ResourceLoadClient::didFailLoadForResource): Deleted. 2019-02-07 Alan Coon Cherry-pick r240808. rdar://problem/47774548 Revert r238819 which is unneeded and caused a performance regression. https://bugs.webkit.org/show_bug.cgi?id=192272 Source/WebCore: * loader/EmptyFrameLoaderClient.h: * loader/FrameLoader.cpp: (WebCore::FrameLoader::prepareForLoadStart): (WebCore::FrameLoader::continueLoadAfterNavigationPolicy): (WebCore::FrameLoader::loadProvisionalItemFromCachedPage): * loader/FrameLoader.h: * loader/FrameLoaderClient.h: Source/WebKit: * WebProcess/InjectedBundle/API/APIInjectedBundlePageLoaderClient.h: (API::InjectedBundle::PageLoaderClient::didStartProvisionalLoadForFrame): * WebProcess/InjectedBundle/API/Cocoa/WKWebProcessPlugInLoadDelegate.h: * WebProcess/InjectedBundle/API/glib/WebKitWebPage.cpp: * WebProcess/InjectedBundle/API/mac/WKWebProcessPlugInBrowserContextController.mm: (PageLoaderClient::didStartProvisionalLoadForFrame): * WebProcess/InjectedBundle/InjectedBundlePageLoaderClient.cpp: (WebKit::InjectedBundlePageLoaderClient::didStartProvisionalLoadForFrame): * WebProcess/InjectedBundle/InjectedBundlePageLoaderClient.h: * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::dispatchDidStartProvisionalLoad): * WebProcess/WebCoreSupport/WebFrameLoaderClient.h: Source/WebKitLegacy/mac: * WebCoreSupport/WebFrameLoaderClient.h: * WebCoreSupport/WebFrameLoaderClient.mm: (WebFrameLoaderClient::dispatchDidStartProvisionalLoad): Source/WebKitLegacy/win: * WebCoreSupport/WebFrameLoaderClient.cpp: (WebFrameLoaderClient::dispatchDidStartProvisionalLoad): * WebCoreSupport/WebFrameLoaderClient.h: Tools: * TestWebKitAPI/Tests/WebKitCocoa/ParserYieldTokenPlugIn.mm: (-[ParserYieldTokenPlugIn webProcessPlugInBrowserContextController:didCommitLoadForFrame:]): (-[ParserYieldTokenPlugIn webProcessPlugInBrowserContextController:willStartProvisionalLoadForFrame:completionHandler:]): Deleted. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240808 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-31 Alex Christensen Revert r238819 which is unneeded and caused a performance regression. https://bugs.webkit.org/show_bug.cgi?id=192272 * WebProcess/InjectedBundle/API/APIInjectedBundlePageLoaderClient.h: (API::InjectedBundle::PageLoaderClient::didStartProvisionalLoadForFrame): * WebProcess/InjectedBundle/API/Cocoa/WKWebProcessPlugInLoadDelegate.h: * WebProcess/InjectedBundle/API/glib/WebKitWebPage.cpp: * WebProcess/InjectedBundle/API/mac/WKWebProcessPlugInBrowserContextController.mm: (PageLoaderClient::didStartProvisionalLoadForFrame): * WebProcess/InjectedBundle/InjectedBundlePageLoaderClient.cpp: (WebKit::InjectedBundlePageLoaderClient::didStartProvisionalLoadForFrame): * WebProcess/InjectedBundle/InjectedBundlePageLoaderClient.h: * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::dispatchDidStartProvisionalLoad): * WebProcess/WebCoreSupport/WebFrameLoaderClient.h: 2019-02-07 Alan Coon Cherry-pick r239697. rdar://problem/47776479 Web Inspector: Remote inspector can crash if attempting to navigate inspector page https://bugs.webkit.org/show_bug.cgi?id=193204 Patch by Joseph Pecoraro on 2019-01-07 Reviewed by Devin Rousso. * UIProcess/mac/RemoteWebInspectorProxyMac.mm: (WebKit::RemoteWebInspectorProxy::platformCreateFrontendPageAndWindow): * UIProcess/mac/WKInspectorViewController.mm: (-[WKInspectorViewController webView:decidePolicyForNavigationAction:decisionHandler:]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239697 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-07 Joseph Pecoraro Web Inspector: Remote inspector can crash if attempting to navigate inspector page https://bugs.webkit.org/show_bug.cgi?id=193204 Reviewed by Devin Rousso. * UIProcess/mac/RemoteWebInspectorProxyMac.mm: (WebKit::RemoteWebInspectorProxy::platformCreateFrontendPageAndWindow): * UIProcess/mac/WKInspectorViewController.mm: (-[WKInspectorViewController webView:decidePolicyForNavigationAction:decisionHandler:]): 2019-02-06 Alan Coon Apply patch. rdar://problem/47822019 2019-02-06 Ryosuke Niwa Validate navigation policy decisions to avoid crashes in continueLoadAfterNavigationPolicy https://bugs.webkit.org/show_bug.cgi?id=194189 Reviewed by Geoffrey Garen. Pass the policy check identifier around functions and store it in PolicyDecisionSender so that we can send it back to WebCore with the navigation policy decision. We also store it in WebFrame in the case the policy decision had to be invalidated before the decision was received (via WebFrame::invalidatePolicyListener). * Scripts/webkit/messages.py: * UIProcess/ProvisionalPageProxy.cpp: (WebKit::ProvisionalPageProxy::decidePolicyForNavigationActionAsync): (WebKit::ProvisionalPageProxy::decidePolicyForResponse): * UIProcess/ProvisionalPageProxy.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::PolicyDecisionSender): Added PolicyCheckIdentifier as a member. (WebKit::WebPageProxy::PolicyDecisionSender::create): (WebKit::WebPageProxy::PolicyDecisionSender::send): (WebKit::WebPageProxy::PolicyDecisionSender::PolicyDecisionSender): (WebKit::WebPageProxy::receivedNavigationPolicyDecision): (WebKit::WebPageProxy::decidePolicyForNavigationActionAsync): (WebKit::WebPageProxy::decidePolicyForNavigationActionAsyncShared): (WebKit::WebPageProxy::decidePolicyForNavigationAction): (WebKit::WebPageProxy::decidePolicyForNavigationActionSync): (WebKit::WebPageProxy::decidePolicyForNewWindowAction): (WebKit::WebPageProxy::decidePolicyForResponse): (WebKit::WebPageProxy::decidePolicyForResponseShared): * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::dispatchDecidePolicyForResponse): (WebKit::WebFrameLoaderClient::dispatchDecidePolicyForNewWindowAction): (WebKit::WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction): * WebProcess/WebCoreSupport/WebFrameLoaderClient.h: * WebProcess/WebPage/WebFrame.cpp: (WebKit::WebFrame::setUpPolicyListener): (WebKit::WebFrame::invalidatePolicyListener): (WebKit::WebFrame::didReceivePolicyDecision): * WebProcess/WebPage/WebFrame.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::didReceivePolicyDecision): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: 2019-02-06 Alan Coon Cherry-pick r239845. rdar://problem/47776472 [macOS] Add name of IORegistry key in sandbox. https://bugs.webkit.org/show_bug.cgi?id=193335 Reviewed by Alexey Proskuryakov. The property IOGVAHEVCDecodeCapabilities was added in https://bugs.webkit.org/show_bug.cgi?id=193324. Also, the property IOGVAHEVCEncodeCapabilities needs to be added. * WebProcess/com.apple.WebProcess.sb.in: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239845 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-10 Per Arne Vollan [macOS] Add name of IORegistry key in sandbox. https://bugs.webkit.org/show_bug.cgi?id=193335 Reviewed by Alexey Proskuryakov. The property IOGVAHEVCDecodeCapabilities was added in https://bugs.webkit.org/show_bug.cgi?id=193324. Also, the property IOGVAHEVCEncodeCapabilities needs to be added. * WebProcess/com.apple.WebProcess.sb.in: 2019-02-06 Alan Coon Cherry-pick r239834. rdar://problem/47776472 [macOS] Add name of IORegistry key in sandbox. https://bugs.webkit.org/show_bug.cgi?id=193324 Reviewed by Brent Fulgham. IOGVAVTCapabilities key has been changed to IOGVAHEVCDecodeCapabilities. * WebProcess/com.apple.WebProcess.sb.in: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239834 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-10 Per Arne Vollan [macOS] Add name of IORegistry key in sandbox. https://bugs.webkit.org/show_bug.cgi?id=193324 Reviewed by Brent Fulgham. IOGVAVTCapabilities key has been changed to IOGVAHEVCDecodeCapabilities. * WebProcess/com.apple.WebProcess.sb.in: 2019-02-06 Alan Coon Cherry-pick r240995. rdar://problem/47843415 Reproducible crash under WKShareSheet presentWithParameters when cancelling a share https://bugs.webkit.org/show_bug.cgi?id=194301 Reviewed by Beth Dakin. * UIProcess/Cocoa/WKShareSheet.mm: (-[WKShareSheet presentWithParameters:completionHandler:]): NSSharingServicePicker's delegate callbacks can be called synchronously. We release the WKShareSheet (which holds our reference to the NSSharingServicePicker) under sharingServicePicker:didChooseSharingService:. On older versions of macOS, there was nothing keeping the NSSharingServicePicker alive inside showRelativeToRect:ofView:preferredEdge:, thus the whole chain of references would fall and result in sending a message to a released NSSharingServicePicker. To resolve this, keep an extra reference to the WKShareSheet until presentation is complete. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240995 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-05 Tim Horton Reproducible crash under WKShareSheet presentWithParameters when cancelling a share https://bugs.webkit.org/show_bug.cgi?id=194301 Reviewed by Beth Dakin. * UIProcess/Cocoa/WKShareSheet.mm: (-[WKShareSheet presentWithParameters:completionHandler:]): NSSharingServicePicker's delegate callbacks can be called synchronously. We release the WKShareSheet (which holds our reference to the NSSharingServicePicker) under sharingServicePicker:didChooseSharingService:. On older versions of macOS, there was nothing keeping the NSSharingServicePicker alive inside showRelativeToRect:ofView:preferredEdge:, thus the whole chain of references would fall and result in sending a message to a released NSSharingServicePicker. To resolve this, keep an extra reference to the WKShareSheet until presentation is complete. 2019-02-05 Alan Coon Cherry-pick r240928. rdar://problem/47810458 Capture state should be managed consistently when doing process swapping https://bugs.webkit.org/show_bug.cgi?id=194122 Reviewed by Eric Carlson. Source/WebKit: When doing PSON, WebPageProxy::resetState is called. It resets the media state, but does not call the client delegates. Instead of directly updating the media state, call the routine used to update it so that client delegates are called. Covered by new API test and layout test. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _mediaCaptureState]): * UIProcess/API/Cocoa/WKWebViewPrivate.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::resetState): (WebKit::WebPageProxy::isPlayingMediaDidChange): (WebKit::WebPageProxy::updatePlayingMediaDidChange): * UIProcess/WebPageProxy.h: Tools: * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: (-[GetUserMediaUIDelegate _webView:requestUserMediaAuthorizationForDevices:url:mainFrameURL:decisionHandler:]): (-[GetUserMediaUIDelegate _webView:checkUserMediaPermissionForURL:mainFrameURL:frameIdentifier:decisionHandler:]): (-[GetUserMediaUIDelegate _webView:mediaCaptureStateDidChange:]): * WebKitTestRunner/InjectedBundle/Bindings/TestRunner.idl: * WebKitTestRunner/InjectedBundle/TestRunner.cpp: (WTR::TestRunner::isDoingMediaCapture const): * WebKitTestRunner/InjectedBundle/TestRunner.h: * WebKitTestRunner/TestController.cpp: (WTR::TestController::isDoingMediaCapture const): * WebKitTestRunner/TestController.h: * WebKitTestRunner/TestInvocation.cpp: (WTR::TestInvocation::didReceiveSynchronousMessageFromInjectedBundle): * WebKitTestRunner/cocoa/TestControllerCocoa.mm: (WTR::TestController::isDoingMediaCapture const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240928 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-04 Youenn Fablet Capture state should be managed consistently when doing process swapping https://bugs.webkit.org/show_bug.cgi?id=194122 Reviewed by Eric Carlson. When doing PSON, WebPageProxy::resetState is called. It resets the media state, but does not call the client delegates. Instead of directly updating the media state, call the routine used to update it so that client delegates are called. Covered by new API test and layout test. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _mediaCaptureState]): * UIProcess/API/Cocoa/WKWebViewPrivate.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::resetState): (WebKit::WebPageProxy::isPlayingMediaDidChange): (WebKit::WebPageProxy::updatePlayingMediaDidChange): * UIProcess/WebPageProxy.h: 2019-02-05 Alan Coon Apply patch. rdar://problem/47810458 fix-194122 2019-02-04 Youenn Fablet Capture state should be managed consistently when doing process swapping https://bugs.webkit.org/show_bug.cgi?id=194122 When doing PSON, WebPageProxy::resetState is called. It resets the media state, but does not call the client delegates. Instead of directly updating the media state, call the routine used to update it so that client delegates are called. Covered by new API test and layout test. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _mediaCaptureState]): * UIProcess/API/Cocoa/WKWebViewPrivate.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::resetState): (WebKit::WebPageProxy::isPlayingMediaDidChange): (WebKit::WebPageProxy::updatePlayingMediaDidChange): * UIProcess/WebPageProxy.h: 2019-02-05 Alan Coon Cherry-pick r239752. rdar://problem/47776478 [WebAuthN] Support U2F HID Authenticators on macOS https://bugs.webkit.org/show_bug.cgi?id=191535 Reviewed by Brent Fulgham. Source/WebCore: This patch changes U2fCommandConstructor to produce register commands with enforcing test of user presence. Otherwise, authenticators would silently generate credentials. It also renames readFromU2fSignResponse to readU2fSignResponse. Tests: http/wpt/webauthn/public-key-credential-create-failure-u2f-silent.https.html http/wpt/webauthn/public-key-credential-create-failure-u2f.https.html http/wpt/webauthn/public-key-credential-create-success-u2f.https.html http/wpt/webauthn/public-key-credential-get-failure-u2f-silent.https.html http/wpt/webauthn/public-key-credential-get-failure-u2f.https.html http/wpt/webauthn/public-key-credential-get-success-u2f.https.html * Modules/webauthn/fido/U2fCommandConstructor.cpp: (fido::WebCore::constructU2fRegisterCommand): * Modules/webauthn/fido/U2fResponseConverter.cpp: (fido::readU2fSignResponse): (fido::readFromU2fSignResponse): Deleted. * Modules/webauthn/fido/U2fResponseConverter.h: Source/WebKit: This patch implements the support for U2F authenticators, and enables it for hid devices. It follows the CTAP spec to map WebAuthN requests to U2F commands and return the responses: https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-client-to-authenticator-protocol-v2.0-id-20180227.html#u2f-interoperability Most of the parts are done before this patch, this patch focues on: 7.2.2 and 7.3.2. Besides implementing the U2fHidAuthenticator, this patch also adds support in the mocking environment for U2F authenticators. It is done by extending the stages in MockHidConnection from 4 to indefinite as multi-round communications are expected to map WebAuthN requests to U2F requests. * Sources.txt: * UIProcess/API/C/WKWebsiteDataStoreRef.cpp: (WKWebsiteDataStoreSetWebAuthenticationMockConfiguration): * UIProcess/WebAuthentication/Cocoa/HidService.mm: (WebKit::HidService::continueAddDeviceAfterGetInfo): * UIProcess/WebAuthentication/fido/CtapHidDriver.cpp: (WebKit::CtapHidDriver::continueAfterChannelAllocated): * UIProcess/WebAuthentication/fido/CtapHidDriver.h: (WebKit::CtapHidDriver::setProtocol): * UIProcess/WebAuthentication/fido/U2fHidAuthenticator.cpp: Added. (WebKit::U2fHidAuthenticator::U2fHidAuthenticator): (WebKit::U2fHidAuthenticator::makeCredential): (WebKit::U2fHidAuthenticator::checkExcludeList): (WebKit::U2fHidAuthenticator::issueRegisterCommand): (WebKit::U2fHidAuthenticator::getAssertion): (WebKit::U2fHidAuthenticator::issueSignCommand): (WebKit::U2fHidAuthenticator::issueNewCommand): (WebKit::U2fHidAuthenticator::issueCommand): (WebKit::U2fHidAuthenticator::responseReceived): (WebKit::U2fHidAuthenticator::continueRegisterCommandAfterResponseReceived): (WebKit::U2fHidAuthenticator::continueCheckOnlyCommandAfterResponseReceived): (WebKit::U2fHidAuthenticator::continueBogusCommandAfterResponseReceived): (WebKit::U2fHidAuthenticator::continueSignCommandAfterResponseReceived): * UIProcess/WebAuthentication/fido/U2fHidAuthenticator.h: Added. * UIProcess/WebAuthentication/Mock/MockHidConnection.cpp: (WebKit::MockHidConnection::parseRequest): (WebKit::MockHidConnection::feedReports): * UIProcess/WebAuthentication/Mock/MockHidConnection.h: * UIProcess/WebAuthentication/Mock/MockWebAuthenticationConfiguration.h: * WebKit.xcodeproj/project.pbxproj: Tools: This patch: 1) adds support for U2F mocking mechanism; 2) updates tests to reflect U2fCommandConstructor changes. * TestWebKitAPI/Tests/WebCore/CtapResponseTest.cpp: (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/WebCore/FidoTestData.h: * WebKitTestRunner/InjectedBundle/TestRunner.cpp: (WTR::TestRunner::setWebAuthenticationMockConfiguration): LayoutTests: Besiding adding tests for U2F authenticators, it also changes payloadBase64 from a string to a vector of strings. New tests are skipped for iOS. * http/wpt/webauthn/ctap-hid-failure.https.html: * http/wpt/webauthn/ctap-hid-success.https.html: * http/wpt/webauthn/public-key-credential-create-failure-hid-silent.https.html: * http/wpt/webauthn/public-key-credential-create-failure-hid.https.html: * http/wpt/webauthn/public-key-credential-create-failure-u2f-silent.https-expected.txt: Added. * http/wpt/webauthn/public-key-credential-create-failure-u2f-silent.https.html: Added. * http/wpt/webauthn/public-key-credential-create-failure-u2f.https-expected.txt: Added. * http/wpt/webauthn/public-key-credential-create-failure-u2f.https.html: Added. * http/wpt/webauthn/public-key-credential-create-success-hid.https.html: * http/wpt/webauthn/public-key-credential-create-success-u2f.https-expected.txt: Added. * http/wpt/webauthn/public-key-credential-create-success-u2f.https.html: Copied from LayoutTests/http/wpt/webauthn/public-key-credential-create-success-hid.https.html. * http/wpt/webauthn/public-key-credential-get-failure-hid-silent.https.html: * http/wpt/webauthn/public-key-credential-get-failure-hid.https.html: * http/wpt/webauthn/public-key-credential-get-failure-u2f-silent.https-expected.txt: Added. * http/wpt/webauthn/public-key-credential-get-failure-u2f-silent.https.html: Added. * http/wpt/webauthn/public-key-credential-get-failure-u2f.https-expected.txt: Added. * http/wpt/webauthn/public-key-credential-get-failure-u2f.https.html: Added. * http/wpt/webauthn/public-key-credential-get-success-hid.https.html: * http/wpt/webauthn/public-key-credential-get-success-u2f.https-expected.txt: Added. * http/wpt/webauthn/public-key-credential-get-success-u2f.https.html: Added. * http/wpt/webauthn/resources/util.js: * platform/ios-wk2/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239752 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-08 Jiewen Tan [WebAuthN] Support U2F HID Authenticators on macOS https://bugs.webkit.org/show_bug.cgi?id=191535 Reviewed by Brent Fulgham. This patch implements the support for U2F authenticators, and enables it for hid devices. It follows the CTAP spec to map WebAuthN requests to U2F commands and return the responses: https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-client-to-authenticator-protocol-v2.0-id-20180227.html#u2f-interoperability Most of the parts are done before this patch, this patch focues on: 7.2.2 and 7.3.2. Besides implementing the U2fHidAuthenticator, this patch also adds support in the mocking environment for U2F authenticators. It is done by extending the stages in MockHidConnection from 4 to indefinite as multi-round communications are expected to map WebAuthN requests to U2F requests. * Sources.txt: * UIProcess/API/C/WKWebsiteDataStoreRef.cpp: (WKWebsiteDataStoreSetWebAuthenticationMockConfiguration): * UIProcess/WebAuthentication/Cocoa/HidService.mm: (WebKit::HidService::continueAddDeviceAfterGetInfo): * UIProcess/WebAuthentication/fido/CtapHidDriver.cpp: (WebKit::CtapHidDriver::continueAfterChannelAllocated): * UIProcess/WebAuthentication/fido/CtapHidDriver.h: (WebKit::CtapHidDriver::setProtocol): * UIProcess/WebAuthentication/fido/U2fHidAuthenticator.cpp: Added. (WebKit::U2fHidAuthenticator::U2fHidAuthenticator): (WebKit::U2fHidAuthenticator::makeCredential): (WebKit::U2fHidAuthenticator::checkExcludeList): (WebKit::U2fHidAuthenticator::issueRegisterCommand): (WebKit::U2fHidAuthenticator::getAssertion): (WebKit::U2fHidAuthenticator::issueSignCommand): (WebKit::U2fHidAuthenticator::issueNewCommand): (WebKit::U2fHidAuthenticator::issueCommand): (WebKit::U2fHidAuthenticator::responseReceived): (WebKit::U2fHidAuthenticator::continueRegisterCommandAfterResponseReceived): (WebKit::U2fHidAuthenticator::continueCheckOnlyCommandAfterResponseReceived): (WebKit::U2fHidAuthenticator::continueBogusCommandAfterResponseReceived): (WebKit::U2fHidAuthenticator::continueSignCommandAfterResponseReceived): * UIProcess/WebAuthentication/fido/U2fHidAuthenticator.h: Added. * UIProcess/WebAuthentication/Mock/MockHidConnection.cpp: (WebKit::MockHidConnection::parseRequest): (WebKit::MockHidConnection::feedReports): * UIProcess/WebAuthentication/Mock/MockHidConnection.h: * UIProcess/WebAuthentication/Mock/MockWebAuthenticationConfiguration.h: * WebKit.xcodeproj/project.pbxproj: 2019-02-05 Alan Coon Cherry-pick r240974. rdar://problem/47830620 Protect globalWebSocketStreamMap with a Lock https://bugs.webkit.org/show_bug.cgi?id=194224 Reviewed by Ryosuke Niwa. * WebProcess/Network/WebSocketStream.cpp: (WebKit::WebSocketStream::streamWithIdentifier): (WebKit::WebSocketStream::networkProcessCrashed): (WebKit::WebSocketStream::WebSocketStream): (WebKit::WebSocketStream::~WebSocketStream): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240974 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-05 Alex Christensen Protect globalWebSocketStreamMap with a Lock https://bugs.webkit.org/show_bug.cgi?id=194224 Reviewed by Ryosuke Niwa. * WebProcess/Network/WebSocketStream.cpp: (WebKit::WebSocketStream::streamWithIdentifier): (WebKit::WebSocketStream::networkProcessCrashed): (WebKit::WebSocketStream::WebSocketStream): (WebKit::WebSocketStream::~WebSocketStream): 2019-02-05 Alan Coon Cherry-pick r240925. rdar://problem/47774545 Unreviewed, avoid -Wswitch warnings introduced in r240880 https://bugs.webkit.org/show_bug.cgi?id=193740 * NetworkProcess/soup/NetworkDataTaskSoup.cpp: (WebKit::NetworkDataTaskSoup::dispatchDidReceiveResponse): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240925 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-04 Michael Catanzaro Unreviewed, avoid -Wswitch warnings introduced in r240880 https://bugs.webkit.org/show_bug.cgi?id=193740 * NetworkProcess/soup/NetworkDataTaskSoup.cpp: (WebKit::NetworkDataTaskSoup::dispatchDidReceiveResponse): 2019-02-05 Alan Coon Cherry-pick r240880. rdar://problem/47774545 REGRESSION: Flaky ASSERTION FAILED: m_uncommittedState.state == State::Committed on http/tests/cookies/same-site/fetch-after-top-level-navigation-initiated-from-iframe-in-cross-origin-page.html https://bugs.webkit.org/show_bug.cgi?id=193740 Reviewed by Alex Christensen. Source/WebCore: * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::willSendRequest): (WebCore::DocumentLoader::continueAfterContentPolicy): * loader/FrameLoader.cpp: (WebCore::FrameLoader::loadURL): (WebCore::FrameLoader::loadWithDocumentLoader): (WebCore::FrameLoader::continueLoadAfterNavigationPolicy): * loader/FrameLoader.h: * loader/FrameLoaderTypes.h: * loader/PolicyChecker.cpp: (WebCore::PolicyChecker::checkNavigationPolicy): (WebCore::PolicyChecker::checkNewWindowPolicy): * loader/PolicyChecker.h: Source/WebKit: The issue was happening when the page is triggering a cross-site navigation while in the middle of parsing. This would cause us to start a new provisional load in a new process before the previous process sends the DidFinishLoadForFrame() IPC to the UIProcess. Getting such IPC after a provisional load has started would mess up our state machine and trip assertions. This patch restores non-PSON behavior which is that the previous load in the old process now gets stopped so that no DidFinishLoadForFrame() / DidFailLoadForFrame() gets sent. To achieve this behavior, I introduced a new "StopAllLoads" PolicyAction that we now send the old process when the load is continuing in a new process, instead of sending it "Ignore". * NetworkProcess/NetworkDataTaskBlob.cpp: (WebKit::NetworkDataTaskBlob::dispatchDidReceiveResponse): * NetworkProcess/cocoa/NetworkSessionCocoa.mm: (toNSURLSessionResponseDisposition): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::receivedNavigationPolicyDecision): Tools: Add API test coverage. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240880 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-01 Chris Dumez REGRESSION: Flaky ASSERTION FAILED: m_uncommittedState.state == State::Committed on http/tests/cookies/same-site/fetch-after-top-level-navigation-initiated-from-iframe-in-cross-origin-page.html https://bugs.webkit.org/show_bug.cgi?id=193740 Reviewed by Alex Christensen. The issue was happening when the page is triggering a cross-site navigation while in the middle of parsing. This would cause us to start a new provisional load in a new process before the previous process sends the DidFinishLoadForFrame() IPC to the UIProcess. Getting such IPC after a provisional load has started would mess up our state machine and trip assertions. This patch restores non-PSON behavior which is that the previous load in the old process now gets stopped so that no DidFinishLoadForFrame() / DidFailLoadForFrame() gets sent. To achieve this behavior, I introduced a new "StopAllLoads" PolicyAction that we now send the old process when the load is continuing in a new process, instead of sending it "Ignore". * NetworkProcess/NetworkDataTaskBlob.cpp: (WebKit::NetworkDataTaskBlob::dispatchDidReceiveResponse): * NetworkProcess/cocoa/NetworkSessionCocoa.mm: (toNSURLSessionResponseDisposition): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::receivedNavigationPolicyDecision): 2019-02-05 Alan Coon Cherry-pick r240818. rdar://problem/47774549 Page zoom level is lost after a process swap or a crash https://bugs.webkit.org/show_bug.cgi?id=194105 Reviewed by Alex Christensen. Source/WebKit: Previously, when the client would call setPageAndTextZoomFactors() on the WebPageProxy, we would update the WebPageProxy's corresponding data members and send an IPC to the WebProcess to apply the zoom factors. The issue is that on process crash or process-swap, we never communicate those zoom factors to the new WebProcess. Even if the client were to call setPageAndTextZoomFactors() with the same factors again, it would be a no-op since the WebPageProxy's data members already reflect the expected values. To address the issue, pass both the page zoom and the text zoom factors to the WebProcess via WebPageCreationParameters. This way, there is no need to send an extra IPC and we're sure the WebPageProxy's factors are properly applied to the WebPage on WebContent process side upon creation (whether after a crash or a process swap). * Shared/WebPageCreationParameters.cpp: (WebKit::WebPageCreationParameters::encode const): (WebKit::WebPageCreationParameters::decode): * Shared/WebPageCreationParameters.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::creationParameters): * WebProcess/WebPage/WebPage.cpp: Tools: Add API test coverage. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: (-[PSONNavigationDelegate webView:didCommitNavigation:]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240818 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-31 Chris Dumez Page zoom level is lost after a process swap or a crash https://bugs.webkit.org/show_bug.cgi?id=194105 Reviewed by Alex Christensen. Previously, when the client would call setPageAndTextZoomFactors() on the WebPageProxy, we would update the WebPageProxy's corresponding data members and send an IPC to the WebProcess to apply the zoom factors. The issue is that on process crash or process-swap, we never communicate those zoom factors to the new WebProcess. Even if the client were to call setPageAndTextZoomFactors() with the same factors again, it would be a no-op since the WebPageProxy's data members already reflect the expected values. To address the issue, pass both the page zoom and the text zoom factors to the WebProcess via WebPageCreationParameters. This way, there is no need to send an extra IPC and we're sure the WebPageProxy's factors are properly applied to the WebPage on WebContent process side upon creation (whether after a crash or a process swap). * Shared/WebPageCreationParameters.cpp: (WebKit::WebPageCreationParameters::encode const): (WebKit::WebPageCreationParameters::decode): * Shared/WebPageCreationParameters.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::creationParameters): * WebProcess/WebPage/WebPage.cpp: 2019-02-05 Alan Coon Cherry-pick r240803. rdar://problem/47774506 Regression(PSON) Crash under WebProcessProxy::canTerminateChildProcess() https://bugs.webkit.org/show_bug.cgi?id=194094 Reviewed by Ryosuke Niwa. If a SuspendedPageProxy gets destroyed while a WebPageProxy is waiting for its to finish to suspend, call the "failure to suspend" completion handler asynchronously instead of synchronouly to make sure the completion handler cannot try and use the suspended page proxy while it is being destroyed. * UIProcess/SuspendedPageProxy.cpp: (WebKit::SuspendedPageProxy::~SuspendedPageProxy): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240803 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-31 Chris Dumez Regression(PSON) Crash under WebProcessProxy::canTerminateChildProcess() https://bugs.webkit.org/show_bug.cgi?id=194094 Reviewed by Ryosuke Niwa. If a SuspendedPageProxy gets destroyed while a WebPageProxy is waiting for its to finish to suspend, call the "failure to suspend" completion handler asynchronously instead of synchronouly to make sure the completion handler cannot try and use the suspended page proxy while it is being destroyed. * UIProcess/SuspendedPageProxy.cpp: (WebKit::SuspendedPageProxy::~SuspendedPageProxy): 2019-02-05 Alan Coon Cherry-pick r240772. rdar://problem/47774490 iOS: Crash in InteractiveUpdateHandler set by ViewGestureController::beginSwipeGesture https://bugs.webkit.org/show_bug.cgi?id=194083 Reviewed by Tim Horton. We think this crash is a regression from r236966. Prior to r236966, we could only called removeSwipeSnapshot() only when m_provisionalOrSameDocumentLoadCallback was set but now we can call it either when m_snapshotRemovalTracker::start was called, or it had been reset. This can result in m_webPageProxyForBackForwardListForCurrentSwipe getting cleared before InteractiveUpdateHandler is called by UIGestureRecognizer, resulting in the crash. This patch tries to restore the behavior prior to r236966 by only invoking removeSwipeSnapshot() when SnapshotRemovalTracker has a valid removal callback set. Unfortunately no new tests since there is no reproducible test case, and neither API tests nor layout tests seem to have the capability to trigger swipe gestures via UIGestureRecognizer, which is required for this crash to occur. Notably, back-forward swipe tests I enabled in r240765 bypass UIKit and emulates the action instead. * UIProcess/Cocoa/ViewGestureController.cpp: (WebKit::ViewGestureController::didReachMainFrameLoadTerminalState): * UIProcess/Cocoa/ViewGestureController.h: (WebKit::ViewGestureController::SnapshotRemovalTracker::hasRemovalCallback const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240772 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-31 Ryosuke Niwa iOS: Crash in InteractiveUpdateHandler set by ViewGestureController::beginSwipeGesture https://bugs.webkit.org/show_bug.cgi?id=194083 Reviewed by Tim Horton. We think this crash is a regression from r236966. Prior to r236966, we could only called removeSwipeSnapshot() only when m_provisionalOrSameDocumentLoadCallback was set but now we can call it either when m_snapshotRemovalTracker::start was called, or it had been reset. This can result in m_webPageProxyForBackForwardListForCurrentSwipe getting cleared before InteractiveUpdateHandler is called by UIGestureRecognizer, resulting in the crash. This patch tries to restore the behavior prior to r236966 by only invoking removeSwipeSnapshot() when SnapshotRemovalTracker has a valid removal callback set. Unfortunately no new tests since there is no reproducible test case, and neither API tests nor layout tests seem to have the capability to trigger swipe gestures via UIGestureRecognizer, which is required for this crash to occur. Notably, back-forward swipe tests I enabled in r240765 bypass UIKit and emulates the action instead. * UIProcess/Cocoa/ViewGestureController.cpp: (WebKit::ViewGestureController::didReachMainFrameLoadTerminalState): * UIProcess/Cocoa/ViewGestureController.h: (WebKit::ViewGestureController::SnapshotRemovalTracker::hasRemovalCallback const): 2019-02-05 Alan Coon Cherry-pick r240757. rdar://problem/47774493 [iOS] REGRESSION (r238635): Text area fails to re-focus after dismissal of keyboard on support.apple.com https://bugs.webkit.org/show_bug.cgi?id=193987 Reviewed by Tim Horton. It is unnecessary to relinquish first responder status when a user explicitly dismissing the keyboard. Moreover, doing so prevents key commands from being intercepted when a hardware keyboard is subsequently attached. Following r238635 a page becomes focused (accepting of keyboard input) and defocused when the WKContentView becomes first responder and resigns first responder, respectively. When a user explicitly dismisses the keyboard by tapping Done (iPhone) or the hide keyboard button (iPad) then UIKit tells WKContentView to resign its first responder status only to make its superview, WKWebView, first responder. When a person subsequently taps on the page again, the WKContentView requests to become the first responder. However changes to page focus are not guaranteed to be sent to the WebProcess immediately (WebPageProxy::activityStateDidChange() will schedule an update). In particular, they are not guaranteed to be sent before the WebProcess is told about a tap. Therefore, the WebProcess has out-of-date information on focus state of the page. Instead we should detect when WKWebView is being asked to resign as a result of the keyboard dismissal and refuse the request, taking care to end the current editing session, blur the focused element, and dismiss the on-screen keyboard. * Platform/spi/ios/UIKitSPI.h: Expose some SPI. * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView setupInteraction]): Register to receive notifications whenever a user explicitly dismisses the keyboard. (-[WKContentView resignFirstResponderForWebView]): If we are being asked to resign as a result of a user explicitly dismissing the keyboard then refuse to resign. (-[WKContentView _keyboardDidRequestDismissal:]): Update state, if applicable. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240757 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-30 Daniel Bates [iOS] REGRESSION (r238635): Text area fails to re-focus after dismissal of keyboard on support.apple.com https://bugs.webkit.org/show_bug.cgi?id=193987 Reviewed by Tim Horton. It is unnecessary to relinquish first responder status when a user explicitly dismissing the keyboard. Moreover, doing so prevents key commands from being intercepted when a hardware keyboard is subsequently attached. Following r238635 a page becomes focused (accepting of keyboard input) and defocused when the WKContentView becomes first responder and resigns first responder, respectively. When a user explicitly dismisses the keyboard by tapping Done (iPhone) or the hide keyboard button (iPad) then UIKit tells WKContentView to resign its first responder status only to make its superview, WKWebView, first responder. When a person subsequently taps on the page again, the WKContentView requests to become the first responder. However changes to page focus are not guaranteed to be sent to the WebProcess immediately (WebPageProxy::activityStateDidChange() will schedule an update). In particular, they are not guaranteed to be sent before the WebProcess is told about a tap. Therefore, the WebProcess has out-of-date information on focus state of the page. Instead we should detect when WKWebView is being asked to resign as a result of the keyboard dismissal and refuse the request, taking care to end the current editing session, blur the focused element, and dismiss the on-screen keyboard. * Platform/spi/ios/UIKitSPI.h: Expose some SPI. * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView setupInteraction]): Register to receive notifications whenever a user explicitly dismisses the keyboard. (-[WKContentView resignFirstResponderForWebView]): If we are being asked to resign as a result of a user explicitly dismissing the keyboard then refuse to resign. (-[WKContentView _keyboardDidRequestDismissal:]): Update state, if applicable. 2019-02-05 Alan Coon Cherry-pick r240725. rdar://problem/47774554 Regression(PSON) Load hang can occur on history navigation https://bugs.webkit.org/show_bug.cgi?id=194030 Reviewed by Antti Koivisto. Source/WebKit: We do not support having more than one WebPage in a WebProcess with the same page ID. As a result, if we decide to reuse an existing process on process-swap, we need to make sure that we either use its suspended page (when possible, meaning that it is for the right HistoryItem / page) or we need make sure we drop the existing suspended page for this process / pagePID combination, so that the WebPage on WebProcess side gets closed before we attempt to do the new load. We were doing this correctly in 2 places in WebProcessPool::processForNavigationInternal() but failed to do so in a third place, when doing back to a HistoryItem which does not have a SuspendedPage but whose process is still alive (presumably because it is kept alive by another suspended page). This patch fixes this third place to remove any suspended page in the process for the current page before reusing the process. An assertion was also added to the call site in WebPageProxy::receivedNavigationPolicyDecision() to make sure we catch this more easily in the future. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::receivedNavigationPolicyDecision): * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::processForNavigationInternal): (WebKit::WebProcessPool::removeAllSuspendedPagesForPage): (WebKit::WebProcessPool::hasSuspendedPageFor const): * UIProcess/WebProcessPool.h: Tools: Add API test coverage. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240725 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-30 Chris Dumez Regression(PSON) Load hang can occur on history navigation https://bugs.webkit.org/show_bug.cgi?id=194030 Reviewed by Antti Koivisto. We do not support having more than one WebPage in a WebProcess with the same page ID. As a result, if we decide to reuse an existing process on process-swap, we need to make sure that we either use its suspended page (when possible, meaning that it is for the right HistoryItem / page) or we need make sure we drop the existing suspended page for this process / pagePID combination, so that the WebPage on WebProcess side gets closed before we attempt to do the new load. We were doing this correctly in 2 places in WebProcessPool::processForNavigationInternal() but failed to do so in a third place, when doing back to a HistoryItem which does not have a SuspendedPage but whose process is still alive (presumably because it is kept alive by another suspended page). This patch fixes this third place to remove any suspended page in the process for the current page before reusing the process. An assertion was also added to the call site in WebPageProxy::receivedNavigationPolicyDecision() to make sure we catch this more easily in the future. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::receivedNavigationPolicyDecision): * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::processForNavigationInternal): (WebKit::WebProcessPool::removeAllSuspendedPagesForPage): (WebKit::WebProcessPool::hasSuspendedPageFor const): * UIProcess/WebProcessPool.h: 2019-02-05 Alan Coon Cherry-pick r240717. rdar://problem/47774504 Crash in WebKit::RemoteLayerTreePropertyApplier::updateChildren https://bugs.webkit.org/show_bug.cgi?id=193897 Reviewed by Simon Fraser. There has been some null pointer crashes where we fail to find a remote layer tree node that matches the transaction properties. * Shared/RemoteLayerTree/RemoteLayerTreePropertyApplier.mm: (WebKit::RemoteLayerTreePropertyApplier::updateChildren): Null check the nodes. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240717 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-30 Antti Koivisto Crash in WebKit::RemoteLayerTreePropertyApplier::updateChildren https://bugs.webkit.org/show_bug.cgi?id=193897 Reviewed by Simon Fraser. There has been some null pointer crashes where we fail to find a remote layer tree node that matches the transaction properties. * Shared/RemoteLayerTree/RemoteLayerTreePropertyApplier.mm: (WebKit::RemoteLayerTreePropertyApplier::updateChildren): Null check the nodes. 2019-02-05 Alan Coon Cherry-pick r240702. rdar://problem/47774503 iOS: Nullptr crash in WebPage::getPositionInformation dereferencing an input element for data list https://bugs.webkit.org/show_bug.cgi?id=193996 Reviewed by Wenson Hsieh. Added a missing nullptr check. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::getPositionInformation): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240702 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-29 Ryosuke Niwa iOS: Nullptr crash in WebPage::getPositionInformation dereferencing an input element for data list https://bugs.webkit.org/show_bug.cgi?id=193996 Reviewed by Wenson Hsieh. Added a missing nullptr check. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::getPositionInformation): 2019-02-05 Alan Coon Cherry-pick r240675. rdar://problem/47776350 Regression (r240046): [PSON] Spurious changes to [WKWebView url] and [WKWebView loading] after [WKWebView loadRequest] https://bugs.webkit.org/show_bug.cgi?id=193967 Reviewed by Alex Christensen. Source/WebKit: Update WebPageProxy::receivedPolicyDecision() to no longer clear the pending URL when we send PolicyAction::Ignore to the old process when the load is continuing in a new process due to PSON. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::receivedNavigationPolicyDecision): (WebKit::WebPageProxy::receivedPolicyDecision): * UIProcess/WebPageProxy.h: Tools: Add API test coverage. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: (-[PSONLoadingObserver observeValueForKeyPath:ofObject:change:context:]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240675 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-29 Chris Dumez Regression (r240046): [PSON] Spurious changes to [WKWebView url] and [WKWebView loading] after [WKWebView loadRequest] https://bugs.webkit.org/show_bug.cgi?id=193967 Reviewed by Alex Christensen. Update WebPageProxy::receivedPolicyDecision() to no longer clear the pending URL when we send PolicyAction::Ignore to the old process when the load is continuing in a new process due to PSON. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::receivedNavigationPolicyDecision): (WebKit::WebPageProxy::receivedPolicyDecision): * UIProcess/WebPageProxy.h: 2019-02-05 Alan Coon Cherry-pick r240663. rdar://problem/47774492 REGRESSION (PSON): Flash on link navigation on Mac https://bugs.webkit.org/show_bug.cgi?id=193961 Reviewed by Chris Dumez. The target page sends EnterAcceleratedCompositingMode message too early, before we have a valid layer tree. * WebProcess/WebPage/DrawingArea.h: (WebKit::DrawingArea::attach): Deleted. Not needed anymore. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::reinitializeWebPage): (WebKit::WebPage::didCompletePageTransition): (WebKit::m_shouldAttachDrawingAreaOnPageTransition): Deleted. Move message sending logic fully to TiledCoreAnimationDrawingArea. Unfreezing the layer tree is sufficient to trigger the message. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.h: * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm: (WebKit::TiledCoreAnimationDrawingArea::TiledCoreAnimationDrawingArea): There is no need to treat process swap case differently. (WebKit::TiledCoreAnimationDrawingArea::sendEnterAcceleratedCompositingModeIfNeeded): Send this after the first successful layer flush with the root layer set. (WebKit::TiledCoreAnimationDrawingArea::flushLayers): (WebKit::TiledCoreAnimationDrawingArea::attach): Deleted. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240663 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-29 Antti Koivisto REGRESSION (PSON): Flash on link navigation on Mac https://bugs.webkit.org/show_bug.cgi?id=193961 Reviewed by Chris Dumez. The target page sends EnterAcceleratedCompositingMode message too early, before we have a valid layer tree. * WebProcess/WebPage/DrawingArea.h: (WebKit::DrawingArea::attach): Deleted. Not needed anymore. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::reinitializeWebPage): (WebKit::WebPage::didCompletePageTransition): (WebKit::m_shouldAttachDrawingAreaOnPageTransition): Deleted. Move message sending logic fully to TiledCoreAnimationDrawingArea. Unfreezing the layer tree is sufficient to trigger the message. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.h: * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm: (WebKit::TiledCoreAnimationDrawingArea::TiledCoreAnimationDrawingArea): There is no need to treat process swap case differently. (WebKit::TiledCoreAnimationDrawingArea::sendEnterAcceleratedCompositingModeIfNeeded): Send this after the first successful layer flush with the root layer set. (WebKit::TiledCoreAnimationDrawingArea::flushLayers): (WebKit::TiledCoreAnimationDrawingArea::attach): Deleted. 2019-02-05 Alan Coon Cherry-pick r240660. rdar://problem/47774552 REGRESSION (PSON): Twitter link gets stuck at t.co after navigating back in tab https://bugs.webkit.org/show_bug.cgi?id=193932 Reviewed by Brady Eidson. Source/WebKit: When doing a client side redirect from origin A to origin B, we would swap process and create a SuspendedPageProxy and save it on the source BackForwardListItem. The issue is that the BackForwardList is locked for such redirect so we end up updating the current BackForwardListItem with origin B's URL while origin A's suspended page remained on the item. When going to another URL in the same origin A, we would not create a suspended page since no process-swap would occur. When pressing the back button, we would go back to the previous BackForwardListItem and use its SuspendedPageProxy, which is for the wrong URL (The pre-client redirect one). To address the issue, we no longer create a SuspendedPageProxy for cross-site client side redirects. There will be no way no go back to this suspended page anyway since the back/forward list item will be updated with the redirection URL. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::suspendCurrentPageIfPossible): Tools: Add API test coverage. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240660 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-29 Chris Dumez REGRESSION (PSON): Twitter link gets stuck at t.co after navigating back in tab https://bugs.webkit.org/show_bug.cgi?id=193932 Reviewed by Brady Eidson. When doing a client side redirect from origin A to origin B, we would swap process and create a SuspendedPageProxy and save it on the source BackForwardListItem. The issue is that the BackForwardList is locked for such redirect so we end up updating the current BackForwardListItem with origin B's URL while origin A's suspended page remained on the item. When going to another URL in the same origin A, we would not create a suspended page since no process-swap would occur. When pressing the back button, we would go back to the previous BackForwardListItem and use its SuspendedPageProxy, which is for the wrong URL (The pre-client redirect one). To address the issue, we no longer create a SuspendedPageProxy for cross-site client side redirects. There will be no way no go back to this suspended page anyway since the back/forward list item will be updated with the redirection URL. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::suspendCurrentPageIfPossible): 2019-02-05 Alan Coon Cherry-pick r239895. rdar://problem/47776475 Allow WebContent process access to some drawing-related IOKit properties https://bugs.webkit.org/show_bug.cgi?id=193086 Reviewed by Eric Carlson. Add one missing IOKit property, and revise the regexp used for another. * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239895 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-11 Brent Fulgham Allow WebContent process access to some drawing-related IOKit properties https://bugs.webkit.org/show_bug.cgi?id=193086 Reviewed by Eric Carlson. Add one missing IOKit property, and revise the regexp used for another. * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb: 2019-02-05 Alan Coon Cherry-pick r239881. rdar://problem/47776480 [iOS] Precision drop state thrashes when dragging near the top edge of an editable element https://bugs.webkit.org/show_bug.cgi?id=193364 Reviewed by Tim Horton. Source/WebCore: Add a new helper method on DragCaretController to compute the bounds of the editable element around the drop caret position. This is either the enclosing form control (in the case of text fields and text areas), or the highest editable root. See WebKit ChangeLog for more details. Test: DragAndDropTests.AvoidPreciseDropNearTopOfTextArea * editing/FrameSelection.cpp: (WebCore::DragCaretController::editableElementRectInRootViewCoordinates const): * editing/FrameSelection.h: Source/WebKit: On iOS, marking a UIDropProposal as precise offsets the hit-testing location of the drop by a small distance either upwards or downwards from the actual location of the user's finger. When dragging over an editable element, WebKit currently marks the drop proposal as precise; however, when dragging over the top edge of an editable element, what happens is that the hit-testing location is offset to a location outside of the editable element, which causes us to turn off precision drop mode; subsequently, turning off precision drop mode removes the offset, which causes us to hit-test within the editable element once again and re-enable precision mode, and the cycle continues. In order to mitigate this, bail out of precision drop mode when dragging near the top or bottom edges of the highest editable root that contains the current drop caret position (or, if the drop caret is inside of a text form control, use the form control as the editable element instead). * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::didPerformDragControllerAction): * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::currentDragCaretEditableElementRect const): * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView dropInteraction:sessionDidUpdate:]): Avoid precise mode when we're less than 25pt away from the top and bottom edge of the editable element rect. Since the drag location offset amount is a fixed offset in window coordinates, we first convert this minimum distance to the content view's coordinate space by dividing by the content scale factor. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::performDragControllerAction): Tools: Add a test to verify that dragging near the top of a textarea element does not flag the drop proposal as precise, whereas dragging near the middle of the textarea does. * TestWebKitAPI/Tests/ios/DragAndDropTestsIOS.mm: (TestWebKitAPI::TEST): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239881 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-11 Wenson Hsieh [iOS] Precision drop state thrashes when dragging near the top edge of an editable element https://bugs.webkit.org/show_bug.cgi?id=193364 Reviewed by Tim Horton. On iOS, marking a UIDropProposal as precise offsets the hit-testing location of the drop by a small distance either upwards or downwards from the actual location of the user's finger. When dragging over an editable element, WebKit currently marks the drop proposal as precise; however, when dragging over the top edge of an editable element, what happens is that the hit-testing location is offset to a location outside of the editable element, which causes us to turn off precision drop mode; subsequently, turning off precision drop mode removes the offset, which causes us to hit-test within the editable element once again and re-enable precision mode, and the cycle continues. In order to mitigate this, bail out of precision drop mode when dragging near the top or bottom edges of the highest editable root that contains the current drop caret position (or, if the drop caret is inside of a text form control, use the form control as the editable element instead). * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::didPerformDragControllerAction): * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::currentDragCaretEditableElementRect const): * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView dropInteraction:sessionDidUpdate:]): Avoid precise mode when we're less than 25pt away from the top and bottom edge of the editable element rect. Since the drag location offset amount is a fixed offset in window coordinates, we first convert this minimum distance to the content view's coordinate space by dividing by the content scale factor. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::performDragControllerAction): 2019-02-05 Alan Coon Apply patch. rdar://problem/47774509 fix-194106 2019-01-31 Youenn Fablet Add an API test to cover UIClient checkUserMediaPermissionForOrigin being nullptr https://bugs.webkit.org/show_bug.cgi?id=194106 Make sure handler is not called after being moved. * UIProcess/UserMediaPermissionRequestManagerProxy.cpp: (WebKit::UserMediaPermissionRequestManagerProxy::getUserMediaPermissionInfo): 2019-01-30 Babak Shafiei Cherry-pick r240633. rdar://problem/47682687 [watchOS] Enable Parental Controls content filtering https://bugs.webkit.org/show_bug.cgi?id=193939 Reviewed by Ryosuke Niwa. Source/JavaScriptCore: * Configurations/FeatureDefines.xcconfig: Source/WebCore: * Configurations/FeatureDefines.xcconfig: Source/WebCore/PAL: * Configurations/FeatureDefines.xcconfig: Source/WebKit: * Configurations/FeatureDefines.xcconfig: Source/WebKitLegacy/mac: * Configurations/FeatureDefines.xcconfig: Source/WTF: * wtf/Platform.h: Tools: * TestWebKitAPI/Configurations/FeatureDefines.xcconfig: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240633 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-28 Andy Estes [watchOS] Enable Parental Controls content filtering https://bugs.webkit.org/show_bug.cgi?id=193939 Reviewed by Ryosuke Niwa. * Configurations/FeatureDefines.xcconfig: 2019-01-30 Babak Shafiei Cherry-pick r240729. rdar://problem/47685553 Ensure image picker sourceType is set before cameraDevice https://bugs.webkit.org/show_bug.cgi?id=193998 Reviewed by Beth Dakin. * UIProcess/ios/forms/WKFileUploadPanel.mm: (-[WKFileUploadPanel _showPhotoPickerWithSourceType:]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240729 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-29 Conrad Shultz Ensure image picker sourceType is set before cameraDevice https://bugs.webkit.org/show_bug.cgi?id=193998 Reviewed by Beth Dakin. * UIProcess/ios/forms/WKFileUploadPanel.mm: (-[WKFileUploadPanel _showPhotoPickerWithSourceType:]): 2019-01-30 Babak Shafiei Cherry-pick r240578. rdar://problem/47685372 WebUserContentController::removeUserScriptMessageHandlerInternal may deref and delete itself https://bugs.webkit.org/show_bug.cgi?id=193901 Reviewed by David Kilzer. Don't know how to repro. * WebProcess/UserContent/WebUserContentController.cpp: (WebKit::WebUserContentController::removeUserScriptMessageHandlerInternal): Calling userMessageHandlers.removeFirstMatching() may remove the last ref to this (because WebUserMessageHandlerDescriptorProxy refs WebUserContentController). Fix by protecting this over the function. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240578 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-28 Antti Koivisto WebUserContentController::removeUserScriptMessageHandlerInternal may deref and delete itself https://bugs.webkit.org/show_bug.cgi?id=193901 Reviewed by David Kilzer. Don't know how to repro. * WebProcess/UserContent/WebUserContentController.cpp: (WebKit::WebUserContentController::removeUserScriptMessageHandlerInternal): Calling userMessageHandlers.removeFirstMatching() may remove the last ref to this (because WebUserMessageHandlerDescriptorProxy refs WebUserContentController). Fix by protecting this over the function. 2019-01-30 Alan Coon Cherry-pick r240733. rdar://problem/47683434 [macOS] Sandbox fails to compile on 10.12 https://bugs.webkit.org/show_bug.cgi?id=194035 Reviewed by Brent Fulgham. This was caused by the commit , which is only valid for 10.14 and later. * PluginProcess/mac/com.apple.WebKit.plugin-common.sb.in: * WebProcess/com.apple.WebProcess.sb.in: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240733 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-30 Per Arne Vollan [macOS] Sandbox fails to compile on 10.12 https://bugs.webkit.org/show_bug.cgi?id=194035 Reviewed by Brent Fulgham. This was caused by the commit , which is only valid for 10.14 and later. * PluginProcess/mac/com.apple.WebKit.plugin-common.sb.in: * WebProcess/com.apple.WebProcess.sb.in: 2019-01-29 Alan Coon Cherry-pick r240659. rdar://problem/47639406 Regression(r240046) VoiceOver is no longer working after a process swap https://bugs.webkit.org/show_bug.cgi?id=193953 Reviewed by Alex Christensen. ProvisionalPageProxy used to forward the RegisterWebProcessAccessibilityToken IPC from the provisional WebProcess to the WebPageProxy right away. This in turn would notify the PageClient whose logic would rely on WebPageProxy::process(), which returns the committed process instead of the provisional one. To address the issue, the ProvisionalPageProxy now stores the token sent by the provisional WebProcess and we only call registerWebProcessAccessibilityToken() on the WebPageProxy *after* we've swapped to the provisional process. * UIProcess/ProvisionalPageProxy.cpp: (WebKit::ProvisionalPageProxy::registerWebProcessAccessibilityToken): (WebKit::ProvisionalPageProxy::didReceiveMessage): * UIProcess/ProvisionalPageProxy.h: (WebKit::ProvisionalPageProxy::takeAccessibilityToken): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::commitProvisionalPage): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240659 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-29 Chris Dumez Regression(r240046) VoiceOver is no longer working after a process swap https://bugs.webkit.org/show_bug.cgi?id=193953 Reviewed by Alex Christensen. ProvisionalPageProxy used to forward the RegisterWebProcessAccessibilityToken IPC from the provisional WebProcess to the WebPageProxy right away. This in turn would notify the PageClient whose logic would rely on WebPageProxy::process(), which returns the committed process instead of the provisional one. To address the issue, the ProvisionalPageProxy now stores the token sent by the provisional WebProcess and we only call registerWebProcessAccessibilityToken() on the WebPageProxy *after* we've swapped to the provisional process. * UIProcess/ProvisionalPageProxy.cpp: (WebKit::ProvisionalPageProxy::registerWebProcessAccessibilityToken): (WebKit::ProvisionalPageProxy::didReceiveMessage): * UIProcess/ProvisionalPageProxy.h: (WebKit::ProvisionalPageProxy::takeAccessibilityToken): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::commitProvisionalPage): 2019-01-28 Alan Coon Cherry-pick r240599. rdar://problem/47609799 Regression(PSON) Crash under WebPageProxy::didStartProgress() https://bugs.webkit.org/show_bug.cgi?id=193915 Reviewed by Alex Christensen. Source/WebKit: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::close): Make sure we destroy the ProvisionalPageProxy if the page gets closed as we do not want to keep receiving IPC after this or even worse, commit the provisional page. (WebKit::WebPageProxy::didStartProgress): Add an assertion in didStartProgress() to make sure we do not receive this IPC after the page has been closed. Tools: Add API test coverage. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240599 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-28 Chris Dumez Regression(PSON) Crash under WebPageProxy::didStartProgress() https://bugs.webkit.org/show_bug.cgi?id=193915 Reviewed by Alex Christensen. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::close): Make sure we destroy the ProvisionalPageProxy if the page gets closed as we do not want to keep receiving IPC after this or even worse, commit the provisional page. (WebKit::WebPageProxy::didStartProgress): Add an assertion in didStartProgress() to make sure we do not receive this IPC after the page has been closed. 2019-01-28 Babak Shafiei Cherry-pick r240516. rdar://problem/47586889 Add SPI to inform an application that "Go Back" has been clicked from a safe browsing warning https://bugs.webkit.org/show_bug.cgi?id=193802 Reviewed by Andy Estes. Source/WebKit: * UIProcess/API/APIUIClient.h: (API::UIClient::didClickGoBackFromSafeBrowsingWarning): * UIProcess/API/Cocoa/WKUIDelegatePrivate.h: * UIProcess/Cocoa/UIDelegate.h: * UIProcess/Cocoa/UIDelegate.mm: (WebKit::UIDelegate::setDelegate): (WebKit::UIDelegate::UIClient::didClickGoBackFromSafeBrowsingWarning): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::decidePolicyForNavigationAction): Tools: * TestWebKitAPI/Tests/WebKitCocoa/SafeBrowsing.mm: (-[SafeBrowsingNavigationDelegate _webViewDidClickGoBackFromSafeBrowsingWarning:]): (TEST): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240516 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-25 Alex Christensen Add SPI to inform an application that "Go Back" has been clicked from a safe browsing warning https://bugs.webkit.org/show_bug.cgi?id=193802 Reviewed by Andy Estes. * UIProcess/API/APIUIClient.h: (API::UIClient::didClickGoBackFromSafeBrowsingWarning): * UIProcess/API/Cocoa/WKUIDelegatePrivate.h: * UIProcess/Cocoa/UIDelegate.h: * UIProcess/Cocoa/UIDelegate.mm: (WebKit::UIDelegate::setDelegate): (WebKit::UIDelegate::UIClient::didClickGoBackFromSafeBrowsingWarning): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::decidePolicyForNavigationAction): 2019-01-28 Babak Shafiei Cherry-pick r240533. rdar://problem/47586823 REGRESSION: Some USDz from 3rd party websites don't go directly to AR QL https://bugs.webkit.org/show_bug.cgi?id=193831 Reviewed by Chris Dumez. Source/WebKit: A System Preview () displays in a modal and doesn't trigger a navigation. If the link was cross origin, it was causing a process swap, which meant that the response defaulted back to a navigation. The fix is to not cause a PSON when the navigation is a system preview. * UIProcess/API/APINavigation.h: (API::Navigation::shouldForceDownload const): This is now just tracking the "download" attribute, and not including System Preview. (API::Navigation::isSystemPreview const): New method to check for a navigation triggered as a System Preview. * UIProcess/WebPageProxy.cpp: Move the code from receivedPolicyDecision to receivedNavigationPolicyDecision, so that downloads and System Previews are detected before we decide to change process. (WebKit::WebPageProxy::receivedNavigationPolicyDecision): (WebKit::WebPageProxy::receivedPolicyDecision): Tools: Two new tests that exercise cross-origin and same-origin System Previews. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240533 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-25 Dean Jackson REGRESSION: Some USDz from 3rd party websites don't go directly to AR QL https://bugs.webkit.org/show_bug.cgi?id=193831 Reviewed by Chris Dumez. A System Preview () displays in a modal and doesn't trigger a navigation. If the link was cross origin, it was causing a process swap, which meant that the response defaulted back to a navigation. The fix is to not cause a PSON when the navigation is a system preview. * UIProcess/API/APINavigation.h: (API::Navigation::shouldForceDownload const): This is now just tracking the "download" attribute, and not including System Preview. (API::Navigation::isSystemPreview const): New method to check for a navigation triggered as a System Preview. * UIProcess/WebPageProxy.cpp: Move the code from receivedPolicyDecision to receivedNavigationPolicyDecision, so that downloads and System Previews are detected before we decide to change process. (WebKit::WebPageProxy::receivedNavigationPolicyDecision): (WebKit::WebPageProxy::receivedPolicyDecision): 2019-01-28 Babak Shafiei Cherry-pick r240484. rdar://problem/47591281 Drop WebKit::WebKitPolicyAction type as it is no longer needed https://bugs.webkit.org/show_bug.cgi?id=193827 Reviewed by Antti Koivisto. Drop WebKit::WebKitPolicyAction type as it is no longer needed. It is now identical to WebCore::PolicyAction. * Shared/WebPolicyAction.h: Removed. * UIProcess/WebFramePolicyListenerProxy.cpp: (WebKit::WebFramePolicyListenerProxy::didReceiveSafeBrowsingResults): (WebKit::WebFramePolicyListenerProxy::use): (WebKit::WebFramePolicyListenerProxy::download): (WebKit::WebFramePolicyListenerProxy::ignore): * UIProcess/WebFramePolicyListenerProxy.h: * UIProcess/WebFrameProxy.cpp: (WebKit::WebFrameProxy::setUpPolicyListenerProxy): * UIProcess/WebFrameProxy.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::receivedNavigationPolicyDecision): (WebKit::WebPageProxy::receivedPolicyDecision): (WebKit::WebPageProxy::decidePolicyForNavigationAction): (WebKit::WebPageProxy::decidePolicyForNavigationActionSync): (WebKit::WebPageProxy::decidePolicyForNewWindowAction): (WebKit::WebPageProxy::decidePolicyForResponseShared): * UIProcess/WebPageProxy.h: * WebKit.xcodeproj/project.pbxproj: * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::dispatchDecidePolicyForResponse): (WebKit::WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction): * WebProcess/WebPage/WebFrame.cpp: (WebKit::WebFrame::didReceivePolicyDecision): (WebKit::toPolicyAction): Deleted. * WebProcess/WebPage/WebFrame.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::didReceivePolicyDecision): * WebProcess/WebPage/WebPage.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240484 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-25 Chris Dumez Drop WebKit::WebKitPolicyAction type as it is no longer needed https://bugs.webkit.org/show_bug.cgi?id=193827 Reviewed by Antti Koivisto. Drop WebKit::WebKitPolicyAction type as it is no longer needed. It is now identical to WebCore::PolicyAction. * Shared/WebPolicyAction.h: Removed. * UIProcess/WebFramePolicyListenerProxy.cpp: (WebKit::WebFramePolicyListenerProxy::didReceiveSafeBrowsingResults): (WebKit::WebFramePolicyListenerProxy::use): (WebKit::WebFramePolicyListenerProxy::download): (WebKit::WebFramePolicyListenerProxy::ignore): * UIProcess/WebFramePolicyListenerProxy.h: * UIProcess/WebFrameProxy.cpp: (WebKit::WebFrameProxy::setUpPolicyListenerProxy): * UIProcess/WebFrameProxy.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::receivedNavigationPolicyDecision): (WebKit::WebPageProxy::receivedPolicyDecision): (WebKit::WebPageProxy::decidePolicyForNavigationAction): (WebKit::WebPageProxy::decidePolicyForNavigationActionSync): (WebKit::WebPageProxy::decidePolicyForNewWindowAction): (WebKit::WebPageProxy::decidePolicyForResponseShared): * UIProcess/WebPageProxy.h: * WebKit.xcodeproj/project.pbxproj: * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::dispatchDecidePolicyForResponse): (WebKit::WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction): * WebProcess/WebPage/WebFrame.cpp: (WebKit::WebFrame::didReceivePolicyDecision): (WebKit::toPolicyAction): Deleted. * WebProcess/WebPage/WebFrame.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::didReceivePolicyDecision): * WebProcess/WebPage/WebPage.h: 2019-01-28 Babak Shafiei Cherry-pick r240542. rdar://problem/47586850 REGRESSION (r238818): Snapshot is removed too late after swiping back on Twitter https://bugs.webkit.org/show_bug.cgi?id=193860 Reviewed by Antti Koivisto. * UIProcess/Cocoa/ViewGestureController.cpp: (WebKit::ViewGestureController::didStartProvisionalOrSameDocumentLoadForMainFrame): (WebKit::ViewGestureController::didStartProvisionalLoadForMainFrame): (WebKit::ViewGestureController::didSameDocumentNavigationForMainFrame): * UIProcess/Cocoa/ViewGestureController.h: Treat provisional load and same document load the same: they already both unpause the snapshot removal tracker, request render tree size notifications, but same-document navigation was missing the call to dispatchAfterEnsuringDrawing and thus would get stuck waiting for RepaintAfterNavigation. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240542 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-25 Tim Horton REGRESSION (r238818): Snapshot is removed too late after swiping back on Twitter https://bugs.webkit.org/show_bug.cgi?id=193860 Reviewed by Antti Koivisto. * UIProcess/Cocoa/ViewGestureController.cpp: (WebKit::ViewGestureController::didStartProvisionalOrSameDocumentLoadForMainFrame): (WebKit::ViewGestureController::didStartProvisionalLoadForMainFrame): (WebKit::ViewGestureController::didSameDocumentNavigationForMainFrame): * UIProcess/Cocoa/ViewGestureController.h: Treat provisional load and same document load the same: they already both unpause the snapshot removal tracker, request render tree size notifications, but same-document navigation was missing the call to dispatchAfterEnsuringDrawing and thus would get stuck waiting for RepaintAfterNavigation. 2019-01-28 Babak Shafiei Cherry-pick r240497. rdar://problem/47586863 iOS: inputmode="none" disables hardware keyboard's globe key https://bugs.webkit.org/show_bug.cgi?id=193811 Reviewed by Wenson Hsieh. Source/WebKit: Removed the support for inputmode="none" for now since we need a new SPI from UIKit to properly implement this feature some time in the future. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _zoomToRevealFocusedElement]): (-[WKContentView inputView]): (-[WKContentView requiresAccessoryView]): (-[WKContentView textInputTraits]): LayoutTests: Updated and renamed the test expecting the keyboard to update upon inputmode content attribute changed to use inputmode="decimal" instead of inputmode="none", and updated another test to expect inputmode="none" has no effect instead of hiding the keyboard. * fast/forms/ios/inputmode-change-update-keyboard-expected.txt: Renamed from inputmode-none-removed-expected.txt. * fast/forms/ios/inputmode-change-update-keyboard.html: Renamed from inputmode-none-removed.html. * fast/forms/ios/inputmode-none-expected.txt: * fast/forms/ios/inputmode-none.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240497 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-25 Ryosuke Niwa iOS: inputmode="none" disables hardware keyboard's globe key https://bugs.webkit.org/show_bug.cgi?id=193811 Reviewed by Wenson Hsieh. Removed the support for inputmode="none" for now since we need a new SPI from UIKit to properly implement this feature some time in the future. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _zoomToRevealFocusedElement]): (-[WKContentView inputView]): (-[WKContentView requiresAccessoryView]): (-[WKContentView textInputTraits]): 2019-01-28 Babak Shafiei Cherry-pick r240493. rdar://problem/47586905 REGRESSION (PSON): After swipe back, first few attempts to swipe forward not recognized as swipe gestures https://bugs.webkit.org/show_bug.cgi?id=193818 Reviewed by Tim Horton. We don't hit the RenderTreeSizeThreshold milestone to remove the snapshot and allow interaction because we request it from a wrong process (the one we are leaving behind). * UIProcess/Cocoa/ViewGestureController.cpp: (WebKit::ViewGestureController::didStartProvisionalLoadForMainFrame): Request the RenderTreeSizeThreshold notification when the load has started and we know the process to use. (WebKit::ViewGestureController::SnapshotRemovalTracker::hasOutstandingEvent): * UIProcess/Cocoa/ViewGestureController.h: (WebKit::ViewGestureController::SnapshotRemovalTracker::renderTreeSizeThreshold const): (WebKit::ViewGestureController::SnapshotRemovalTracker::setRenderTreeSizeThreshold): * UIProcess/mac/ViewGestureControllerMac.mm: (WebKit::ViewGestureController::endSwipeGesture): Don't request immediately, save the threshold to SnapshotRemovalTracker. (WebKit::ViewGestureController::requestRenderTreeSizeNotificationIfNeeded): Do the request to the right process. * WebProcess/WebPage/ViewGestureGeometryCollector.cpp: (WebKit::ViewGestureGeometryCollector::setRenderTreeSizeNotificationThreshold): Ensure we send the notification even if we reached the threshold before it was requested. (WebKit::ViewGestureGeometryCollector::sendDidHitRenderTreeSizeThresholdIfNeeded): (WebKit::ViewGestureGeometryCollector::mainFrameDidLayout): * WebProcess/WebPage/ViewGestureGeometryCollector.h: (WebKit::ViewGestureGeometryCollector::setRenderTreeSizeNotificationThreshold): Deleted. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240493 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-25 Antti Koivisto REGRESSION (PSON): After swipe back, first few attempts to swipe forward not recognized as swipe gestures https://bugs.webkit.org/show_bug.cgi?id=193818 Reviewed by Tim Horton. We don't hit the RenderTreeSizeThreshold milestone to remove the snapshot and allow interaction because we request it from a wrong process (the one we are leaving behind). * UIProcess/Cocoa/ViewGestureController.cpp: (WebKit::ViewGestureController::didStartProvisionalLoadForMainFrame): Request the RenderTreeSizeThreshold notification when the load has started and we know the process to use. (WebKit::ViewGestureController::SnapshotRemovalTracker::hasOutstandingEvent): * UIProcess/Cocoa/ViewGestureController.h: (WebKit::ViewGestureController::SnapshotRemovalTracker::renderTreeSizeThreshold const): (WebKit::ViewGestureController::SnapshotRemovalTracker::setRenderTreeSizeThreshold): * UIProcess/mac/ViewGestureControllerMac.mm: (WebKit::ViewGestureController::endSwipeGesture): Don't request immediately, save the threshold to SnapshotRemovalTracker. (WebKit::ViewGestureController::requestRenderTreeSizeNotificationIfNeeded): Do the request to the right process. * WebProcess/WebPage/ViewGestureGeometryCollector.cpp: (WebKit::ViewGestureGeometryCollector::setRenderTreeSizeNotificationThreshold): Ensure we send the notification even if we reached the threshold before it was requested. (WebKit::ViewGestureGeometryCollector::sendDidHitRenderTreeSizeThresholdIfNeeded): (WebKit::ViewGestureGeometryCollector::mainFrameDidLayout): * WebProcess/WebPage/ViewGestureGeometryCollector.h: (WebKit::ViewGestureGeometryCollector::setRenderTreeSizeNotificationThreshold): Deleted. 2019-01-28 Babak Shafiei Cherry-pick r240490. rdar://problem/47586864 WKWebView.goBack should reload if there is a safe browsing warning https://bugs.webkit.org/show_bug.cgi?id=193805 Reviewed by Geoff Garen. Source/WebKit: If a WKWebView is showing a safe browsing warning and the user clicks a back button in the app which calls WKWebView.goBack, the WKWebView is in a state where it has not navigated yet, so actually going back will appear to the user to go back twice. We can't just do nothing because the app is in a state where it is expecting a navigation to happen. Reloading achieves what the user expects and makes the app work like the app expects. * UIProcess/API/C/WKPage.cpp: (WKPageGoBack): * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView goBack]): * UIProcess/PageClient.h: (WebKit::PageClient::hasSafeBrowsingWarning const): * UIProcess/mac/PageClientImplMac.h: * UIProcess/mac/PageClientImplMac.mm: (WebKit::PageClientImpl::hasSafeBrowsingWarning const): Tools: * TestWebKitAPI/Tests/WebKitCocoa/SafeBrowsing.mm: (+[Simple3LookupContext sharedLookupContext]): (-[Simple3LookupContext lookUpURL:completionHandler:]): (-[WKWebViewGoBackNavigationDelegate webView:didFinishNavigation:]): (TEST): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240490 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-25 Alex Christensen WKWebView.goBack should reload if there is a safe browsing warning https://bugs.webkit.org/show_bug.cgi?id=193805 Reviewed by Geoff Garen. If a WKWebView is showing a safe browsing warning and the user clicks a back button in the app which calls WKWebView.goBack, the WKWebView is in a state where it has not navigated yet, so actually going back will appear to the user to go back twice. We can't just do nothing because the app is in a state where it is expecting a navigation to happen. Reloading achieves what the user expects and makes the app work like the app expects. * UIProcess/API/C/WKPage.cpp: (WKPageGoBack): * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView goBack]): * UIProcess/PageClient.h: (WebKit::PageClient::hasSafeBrowsingWarning const): * UIProcess/mac/PageClientImplMac.h: * UIProcess/mac/PageClientImplMac.mm: (WebKit::PageClientImpl::hasSafeBrowsingWarning const): 2019-01-28 Babak Shafiei Cherry-pick r240485. rdar://problem/47586895 Regression(PSON) cross-site provisional page is not canceled if a new same-site one is started https://bugs.webkit.org/show_bug.cgi?id=193788 Reviewed by Alex Christensen. Source/WebKit: When the page starts a new provisional load, make sure we cancel any pending one in the provisional process, as it would have happened in the first provisional load happened in the same process. Without this, we could have 2 parallel loads happening, one in the committed process and another in the provisional one, leading to assertion failures in debug. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared): Tools: Add API test coverage. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: (-[PSONNavigationDelegate webView:didStartProvisionalNavigation:]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240485 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-25 Chris Dumez Regression(PSON) cross-site provisional page is not canceled if a new same-site one is started https://bugs.webkit.org/show_bug.cgi?id=193788 Reviewed by Alex Christensen. When the page starts a new provisional load, make sure we cancel any pending one in the provisional process, as it would have happened in the first provisional load happened in the same process. Without this, we could have 2 parallel loads happening, one in the committed process and another in the provisional one, leading to assertion failures in debug. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared): 2019-01-28 Babak Shafiei Cherry-pick r240477. rdar://problem/47586845 Regression(PSON?) Crash under NavigationState::NavigationClient::decidePolicyForNavigationAction() https://bugs.webkit.org/show_bug.cgi?id=193779 Reviewed by Antti Koivisto. Source/WebKit: * UIProcess/Cocoa/NavigationState.mm: (WebKit::tryAppLink): (WebKit::NavigationState::NavigationClient::decidePolicyForNavigationAction): We were crashing when trying to get the URL of the main frame, which was sad because we never ended up using the main frame URL. Therefore, this patch drops the code in question. * UIProcess/ProvisionalPageProxy.cpp: (WebKit::ProvisionalPageProxy::decidePolicyForNavigationActionAsync): Add assertion to make sure that the DecidePolicyForNavigationActionAsync IPC it is getting from the process is related to its main frame. Tools: Add API test that quickly navigates forward to a previous process without waiting for it to suspend. I suspect the crash could have been happening due to receiving leftover IPC from the process' previous page when reconnecting the it for the forward navigation. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240477 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-25 Chris Dumez Regression(PSON?) Crash under NavigationState::NavigationClient::decidePolicyForNavigationAction() https://bugs.webkit.org/show_bug.cgi?id=193779 Reviewed by Antti Koivisto. * UIProcess/Cocoa/NavigationState.mm: (WebKit::tryAppLink): (WebKit::NavigationState::NavigationClient::decidePolicyForNavigationAction): We were crashing when trying to get the URL of the main frame, which was sad because we never ended up using the main frame URL. Therefore, this patch drops the code in question. * UIProcess/ProvisionalPageProxy.cpp: (WebKit::ProvisionalPageProxy::decidePolicyForNavigationActionAsync): Add assertion to make sure that the DecidePolicyForNavigationActionAsync IPC it is getting from the process is related to its main frame. 2019-01-28 Babak Shafiei Cherry-pick r240443. rdar://problem/47586900 [PSON] Flash on back navigation on Mac https://bugs.webkit.org/show_bug.cgi?id=193716 Reviewed by Chris Dumez. Source/WebKit: We close the page immediately if we fail to suspend. Layers disappear and we get a flash. * UIProcess/SuspendedPageProxy.cpp: (WebKit::SuspendedPageProxy::~SuspendedPageProxy): (WebKit::SuspendedPageProxy::close): Track closed state so we don't send the message twice, causing unhandled message errors in web process. (WebKit::SuspendedPageProxy::didProcessRequestToSuspend): Close the suspended page if the suspension fails. Skip this if we are using web process side compositing on Mac. * UIProcess/SuspendedPageProxy.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::enterAcceleratedCompositingMode): On Mac, close the failed SuspendedPageProxy when entering compositing mode. At this point we don't need it to keep layers alive. * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::closeFailedSuspendedPagesForPage): * UIProcess/WebProcessPool.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::suspendForProcessSwap): Don't close the page on suspension failure. This is now managed by the UI process. Tools: * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: Closing of the previous page is delayed so waiting for didFinishNavigation is not sufficient to guarantee we have received all the messages. Wait for them. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240443 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-24 Antti Koivisto [PSON] Flash on back navigation on Mac https://bugs.webkit.org/show_bug.cgi?id=193716 Reviewed by Chris Dumez. We close the page immediately if we fail to suspend. Layers disappear and we get a flash. * UIProcess/SuspendedPageProxy.cpp: (WebKit::SuspendedPageProxy::~SuspendedPageProxy): (WebKit::SuspendedPageProxy::close): Track closed state so we don't send the message twice, causing unhandled message errors in web process. (WebKit::SuspendedPageProxy::didProcessRequestToSuspend): Close the suspended page if the suspension fails. Skip this if we are using web process side compositing on Mac. * UIProcess/SuspendedPageProxy.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::enterAcceleratedCompositingMode): On Mac, close the failed SuspendedPageProxy when entering compositing mode. At this point we don't need it to keep layers alive. * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::closeFailedSuspendedPagesForPage): * UIProcess/WebProcessPool.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::suspendForProcessSwap): Don't close the page on suspension failure. This is now managed by the UI process. 2019-01-28 Babak Shafiei Cherry-pick r240442. rdar://problem/47586826 Regression(PSON) Back/Forward list items' URL sometimes gets replaced with the URL of a subframe https://bugs.webkit.org/show_bug.cgi?id=193761 Reviewed by Alex Christensen. Source/WebKit: When doing a history navigation cross-process, the UIProcess would first send the back/forward list items to the destination WebProcess via WebPage::updateBackForwardListForReattach(), then ask the process to navigate to the expected back/forward list item. WebPage::updateBackForwardListForReattach() would call restoreSessionInternal(), which would call toHistoryItem() on each BackForwardListItem. This may end up creating more than one HistoryItem for each BackForwardListItem because HistoryItems are part of a tree (each frame has its own list of history items). Note that BackForwardListItems and HistoryItem share a BackForwardItemIdentifier which is a (processIdentifier, itemIdentifier) pair. We normally generate the HistoryItem's identifier from inside its constructor like so: `{ Process::identifier(), generateObjectIdentifier() }` However, when calling updateBackForwardListForReattach() and constructing children HistoryItem, applyFrameState() would generate the identifier by itself and passing it to the HistoryItem constructor. Its genegates the ID the exact same way so this would in theory not be a problem. Unfortunately, both calls to generateObjectIdentifier() get inlined and both call sites end up with their own static counter to generate ids. As a result, we may end up with conflicts as HistoryItems for child frames (restored by restoreSessionInternal()) can end up with the same identifier as HistoryItems for top frames. This confusion would lead to the WebContent process sending the UIProcess bad information and the URL of subframes could end up as the WebBackForwardListItem's mainframe URL. * WebProcess/WebCoreSupport/SessionStateConversion.cpp: (WebKit::applyFrameState): Stop calling generateObjectIdentifier() explicitly and let the HistoryItem constructor take care of it. Calling generateObjectIdentifier() for the same type from different places is not safe due to inlining. Tools: Add API test coverage. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240442 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-24 Chris Dumez Regression(PSON) Back/Forward list items' URL sometimes gets replaced with the URL of a subframe https://bugs.webkit.org/show_bug.cgi?id=193761 Reviewed by Alex Christensen. When doing a history navigation cross-process, the UIProcess would first send the back/forward list items to the destination WebProcess via WebPage::updateBackForwardListForReattach(), then ask the process to navigate to the expected back/forward list item. WebPage::updateBackForwardListForReattach() would call restoreSessionInternal(), which would call toHistoryItem() on each BackForwardListItem. This may end up creating more than one HistoryItem for each BackForwardListItem because HistoryItems are part of a tree (each frame has its own list of history items). Note that BackForwardListItems and HistoryItem share a BackForwardItemIdentifier which is a (processIdentifier, itemIdentifier) pair. We normally generate the HistoryItem's identifier from inside its constructor like so: `{ Process::identifier(), generateObjectIdentifier() }` However, when calling updateBackForwardListForReattach() and constructing children HistoryItem, applyFrameState() would generate the identifier by itself and passing it to the HistoryItem constructor. Its genegates the ID the exact same way so this would in theory not be a problem. Unfortunately, both calls to generateObjectIdentifier() get inlined and both call sites end up with their own static counter to generate ids. As a result, we may end up with conflicts as HistoryItems for child frames (restored by restoreSessionInternal()) can end up with the same identifier as HistoryItems for top frames. This confusion would lead to the WebContent process sending the UIProcess bad information and the URL of subframes could end up as the WebBackForwardListItem's mainframe URL. * WebProcess/WebCoreSupport/SessionStateConversion.cpp: (WebKit::applyFrameState): Stop calling generateObjectIdentifier() explicitly and let the HistoryItem constructor take care of it. Calling generateObjectIdentifier() for the same type from different places is not safe due to inlining. 2019-01-24 Alan Coon Cherry-pick r240461. rdar://problem/47536283 [iOS] Silence MediaPlayer compile warnings https://bugs.webkit.org/show_bug.cgi?id=193780 Reviewed by Jer Noble. Source/WebCore/PAL: * pal/spi/ios/MediaPlayerSPI.h: Source/WebKit: * UIProcess/ios/forms/WKAirPlayRoutePicker.mm: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240461 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-24 Eric Carlson [iOS] Silence MediaPlayer compile warnings https://bugs.webkit.org/show_bug.cgi?id=193780 Reviewed by Jer Noble. * UIProcess/ios/forms/WKAirPlayRoutePicker.mm: 2019-01-23 Alan Coon Cherry-pick r240325. rdar://problem/47494727 Regression(r240178) Some API tests are crashing https://bugs.webkit.org/show_bug.cgi?id=193680 Reviewed by Alex Christensen. r240178 made sure that userScripts / scriptMessageHandlers / contentExtensions are always properly populated in the WebPageCreationParameters. This was needed in case we need to reconstruct the WebUserContentController on the WebProcess side. However, this caused a regression in the case we reuse a process where the WebUserContentController still exists (because it was kept alive, e.g. by the WebPageGroup). In that case, we would add duplicate entries to the existing WebUserContentController instance because its "add" methods did not have duplicate checks. To address the issue, this patch adds duplicate checks to the WebUserContentController "add" methods. * WebProcess/UserContent/WebUserContentController.cpp: (WebKit::WebUserContentController::addUserScriptMessageHandlerInternal): (WebKit::WebUserContentController::removeUserScriptMessageHandlerInternal): (WebKit::WebUserContentController::addUserScriptInternal): (WebKit::WebUserContentController::removeUserScriptInternal): (WebKit::WebUserContentController::addUserStyleSheetInternal): (WebKit::WebUserContentController::removeUserStyleSheetInternal): (WebKit::WebUserContentController::forEachUserMessageHandler const): * WebProcess/UserContent/WebUserContentController.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240325 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-22 Chris Dumez Regression(r240178) Some API tests are crashing https://bugs.webkit.org/show_bug.cgi?id=193680 Reviewed by Alex Christensen. r240178 made sure that userScripts / scriptMessageHandlers / contentExtensions are always properly populated in the WebPageCreationParameters. This was needed in case we need to reconstruct the WebUserContentController on the WebProcess side. However, this caused a regression in the case we reuse a process where the WebUserContentController still exists (because it was kept alive, e.g. by the WebPageGroup). In that case, we would add duplicate entries to the existing WebUserContentController instance because its "add" methods did not have duplicate checks. To address the issue, this patch adds duplicate checks to the WebUserContentController "add" methods. * WebProcess/UserContent/WebUserContentController.cpp: (WebKit::WebUserContentController::addUserScriptMessageHandlerInternal): (WebKit::WebUserContentController::removeUserScriptMessageHandlerInternal): (WebKit::WebUserContentController::addUserScriptInternal): (WebKit::WebUserContentController::removeUserScriptInternal): (WebKit::WebUserContentController::addUserStyleSheetInternal): (WebKit::WebUserContentController::removeUserStyleSheetInternal): (WebKit::WebUserContentController::forEachUserMessageHandler const): * WebProcess/UserContent/WebUserContentController.h: 2019-01-23 Alan Coon Cherry-pick r240298. rdar://problem/47494772 [iOS] Flash when swiping back to Google search result page https://bugs.webkit.org/show_bug.cgi?id=193668 Reviewed by Simon Fraser. If the google page is scrolled, there is sometimes a short flash. When restoring the page state we also restore exposedContentRect which is used to determine which part of the page to create layers for. Scroll position is restored by the UI process later so we rely on this to get the right layers for the initial view update. A viewport configuration update may sometimes trample over the restored exposedContentRect, moving it to top left. In this case the initial layer tree unfreeze commit may not have layers to cover the actual visible view position. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::didCommitLoad): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::restorePageState): Set a bit to indicate we have already restored the exposedContentRect. (WebKit::WebPage::viewportConfigurationChanged): Only reset exposedContentRect if wasn't already set by restorePageState. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240298 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-22 Antti Koivisto [iOS] Flash when swiping back to Google search result page https://bugs.webkit.org/show_bug.cgi?id=193668 Reviewed by Simon Fraser. If the google page is scrolled, there is sometimes a short flash. When restoring the page state we also restore exposedContentRect which is used to determine which part of the page to create layers for. Scroll position is restored by the UI process later so we rely on this to get the right layers for the initial view update. A viewport configuration update may sometimes trample over the restored exposedContentRect, moving it to top left. In this case the initial layer tree unfreeze commit may not have layers to cover the actual visible view position. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::didCommitLoad): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::restorePageState): Set a bit to indicate we have already restored the exposedContentRect. (WebKit::WebPage::viewportConfigurationChanged): Only reset exposedContentRect if wasn't already set by restorePageState. 2019-01-23 Alan Coon Cherry-pick r240178. rdar://problem/47494727 Regression(PSON) Content blockers are sometimes lost on back navigation cross-site https://bugs.webkit.org/show_bug.cgi?id=193588 Reviewed by Alex Christensen. Source/WebKit: When the WebPageProxy needs to create initialization parameters for its WebPage in the WebContent process, it calls WebProcessProxy::addWebUserContentControllerProxy() which calls WebUserContentControllerProxy::addProcess(). This last call is supposed to register the WebProcessProxy with the WebUserContentControllerProxy and adding the contentRuleLists to the WebPageCreationParameters. The issue is that if the WebUserContentControllerProxy already knows about this WebProcessProxy, it would return early and not populate the WebPageCreationParameters. In PSON world, when navigating back to a page that failed to enter page cache, we reuse the process where we previously loaded the page but re-create a new WebPage on the WebContent process site. When this happens, WebUserContentControllerProxy would not add the contentRuleLists to the WebPageCreationParameters and the new WebPage in the previously-suspended process would be missing them. * UIProcess/UserContent/WebUserContentControllerProxy.cpp: (WebKit::WebUserContentControllerProxy::addProcess): Tools: Add layout test coverage. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240178 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-18 Chris Dumez Regression(PSON) Content blockers are sometimes lost on back navigation cross-site https://bugs.webkit.org/show_bug.cgi?id=193588 Reviewed by Alex Christensen. When the WebPageProxy needs to create initialization parameters for its WebPage in the WebContent process, it calls WebProcessProxy::addWebUserContentControllerProxy() which calls WebUserContentControllerProxy::addProcess(). This last call is supposed to register the WebProcessProxy with the WebUserContentControllerProxy and adding the contentRuleLists to the WebPageCreationParameters. The issue is that if the WebUserContentControllerProxy already knows about this WebProcessProxy, it would return early and not populate the WebPageCreationParameters. In PSON world, when navigating back to a page that failed to enter page cache, we reuse the process where we previously loaded the page but re-create a new WebPage on the WebContent process site. When this happens, WebUserContentControllerProxy would not add the contentRuleLists to the WebPageCreationParameters and the new WebPage in the previously-suspended process would be missing them. * UIProcess/UserContent/WebUserContentControllerProxy.cpp: (WebKit::WebUserContentControllerProxy::addProcess): 2019-01-23 Alan Coon Cherry-pick r239994. rdar://problem/47295338 Add allow directive for MTLCompilerService.xpc to PluginProcess and WebContent https://bugs.webkit.org/show_bug.cgi?id=193453 Reviewed by Brent Fulgham. * PluginProcess/mac/com.apple.WebKit.plugin-common.sb.in: * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb: * WebProcess/com.apple.WebProcess.sb.in: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239994 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-15 Per Arne Vollan Add allow directive for MTLCompilerService.xpc to PluginProcess and WebContent https://bugs.webkit.org/show_bug.cgi?id=193453 Reviewed by Brent Fulgham. * PluginProcess/mac/com.apple.WebKit.plugin-common.sb.in: * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb: * WebProcess/com.apple.WebProcess.sb.in: 2019-01-23 Alan Coon Cherry-pick r239947. rdar://problem/47295371 Re-enable ability to build --cloop builds. https://bugs.webkit.org/show_bug.cgi?id=192955 Source/JavaScriptCore: Reviewed by Saam barati and Keith Miller. * Configurations/FeatureDefines.xcconfig: Source/WebCore: Reviewed by Saam barati and Keith Miller. * Configurations/FeatureDefines.xcconfig: Source/WebCore/PAL: Reviewed by Saam barati and Keith Miller. * Configurations/FeatureDefines.xcconfig: Source/WebKit: Reviewed by Saam barati and Keith Miller. * Configurations/FeatureDefines.xcconfig: Source/WebKitLegacy/mac: Reviewed by Saam barati and Keith Miller. * Configurations/FeatureDefines.xcconfig: Tools: Reviewed by Saam barati and Keith Miller. The --cloop build option was being ignored this whole time since r236381. This patch makes it possible to build CLoop builds again. * Scripts/build-jsc: * Scripts/webkitperl/FeatureList.pm: * TestWebKitAPI/Configurations/FeatureDefines.xcconfig: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239947 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-14 Mark Lam Re-enable ability to build --cloop builds. https://bugs.webkit.org/show_bug.cgi?id=192955 Reviewed by Saam barati and Keith Miller. * Configurations/FeatureDefines.xcconfig: 2019-01-23 Alan Coon Revert r239619. rdar://problem/47465051 2019-01-23 Kocsen Chung Cherry-pick r240010. rdar://problem/47457965 Cannot tab out of WKWebView on macOS https://bugs.webkit.org/show_bug.cgi?id=161448 Reviewed by Dean Jackson. Source/WebCore/PAL: * pal/spi/mac/NSViewSPI.h: * pal/spi/mac/NSWindowSPI.h: Move some SPI declarations in here from WebKitLegacy. Source/WebKit: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::takeFocus): If the UIDelegate doesn't implement takeFocus, provide a simple default implementation that just uses AppKit's key view loop to move the focus. * UIProcess/API/APIUIClient.h: (API::UIClient::takeFocus): * UIProcess/API/C/WKPage.cpp: (WKPageSetPageUIClient): * UIProcess/Cocoa/UIDelegate.h: * UIProcess/Cocoa/UIDelegate.mm: (WebKit::UIDelegate::UIClient::takeFocus): Make API::UIClient's takeFocus return a bool indicating whether the client implements it or not. * UIProcess/PageClient.h: * UIProcess/mac/PageClientImplMac.h: * UIProcess/mac/PageClientImplMac.mm: (WebKit::PageClientImpl::takeFocus): Plumb takeFocus to WebViewImpl. * UIProcess/Cocoa/WebViewImpl.h: * UIProcess/Cocoa/WebViewImpl.mm: (WebKit::WebViewImpl::takeFocus): Borrow the relevant portion of WebKitLegacy's implementation of takeFocus, shifting focus to the next/previous key view in the window. Source/WebKitLegacy/mac: * WebCoreSupport/WebChromeClient.mm: * WebView/WebView.mm: Make use of SPI headers. Tools: Add a test that tabbing into and out of WKWebView works correctly. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKitCocoa/CommandBackForward.mm: (WebKit2_CommandBackForwardTest::SetUp): (-[CommandBackForwardOffscreenWindow isKeyWindow]): Deleted. (-[CommandBackForwardOffscreenWindow isVisible]): Deleted. * TestWebKitAPI/Tests/WebKitCocoa/TabOutOfWebView.mm: Added. (-[FocusableView canBecomeKeyView]): (TEST): * TestWebKitAPI/mac/OffscreenWindow.h: Added. * TestWebKitAPI/mac/OffscreenWindow.mm: Added. (-[OffscreenWindow initWithSize:]): (-[OffscreenWindow isKeyWindow]): (-[OffscreenWindow isVisible]): * TestWebKitAPI/mac/PlatformWebViewMac.mm: (TestWebKitAPI::PlatformWebView::initialize): (-[ActiveOffscreenWindow isKeyWindow]): Deleted. (-[ActiveOffscreenWindow isVisible]): Deleted. Factor ActiveOffscreenWindow out into OffscreenWindow and share it. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240010 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-15 Tim Horton Cannot tab out of WKWebView on macOS https://bugs.webkit.org/show_bug.cgi?id=161448 Reviewed by Dean Jackson. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::takeFocus): If the UIDelegate doesn't implement takeFocus, provide a simple default implementation that just uses AppKit's key view loop to move the focus. * UIProcess/API/APIUIClient.h: (API::UIClient::takeFocus): * UIProcess/API/C/WKPage.cpp: (WKPageSetPageUIClient): * UIProcess/Cocoa/UIDelegate.h: * UIProcess/Cocoa/UIDelegate.mm: (WebKit::UIDelegate::UIClient::takeFocus): Make API::UIClient's takeFocus return a bool indicating whether the client implements it or not. * UIProcess/PageClient.h: * UIProcess/mac/PageClientImplMac.h: * UIProcess/mac/PageClientImplMac.mm: (WebKit::PageClientImpl::takeFocus): Plumb takeFocus to WebViewImpl. * UIProcess/Cocoa/WebViewImpl.h: * UIProcess/Cocoa/WebViewImpl.mm: (WebKit::WebViewImpl::takeFocus): Borrow the relevant portion of WebKitLegacy's implementation of takeFocus, shifting focus to the next/previous key view in the window. 2019-01-23 Alan Coon Cherry-pick r240161. rdar://problem/47458286 Regression(PSON) Scroll position is not always restored properly when navigating back https://bugs.webkit.org/show_bug.cgi?id=193578 Reviewed by Tim Horton. Source/WebKit: Fix issues causing the scroll position to not be restored at all (or incorrectly) when navigating back cross-site with PSON enabled. Also make sure that the swipe gesture snapshot really stays up until we've restored the scroll position. Note that even after those changes, I can still sometimes reproduce a white flash when swiping back to Google search results (scroll position being correct now). This is tracked by and happens even if I disable PSON entirely. * Shared/SessionState.cpp: (WebKit::FrameState::encode const): (WebKit::FrameState::decode): * Shared/SessionState.h: * WebProcess/WebCoreSupport/SessionStateConversion.cpp: (WebKit::toFrameState): (WebKit::applyFrameState): obscuredInsets is present on the HistoryItem in the WebProcess but was never passed to or stored by the UIProcess on the WebBackForwardListItem. obscuredInsets is needed to properly restore the scrollPosition (position was 70px off on my iPad without this). With PSON enabled, if you swipe back cross-process and the previous page was not put into PageCache, then the HistoryItem is gone on the WebProcess side. What happens is that the UIProcess sends its WebBackForwardListItem to the WebProcess, which restores the HistoryItem there, and then asks it to load it. The obscuredInsets was getting lost in the process since the UIProcess never knew about it. * UIProcess/Cocoa/ViewGestureController.cpp: (WebKit::ViewGestureController::didReachMainFrameLoadTerminalState): Drop logic that was causing the ViewGestureController to not wait for the scroll position to be restored before taking down the snapshot, when UI-side compositing is enabled. If you look at the comment above the code, you'll see that the code in question was meant to impact only the non-UI side compositing code path. As a matter of fact, when the code was reviewed at https://bugs.webkit.org/show_bug.cgi?id=151224, it was protected by a #if PLATFORM(MAC), before getting modified the wrong way before landing. In practice, we would have often restored the scroll position by the time the load is finished so it would not cause a flash in most cases. However, with PSON enabled and the layer tree freezing we do on process-swap, the first post-scroll restoration layer tree commit may now occur a little bit later and we would lose the race more often. * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::updateBackForwardItem): * UIProcess/WebProcessProxy.h: When adding PageCache support to PSON, we used to navigate the "suspended" page to about:blank. This would lead to unwanted WebProcessProxy::updateBackForwardItem() calls from the WebProcess which we wanted to ignore. We thus added logic to ignore updateBackForwardItem() IPC from the old WebProcess after a swap. The issue with this is that we sometimes miss/ignore legit updates to the HistoryItem from the old process, in particular with regards to the scroll position and the pageScaleFactor. So if you swiped and then quickly enough did a cross-site navigation, the UIProcess' WebBackForwardList would not get updated with the latest scroll position and we would thus fail to restore it later on. To address the issue, we now stop ignoring updates from the old WebProcess after a swap. This logic is no longer needed since we no longer navigate the old page to about:blank after a swap, we merely suspend it "in place". Tools: Add API test coverage. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240161 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-18 Chris Dumez Regression(PSON) Scroll position is not always restored properly when navigating back https://bugs.webkit.org/show_bug.cgi?id=193578 Reviewed by Tim Horton. Fix issues causing the scroll position to not be restored at all (or incorrectly) when navigating back cross-site with PSON enabled. Also make sure that the swipe gesture snapshot really stays up until we've restored the scroll position. Note that even after those changes, I can still sometimes reproduce a white flash when swiping back to Google search results (scroll position being correct now). This is tracked by and happens even if I disable PSON entirely. * Shared/SessionState.cpp: (WebKit::FrameState::encode const): (WebKit::FrameState::decode): * Shared/SessionState.h: * WebProcess/WebCoreSupport/SessionStateConversion.cpp: (WebKit::toFrameState): (WebKit::applyFrameState): obscuredInsets is present on the HistoryItem in the WebProcess but was never passed to or stored by the UIProcess on the WebBackForwardListItem. obscuredInsets is needed to properly restore the scrollPosition (position was 70px off on my iPad without this). With PSON enabled, if you swipe back cross-process and the previous page was not put into PageCache, then the HistoryItem is gone on the WebProcess side. What happens is that the UIProcess sends its WebBackForwardListItem to the WebProcess, which restores the HistoryItem there, and then asks it to load it. The obscuredInsets was getting lost in the process since the UIProcess never knew about it. * UIProcess/Cocoa/ViewGestureController.cpp: (WebKit::ViewGestureController::didReachMainFrameLoadTerminalState): Drop logic that was causing the ViewGestureController to not wait for the scroll position to be restored before taking down the snapshot, when UI-side compositing is enabled. If you look at the comment above the code, you'll see that the code in question was meant to impact only the non-UI side compositing code path. As a matter of fact, when the code was reviewed at https://bugs.webkit.org/show_bug.cgi?id=151224, it was protected by a #if PLATFORM(MAC), before getting modified the wrong way before landing. In practice, we would have often restored the scroll position by the time the load is finished so it would not cause a flash in most cases. However, with PSON enabled and the layer tree freezing we do on process-swap, the first post-scroll restoration layer tree commit may now occur a little bit later and we would lose the race more often. * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::updateBackForwardItem): * UIProcess/WebProcessProxy.h: When adding PageCache support to PSON, we used to navigate the "suspended" page to about:blank. This would lead to unwanted WebProcessProxy::updateBackForwardItem() calls from the WebProcess which we wanted to ignore. We thus added logic to ignore updateBackForwardItem() IPC from the old WebProcess after a swap. The issue with this is that we sometimes miss/ignore legit updates to the HistoryItem from the old process, in particular with regards to the scroll position and the pageScaleFactor. So if you swiped and then quickly enough did a cross-site navigation, the UIProcess' WebBackForwardList would not get updated with the latest scroll position and we would thus fail to restore it later on. To address the issue, we now stop ignoring updates from the old WebProcess after a swap. This logic is no longer needed since we no longer navigate the old page to about:blank after a swap, we merely suspend it "in place". 2019-01-23 Alan Coon Cherry-pick r240087. rdar://problem/47458394 Revert r239938 https://bugs.webkit.org/show_bug.cgi?id=193267 * Configurations/WebContent-iOS.entitlements: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240087 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-16 Alex Christensen Revert r239938 https://bugs.webkit.org/show_bug.cgi?id=193267 * Configurations/WebContent-iOS.entitlements: 2019-01-23 Alan Coon Cherry-pick r240045. rdar://problem/47458249 Frequent null-deref under TiledCoreAnimationDrawingArea::scaleViewToFitDocumentIfNeeded() https://bugs.webkit.org/show_bug.cgi?id=193468 Reviewed by Zalan Bujtas. * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm: (WebKit::TiledCoreAnimationDrawingArea::scaleViewToFitDocumentIfNeeded): Adjust the null-check a bit; Zalan pointed out that the layout could be responsible for the Frame/RenderView going away, so we should bail *after* layout, not before. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240045 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-16 Tim Horton Frequent null-deref under TiledCoreAnimationDrawingArea::scaleViewToFitDocumentIfNeeded() https://bugs.webkit.org/show_bug.cgi?id=193468 Reviewed by Zalan Bujtas. * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm: (WebKit::TiledCoreAnimationDrawingArea::scaleViewToFitDocumentIfNeeded): Adjust the null-check a bit; Zalan pointed out that the layout could be responsible for the Frame/RenderView going away, so we should bail *after* layout, not before. 2019-01-23 Alan Coon Cherry-pick r240016. rdar://problem/47458249 Frequent null-deref under TiledCoreAnimationDrawingArea::scaleViewToFitDocumentIfNeeded() https://bugs.webkit.org/show_bug.cgi?id=193468 Reviewed by Beth Dakin. * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm: (WebKit::TiledCoreAnimationDrawingArea::scaleViewToFitDocumentIfNeeded): I'm not sure why this got *worse*, but we should null-check RenderView. It's OK to bail from scaleViewToFitDocumentIfNeeded, we'll re-do it the next time we paint (which will surely happen if we gain a RenderView). git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240016 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-15 Tim Horton Frequent null-deref under TiledCoreAnimationDrawingArea::scaleViewToFitDocumentIfNeeded() https://bugs.webkit.org/show_bug.cgi?id=193468 Reviewed by Beth Dakin. * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm: (WebKit::TiledCoreAnimationDrawingArea::scaleViewToFitDocumentIfNeeded): I'm not sure why this got *worse*, but we should null-check RenderView. It's OK to bail from scaleViewToFitDocumentIfNeeded, we'll re-do it the next time we paint (which will surely happen if we gain a RenderView). 2019-01-22 Alan Coon Cherry-pick r240055. rdar://problem/47099573 Regression(r240046) Several API tests are crashing https://bugs.webkit.org/show_bug.cgi?id=193509 Reviewed by Geoffrey Garen. The crashes would happen because loadRequestShared() would take a WebProcessProxy& in parameter but then call reattachToWebProcess() if the page is not valid, which would replace m_process and invalidate our process reference. To address the issue, move the reattachToWebProcess() call to loadRequest(), before calling loadRequestShared(). Also, update *Shared() methods to take a Ref&& instead of a WebProcessProxy& in parameter. Since we call client delegates, we need to make sure our process stays alive. * UIProcess/ProvisionalPageProxy.cpp: (WebKit::ProvisionalPageProxy::loadData): (WebKit::ProvisionalPageProxy::loadRequest): (WebKit::ProvisionalPageProxy::didCreateMainFrame): (WebKit::ProvisionalPageProxy::didPerformClientRedirect): (WebKit::ProvisionalPageProxy::didStartProvisionalLoadForFrame): (WebKit::ProvisionalPageProxy::didFailProvisionalLoadForFrame): (WebKit::ProvisionalPageProxy::didNavigateWithNavigationData): (WebKit::ProvisionalPageProxy::didChangeProvisionalURLForFrame): (WebKit::ProvisionalPageProxy::decidePolicyForNavigationActionAsync): (WebKit::ProvisionalPageProxy::decidePolicyForResponse): (WebKit::ProvisionalPageProxy::startURLSchemeTask): (WebKit::ProvisionalPageProxy::backForwardGoToItem): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::loadRequest): (WebKit::WebPageProxy::loadRequestWithNavigationShared): (WebKit::WebPageProxy::loadData): (WebKit::WebPageProxy::loadDataWithNavigationShared): (WebKit::WebPageProxy::didPerformDragControllerAction): (WebKit::WebPageProxy::findPlugin): (WebKit::WebPageProxy::didCreateMainFrame): (WebKit::WebPageProxy::didCreateSubframe): (WebKit::WebPageProxy::didStartProvisionalLoadForFrame): (WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared): (WebKit::WebPageProxy::didReceiveServerRedirectForProvisionalLoadForFrame): (WebKit::WebPageProxy::didReceiveServerRedirectForProvisionalLoadForFrameShared): (WebKit::WebPageProxy::willPerformClientRedirectForFrame): (WebKit::WebPageProxy::didCancelClientRedirectForFrame): (WebKit::WebPageProxy::didChangeProvisionalURLForFrame): (WebKit::WebPageProxy::didChangeProvisionalURLForFrameShared): (WebKit::WebPageProxy::didFailProvisionalLoadForFrame): (WebKit::WebPageProxy::didFailProvisionalLoadForFrameShared): (WebKit::WebPageProxy::didCommitLoadForFrame): (WebKit::WebPageProxy::didFinishDocumentLoadForFrame): (WebKit::WebPageProxy::didFinishLoadForFrame): (WebKit::WebPageProxy::didFailLoadForFrame): (WebKit::WebPageProxy::didSameDocumentNavigationForFrame): (WebKit::WebPageProxy::didReceiveTitleForFrame): (WebKit::WebPageProxy::didFirstVisuallyNonEmptyLayoutForFrame): (WebKit::WebPageProxy::didDisplayInsecureContentForFrame): (WebKit::WebPageProxy::didRunInsecureContentForFrame): (WebKit::WebPageProxy::frameDidBecomeFrameSet): (WebKit::WebPageProxy::decidePolicyForNavigationActionAsync): (WebKit::WebPageProxy::decidePolicyForNavigationActionAsyncShared): (WebKit::WebPageProxy::decidePolicyForNavigationAction): (WebKit::WebPageProxy::decidePolicyForNavigationActionSync): (WebKit::WebPageProxy::decidePolicyForNewWindowAction): (WebKit::WebPageProxy::decidePolicyForResponse): (WebKit::WebPageProxy::decidePolicyForResponseShared): (WebKit::WebPageProxy::unableToImplementPolicy): (WebKit::WebPageProxy::willSubmitForm): (WebKit::WebPageProxy::didNavigateWithNavigationData): (WebKit::WebPageProxy::didNavigateWithNavigationDataShared): (WebKit::WebPageProxy::didPerformClientRedirect): (WebKit::WebPageProxy::didPerformClientRedirectShared): (WebKit::WebPageProxy::didPerformServerRedirect): (WebKit::WebPageProxy::didUpdateHistoryTitle): (WebKit::WebPageProxy::createNewPage): (WebKit::WebPageProxy::runJavaScriptAlert): (WebKit::WebPageProxy::runJavaScriptConfirm): (WebKit::WebPageProxy::runJavaScriptPrompt): (WebKit::WebPageProxy::unavailablePluginButtonClicked): (WebKit::WebPageProxy::runBeforeUnloadConfirmPanel): (WebKit::WebPageProxy::runOpenPanel): (WebKit::WebPageProxy::printFrame): (WebKit::WebPageProxy::backForwardGoToItem): (WebKit::WebPageProxy::backForwardGoToItemShared): (WebKit::WebPageProxy::learnWord): (WebKit::WebPageProxy::ignoreWord): (WebKit::WebPageProxy::didReceiveEvent): (WebKit::WebPageProxy::editingRangeCallback): (WebKit::WebPageProxy::rectForCharacterRangeCallback): (WebKit::WebPageProxy::focusedFrameChanged): (WebKit::WebPageProxy::frameSetLargestFrameChanged): (WebKit::WebPageProxy::exceededDatabaseQuota): (WebKit::WebPageProxy::requestGeolocationPermissionForFrame): (WebKit::WebPageProxy::requestUserMediaPermissionForFrame): (WebKit::WebPageProxy::enumerateMediaDevicesForFrame): (WebKit::WebPageProxy::startURLSchemeTask): (WebKit::WebPageProxy::startURLSchemeTaskShared): (WebKit::WebPageProxy::stopURLSchemeTask): (WebKit::WebPageProxy::loadSynchronousURLSchemeTask): * UIProcess/WebPageProxy.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240055 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-16 Chris Dumez Regression(r240046) Several API tests are crashing https://bugs.webkit.org/show_bug.cgi?id=193509 Reviewed by Geoffrey Garen. The crashes would happen because loadRequestShared() would take a WebProcessProxy& in parameter but then call reattachToWebProcess() if the page is not valid, which would replace m_process and invalidate our process reference. To address the issue, move the reattachToWebProcess() call to loadRequest(), before calling loadRequestShared(). Also, update *Shared() methods to take a Ref&& instead of a WebProcessProxy& in parameter. Since we call client delegates, we need to make sure our process stays alive. * UIProcess/ProvisionalPageProxy.cpp: (WebKit::ProvisionalPageProxy::loadData): (WebKit::ProvisionalPageProxy::loadRequest): (WebKit::ProvisionalPageProxy::didCreateMainFrame): (WebKit::ProvisionalPageProxy::didPerformClientRedirect): (WebKit::ProvisionalPageProxy::didStartProvisionalLoadForFrame): (WebKit::ProvisionalPageProxy::didFailProvisionalLoadForFrame): (WebKit::ProvisionalPageProxy::didNavigateWithNavigationData): (WebKit::ProvisionalPageProxy::didChangeProvisionalURLForFrame): (WebKit::ProvisionalPageProxy::decidePolicyForNavigationActionAsync): (WebKit::ProvisionalPageProxy::decidePolicyForResponse): (WebKit::ProvisionalPageProxy::startURLSchemeTask): (WebKit::ProvisionalPageProxy::backForwardGoToItem): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::loadRequest): (WebKit::WebPageProxy::loadRequestWithNavigationShared): (WebKit::WebPageProxy::loadData): (WebKit::WebPageProxy::loadDataWithNavigationShared): (WebKit::WebPageProxy::didPerformDragControllerAction): (WebKit::WebPageProxy::findPlugin): (WebKit::WebPageProxy::didCreateMainFrame): (WebKit::WebPageProxy::didCreateSubframe): (WebKit::WebPageProxy::didStartProvisionalLoadForFrame): (WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared): (WebKit::WebPageProxy::didReceiveServerRedirectForProvisionalLoadForFrame): (WebKit::WebPageProxy::didReceiveServerRedirectForProvisionalLoadForFrameShared): (WebKit::WebPageProxy::willPerformClientRedirectForFrame): (WebKit::WebPageProxy::didCancelClientRedirectForFrame): (WebKit::WebPageProxy::didChangeProvisionalURLForFrame): (WebKit::WebPageProxy::didChangeProvisionalURLForFrameShared): (WebKit::WebPageProxy::didFailProvisionalLoadForFrame): (WebKit::WebPageProxy::didFailProvisionalLoadForFrameShared): (WebKit::WebPageProxy::didCommitLoadForFrame): (WebKit::WebPageProxy::didFinishDocumentLoadForFrame): (WebKit::WebPageProxy::didFinishLoadForFrame): (WebKit::WebPageProxy::didFailLoadForFrame): (WebKit::WebPageProxy::didSameDocumentNavigationForFrame): (WebKit::WebPageProxy::didReceiveTitleForFrame): (WebKit::WebPageProxy::didFirstVisuallyNonEmptyLayoutForFrame): (WebKit::WebPageProxy::didDisplayInsecureContentForFrame): (WebKit::WebPageProxy::didRunInsecureContentForFrame): (WebKit::WebPageProxy::frameDidBecomeFrameSet): (WebKit::WebPageProxy::decidePolicyForNavigationActionAsync): (WebKit::WebPageProxy::decidePolicyForNavigationActionAsyncShared): (WebKit::WebPageProxy::decidePolicyForNavigationAction): (WebKit::WebPageProxy::decidePolicyForNavigationActionSync): (WebKit::WebPageProxy::decidePolicyForNewWindowAction): (WebKit::WebPageProxy::decidePolicyForResponse): (WebKit::WebPageProxy::decidePolicyForResponseShared): (WebKit::WebPageProxy::unableToImplementPolicy): (WebKit::WebPageProxy::willSubmitForm): (WebKit::WebPageProxy::didNavigateWithNavigationData): (WebKit::WebPageProxy::didNavigateWithNavigationDataShared): (WebKit::WebPageProxy::didPerformClientRedirect): (WebKit::WebPageProxy::didPerformClientRedirectShared): (WebKit::WebPageProxy::didPerformServerRedirect): (WebKit::WebPageProxy::didUpdateHistoryTitle): (WebKit::WebPageProxy::createNewPage): (WebKit::WebPageProxy::runJavaScriptAlert): (WebKit::WebPageProxy::runJavaScriptConfirm): (WebKit::WebPageProxy::runJavaScriptPrompt): (WebKit::WebPageProxy::unavailablePluginButtonClicked): (WebKit::WebPageProxy::runBeforeUnloadConfirmPanel): (WebKit::WebPageProxy::runOpenPanel): (WebKit::WebPageProxy::printFrame): (WebKit::WebPageProxy::backForwardGoToItem): (WebKit::WebPageProxy::backForwardGoToItemShared): (WebKit::WebPageProxy::learnWord): (WebKit::WebPageProxy::ignoreWord): (WebKit::WebPageProxy::didReceiveEvent): (WebKit::WebPageProxy::editingRangeCallback): (WebKit::WebPageProxy::rectForCharacterRangeCallback): (WebKit::WebPageProxy::focusedFrameChanged): (WebKit::WebPageProxy::frameSetLargestFrameChanged): (WebKit::WebPageProxy::exceededDatabaseQuota): (WebKit::WebPageProxy::requestGeolocationPermissionForFrame): (WebKit::WebPageProxy::requestUserMediaPermissionForFrame): (WebKit::WebPageProxy::enumerateMediaDevicesForFrame): (WebKit::WebPageProxy::startURLSchemeTask): (WebKit::WebPageProxy::startURLSchemeTaskShared): (WebKit::WebPageProxy::stopURLSchemeTask): (WebKit::WebPageProxy::loadSynchronousURLSchemeTask): * UIProcess/WebPageProxy.h: 2019-01-22 Alan Coon Cherry-pick r240046. rdar://problem/47099573 Regression(PSON) View becomes blank after click a cross-site download link https://bugs.webkit.org/show_bug.cgi?id=193361 Reviewed by Geoffrey Garen. Source/WebCore: * loader/FrameLoader.cpp: (WebCore::FrameLoader::commitProvisionalLoad): When restoring from PageCache, make sure we notify the client that the load was committed *before* we tell it that the navigation is complete. This would confuse the ProvisionalPageProxy logic in the UIProcess. Source/WebKit: The issue tracked by rdar://problem/47099573 is that a provisional load may get canceled (or converted into a download) *after* we've decided to process-swap. In such cases, the view should keep displaying the current site and it should still be interactive. However, with the previous PSON model, the view (pageProxy) would have already swapped to the new process and would end up displaying the initially empty document. To address the issue, this patch introduces the concept of a provisional load in the UIProcess, handled by a ProvisionalPageProxy which has its own privisional process. The WebPageProxy owns the ProvisionalPageProxy but we do not commit the provisional page until after the load was committed in the new process. This means that the view / WebPageProxy keeps using the old process and displays the current content until a load has committed in the provisional page. If no load commits in the provisional process (e.g. because the load is cancelled or converted into a download), then we merely destroy the ProvisionalPageProxy and terminate its process, without impacting the WebPageProxy. * Shared/WebPageCreationParameters.cpp: (WebKit::WebPageCreationParameters::encode const): (WebKit::WebPageCreationParameters::decode): * Shared/WebPageCreationParameters.h: Rename isSwapFromSuspended to isProcessSwap for clarity as we always want to delay attaching the drawing area in case of a process-swap, no matter what now that the previous process is kept alive until the provisional load is committed in the new process. * Shared/WebPolicyAction.h: Drop Suspend policy action. At decidePolicyForNavigationAction time, in case of process-swap, we now tell the previous process to simply ignore the load, while we create a ProvisionalPageProxy to do the new load in a new process. Suspension of the previous page in the old process, happens later, when a load is actually committed in the new process. * Sources.txt: Add new ProvisionalPageProxy file. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _killWebContentProcessAndResetState]): When calling _killWebContentProcessAndResetState on a WKWebView, kill both the current process and the provisional one, to maintain previous behavior in our API tests. * UIProcess/API/gtk/PageClientImpl.cpp: (WebKit::PageClientImpl::createDrawingAreaProxy): * UIProcess/API/gtk/PageClientImpl.h: * UIProcess/API/wpe/PageClientImpl.cpp: (WebKit::PageClientImpl::createDrawingAreaProxy): * UIProcess/API/wpe/PageClientImpl.h: * UIProcess/AcceleratedDrawingAreaProxy.cpp: (WebKit::AcceleratedDrawingAreaProxy::AcceleratedDrawingAreaProxy): (WebKit::AcceleratedDrawingAreaProxy::didUpdateBackingStoreState): (WebKit::AcceleratedDrawingAreaProxy::sendUpdateBackingStoreState): (WebKit::AcceleratedDrawingAreaProxy::waitForAndDispatchDidUpdateBackingStoreState): (WebKit::AcceleratedDrawingAreaProxy::setNativeSurfaceHandleForCompositing): (WebKit::AcceleratedDrawingAreaProxy::destroyNativeSurfaceHandleForCompositing): * UIProcess/AcceleratedDrawingAreaProxy.h: * UIProcess/Cocoa/WebViewImpl.h: * UIProcess/Cocoa/WebViewImpl.mm: (WebKit::WebViewImpl::createDrawingAreaProxy): * UIProcess/DrawingAreaProxy.cpp: (WebKit::DrawingAreaProxy::DrawingAreaProxy): (WebKit::DrawingAreaProxy::~DrawingAreaProxy): (WebKit::DrawingAreaProxy::viewExposedRectChangedTimerFired): * UIProcess/DrawingAreaProxy.h: (WebKit::DrawingAreaProxy::process): * UIProcess/DrawingAreaProxyImpl.cpp: (WebKit::DrawingAreaProxyImpl::DrawingAreaProxyImpl): (WebKit::DrawingAreaProxyImpl::update): * UIProcess/DrawingAreaProxyImpl.h: * UIProcess/PageClient.h: * UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h: * UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::RemoteLayerTreeDrawingAreaProxy): (WebKit::RemoteLayerTreeDrawingAreaProxy::~RemoteLayerTreeDrawingAreaProxy): (WebKit::RemoteLayerTreeDrawingAreaProxy::deviceScaleFactorDidChange): (WebKit::RemoteLayerTreeDrawingAreaProxy::sendUpdateGeometry): (WebKit::RemoteLayerTreeDrawingAreaProxy::acceleratedAnimationDidStart): (WebKit::RemoteLayerTreeDrawingAreaProxy::acceleratedAnimationDidEnd): (WebKit::RemoteLayerTreeDrawingAreaProxy::didRefreshDisplay): (WebKit::RemoteLayerTreeDrawingAreaProxy::waitForDidUpdateActivityState): (WebKit::RemoteLayerTreeDrawingAreaProxy::dispatchAfterEnsuringDrawing): * UIProcess/ios/PageClientImplIOS.h: * UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::createDrawingAreaProxy): * UIProcess/ios/WKContentView.h: * UIProcess/ios/WKContentView.mm: (-[WKContentView _createDrawingAreaProxy:]): * UIProcess/mac/PageClientImplMac.h: * UIProcess/mac/PageClientImplMac.mm: (WebKit::PageClientImpl::createDrawingAreaProxy): * UIProcess/mac/TiledCoreAnimationDrawingAreaProxy.h: * UIProcess/mac/TiledCoreAnimationDrawingAreaProxy.mm: (WebKit::TiledCoreAnimationDrawingAreaProxy::TiledCoreAnimationDrawingAreaProxy): (WebKit::TiledCoreAnimationDrawingAreaProxy::deviceScaleFactorDidChange): (WebKit::TiledCoreAnimationDrawingAreaProxy::colorSpaceDidChange): (WebKit::TiledCoreAnimationDrawingAreaProxy::waitForDidUpdateActivityState): (WebKit::TiledCoreAnimationDrawingAreaProxy::createFence): (WebKit::TiledCoreAnimationDrawingAreaProxy::sendUpdateGeometry): (WebKit::TiledCoreAnimationDrawingAreaProxy::adjustTransientZoom): (WebKit::TiledCoreAnimationDrawingAreaProxy::commitTransientZoom): (WebKit::TiledCoreAnimationDrawingAreaProxy::dispatchAfterEnsuringDrawing): * UIProcess/mac/WebPageProxyMac.mm: * UIProcess/win/PageClientImpl.cpp: (WebKit::PageClientImpl::createDrawingAreaProxy): * UIProcess/win/PageClientImpl.h: * UIProcess/win/PageClientImpl.cpp: (WebKit::PageClientImpl::createDrawingAreaProxy): * UIProcess/win/PageClientImpl.h: * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm: (WebKit::TiledCoreAnimationDrawingArea::TiledCoreAnimationDrawingArea): Pass the drawing area's associated process when constructing it and store it as a member in addition to the page. This is necessary now that a page can be associated with 2 WebProcesses at a time, each having its own drawing area. * UIProcess/Cocoa/WebPageProxyCocoa.mm: (WebKit::WebPageProxy::createSandboxExtensionsIfNeeded): Pass the process. * UIProcess/ProvisionalPageProxy.cpp: Added. (WebKit::ProvisionalPageProxy::ProvisionalPageProxy): (WebKit::ProvisionalPageProxy::~ProvisionalPageProxy): (WebKit::ProvisionalPageProxy::processDidTerminate): (WebKit::ProvisionalPageProxy::takeDrawingArea): (WebKit::ProvisionalPageProxy::cancel): (WebKit::ProvisionalPageProxy::processDidFinishLaunching): (WebKit::ProvisionalPageProxy::finishInitializingWebPageAfterProcessLaunch): (WebKit::ProvisionalPageProxy::initializeWebPage): (WebKit::ProvisionalPageProxy::loadData): (WebKit::ProvisionalPageProxy::loadRequest): (WebKit::ProvisionalPageProxy::goToBackForwardItem): (WebKit::ProvisionalPageProxy::didCreateMainFrame): (WebKit::ProvisionalPageProxy::didPerformClientRedirect): (WebKit::ProvisionalPageProxy::didStartProvisionalLoadForFrame): (WebKit::ProvisionalPageProxy::didFailProvisionalLoadForFrame): (WebKit::ProvisionalPageProxy::didCommitLoadForFrame): (WebKit::ProvisionalPageProxy::didNavigateWithNavigationData): (WebKit::ProvisionalPageProxy::didChangeProvisionalURLForFrame): (WebKit::ProvisionalPageProxy::decidePolicyForNavigationActionAsync): (WebKit::ProvisionalPageProxy::decidePolicyForResponse): (WebKit::ProvisionalPageProxy::startURLSchemeTask): (WebKit::ProvisionalPageProxy::backForwardGoToItem): (WebKit::ProvisionalPageProxy::didReceiveMessage): (WebKit::ProvisionalPageProxy::didReceiveSyncMessage): * UIProcess/ProvisionalPageProxy.h: Added. (WebKit::ProvisionalPageProxy::page): (WebKit::ProvisionalPageProxy::mainFrame const): (WebKit::ProvisionalPageProxy::process): (WebKit::ProvisionalPageProxy::processSwapRequestedByClient const): (WebKit::ProvisionalPageProxy::navigationID const): (WebKit::ProvisionalPageProxy::drawingArea const): New WebPageProxy-like class which is owned by the WebPageProxy and proxies IPC from the provisional process. * UIProcess/SuspendedPageProxy.cpp: (WebKit::SuspendedPageProxy::~SuspendedPageProxy): (WebKit::SuspendedPageProxy::unsuspend): (WebKit::SuspendedPageProxy::didProcessRequestToSuspend): Unregister the SuspendedPageProxy as an IPC message receiver a little bit earlier when we're going to unsuspend it. This avoids conflicting with the ProvisionalPageProxy which tries to register itself as an IPC message receiver for the same pageID when a process-swap occurs and we're switching to a suspended page. * UIProcess/WebFrameProxy.cpp: (WebKit::WebFrameProxy::isMainFrame const): WebFrameProxy::isMainFrame() relies on checking that the frame is the WebPageProxy's m_mainFrame. Now that the WebPageProxy can have a ProvisionalPageProxy, also check if it is the ProvisionalPageProxy's m_mainFrame to maintain previous behavior. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::provisionalDrawingArea const): Add getter for the provisional drawing area. We normally only deal with the page's current drawing area, but the ViewGestureController needs access to the provisional once to display the swipe gesture snapshot. (WebKit::WebPageProxy::swapToWebProcess): swapToWebProcess() no longer takes care of unsuspending the SuspendedPage because we now call swapToWebProcess() later, when a load is actually committed in the provisional page / process. swapToWebProcess() now also needs to initialize some data members such as the drawing area and the main frame as it is transferring them over from the ProvisionalPageProxy which started the provisional load. (WebKit::WebPageProxy::finishAttachingToWebProcess): We no longer need IsSwapFromSuspended parameter as this is called later now, after a load has actually been committed in the provisional process. (WebKit::WebPageProxy::setDrawingArea): (WebKit::WebPageProxy::initializeWebPage): - We no longer need IsSwapFromSuspended parameter as this is called later now, after a load has actually been committed in the provisional process. - Factor some code out to WebPageProxy::setDrawingArea() so that it can be shared with swapToWebProcess(). (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle): (WebKit::WebPageProxy::loadRequest): (WebKit::WebPageProxy::loadRequestWithNavigationShared): Only call setPendingAPIRequestURL() in loadRequestWithNavigation() only if ShouldTreatAsContinuingLoad is not Yes. This avoids hitting some assertions as this was already called during the first API call if needed. (WebKit::WebPageProxy::loadData): (WebKit::WebPageProxy::loadDataWithNavigationShared): (WebKit::WebPageProxy::stopLoading): (WebKit::WebPageProxy::reload): (WebKit::WebPageProxy::didPerformDragControllerAction): (WebKit::WebPageProxy::findPlugin): (WebKit::WebPageProxy::receivedNavigationPolicyDecision): In case of process swap, tell the previous process to ignore the load instead of suspending it right away. Suspension now happens later, only if we end up committing the provisional load in the new process. Also discard the SuspendedPage if it failed to suspend (we only reuse its process in this case). This used to happen a bit later but it is clearer if we do this as early as possible I think. (WebKit::WebPageProxy::commitProvisionalPage): When the load is committed in the new process, we call WebPageProxy::commitProvisionalPage(). It takes care of: - Actually swapping the WebPageProxy to the new process by calling processDidTerminate() / swapToWebProcess(). - Suspending the current page. - Letting the client know the load is comitted - Destroy the ProvisionalPageProxy. This work used to happen earlier in continueNavigationInNewProcess(). (WebKit::WebPageProxy::continueNavigationInNewProcess): Moved some of the logic to commitProvisionalPage(). We now merely start the load in a new ProvisionalPageProxy, without actually having the WebPageProxy switch to the new process yet. (WebKit::WebPageProxy::didCreateMainFrame): (WebKit::WebPageProxy::didCreateSubframe): (WebKit::WebPageProxy::didCreateWindow): Drop some code that is no longer needed, now that the ProvisionalPageProxy takes care of this. (WebKit::WebPageProxy::didDestroyNavigation): On process-swap, when telling the previous process to ignore the load and starting the new load in a new ProvisionalPageProxy, the previous WebPage attempts to destroy the navigation. In this case, we ignore the call since the navigation is merely taken over by the ProvisionalPageProxy. (WebKit::WebPageProxy::didStartProvisionalLoadForFrame): (WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared): Moved some PSON logic to the ProvisionalPageProxy instead. (WebKit::WebPageProxy::didReceiveServerRedirectForProvisionalLoadForFrame): (WebKit::WebPageProxy::didReceiveServerRedirectForProvisionalLoadForFrameShared): (WebKit::WebPageProxy::willPerformClientRedirectForFrame): (WebKit::WebPageProxy::didCancelClientRedirectForFrame): (WebKit::WebPageProxy::didChangeProvisionalURLForFrame): (WebKit::WebPageProxy::didChangeProvisionalURLForFrameShared): (WebKit::WebPageProxy::didFailProvisionalLoadForFrame): (WebKit::WebPageProxy::didFailProvisionalLoadForFrameShared): When didFailProvisionalLoadForFrame() is called for a ProvisionalPageProxy, destroy it. (WebKit::WebPageProxy::didCommitLoadForFrame): (WebKit::WebPageProxy::didFinishDocumentLoadForFrame): (WebKit::WebPageProxy::didFinishLoadForFrame): (WebKit::WebPageProxy::didFailLoadForFrame): (WebKit::WebPageProxy::didSameDocumentNavigationForFrame): (WebKit::WebPageProxy::didReceiveTitleForFrame): (WebKit::WebPageProxy::didFirstVisuallyNonEmptyLayoutForFrame): (WebKit::WebPageProxy::didDisplayInsecureContentForFrame): (WebKit::WebPageProxy::didRunInsecureContentForFrame): (WebKit::WebPageProxy::frameDidBecomeFrameSet): (WebKit::WebPageProxy::decidePolicyForNavigationActionAsync): (WebKit::WebPageProxy::decidePolicyForNavigationActionAsyncShared): (WebKit::WebPageProxy::decidePolicyForNavigationAction): (WebKit::WebPageProxy::decidePolicyForNavigationActionSync): (WebKit::WebPageProxy::decidePolicyForNewWindowAction): (WebKit::WebPageProxy::decidePolicyForResponse): (WebKit::WebPageProxy::decidePolicyForResponseShared): (WebKit::WebPageProxy::unableToImplementPolicy): (WebKit::WebPageProxy::willSubmitForm): (WebKit::WebPageProxy::didNavigateWithNavigationData): (WebKit::WebPageProxy::didNavigateWithNavigationDataShared): (WebKit::WebPageProxy::didPerformClientRedirect): (WebKit::WebPageProxy::didPerformClientRedirectShared): (WebKit::WebPageProxy::didPerformServerRedirect): (WebKit::WebPageProxy::didUpdateHistoryTitle): (WebKit::WebPageProxy::createNewPage): (WebKit::WebPageProxy::runJavaScriptAlert): (WebKit::WebPageProxy::runJavaScriptConfirm): (WebKit::WebPageProxy::runJavaScriptPrompt): (WebKit::WebPageProxy::unavailablePluginButtonClicked): (WebKit::WebPageProxy::runBeforeUnloadConfirmPanel): (WebKit::WebPageProxy::runOpenPanel): (WebKit::WebPageProxy::printFrame): (WebKit::WebPageProxy::backForwardGoToItem): (WebKit::WebPageProxy::backForwardGoToItemShared): (WebKit::WebPageProxy::learnWord): (WebKit::WebPageProxy::ignoreWord): (WebKit::WebPageProxy::didReceiveEvent): (WebKit::WebPageProxy::editingRangeCallback): (WebKit::WebPageProxy::rectForCharacterRangeCallback): (WebKit::WebPageProxy::focusedFrameChanged): (WebKit::WebPageProxy::frameSetLargestFrameChanged): (WebKit::WebPageProxy::provisionalProcessDidTerminate): Cancel the provisiona load and destroy the ProvisionalPageProxy if the provisional process crashes. (WebKit::WebPageProxy::resetState): Drop some code that is no longer needed. (WebKit::WebPageProxy::creationParameters): - Move the hasRegisteredServiceWorkers flag initialization from the call site to here now that we have more than one call site. This was just some bad factoring. - Take the process in parameter now that we page can be associated with several processes at a time. (WebKit::WebPageProxy::exceededDatabaseQuota): (WebKit::WebPageProxy::requestGeolocationPermissionForFrame): (WebKit::WebPageProxy::requestUserMediaPermissionForFrame): (WebKit::WebPageProxy::enumerateMediaDevicesForFrame): (WebKit::WebPageProxy::startURLSchemeTask): (WebKit::WebPageProxy::startURLSchemeTaskShared): (WebKit::WebPageProxy::stopURLSchemeTask): (WebKit::WebPageProxy::loadSynchronousURLSchemeTask): (WebKit::WebPageProxy::checkURLReceivedFromCurrentOrPreviousWebProcess): (WebKit::WebPageProxy::willAcquireUniversalFileReadSandboxExtension): * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::visitedLinkStore): (WebKit::WebPageProxy::provisionalPageProxy const): * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::hasProvisionalPageWithID const): (WebKit::WebProcessProxy::updateBackForwardItem): (WebKit::WebProcessProxy::processDidTerminateOrFailedToLaunch): (WebKit::WebProcessProxy::didFinishLaunching): (WebKit::WebProcessProxy::canTerminateChildProcess): * UIProcess/WebProcessProxy.h: (WebKit::WebProcessProxy::addProvisionalPageProxy): (WebKit::WebProcessProxy::removeProvisionalPageProxy): Before updating a BackForwardListItem, we normally make sure the process has a WebPageProxy with the item's pageID. We have to tweak the logic because there may now be no WebPageProxy with this pageID associated with this process yet, because it is still a ProvisionalPageProxy. * UIProcess/WebURLSchemeHandler.cpp: (WebKit::WebURLSchemeHandler::startTask): * UIProcess/WebURLSchemeHandler.h: * UIProcess/WebURLSchemeTask.cpp: (WebKit::WebURLSchemeTask::create): (WebKit::WebURLSchemeTask::WebURLSchemeTask): (WebKit::WebURLSchemeTask::didPerformRedirection): (WebKit::WebURLSchemeTask::didReceiveResponse): (WebKit::WebURLSchemeTask::didReceiveData): (WebKit::WebURLSchemeTask::didComplete): (WebKit::WebURLSchemeTask::pageDestroyed): * UIProcess/WebURLSchemeTask.h: Pass the process when constructing a WebURLSchemeTask and store it as a data member in addition to the page. This is necessary now that a WebPageProxy can be associated with several WebProcesses. * UIProcess/ios/ViewGestureControllerIOS.mm: (WebKit::ViewGestureController::endSwipeGesture): Use the provisional drawing area to display the swipe snapshot as it may differ from the one currently associated with the page in case of process swap. * WebKit.xcodeproj/project.pbxproj: Add ProvisionalPageProxy class. * WebProcess/WebPage/WebFrame.cpp: (WebKit::toPolicyAction): (WebKit::WebFrame::didReceivePolicyDecision): * WebProcess/WebPage/WebPage.cpp: (WebKit::m_shouldAttachDrawingAreaOnPageTransition): (WebKit::WebPage::reinitializeWebPage): (WebKit::WebPage::didReceivePolicyDecision): Stop dealing with WebPolicyAction::Suspend as it no longer exists. (WebKit::WebPage::didCompletePageTransition): (WebKit::WebPage::setIsSuspended): Suspend the Page when setIsSuspended(true) is called, now that there is no longer a WebPolicyAction::Suspend. setIsSuspended(true) IPC is sent when we actually commit the provisional page. * WebProcess/WebPage/WebPage.h: Tools: Add API test coverage. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: (-[PSONNavigationDelegate webView:decidePolicyForNavigationResponse:decisionHandler:]): LayoutTests: Skip test testing the cross-process DOMWindow API as I broke it with this patch. The feature is far from ready and off by default anyway. I will add support back in a follow-up. * platform/wk2/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240046 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-16 Chris Dumez Regression(PSON) View becomes blank after click a cross-site download link https://bugs.webkit.org/show_bug.cgi?id=193361 Reviewed by Geoffrey Garen. The issue tracked by rdar://problem/47099573 is that a provisional load may get canceled (or converted into a download) *after* we've decided to process-swap. In such cases, the view should keep displaying the current site and it should still be interactive. However, with the previous PSON model, the view (pageProxy) would have already swapped to the new process and would end up displaying the initially empty document. To address the issue, this patch introduces the concept of a provisional load in the UIProcess, handled by a ProvisionalPageProxy which has its own privisional process. The WebPageProxy owns the ProvisionalPageProxy but we do not commit the provisional page until after the load was committed in the new process. This means that the view / WebPageProxy keeps using the old process and displays the current content until a load has committed in the provisional page. If no load commits in the provisional process (e.g. because the load is cancelled or converted into a download), then we merely destroy the ProvisionalPageProxy and terminate its process, without impacting the WebPageProxy. * Shared/WebPageCreationParameters.cpp: (WebKit::WebPageCreationParameters::encode const): (WebKit::WebPageCreationParameters::decode): * Shared/WebPageCreationParameters.h: Rename isSwapFromSuspended to isProcessSwap for clarity as we always want to delay attaching the drawing area in case of a process-swap, no matter what now that the previous process is kept alive until the provisional load is committed in the new process. * Shared/WebPolicyAction.h: Drop Suspend policy action. At decidePolicyForNavigationAction time, in case of process-swap, we now tell the previous process to simply ignore the load, while we create a ProvisionalPageProxy to do the new load in a new process. Suspension of the previous page in the old process, happens later, when a load is actually committed in the new process. * Sources.txt: Add new ProvisionalPageProxy file. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _killWebContentProcessAndResetState]): When calling _killWebContentProcessAndResetState on a WKWebView, kill both the current process and the provisional one, to maintain previous behavior in our API tests. * UIProcess/API/gtk/PageClientImpl.cpp: (WebKit::PageClientImpl::createDrawingAreaProxy): * UIProcess/API/gtk/PageClientImpl.h: * UIProcess/API/wpe/PageClientImpl.cpp: (WebKit::PageClientImpl::createDrawingAreaProxy): * UIProcess/API/wpe/PageClientImpl.h: * UIProcess/AcceleratedDrawingAreaProxy.cpp: (WebKit::AcceleratedDrawingAreaProxy::AcceleratedDrawingAreaProxy): (WebKit::AcceleratedDrawingAreaProxy::didUpdateBackingStoreState): (WebKit::AcceleratedDrawingAreaProxy::sendUpdateBackingStoreState): (WebKit::AcceleratedDrawingAreaProxy::waitForAndDispatchDidUpdateBackingStoreState): (WebKit::AcceleratedDrawingAreaProxy::setNativeSurfaceHandleForCompositing): (WebKit::AcceleratedDrawingAreaProxy::destroyNativeSurfaceHandleForCompositing): * UIProcess/AcceleratedDrawingAreaProxy.h: * UIProcess/Cocoa/WebViewImpl.h: * UIProcess/Cocoa/WebViewImpl.mm: (WebKit::WebViewImpl::createDrawingAreaProxy): * UIProcess/DrawingAreaProxy.cpp: (WebKit::DrawingAreaProxy::DrawingAreaProxy): (WebKit::DrawingAreaProxy::~DrawingAreaProxy): (WebKit::DrawingAreaProxy::viewExposedRectChangedTimerFired): * UIProcess/DrawingAreaProxy.h: (WebKit::DrawingAreaProxy::process): * UIProcess/DrawingAreaProxyImpl.cpp: (WebKit::DrawingAreaProxyImpl::DrawingAreaProxyImpl): (WebKit::DrawingAreaProxyImpl::update): * UIProcess/DrawingAreaProxyImpl.h: * UIProcess/PageClient.h: * UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h: * UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::RemoteLayerTreeDrawingAreaProxy): (WebKit::RemoteLayerTreeDrawingAreaProxy::~RemoteLayerTreeDrawingAreaProxy): (WebKit::RemoteLayerTreeDrawingAreaProxy::deviceScaleFactorDidChange): (WebKit::RemoteLayerTreeDrawingAreaProxy::sendUpdateGeometry): (WebKit::RemoteLayerTreeDrawingAreaProxy::acceleratedAnimationDidStart): (WebKit::RemoteLayerTreeDrawingAreaProxy::acceleratedAnimationDidEnd): (WebKit::RemoteLayerTreeDrawingAreaProxy::didRefreshDisplay): (WebKit::RemoteLayerTreeDrawingAreaProxy::waitForDidUpdateActivityState): (WebKit::RemoteLayerTreeDrawingAreaProxy::dispatchAfterEnsuringDrawing): * UIProcess/ios/PageClientImplIOS.h: * UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::createDrawingAreaProxy): * UIProcess/ios/WKContentView.h: * UIProcess/ios/WKContentView.mm: (-[WKContentView _createDrawingAreaProxy:]): * UIProcess/mac/PageClientImplMac.h: * UIProcess/mac/PageClientImplMac.mm: (WebKit::PageClientImpl::createDrawingAreaProxy): * UIProcess/mac/TiledCoreAnimationDrawingAreaProxy.h: * UIProcess/mac/TiledCoreAnimationDrawingAreaProxy.mm: (WebKit::TiledCoreAnimationDrawingAreaProxy::TiledCoreAnimationDrawingAreaProxy): (WebKit::TiledCoreAnimationDrawingAreaProxy::deviceScaleFactorDidChange): (WebKit::TiledCoreAnimationDrawingAreaProxy::colorSpaceDidChange): (WebKit::TiledCoreAnimationDrawingAreaProxy::waitForDidUpdateActivityState): (WebKit::TiledCoreAnimationDrawingAreaProxy::createFence): (WebKit::TiledCoreAnimationDrawingAreaProxy::sendUpdateGeometry): (WebKit::TiledCoreAnimationDrawingAreaProxy::adjustTransientZoom): (WebKit::TiledCoreAnimationDrawingAreaProxy::commitTransientZoom): (WebKit::TiledCoreAnimationDrawingAreaProxy::dispatchAfterEnsuringDrawing): * UIProcess/mac/WebPageProxyMac.mm: * UIProcess/win/PageClientImpl.cpp: (WebKit::PageClientImpl::createDrawingAreaProxy): * UIProcess/win/PageClientImpl.h: * UIProcess/win/PageClientImpl.cpp: (WebKit::PageClientImpl::createDrawingAreaProxy): * UIProcess/win/PageClientImpl.h: * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm: (WebKit::TiledCoreAnimationDrawingArea::TiledCoreAnimationDrawingArea): Pass the drawing area's associated process when constructing it and store it as a member in addition to the page. This is necessary now that a page can be associated with 2 WebProcesses at a time, each having its own drawing area. * UIProcess/Cocoa/WebPageProxyCocoa.mm: (WebKit::WebPageProxy::createSandboxExtensionsIfNeeded): Pass the process. * UIProcess/ProvisionalPageProxy.cpp: Added. (WebKit::ProvisionalPageProxy::ProvisionalPageProxy): (WebKit::ProvisionalPageProxy::~ProvisionalPageProxy): (WebKit::ProvisionalPageProxy::processDidTerminate): (WebKit::ProvisionalPageProxy::takeDrawingArea): (WebKit::ProvisionalPageProxy::cancel): (WebKit::ProvisionalPageProxy::processDidFinishLaunching): (WebKit::ProvisionalPageProxy::finishInitializingWebPageAfterProcessLaunch): (WebKit::ProvisionalPageProxy::initializeWebPage): (WebKit::ProvisionalPageProxy::loadData): (WebKit::ProvisionalPageProxy::loadRequest): (WebKit::ProvisionalPageProxy::goToBackForwardItem): (WebKit::ProvisionalPageProxy::didCreateMainFrame): (WebKit::ProvisionalPageProxy::didPerformClientRedirect): (WebKit::ProvisionalPageProxy::didStartProvisionalLoadForFrame): (WebKit::ProvisionalPageProxy::didFailProvisionalLoadForFrame): (WebKit::ProvisionalPageProxy::didCommitLoadForFrame): (WebKit::ProvisionalPageProxy::didNavigateWithNavigationData): (WebKit::ProvisionalPageProxy::didChangeProvisionalURLForFrame): (WebKit::ProvisionalPageProxy::decidePolicyForNavigationActionAsync): (WebKit::ProvisionalPageProxy::decidePolicyForResponse): (WebKit::ProvisionalPageProxy::startURLSchemeTask): (WebKit::ProvisionalPageProxy::backForwardGoToItem): (WebKit::ProvisionalPageProxy::didReceiveMessage): (WebKit::ProvisionalPageProxy::didReceiveSyncMessage): * UIProcess/ProvisionalPageProxy.h: Added. (WebKit::ProvisionalPageProxy::page): (WebKit::ProvisionalPageProxy::mainFrame const): (WebKit::ProvisionalPageProxy::process): (WebKit::ProvisionalPageProxy::processSwapRequestedByClient const): (WebKit::ProvisionalPageProxy::navigationID const): (WebKit::ProvisionalPageProxy::drawingArea const): New WebPageProxy-like class which is owned by the WebPageProxy and proxies IPC from the provisional process. * UIProcess/SuspendedPageProxy.cpp: (WebKit::SuspendedPageProxy::~SuspendedPageProxy): (WebKit::SuspendedPageProxy::unsuspend): (WebKit::SuspendedPageProxy::didProcessRequestToSuspend): Unregister the SuspendedPageProxy as an IPC message receiver a little bit earlier when we're going to unsuspend it. This avoids conflicting with the ProvisionalPageProxy which tries to register itself as an IPC message receiver for the same pageID when a process-swap occurs and we're switching to a suspended page. * UIProcess/WebFrameProxy.cpp: (WebKit::WebFrameProxy::isMainFrame const): WebFrameProxy::isMainFrame() relies on checking that the frame is the WebPageProxy's m_mainFrame. Now that the WebPageProxy can have a ProvisionalPageProxy, also check if it is the ProvisionalPageProxy's m_mainFrame to maintain previous behavior. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::provisionalDrawingArea const): Add getter for the provisional drawing area. We normally only deal with the page's current drawing area, but the ViewGestureController needs access to the provisional once to display the swipe gesture snapshot. (WebKit::WebPageProxy::swapToWebProcess): swapToWebProcess() no longer takes care of unsuspending the SuspendedPage because we now call swapToWebProcess() later, when a load is actually committed in the provisional page / process. swapToWebProcess() now also needs to initialize some data members such as the drawing area and the main frame as it is transferring them over from the ProvisionalPageProxy which started the provisional load. (WebKit::WebPageProxy::finishAttachingToWebProcess): We no longer need IsSwapFromSuspended parameter as this is called later now, after a load has actually been committed in the provisional process. (WebKit::WebPageProxy::setDrawingArea): (WebKit::WebPageProxy::initializeWebPage): - We no longer need IsSwapFromSuspended parameter as this is called later now, after a load has actually been committed in the provisional process. - Factor some code out to WebPageProxy::setDrawingArea() so that it can be shared with swapToWebProcess(). (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle): (WebKit::WebPageProxy::loadRequest): (WebKit::WebPageProxy::loadRequestWithNavigationShared): Only call setPendingAPIRequestURL() in loadRequestWithNavigation() only if ShouldTreatAsContinuingLoad is not Yes. This avoids hitting some assertions as this was already called during the first API call if needed. (WebKit::WebPageProxy::loadData): (WebKit::WebPageProxy::loadDataWithNavigationShared): (WebKit::WebPageProxy::stopLoading): (WebKit::WebPageProxy::reload): (WebKit::WebPageProxy::didPerformDragControllerAction): (WebKit::WebPageProxy::findPlugin): (WebKit::WebPageProxy::receivedNavigationPolicyDecision): In case of process swap, tell the previous process to ignore the load instead of suspending it right away. Suspension now happens later, only if we end up committing the provisional load in the new process. Also discard the SuspendedPage if it failed to suspend (we only reuse its process in this case). This used to happen a bit later but it is clearer if we do this as early as possible I think. (WebKit::WebPageProxy::commitProvisionalPage): When the load is committed in the new process, we call WebPageProxy::commitProvisionalPage(). It takes care of: - Actually swapping the WebPageProxy to the new process by calling processDidTerminate() / swapToWebProcess(). - Suspending the current page. - Letting the client know the load is comitted - Destroy the ProvisionalPageProxy. This work used to happen earlier in continueNavigationInNewProcess(). (WebKit::WebPageProxy::continueNavigationInNewProcess): Moved some of the logic to commitProvisionalPage(). We now merely start the load in a new ProvisionalPageProxy, without actually having the WebPageProxy switch to the new process yet. (WebKit::WebPageProxy::didCreateMainFrame): (WebKit::WebPageProxy::didCreateSubframe): (WebKit::WebPageProxy::didCreateWindow): Drop some code that is no longer needed, now that the ProvisionalPageProxy takes care of this. (WebKit::WebPageProxy::didDestroyNavigation): On process-swap, when telling the previous process to ignore the load and starting the new load in a new ProvisionalPageProxy, the previous WebPage attempts to destroy the navigation. In this case, we ignore the call since the navigation is merely taken over by the ProvisionalPageProxy. (WebKit::WebPageProxy::didStartProvisionalLoadForFrame): (WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared): Moved some PSON logic to the ProvisionalPageProxy instead. (WebKit::WebPageProxy::didReceiveServerRedirectForProvisionalLoadForFrame): (WebKit::WebPageProxy::didReceiveServerRedirectForProvisionalLoadForFrameShared): (WebKit::WebPageProxy::willPerformClientRedirectForFrame): (WebKit::WebPageProxy::didCancelClientRedirectForFrame): (WebKit::WebPageProxy::didChangeProvisionalURLForFrame): (WebKit::WebPageProxy::didChangeProvisionalURLForFrameShared): (WebKit::WebPageProxy::didFailProvisionalLoadForFrame): (WebKit::WebPageProxy::didFailProvisionalLoadForFrameShared): When didFailProvisionalLoadForFrame() is called for a ProvisionalPageProxy, destroy it. (WebKit::WebPageProxy::didCommitLoadForFrame): (WebKit::WebPageProxy::didFinishDocumentLoadForFrame): (WebKit::WebPageProxy::didFinishLoadForFrame): (WebKit::WebPageProxy::didFailLoadForFrame): (WebKit::WebPageProxy::didSameDocumentNavigationForFrame): (WebKit::WebPageProxy::didReceiveTitleForFrame): (WebKit::WebPageProxy::didFirstVisuallyNonEmptyLayoutForFrame): (WebKit::WebPageProxy::didDisplayInsecureContentForFrame): (WebKit::WebPageProxy::didRunInsecureContentForFrame): (WebKit::WebPageProxy::frameDidBecomeFrameSet): (WebKit::WebPageProxy::decidePolicyForNavigationActionAsync): (WebKit::WebPageProxy::decidePolicyForNavigationActionAsyncShared): (WebKit::WebPageProxy::decidePolicyForNavigationAction): (WebKit::WebPageProxy::decidePolicyForNavigationActionSync): (WebKit::WebPageProxy::decidePolicyForNewWindowAction): (WebKit::WebPageProxy::decidePolicyForResponse): (WebKit::WebPageProxy::decidePolicyForResponseShared): (WebKit::WebPageProxy::unableToImplementPolicy): (WebKit::WebPageProxy::willSubmitForm): (WebKit::WebPageProxy::didNavigateWithNavigationData): (WebKit::WebPageProxy::didNavigateWithNavigationDataShared): (WebKit::WebPageProxy::didPerformClientRedirect): (WebKit::WebPageProxy::didPerformClientRedirectShared): (WebKit::WebPageProxy::didPerformServerRedirect): (WebKit::WebPageProxy::didUpdateHistoryTitle): (WebKit::WebPageProxy::createNewPage): (WebKit::WebPageProxy::runJavaScriptAlert): (WebKit::WebPageProxy::runJavaScriptConfirm): (WebKit::WebPageProxy::runJavaScriptPrompt): (WebKit::WebPageProxy::unavailablePluginButtonClicked): (WebKit::WebPageProxy::runBeforeUnloadConfirmPanel): (WebKit::WebPageProxy::runOpenPanel): (WebKit::WebPageProxy::printFrame): (WebKit::WebPageProxy::backForwardGoToItem): (WebKit::WebPageProxy::backForwardGoToItemShared): (WebKit::WebPageProxy::learnWord): (WebKit::WebPageProxy::ignoreWord): (WebKit::WebPageProxy::didReceiveEvent): (WebKit::WebPageProxy::editingRangeCallback): (WebKit::WebPageProxy::rectForCharacterRangeCallback): (WebKit::WebPageProxy::focusedFrameChanged): (WebKit::WebPageProxy::frameSetLargestFrameChanged): (WebKit::WebPageProxy::provisionalProcessDidTerminate): Cancel the provisiona load and destroy the ProvisionalPageProxy if the provisional process crashes. (WebKit::WebPageProxy::resetState): Drop some code that is no longer needed. (WebKit::WebPageProxy::creationParameters): - Move the hasRegisteredServiceWorkers flag initialization from the call site to here now that we have more than one call site. This was just some bad factoring. - Take the process in parameter now that we page can be associated with several processes at a time. (WebKit::WebPageProxy::exceededDatabaseQuota): (WebKit::WebPageProxy::requestGeolocationPermissionForFrame): (WebKit::WebPageProxy::requestUserMediaPermissionForFrame): (WebKit::WebPageProxy::enumerateMediaDevicesForFrame): (WebKit::WebPageProxy::startURLSchemeTask): (WebKit::WebPageProxy::startURLSchemeTaskShared): (WebKit::WebPageProxy::stopURLSchemeTask): (WebKit::WebPageProxy::loadSynchronousURLSchemeTask): (WebKit::WebPageProxy::checkURLReceivedFromCurrentOrPreviousWebProcess): (WebKit::WebPageProxy::willAcquireUniversalFileReadSandboxExtension): * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::visitedLinkStore): (WebKit::WebPageProxy::provisionalPageProxy const): * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::hasProvisionalPageWithID const): (WebKit::WebProcessProxy::updateBackForwardItem): (WebKit::WebProcessProxy::processDidTerminateOrFailedToLaunch): (WebKit::WebProcessProxy::didFinishLaunching): (WebKit::WebProcessProxy::canTerminateChildProcess): * UIProcess/WebProcessProxy.h: (WebKit::WebProcessProxy::addProvisionalPageProxy): (WebKit::WebProcessProxy::removeProvisionalPageProxy): Before updating a BackForwardListItem, we normally make sure the process has a WebPageProxy with the item's pageID. We have to tweak the logic because there may now be no WebPageProxy with this pageID associated with this process yet, because it is still a ProvisionalPageProxy. * UIProcess/WebURLSchemeHandler.cpp: (WebKit::WebURLSchemeHandler::startTask): * UIProcess/WebURLSchemeHandler.h: * UIProcess/WebURLSchemeTask.cpp: (WebKit::WebURLSchemeTask::create): (WebKit::WebURLSchemeTask::WebURLSchemeTask): (WebKit::WebURLSchemeTask::didPerformRedirection): (WebKit::WebURLSchemeTask::didReceiveResponse): (WebKit::WebURLSchemeTask::didReceiveData): (WebKit::WebURLSchemeTask::didComplete): (WebKit::WebURLSchemeTask::pageDestroyed): * UIProcess/WebURLSchemeTask.h: Pass the process when constructing a WebURLSchemeTask and store it as a data member in addition to the page. This is necessary now that a WebPageProxy can be associated with several WebProcesses. * UIProcess/ios/ViewGestureControllerIOS.mm: (WebKit::ViewGestureController::endSwipeGesture): Use the provisional drawing area to display the swipe snapshot as it may differ from the one currently associated with the page in case of process swap. * WebKit.xcodeproj/project.pbxproj: Add ProvisionalPageProxy class. * WebProcess/WebPage/WebFrame.cpp: (WebKit::toPolicyAction): (WebKit::WebFrame::didReceivePolicyDecision): * WebProcess/WebPage/WebPage.cpp: (WebKit::m_shouldAttachDrawingAreaOnPageTransition): (WebKit::WebPage::reinitializeWebPage): (WebKit::WebPage::didReceivePolicyDecision): Stop dealing with WebPolicyAction::Suspend as it no longer exists. (WebKit::WebPage::didCompletePageTransition): (WebKit::WebPage::setIsSuspended): Suspend the Page when setIsSuspended(true) is called, now that there is no longer a WebPolicyAction::Suspend. setIsSuspended(true) IPC is sent when we actually commit the provisional page. * WebProcess/WebPage/WebPage.h: 2019-01-22 Alan Coon Revert r240258. rdar://problem/47099573 2019-01-22 Alan Coon Revert r240259. rdar://problem/47099573 2019-01-22 Alan Coon Revert r240260. rdar://problem/47099573 2019-01-22 Alan Coon Revert r240262. rdar://problem/47099573 2019-01-22 Alan Coon Revert r240263. rdar://problem/47099573 2019-01-22 Alan Coon Revert r240264. rdar://problem/47099573 2019-01-22 Alan Coon Cherry-pick r240055. rdar://problem/47099573 Regression(r240046) Several API tests are crashing https://bugs.webkit.org/show_bug.cgi?id=193509 Reviewed by Geoffrey Garen. The crashes would happen because loadRequestShared() would take a WebProcessProxy& in parameter but then call reattachToWebProcess() if the page is not valid, which would replace m_process and invalidate our process reference. To address the issue, move the reattachToWebProcess() call to loadRequest(), before calling loadRequestShared(). Also, update *Shared() methods to take a Ref&& instead of a WebProcessProxy& in parameter. Since we call client delegates, we need to make sure our process stays alive. * UIProcess/ProvisionalPageProxy.cpp: (WebKit::ProvisionalPageProxy::loadData): (WebKit::ProvisionalPageProxy::loadRequest): (WebKit::ProvisionalPageProxy::didCreateMainFrame): (WebKit::ProvisionalPageProxy::didPerformClientRedirect): (WebKit::ProvisionalPageProxy::didStartProvisionalLoadForFrame): (WebKit::ProvisionalPageProxy::didFailProvisionalLoadForFrame): (WebKit::ProvisionalPageProxy::didNavigateWithNavigationData): (WebKit::ProvisionalPageProxy::didChangeProvisionalURLForFrame): (WebKit::ProvisionalPageProxy::decidePolicyForNavigationActionAsync): (WebKit::ProvisionalPageProxy::decidePolicyForResponse): (WebKit::ProvisionalPageProxy::startURLSchemeTask): (WebKit::ProvisionalPageProxy::backForwardGoToItem): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::loadRequest): (WebKit::WebPageProxy::loadRequestWithNavigationShared): (WebKit::WebPageProxy::loadData): (WebKit::WebPageProxy::loadDataWithNavigationShared): (WebKit::WebPageProxy::didPerformDragControllerAction): (WebKit::WebPageProxy::findPlugin): (WebKit::WebPageProxy::didCreateMainFrame): (WebKit::WebPageProxy::didCreateSubframe): (WebKit::WebPageProxy::didStartProvisionalLoadForFrame): (WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared): (WebKit::WebPageProxy::didReceiveServerRedirectForProvisionalLoadForFrame): (WebKit::WebPageProxy::didReceiveServerRedirectForProvisionalLoadForFrameShared): (WebKit::WebPageProxy::willPerformClientRedirectForFrame): (WebKit::WebPageProxy::didCancelClientRedirectForFrame): (WebKit::WebPageProxy::didChangeProvisionalURLForFrame): (WebKit::WebPageProxy::didChangeProvisionalURLForFrameShared): (WebKit::WebPageProxy::didFailProvisionalLoadForFrame): (WebKit::WebPageProxy::didFailProvisionalLoadForFrameShared): (WebKit::WebPageProxy::didCommitLoadForFrame): (WebKit::WebPageProxy::didFinishDocumentLoadForFrame): (WebKit::WebPageProxy::didFinishLoadForFrame): (WebKit::WebPageProxy::didFailLoadForFrame): (WebKit::WebPageProxy::didSameDocumentNavigationForFrame): (WebKit::WebPageProxy::didReceiveTitleForFrame): (WebKit::WebPageProxy::didFirstVisuallyNonEmptyLayoutForFrame): (WebKit::WebPageProxy::didDisplayInsecureContentForFrame): (WebKit::WebPageProxy::didRunInsecureContentForFrame): (WebKit::WebPageProxy::frameDidBecomeFrameSet): (WebKit::WebPageProxy::decidePolicyForNavigationActionAsync): (WebKit::WebPageProxy::decidePolicyForNavigationActionAsyncShared): (WebKit::WebPageProxy::decidePolicyForNavigationAction): (WebKit::WebPageProxy::decidePolicyForNavigationActionSync): (WebKit::WebPageProxy::decidePolicyForNewWindowAction): (WebKit::WebPageProxy::decidePolicyForResponse): (WebKit::WebPageProxy::decidePolicyForResponseShared): (WebKit::WebPageProxy::unableToImplementPolicy): (WebKit::WebPageProxy::willSubmitForm): (WebKit::WebPageProxy::didNavigateWithNavigationData): (WebKit::WebPageProxy::didNavigateWithNavigationDataShared): (WebKit::WebPageProxy::didPerformClientRedirect): (WebKit::WebPageProxy::didPerformClientRedirectShared): (WebKit::WebPageProxy::didPerformServerRedirect): (WebKit::WebPageProxy::didUpdateHistoryTitle): (WebKit::WebPageProxy::createNewPage): (WebKit::WebPageProxy::runJavaScriptAlert): (WebKit::WebPageProxy::runJavaScriptConfirm): (WebKit::WebPageProxy::runJavaScriptPrompt): (WebKit::WebPageProxy::unavailablePluginButtonClicked): (WebKit::WebPageProxy::runBeforeUnloadConfirmPanel): (WebKit::WebPageProxy::runOpenPanel): (WebKit::WebPageProxy::printFrame): (WebKit::WebPageProxy::backForwardGoToItem): (WebKit::WebPageProxy::backForwardGoToItemShared): (WebKit::WebPageProxy::learnWord): (WebKit::WebPageProxy::ignoreWord): (WebKit::WebPageProxy::didReceiveEvent): (WebKit::WebPageProxy::editingRangeCallback): (WebKit::WebPageProxy::rectForCharacterRangeCallback): (WebKit::WebPageProxy::focusedFrameChanged): (WebKit::WebPageProxy::frameSetLargestFrameChanged): (WebKit::WebPageProxy::exceededDatabaseQuota): (WebKit::WebPageProxy::requestGeolocationPermissionForFrame): (WebKit::WebPageProxy::requestUserMediaPermissionForFrame): (WebKit::WebPageProxy::enumerateMediaDevicesForFrame): (WebKit::WebPageProxy::startURLSchemeTask): (WebKit::WebPageProxy::startURLSchemeTaskShared): (WebKit::WebPageProxy::stopURLSchemeTask): (WebKit::WebPageProxy::loadSynchronousURLSchemeTask): * UIProcess/WebPageProxy.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240055 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-16 Chris Dumez Regression(r240046) Several API tests are crashing https://bugs.webkit.org/show_bug.cgi?id=193509 Reviewed by Geoffrey Garen. The crashes would happen because loadRequestShared() would take a WebProcessProxy& in parameter but then call reattachToWebProcess() if the page is not valid, which would replace m_process and invalidate our process reference. To address the issue, move the reattachToWebProcess() call to loadRequest(), before calling loadRequestShared(). Also, update *Shared() methods to take a Ref&& instead of a WebProcessProxy& in parameter. Since we call client delegates, we need to make sure our process stays alive. * UIProcess/ProvisionalPageProxy.cpp: (WebKit::ProvisionalPageProxy::loadData): (WebKit::ProvisionalPageProxy::loadRequest): (WebKit::ProvisionalPageProxy::didCreateMainFrame): (WebKit::ProvisionalPageProxy::didPerformClientRedirect): (WebKit::ProvisionalPageProxy::didStartProvisionalLoadForFrame): (WebKit::ProvisionalPageProxy::didFailProvisionalLoadForFrame): (WebKit::ProvisionalPageProxy::didNavigateWithNavigationData): (WebKit::ProvisionalPageProxy::didChangeProvisionalURLForFrame): (WebKit::ProvisionalPageProxy::decidePolicyForNavigationActionAsync): (WebKit::ProvisionalPageProxy::decidePolicyForResponse): (WebKit::ProvisionalPageProxy::startURLSchemeTask): (WebKit::ProvisionalPageProxy::backForwardGoToItem): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::loadRequest): (WebKit::WebPageProxy::loadRequestWithNavigationShared): (WebKit::WebPageProxy::loadData): (WebKit::WebPageProxy::loadDataWithNavigationShared): (WebKit::WebPageProxy::didPerformDragControllerAction): (WebKit::WebPageProxy::findPlugin): (WebKit::WebPageProxy::didCreateMainFrame): (WebKit::WebPageProxy::didCreateSubframe): (WebKit::WebPageProxy::didStartProvisionalLoadForFrame): (WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared): (WebKit::WebPageProxy::didReceiveServerRedirectForProvisionalLoadForFrame): (WebKit::WebPageProxy::didReceiveServerRedirectForProvisionalLoadForFrameShared): (WebKit::WebPageProxy::willPerformClientRedirectForFrame): (WebKit::WebPageProxy::didCancelClientRedirectForFrame): (WebKit::WebPageProxy::didChangeProvisionalURLForFrame): (WebKit::WebPageProxy::didChangeProvisionalURLForFrameShared): (WebKit::WebPageProxy::didFailProvisionalLoadForFrame): (WebKit::WebPageProxy::didFailProvisionalLoadForFrameShared): (WebKit::WebPageProxy::didCommitLoadForFrame): (WebKit::WebPageProxy::didFinishDocumentLoadForFrame): (WebKit::WebPageProxy::didFinishLoadForFrame): (WebKit::WebPageProxy::didFailLoadForFrame): (WebKit::WebPageProxy::didSameDocumentNavigationForFrame): (WebKit::WebPageProxy::didReceiveTitleForFrame): (WebKit::WebPageProxy::didFirstVisuallyNonEmptyLayoutForFrame): (WebKit::WebPageProxy::didDisplayInsecureContentForFrame): (WebKit::WebPageProxy::didRunInsecureContentForFrame): (WebKit::WebPageProxy::frameDidBecomeFrameSet): (WebKit::WebPageProxy::decidePolicyForNavigationActionAsync): (WebKit::WebPageProxy::decidePolicyForNavigationActionAsyncShared): (WebKit::WebPageProxy::decidePolicyForNavigationAction): (WebKit::WebPageProxy::decidePolicyForNavigationActionSync): (WebKit::WebPageProxy::decidePolicyForNewWindowAction): (WebKit::WebPageProxy::decidePolicyForResponse): (WebKit::WebPageProxy::decidePolicyForResponseShared): (WebKit::WebPageProxy::unableToImplementPolicy): (WebKit::WebPageProxy::willSubmitForm): (WebKit::WebPageProxy::didNavigateWithNavigationData): (WebKit::WebPageProxy::didNavigateWithNavigationDataShared): (WebKit::WebPageProxy::didPerformClientRedirect): (WebKit::WebPageProxy::didPerformClientRedirectShared): (WebKit::WebPageProxy::didPerformServerRedirect): (WebKit::WebPageProxy::didUpdateHistoryTitle): (WebKit::WebPageProxy::createNewPage): (WebKit::WebPageProxy::runJavaScriptAlert): (WebKit::WebPageProxy::runJavaScriptConfirm): (WebKit::WebPageProxy::runJavaScriptPrompt): (WebKit::WebPageProxy::unavailablePluginButtonClicked): (WebKit::WebPageProxy::runBeforeUnloadConfirmPanel): (WebKit::WebPageProxy::runOpenPanel): (WebKit::WebPageProxy::printFrame): (WebKit::WebPageProxy::backForwardGoToItem): (WebKit::WebPageProxy::backForwardGoToItemShared): (WebKit::WebPageProxy::learnWord): (WebKit::WebPageProxy::ignoreWord): (WebKit::WebPageProxy::didReceiveEvent): (WebKit::WebPageProxy::editingRangeCallback): (WebKit::WebPageProxy::rectForCharacterRangeCallback): (WebKit::WebPageProxy::focusedFrameChanged): (WebKit::WebPageProxy::frameSetLargestFrameChanged): (WebKit::WebPageProxy::exceededDatabaseQuota): (WebKit::WebPageProxy::requestGeolocationPermissionForFrame): (WebKit::WebPageProxy::requestUserMediaPermissionForFrame): (WebKit::WebPageProxy::enumerateMediaDevicesForFrame): (WebKit::WebPageProxy::startURLSchemeTask): (WebKit::WebPageProxy::startURLSchemeTaskShared): (WebKit::WebPageProxy::stopURLSchemeTask): (WebKit::WebPageProxy::loadSynchronousURLSchemeTask): * UIProcess/WebPageProxy.h: 2019-01-22 Alan Coon Cherry-pick r240046. rdar://problem/47099573 Regression(PSON) View becomes blank after click a cross-site download link https://bugs.webkit.org/show_bug.cgi?id=193361 Reviewed by Geoffrey Garen. Source/WebCore: * loader/FrameLoader.cpp: (WebCore::FrameLoader::commitProvisionalLoad): When restoring from PageCache, make sure we notify the client that the load was committed *before* we tell it that the navigation is complete. This would confuse the ProvisionalPageProxy logic in the UIProcess. Source/WebKit: The issue tracked by rdar://problem/47099573 is that a provisional load may get canceled (or converted into a download) *after* we've decided to process-swap. In such cases, the view should keep displaying the current site and it should still be interactive. However, with the previous PSON model, the view (pageProxy) would have already swapped to the new process and would end up displaying the initially empty document. To address the issue, this patch introduces the concept of a provisional load in the UIProcess, handled by a ProvisionalPageProxy which has its own privisional process. The WebPageProxy owns the ProvisionalPageProxy but we do not commit the provisional page until after the load was committed in the new process. This means that the view / WebPageProxy keeps using the old process and displays the current content until a load has committed in the provisional page. If no load commits in the provisional process (e.g. because the load is cancelled or converted into a download), then we merely destroy the ProvisionalPageProxy and terminate its process, without impacting the WebPageProxy. * Shared/WebPageCreationParameters.cpp: (WebKit::WebPageCreationParameters::encode const): (WebKit::WebPageCreationParameters::decode): * Shared/WebPageCreationParameters.h: Rename isSwapFromSuspended to isProcessSwap for clarity as we always want to delay attaching the drawing area in case of a process-swap, no matter what now that the previous process is kept alive until the provisional load is committed in the new process. * Shared/WebPolicyAction.h: Drop Suspend policy action. At decidePolicyForNavigationAction time, in case of process-swap, we now tell the previous process to simply ignore the load, while we create a ProvisionalPageProxy to do the new load in a new process. Suspension of the previous page in the old process, happens later, when a load is actually committed in the new process. * Sources.txt: Add new ProvisionalPageProxy file. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _killWebContentProcessAndResetState]): When calling _killWebContentProcessAndResetState on a WKWebView, kill both the current process and the provisional one, to maintain previous behavior in our API tests. * UIProcess/API/gtk/PageClientImpl.cpp: (WebKit::PageClientImpl::createDrawingAreaProxy): * UIProcess/API/gtk/PageClientImpl.h: * UIProcess/API/wpe/PageClientImpl.cpp: (WebKit::PageClientImpl::createDrawingAreaProxy): * UIProcess/API/wpe/PageClientImpl.h: * UIProcess/AcceleratedDrawingAreaProxy.cpp: (WebKit::AcceleratedDrawingAreaProxy::AcceleratedDrawingAreaProxy): (WebKit::AcceleratedDrawingAreaProxy::didUpdateBackingStoreState): (WebKit::AcceleratedDrawingAreaProxy::sendUpdateBackingStoreState): (WebKit::AcceleratedDrawingAreaProxy::waitForAndDispatchDidUpdateBackingStoreState): (WebKit::AcceleratedDrawingAreaProxy::setNativeSurfaceHandleForCompositing): (WebKit::AcceleratedDrawingAreaProxy::destroyNativeSurfaceHandleForCompositing): * UIProcess/AcceleratedDrawingAreaProxy.h: * UIProcess/Cocoa/WebViewImpl.h: * UIProcess/Cocoa/WebViewImpl.mm: (WebKit::WebViewImpl::createDrawingAreaProxy): * UIProcess/DrawingAreaProxy.cpp: (WebKit::DrawingAreaProxy::DrawingAreaProxy): (WebKit::DrawingAreaProxy::~DrawingAreaProxy): (WebKit::DrawingAreaProxy::viewExposedRectChangedTimerFired): * UIProcess/DrawingAreaProxy.h: (WebKit::DrawingAreaProxy::process): * UIProcess/DrawingAreaProxyImpl.cpp: (WebKit::DrawingAreaProxyImpl::DrawingAreaProxyImpl): (WebKit::DrawingAreaProxyImpl::update): * UIProcess/DrawingAreaProxyImpl.h: * UIProcess/PageClient.h: * UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h: * UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::RemoteLayerTreeDrawingAreaProxy): (WebKit::RemoteLayerTreeDrawingAreaProxy::~RemoteLayerTreeDrawingAreaProxy): (WebKit::RemoteLayerTreeDrawingAreaProxy::deviceScaleFactorDidChange): (WebKit::RemoteLayerTreeDrawingAreaProxy::sendUpdateGeometry): (WebKit::RemoteLayerTreeDrawingAreaProxy::acceleratedAnimationDidStart): (WebKit::RemoteLayerTreeDrawingAreaProxy::acceleratedAnimationDidEnd): (WebKit::RemoteLayerTreeDrawingAreaProxy::didRefreshDisplay): (WebKit::RemoteLayerTreeDrawingAreaProxy::waitForDidUpdateActivityState): (WebKit::RemoteLayerTreeDrawingAreaProxy::dispatchAfterEnsuringDrawing): * UIProcess/ios/PageClientImplIOS.h: * UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::createDrawingAreaProxy): * UIProcess/ios/WKContentView.h: * UIProcess/ios/WKContentView.mm: (-[WKContentView _createDrawingAreaProxy:]): * UIProcess/mac/PageClientImplMac.h: * UIProcess/mac/PageClientImplMac.mm: (WebKit::PageClientImpl::createDrawingAreaProxy): * UIProcess/mac/TiledCoreAnimationDrawingAreaProxy.h: * UIProcess/mac/TiledCoreAnimationDrawingAreaProxy.mm: (WebKit::TiledCoreAnimationDrawingAreaProxy::TiledCoreAnimationDrawingAreaProxy): (WebKit::TiledCoreAnimationDrawingAreaProxy::deviceScaleFactorDidChange): (WebKit::TiledCoreAnimationDrawingAreaProxy::colorSpaceDidChange): (WebKit::TiledCoreAnimationDrawingAreaProxy::waitForDidUpdateActivityState): (WebKit::TiledCoreAnimationDrawingAreaProxy::createFence): (WebKit::TiledCoreAnimationDrawingAreaProxy::sendUpdateGeometry): (WebKit::TiledCoreAnimationDrawingAreaProxy::adjustTransientZoom): (WebKit::TiledCoreAnimationDrawingAreaProxy::commitTransientZoom): (WebKit::TiledCoreAnimationDrawingAreaProxy::dispatchAfterEnsuringDrawing): * UIProcess/mac/WebPageProxyMac.mm: * UIProcess/win/PageClientImpl.cpp: (WebKit::PageClientImpl::createDrawingAreaProxy): * UIProcess/win/PageClientImpl.h: * UIProcess/win/PageClientImpl.cpp: (WebKit::PageClientImpl::createDrawingAreaProxy): * UIProcess/win/PageClientImpl.h: * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm: (WebKit::TiledCoreAnimationDrawingArea::TiledCoreAnimationDrawingArea): Pass the drawing area's associated process when constructing it and store it as a member in addition to the page. This is necessary now that a page can be associated with 2 WebProcesses at a time, each having its own drawing area. * UIProcess/Cocoa/WebPageProxyCocoa.mm: (WebKit::WebPageProxy::createSandboxExtensionsIfNeeded): Pass the process. * UIProcess/ProvisionalPageProxy.cpp: Added. (WebKit::ProvisionalPageProxy::ProvisionalPageProxy): (WebKit::ProvisionalPageProxy::~ProvisionalPageProxy): (WebKit::ProvisionalPageProxy::processDidTerminate): (WebKit::ProvisionalPageProxy::takeDrawingArea): (WebKit::ProvisionalPageProxy::cancel): (WebKit::ProvisionalPageProxy::processDidFinishLaunching): (WebKit::ProvisionalPageProxy::finishInitializingWebPageAfterProcessLaunch): (WebKit::ProvisionalPageProxy::initializeWebPage): (WebKit::ProvisionalPageProxy::loadData): (WebKit::ProvisionalPageProxy::loadRequest): (WebKit::ProvisionalPageProxy::goToBackForwardItem): (WebKit::ProvisionalPageProxy::didCreateMainFrame): (WebKit::ProvisionalPageProxy::didPerformClientRedirect): (WebKit::ProvisionalPageProxy::didStartProvisionalLoadForFrame): (WebKit::ProvisionalPageProxy::didFailProvisionalLoadForFrame): (WebKit::ProvisionalPageProxy::didCommitLoadForFrame): (WebKit::ProvisionalPageProxy::didNavigateWithNavigationData): (WebKit::ProvisionalPageProxy::didChangeProvisionalURLForFrame): (WebKit::ProvisionalPageProxy::decidePolicyForNavigationActionAsync): (WebKit::ProvisionalPageProxy::decidePolicyForResponse): (WebKit::ProvisionalPageProxy::startURLSchemeTask): (WebKit::ProvisionalPageProxy::backForwardGoToItem): (WebKit::ProvisionalPageProxy::didReceiveMessage): (WebKit::ProvisionalPageProxy::didReceiveSyncMessage): * UIProcess/ProvisionalPageProxy.h: Added. (WebKit::ProvisionalPageProxy::page): (WebKit::ProvisionalPageProxy::mainFrame const): (WebKit::ProvisionalPageProxy::process): (WebKit::ProvisionalPageProxy::processSwapRequestedByClient const): (WebKit::ProvisionalPageProxy::navigationID const): (WebKit::ProvisionalPageProxy::drawingArea const): New WebPageProxy-like class which is owned by the WebPageProxy and proxies IPC from the provisional process. * UIProcess/SuspendedPageProxy.cpp: (WebKit::SuspendedPageProxy::~SuspendedPageProxy): (WebKit::SuspendedPageProxy::unsuspend): (WebKit::SuspendedPageProxy::didProcessRequestToSuspend): Unregister the SuspendedPageProxy as an IPC message receiver a little bit earlier when we're going to unsuspend it. This avoids conflicting with the ProvisionalPageProxy which tries to register itself as an IPC message receiver for the same pageID when a process-swap occurs and we're switching to a suspended page. * UIProcess/WebFrameProxy.cpp: (WebKit::WebFrameProxy::isMainFrame const): WebFrameProxy::isMainFrame() relies on checking that the frame is the WebPageProxy's m_mainFrame. Now that the WebPageProxy can have a ProvisionalPageProxy, also check if it is the ProvisionalPageProxy's m_mainFrame to maintain previous behavior. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::provisionalDrawingArea const): Add getter for the provisional drawing area. We normally only deal with the page's current drawing area, but the ViewGestureController needs access to the provisional once to display the swipe gesture snapshot. (WebKit::WebPageProxy::swapToWebProcess): swapToWebProcess() no longer takes care of unsuspending the SuspendedPage because we now call swapToWebProcess() later, when a load is actually committed in the provisional page / process. swapToWebProcess() now also needs to initialize some data members such as the drawing area and the main frame as it is transferring them over from the ProvisionalPageProxy which started the provisional load. (WebKit::WebPageProxy::finishAttachingToWebProcess): We no longer need IsSwapFromSuspended parameter as this is called later now, after a load has actually been committed in the provisional process. (WebKit::WebPageProxy::setDrawingArea): (WebKit::WebPageProxy::initializeWebPage): - We no longer need IsSwapFromSuspended parameter as this is called later now, after a load has actually been committed in the provisional process. - Factor some code out to WebPageProxy::setDrawingArea() so that it can be shared with swapToWebProcess(). (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle): (WebKit::WebPageProxy::loadRequest): (WebKit::WebPageProxy::loadRequestWithNavigationShared): Only call setPendingAPIRequestURL() in loadRequestWithNavigation() only if ShouldTreatAsContinuingLoad is not Yes. This avoids hitting some assertions as this was already called during the first API call if needed. (WebKit::WebPageProxy::loadData): (WebKit::WebPageProxy::loadDataWithNavigationShared): (WebKit::WebPageProxy::stopLoading): (WebKit::WebPageProxy::reload): (WebKit::WebPageProxy::didPerformDragControllerAction): (WebKit::WebPageProxy::findPlugin): (WebKit::WebPageProxy::receivedNavigationPolicyDecision): In case of process swap, tell the previous process to ignore the load instead of suspending it right away. Suspension now happens later, only if we end up committing the provisional load in the new process. Also discard the SuspendedPage if it failed to suspend (we only reuse its process in this case). This used to happen a bit later but it is clearer if we do this as early as possible I think. (WebKit::WebPageProxy::commitProvisionalPage): When the load is committed in the new process, we call WebPageProxy::commitProvisionalPage(). It takes care of: - Actually swapping the WebPageProxy to the new process by calling processDidTerminate() / swapToWebProcess(). - Suspending the current page. - Letting the client know the load is comitted - Destroy the ProvisionalPageProxy. This work used to happen earlier in continueNavigationInNewProcess(). (WebKit::WebPageProxy::continueNavigationInNewProcess): Moved some of the logic to commitProvisionalPage(). We now merely start the load in a new ProvisionalPageProxy, without actually having the WebPageProxy switch to the new process yet. (WebKit::WebPageProxy::didCreateMainFrame): (WebKit::WebPageProxy::didCreateSubframe): (WebKit::WebPageProxy::didCreateWindow): Drop some code that is no longer needed, now that the ProvisionalPageProxy takes care of this. (WebKit::WebPageProxy::didDestroyNavigation): On process-swap, when telling the previous process to ignore the load and starting the new load in a new ProvisionalPageProxy, the previous WebPage attempts to destroy the navigation. In this case, we ignore the call since the navigation is merely taken over by the ProvisionalPageProxy. (WebKit::WebPageProxy::didStartProvisionalLoadForFrame): (WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared): Moved some PSON logic to the ProvisionalPageProxy instead. (WebKit::WebPageProxy::didReceiveServerRedirectForProvisionalLoadForFrame): (WebKit::WebPageProxy::didReceiveServerRedirectForProvisionalLoadForFrameShared): (WebKit::WebPageProxy::willPerformClientRedirectForFrame): (WebKit::WebPageProxy::didCancelClientRedirectForFrame): (WebKit::WebPageProxy::didChangeProvisionalURLForFrame): (WebKit::WebPageProxy::didChangeProvisionalURLForFrameShared): (WebKit::WebPageProxy::didFailProvisionalLoadForFrame): (WebKit::WebPageProxy::didFailProvisionalLoadForFrameShared): When didFailProvisionalLoadForFrame() is called for a ProvisionalPageProxy, destroy it. (WebKit::WebPageProxy::didCommitLoadForFrame): (WebKit::WebPageProxy::didFinishDocumentLoadForFrame): (WebKit::WebPageProxy::didFinishLoadForFrame): (WebKit::WebPageProxy::didFailLoadForFrame): (WebKit::WebPageProxy::didSameDocumentNavigationForFrame): (WebKit::WebPageProxy::didReceiveTitleForFrame): (WebKit::WebPageProxy::didFirstVisuallyNonEmptyLayoutForFrame): (WebKit::WebPageProxy::didDisplayInsecureContentForFrame): (WebKit::WebPageProxy::didRunInsecureContentForFrame): (WebKit::WebPageProxy::frameDidBecomeFrameSet): (WebKit::WebPageProxy::decidePolicyForNavigationActionAsync): (WebKit::WebPageProxy::decidePolicyForNavigationActionAsyncShared): (WebKit::WebPageProxy::decidePolicyForNavigationAction): (WebKit::WebPageProxy::decidePolicyForNavigationActionSync): (WebKit::WebPageProxy::decidePolicyForNewWindowAction): (WebKit::WebPageProxy::decidePolicyForResponse): (WebKit::WebPageProxy::decidePolicyForResponseShared): (WebKit::WebPageProxy::unableToImplementPolicy): (WebKit::WebPageProxy::willSubmitForm): (WebKit::WebPageProxy::didNavigateWithNavigationData): (WebKit::WebPageProxy::didNavigateWithNavigationDataShared): (WebKit::WebPageProxy::didPerformClientRedirect): (WebKit::WebPageProxy::didPerformClientRedirectShared): (WebKit::WebPageProxy::didPerformServerRedirect): (WebKit::WebPageProxy::didUpdateHistoryTitle): (WebKit::WebPageProxy::createNewPage): (WebKit::WebPageProxy::runJavaScriptAlert): (WebKit::WebPageProxy::runJavaScriptConfirm): (WebKit::WebPageProxy::runJavaScriptPrompt): (WebKit::WebPageProxy::unavailablePluginButtonClicked): (WebKit::WebPageProxy::runBeforeUnloadConfirmPanel): (WebKit::WebPageProxy::runOpenPanel): (WebKit::WebPageProxy::printFrame): (WebKit::WebPageProxy::backForwardGoToItem): (WebKit::WebPageProxy::backForwardGoToItemShared): (WebKit::WebPageProxy::learnWord): (WebKit::WebPageProxy::ignoreWord): (WebKit::WebPageProxy::didReceiveEvent): (WebKit::WebPageProxy::editingRangeCallback): (WebKit::WebPageProxy::rectForCharacterRangeCallback): (WebKit::WebPageProxy::focusedFrameChanged): (WebKit::WebPageProxy::frameSetLargestFrameChanged): (WebKit::WebPageProxy::provisionalProcessDidTerminate): Cancel the provisiona load and destroy the ProvisionalPageProxy if the provisional process crashes. (WebKit::WebPageProxy::resetState): Drop some code that is no longer needed. (WebKit::WebPageProxy::creationParameters): - Move the hasRegisteredServiceWorkers flag initialization from the call site to here now that we have more than one call site. This was just some bad factoring. - Take the process in parameter now that we page can be associated with several processes at a time. (WebKit::WebPageProxy::exceededDatabaseQuota): (WebKit::WebPageProxy::requestGeolocationPermissionForFrame): (WebKit::WebPageProxy::requestUserMediaPermissionForFrame): (WebKit::WebPageProxy::enumerateMediaDevicesForFrame): (WebKit::WebPageProxy::startURLSchemeTask): (WebKit::WebPageProxy::startURLSchemeTaskShared): (WebKit::WebPageProxy::stopURLSchemeTask): (WebKit::WebPageProxy::loadSynchronousURLSchemeTask): (WebKit::WebPageProxy::checkURLReceivedFromCurrentOrPreviousWebProcess): (WebKit::WebPageProxy::willAcquireUniversalFileReadSandboxExtension): * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::visitedLinkStore): (WebKit::WebPageProxy::provisionalPageProxy const): * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::hasProvisionalPageWithID const): (WebKit::WebProcessProxy::updateBackForwardItem): (WebKit::WebProcessProxy::processDidTerminateOrFailedToLaunch): (WebKit::WebProcessProxy::didFinishLaunching): (WebKit::WebProcessProxy::canTerminateChildProcess): * UIProcess/WebProcessProxy.h: (WebKit::WebProcessProxy::addProvisionalPageProxy): (WebKit::WebProcessProxy::removeProvisionalPageProxy): Before updating a BackForwardListItem, we normally make sure the process has a WebPageProxy with the item's pageID. We have to tweak the logic because there may now be no WebPageProxy with this pageID associated with this process yet, because it is still a ProvisionalPageProxy. * UIProcess/WebURLSchemeHandler.cpp: (WebKit::WebURLSchemeHandler::startTask): * UIProcess/WebURLSchemeHandler.h: * UIProcess/WebURLSchemeTask.cpp: (WebKit::WebURLSchemeTask::create): (WebKit::WebURLSchemeTask::WebURLSchemeTask): (WebKit::WebURLSchemeTask::didPerformRedirection): (WebKit::WebURLSchemeTask::didReceiveResponse): (WebKit::WebURLSchemeTask::didReceiveData): (WebKit::WebURLSchemeTask::didComplete): (WebKit::WebURLSchemeTask::pageDestroyed): * UIProcess/WebURLSchemeTask.h: Pass the process when constructing a WebURLSchemeTask and store it as a data member in addition to the page. This is necessary now that a WebPageProxy can be associated with several WebProcesses. * UIProcess/ios/ViewGestureControllerIOS.mm: (WebKit::ViewGestureController::endSwipeGesture): Use the provisional drawing area to display the swipe snapshot as it may differ from the one currently associated with the page in case of process swap. * WebKit.xcodeproj/project.pbxproj: Add ProvisionalPageProxy class. * WebProcess/WebPage/WebFrame.cpp: (WebKit::toPolicyAction): (WebKit::WebFrame::didReceivePolicyDecision): * WebProcess/WebPage/WebPage.cpp: (WebKit::m_shouldAttachDrawingAreaOnPageTransition): (WebKit::WebPage::reinitializeWebPage): (WebKit::WebPage::didReceivePolicyDecision): Stop dealing with WebPolicyAction::Suspend as it no longer exists. (WebKit::WebPage::didCompletePageTransition): (WebKit::WebPage::setIsSuspended): Suspend the Page when setIsSuspended(true) is called, now that there is no longer a WebPolicyAction::Suspend. setIsSuspended(true) IPC is sent when we actually commit the provisional page. * WebProcess/WebPage/WebPage.h: Tools: Add API test coverage. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: (-[PSONNavigationDelegate webView:decidePolicyForNavigationResponse:decisionHandler:]): LayoutTests: Skip test testing the cross-process DOMWindow API as I broke it with this patch. The feature is far from ready and off by default anyway. I will add support back in a follow-up. * platform/wk2/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240046 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-16 Chris Dumez Regression(PSON) View becomes blank after click a cross-site download link https://bugs.webkit.org/show_bug.cgi?id=193361 Reviewed by Geoffrey Garen. The issue tracked by rdar://problem/47099573 is that a provisional load may get canceled (or converted into a download) *after* we've decided to process-swap. In such cases, the view should keep displaying the current site and it should still be interactive. However, with the previous PSON model, the view (pageProxy) would have already swapped to the new process and would end up displaying the initially empty document. To address the issue, this patch introduces the concept of a provisional load in the UIProcess, handled by a ProvisionalPageProxy which has its own privisional process. The WebPageProxy owns the ProvisionalPageProxy but we do not commit the provisional page until after the load was committed in the new process. This means that the view / WebPageProxy keeps using the old process and displays the current content until a load has committed in the provisional page. If no load commits in the provisional process (e.g. because the load is cancelled or converted into a download), then we merely destroy the ProvisionalPageProxy and terminate its process, without impacting the WebPageProxy. * Shared/WebPageCreationParameters.cpp: (WebKit::WebPageCreationParameters::encode const): (WebKit::WebPageCreationParameters::decode): * Shared/WebPageCreationParameters.h: Rename isSwapFromSuspended to isProcessSwap for clarity as we always want to delay attaching the drawing area in case of a process-swap, no matter what now that the previous process is kept alive until the provisional load is committed in the new process. * Shared/WebPolicyAction.h: Drop Suspend policy action. At decidePolicyForNavigationAction time, in case of process-swap, we now tell the previous process to simply ignore the load, while we create a ProvisionalPageProxy to do the new load in a new process. Suspension of the previous page in the old process, happens later, when a load is actually committed in the new process. * Sources.txt: Add new ProvisionalPageProxy file. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _killWebContentProcessAndResetState]): When calling _killWebContentProcessAndResetState on a WKWebView, kill both the current process and the provisional one, to maintain previous behavior in our API tests. * UIProcess/API/gtk/PageClientImpl.cpp: (WebKit::PageClientImpl::createDrawingAreaProxy): * UIProcess/API/gtk/PageClientImpl.h: * UIProcess/API/wpe/PageClientImpl.cpp: (WebKit::PageClientImpl::createDrawingAreaProxy): * UIProcess/API/wpe/PageClientImpl.h: * UIProcess/AcceleratedDrawingAreaProxy.cpp: (WebKit::AcceleratedDrawingAreaProxy::AcceleratedDrawingAreaProxy): (WebKit::AcceleratedDrawingAreaProxy::didUpdateBackingStoreState): (WebKit::AcceleratedDrawingAreaProxy::sendUpdateBackingStoreState): (WebKit::AcceleratedDrawingAreaProxy::waitForAndDispatchDidUpdateBackingStoreState): (WebKit::AcceleratedDrawingAreaProxy::setNativeSurfaceHandleForCompositing): (WebKit::AcceleratedDrawingAreaProxy::destroyNativeSurfaceHandleForCompositing): * UIProcess/AcceleratedDrawingAreaProxy.h: * UIProcess/Cocoa/WebViewImpl.h: * UIProcess/Cocoa/WebViewImpl.mm: (WebKit::WebViewImpl::createDrawingAreaProxy): * UIProcess/DrawingAreaProxy.cpp: (WebKit::DrawingAreaProxy::DrawingAreaProxy): (WebKit::DrawingAreaProxy::~DrawingAreaProxy): (WebKit::DrawingAreaProxy::viewExposedRectChangedTimerFired): * UIProcess/DrawingAreaProxy.h: (WebKit::DrawingAreaProxy::process): * UIProcess/DrawingAreaProxyImpl.cpp: (WebKit::DrawingAreaProxyImpl::DrawingAreaProxyImpl): (WebKit::DrawingAreaProxyImpl::update): * UIProcess/DrawingAreaProxyImpl.h: * UIProcess/PageClient.h: * UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h: * UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::RemoteLayerTreeDrawingAreaProxy): (WebKit::RemoteLayerTreeDrawingAreaProxy::~RemoteLayerTreeDrawingAreaProxy): (WebKit::RemoteLayerTreeDrawingAreaProxy::deviceScaleFactorDidChange): (WebKit::RemoteLayerTreeDrawingAreaProxy::sendUpdateGeometry): (WebKit::RemoteLayerTreeDrawingAreaProxy::acceleratedAnimationDidStart): (WebKit::RemoteLayerTreeDrawingAreaProxy::acceleratedAnimationDidEnd): (WebKit::RemoteLayerTreeDrawingAreaProxy::didRefreshDisplay): (WebKit::RemoteLayerTreeDrawingAreaProxy::waitForDidUpdateActivityState): (WebKit::RemoteLayerTreeDrawingAreaProxy::dispatchAfterEnsuringDrawing): * UIProcess/ios/PageClientImplIOS.h: * UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::createDrawingAreaProxy): * UIProcess/ios/WKContentView.h: * UIProcess/ios/WKContentView.mm: (-[WKContentView _createDrawingAreaProxy:]): * UIProcess/mac/PageClientImplMac.h: * UIProcess/mac/PageClientImplMac.mm: (WebKit::PageClientImpl::createDrawingAreaProxy): * UIProcess/mac/TiledCoreAnimationDrawingAreaProxy.h: * UIProcess/mac/TiledCoreAnimationDrawingAreaProxy.mm: (WebKit::TiledCoreAnimationDrawingAreaProxy::TiledCoreAnimationDrawingAreaProxy): (WebKit::TiledCoreAnimationDrawingAreaProxy::deviceScaleFactorDidChange): (WebKit::TiledCoreAnimationDrawingAreaProxy::colorSpaceDidChange): (WebKit::TiledCoreAnimationDrawingAreaProxy::waitForDidUpdateActivityState): (WebKit::TiledCoreAnimationDrawingAreaProxy::createFence): (WebKit::TiledCoreAnimationDrawingAreaProxy::sendUpdateGeometry): (WebKit::TiledCoreAnimationDrawingAreaProxy::adjustTransientZoom): (WebKit::TiledCoreAnimationDrawingAreaProxy::commitTransientZoom): (WebKit::TiledCoreAnimationDrawingAreaProxy::dispatchAfterEnsuringDrawing): * UIProcess/mac/WebPageProxyMac.mm: * UIProcess/win/PageClientImpl.cpp: (WebKit::PageClientImpl::createDrawingAreaProxy): * UIProcess/win/PageClientImpl.h: * UIProcess/win/PageClientImpl.cpp: (WebKit::PageClientImpl::createDrawingAreaProxy): * UIProcess/win/PageClientImpl.h: * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm: (WebKit::TiledCoreAnimationDrawingArea::TiledCoreAnimationDrawingArea): Pass the drawing area's associated process when constructing it and store it as a member in addition to the page. This is necessary now that a page can be associated with 2 WebProcesses at a time, each having its own drawing area. * UIProcess/Cocoa/WebPageProxyCocoa.mm: (WebKit::WebPageProxy::createSandboxExtensionsIfNeeded): Pass the process. * UIProcess/ProvisionalPageProxy.cpp: Added. (WebKit::ProvisionalPageProxy::ProvisionalPageProxy): (WebKit::ProvisionalPageProxy::~ProvisionalPageProxy): (WebKit::ProvisionalPageProxy::processDidTerminate): (WebKit::ProvisionalPageProxy::takeDrawingArea): (WebKit::ProvisionalPageProxy::cancel): (WebKit::ProvisionalPageProxy::processDidFinishLaunching): (WebKit::ProvisionalPageProxy::finishInitializingWebPageAfterProcessLaunch): (WebKit::ProvisionalPageProxy::initializeWebPage): (WebKit::ProvisionalPageProxy::loadData): (WebKit::ProvisionalPageProxy::loadRequest): (WebKit::ProvisionalPageProxy::goToBackForwardItem): (WebKit::ProvisionalPageProxy::didCreateMainFrame): (WebKit::ProvisionalPageProxy::didPerformClientRedirect): (WebKit::ProvisionalPageProxy::didStartProvisionalLoadForFrame): (WebKit::ProvisionalPageProxy::didFailProvisionalLoadForFrame): (WebKit::ProvisionalPageProxy::didCommitLoadForFrame): (WebKit::ProvisionalPageProxy::didNavigateWithNavigationData): (WebKit::ProvisionalPageProxy::didChangeProvisionalURLForFrame): (WebKit::ProvisionalPageProxy::decidePolicyForNavigationActionAsync): (WebKit::ProvisionalPageProxy::decidePolicyForResponse): (WebKit::ProvisionalPageProxy::startURLSchemeTask): (WebKit::ProvisionalPageProxy::backForwardGoToItem): (WebKit::ProvisionalPageProxy::didReceiveMessage): (WebKit::ProvisionalPageProxy::didReceiveSyncMessage): * UIProcess/ProvisionalPageProxy.h: Added. (WebKit::ProvisionalPageProxy::page): (WebKit::ProvisionalPageProxy::mainFrame const): (WebKit::ProvisionalPageProxy::process): (WebKit::ProvisionalPageProxy::processSwapRequestedByClient const): (WebKit::ProvisionalPageProxy::navigationID const): (WebKit::ProvisionalPageProxy::drawingArea const): New WebPageProxy-like class which is owned by the WebPageProxy and proxies IPC from the provisional process. * UIProcess/SuspendedPageProxy.cpp: (WebKit::SuspendedPageProxy::~SuspendedPageProxy): (WebKit::SuspendedPageProxy::unsuspend): (WebKit::SuspendedPageProxy::didProcessRequestToSuspend): Unregister the SuspendedPageProxy as an IPC message receiver a little bit earlier when we're going to unsuspend it. This avoids conflicting with the ProvisionalPageProxy which tries to register itself as an IPC message receiver for the same pageID when a process-swap occurs and we're switching to a suspended page. * UIProcess/WebFrameProxy.cpp: (WebKit::WebFrameProxy::isMainFrame const): WebFrameProxy::isMainFrame() relies on checking that the frame is the WebPageProxy's m_mainFrame. Now that the WebPageProxy can have a ProvisionalPageProxy, also check if it is the ProvisionalPageProxy's m_mainFrame to maintain previous behavior. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::provisionalDrawingArea const): Add getter for the provisional drawing area. We normally only deal with the page's current drawing area, but the ViewGestureController needs access to the provisional once to display the swipe gesture snapshot. (WebKit::WebPageProxy::swapToWebProcess): swapToWebProcess() no longer takes care of unsuspending the SuspendedPage because we now call swapToWebProcess() later, when a load is actually committed in the provisional page / process. swapToWebProcess() now also needs to initialize some data members such as the drawing area and the main frame as it is transferring them over from the ProvisionalPageProxy which started the provisional load. (WebKit::WebPageProxy::finishAttachingToWebProcess): We no longer need IsSwapFromSuspended parameter as this is called later now, after a load has actually been committed in the provisional process. (WebKit::WebPageProxy::setDrawingArea): (WebKit::WebPageProxy::initializeWebPage): - We no longer need IsSwapFromSuspended parameter as this is called later now, after a load has actually been committed in the provisional process. - Factor some code out to WebPageProxy::setDrawingArea() so that it can be shared with swapToWebProcess(). (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle): (WebKit::WebPageProxy::loadRequest): (WebKit::WebPageProxy::loadRequestWithNavigationShared): Only call setPendingAPIRequestURL() in loadRequestWithNavigation() only if ShouldTreatAsContinuingLoad is not Yes. This avoids hitting some assertions as this was already called during the first API call if needed. (WebKit::WebPageProxy::loadData): (WebKit::WebPageProxy::loadDataWithNavigationShared): (WebKit::WebPageProxy::stopLoading): (WebKit::WebPageProxy::reload): (WebKit::WebPageProxy::didPerformDragControllerAction): (WebKit::WebPageProxy::findPlugin): (WebKit::WebPageProxy::receivedNavigationPolicyDecision): In case of process swap, tell the previous process to ignore the load instead of suspending it right away. Suspension now happens later, only if we end up committing the provisional load in the new process. Also discard the SuspendedPage if it failed to suspend (we only reuse its process in this case). This used to happen a bit later but it is clearer if we do this as early as possible I think. (WebKit::WebPageProxy::commitProvisionalPage): When the load is committed in the new process, we call WebPageProxy::commitProvisionalPage(). It takes care of: - Actually swapping the WebPageProxy to the new process by calling processDidTerminate() / swapToWebProcess(). - Suspending the current page. - Letting the client know the load is comitted - Destroy the ProvisionalPageProxy. This work used to happen earlier in continueNavigationInNewProcess(). (WebKit::WebPageProxy::continueNavigationInNewProcess): Moved some of the logic to commitProvisionalPage(). We now merely start the load in a new ProvisionalPageProxy, without actually having the WebPageProxy switch to the new process yet. (WebKit::WebPageProxy::didCreateMainFrame): (WebKit::WebPageProxy::didCreateSubframe): (WebKit::WebPageProxy::didCreateWindow): Drop some code that is no longer needed, now that the ProvisionalPageProxy takes care of this. (WebKit::WebPageProxy::didDestroyNavigation): On process-swap, when telling the previous process to ignore the load and starting the new load in a new ProvisionalPageProxy, the previous WebPage attempts to destroy the navigation. In this case, we ignore the call since the navigation is merely taken over by the ProvisionalPageProxy. (WebKit::WebPageProxy::didStartProvisionalLoadForFrame): (WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared): Moved some PSON logic to the ProvisionalPageProxy instead. (WebKit::WebPageProxy::didReceiveServerRedirectForProvisionalLoadForFrame): (WebKit::WebPageProxy::didReceiveServerRedirectForProvisionalLoadForFrameShared): (WebKit::WebPageProxy::willPerformClientRedirectForFrame): (WebKit::WebPageProxy::didCancelClientRedirectForFrame): (WebKit::WebPageProxy::didChangeProvisionalURLForFrame): (WebKit::WebPageProxy::didChangeProvisionalURLForFrameShared): (WebKit::WebPageProxy::didFailProvisionalLoadForFrame): (WebKit::WebPageProxy::didFailProvisionalLoadForFrameShared): When didFailProvisionalLoadForFrame() is called for a ProvisionalPageProxy, destroy it. (WebKit::WebPageProxy::didCommitLoadForFrame): (WebKit::WebPageProxy::didFinishDocumentLoadForFrame): (WebKit::WebPageProxy::didFinishLoadForFrame): (WebKit::WebPageProxy::didFailLoadForFrame): (WebKit::WebPageProxy::didSameDocumentNavigationForFrame): (WebKit::WebPageProxy::didReceiveTitleForFrame): (WebKit::WebPageProxy::didFirstVisuallyNonEmptyLayoutForFrame): (WebKit::WebPageProxy::didDisplayInsecureContentForFrame): (WebKit::WebPageProxy::didRunInsecureContentForFrame): (WebKit::WebPageProxy::frameDidBecomeFrameSet): (WebKit::WebPageProxy::decidePolicyForNavigationActionAsync): (WebKit::WebPageProxy::decidePolicyForNavigationActionAsyncShared): (WebKit::WebPageProxy::decidePolicyForNavigationAction): (WebKit::WebPageProxy::decidePolicyForNavigationActionSync): (WebKit::WebPageProxy::decidePolicyForNewWindowAction): (WebKit::WebPageProxy::decidePolicyForResponse): (WebKit::WebPageProxy::decidePolicyForResponseShared): (WebKit::WebPageProxy::unableToImplementPolicy): (WebKit::WebPageProxy::willSubmitForm): (WebKit::WebPageProxy::didNavigateWithNavigationData): (WebKit::WebPageProxy::didNavigateWithNavigationDataShared): (WebKit::WebPageProxy::didPerformClientRedirect): (WebKit::WebPageProxy::didPerformClientRedirectShared): (WebKit::WebPageProxy::didPerformServerRedirect): (WebKit::WebPageProxy::didUpdateHistoryTitle): (WebKit::WebPageProxy::createNewPage): (WebKit::WebPageProxy::runJavaScriptAlert): (WebKit::WebPageProxy::runJavaScriptConfirm): (WebKit::WebPageProxy::runJavaScriptPrompt): (WebKit::WebPageProxy::unavailablePluginButtonClicked): (WebKit::WebPageProxy::runBeforeUnloadConfirmPanel): (WebKit::WebPageProxy::runOpenPanel): (WebKit::WebPageProxy::printFrame): (WebKit::WebPageProxy::backForwardGoToItem): (WebKit::WebPageProxy::backForwardGoToItemShared): (WebKit::WebPageProxy::learnWord): (WebKit::WebPageProxy::ignoreWord): (WebKit::WebPageProxy::didReceiveEvent): (WebKit::WebPageProxy::editingRangeCallback): (WebKit::WebPageProxy::rectForCharacterRangeCallback): (WebKit::WebPageProxy::focusedFrameChanged): (WebKit::WebPageProxy::frameSetLargestFrameChanged): (WebKit::WebPageProxy::provisionalProcessDidTerminate): Cancel the provisiona load and destroy the ProvisionalPageProxy if the provisional process crashes. (WebKit::WebPageProxy::resetState): Drop some code that is no longer needed. (WebKit::WebPageProxy::creationParameters): - Move the hasRegisteredServiceWorkers flag initialization from the call site to here now that we have more than one call site. This was just some bad factoring. - Take the process in parameter now that we page can be associated with several processes at a time. (WebKit::WebPageProxy::exceededDatabaseQuota): (WebKit::WebPageProxy::requestGeolocationPermissionForFrame): (WebKit::WebPageProxy::requestUserMediaPermissionForFrame): (WebKit::WebPageProxy::enumerateMediaDevicesForFrame): (WebKit::WebPageProxy::startURLSchemeTask): (WebKit::WebPageProxy::startURLSchemeTaskShared): (WebKit::WebPageProxy::stopURLSchemeTask): (WebKit::WebPageProxy::loadSynchronousURLSchemeTask): (WebKit::WebPageProxy::checkURLReceivedFromCurrentOrPreviousWebProcess): (WebKit::WebPageProxy::willAcquireUniversalFileReadSandboxExtension): * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::visitedLinkStore): (WebKit::WebPageProxy::provisionalPageProxy const): * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::hasProvisionalPageWithID const): (WebKit::WebProcessProxy::updateBackForwardItem): (WebKit::WebProcessProxy::processDidTerminateOrFailedToLaunch): (WebKit::WebProcessProxy::didFinishLaunching): (WebKit::WebProcessProxy::canTerminateChildProcess): * UIProcess/WebProcessProxy.h: (WebKit::WebProcessProxy::addProvisionalPageProxy): (WebKit::WebProcessProxy::removeProvisionalPageProxy): Before updating a BackForwardListItem, we normally make sure the process has a WebPageProxy with the item's pageID. We have to tweak the logic because there may now be no WebPageProxy with this pageID associated with this process yet, because it is still a ProvisionalPageProxy. * UIProcess/WebURLSchemeHandler.cpp: (WebKit::WebURLSchemeHandler::startTask): * UIProcess/WebURLSchemeHandler.h: * UIProcess/WebURLSchemeTask.cpp: (WebKit::WebURLSchemeTask::create): (WebKit::WebURLSchemeTask::WebURLSchemeTask): (WebKit::WebURLSchemeTask::didPerformRedirection): (WebKit::WebURLSchemeTask::didReceiveResponse): (WebKit::WebURLSchemeTask::didReceiveData): (WebKit::WebURLSchemeTask::didComplete): (WebKit::WebURLSchemeTask::pageDestroyed): * UIProcess/WebURLSchemeTask.h: Pass the process when constructing a WebURLSchemeTask and store it as a data member in addition to the page. This is necessary now that a WebPageProxy can be associated with several WebProcesses. * UIProcess/ios/ViewGestureControllerIOS.mm: (WebKit::ViewGestureController::endSwipeGesture): Use the provisional drawing area to display the swipe snapshot as it may differ from the one currently associated with the page in case of process swap. * WebKit.xcodeproj/project.pbxproj: Add ProvisionalPageProxy class. * WebProcess/WebPage/WebFrame.cpp: (WebKit::toPolicyAction): (WebKit::WebFrame::didReceivePolicyDecision): * WebProcess/WebPage/WebPage.cpp: (WebKit::m_shouldAttachDrawingAreaOnPageTransition): (WebKit::WebPage::reinitializeWebPage): (WebKit::WebPage::didReceivePolicyDecision): Stop dealing with WebPolicyAction::Suspend as it no longer exists. (WebKit::WebPage::didCompletePageTransition): (WebKit::WebPage::setIsSuspended): Suspend the Page when setIsSuspended(true) is called, now that there is no longer a WebPolicyAction::Suspend. setIsSuspended(true) IPC is sent when we actually commit the provisional page. * WebProcess/WebPage/WebPage.h: 2019-01-22 Alan Coon Cherry-pick r240015. rdar://problem/47099573 Unreviewed, rolling out r239993, r239995, r239997, and r239999. Caused assertions under ViewGestureController::disconnectFromProcess() Reverted changesets: "Regression(PSON) View becomes blank after click a cross-site download link" https://bugs.webkit.org/show_bug.cgi?id=193361 https://trac.webkit.org/changeset/239993 "Unreviewed iOS build fix after r239993." https://trac.webkit.org/changeset/239995 "Fix iOS build after r239993" https://bugs.webkit.org/show_bug.cgi?id=193361 https://trac.webkit.org/changeset/239997 "Unreviewed, revert part of r239997 as it is not needed to fix the build." https://trac.webkit.org/changeset/239999 git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240015 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-15 Chris Dumez Unreviewed, rolling out r239993, r239995, r239997, and r239999. Caused assertions under ViewGestureController::disconnectFromProcess() Reverted changesets: "Regression(PSON) View becomes blank after click a cross-site download link" https://bugs.webkit.org/show_bug.cgi?id=193361 https://trac.webkit.org/changeset/239993 "Unreviewed iOS build fix after r239993." https://trac.webkit.org/changeset/239995 "Fix iOS build after r239993" https://bugs.webkit.org/show_bug.cgi?id=193361 https://trac.webkit.org/changeset/239997 "Unreviewed, revert part of r239997 as it is not needed to fix the build." https://trac.webkit.org/changeset/239999 2019-01-22 Alan Coon Cherry-pick r239997. rdar://problem/47099573 Fix iOS build after r239993 https://bugs.webkit.org/show_bug.cgi?id=193361 Source/WebKit: * UIProcess/ProvisionalPageProxy.h: * UIProcess/SuspendedPageProxy.h: Source/WTF: * wtf/RefCounter.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239997 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-15 Alex Christensen Fix iOS build after r239993 https://bugs.webkit.org/show_bug.cgi?id=193361 * UIProcess/ProvisionalPageProxy.h: * UIProcess/SuspendedPageProxy.h: 2019-01-22 Alan Coon Cherry-pick r239995. rdar://problem/47099573 Unreviewed iOS build fix after r239993. * UIProcess/SuspendedPageProxy.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239995 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-15 Chris Dumez Unreviewed iOS build fix after r239993. * UIProcess/SuspendedPageProxy.h: 2019-01-22 Alan Coon Cherry-pick r239993. rdar://problem/47099573 Regression(PSON) View becomes blank after click a cross-site download link https://bugs.webkit.org/show_bug.cgi?id=193361 Reviewed by Geoff Garen. Source/WebCore: * loader/FrameLoader.cpp: (WebCore::FrameLoader::commitProvisionalLoad): When restoring from PageCache, make sure we notify the client that the load was committed *before* we tell it that the navigation is complete. This would confuse the ProvisionalPageProxy logic in the UIProcess. Source/WebKit: The issue tracked by rdar://problem/47099573 is that a provisional load may get canceled (or converted into a download) *after* we've decided to process-swap. In such cases, the view should keep displaying the current site and it should still be interactive. However, with the previous PSON model, the view (pageProxy) would have already swapped to the new process and would end up displaying the initially empty document. To address the issue, this patch introduces the concept of a provisional load in the UIProcess, handled by a ProvisionalPageProxy which has its own privisional process. The WebPageProxy owns the ProvisionalPageProxy but we do not commit the provisional page until after the load was committed in the new process. This means that the view / WebPageProxy keeps using the old process and displays the current content until a load has committed in the provisional page. If no load commits in the provisional process (e.g. because the load is cancelled or converted into a download), then we merely destroy the ProvisionalPageProxy and terminate its process, without impacting the WebPageProxy. * Shared/WebPageCreationParameters.cpp: (WebKit::WebPageCreationParameters::encode const): (WebKit::WebPageCreationParameters::decode): * Shared/WebPageCreationParameters.h: Rename isSwapFromSuspended to isProcessSwap for clarity as we always want to delay attaching the drawing area in case of a process-swap, no matter what now that the previous process is kept alive until the provisional load is committed in the new process. * Shared/WebPolicyAction.h: Drop Suspend policy action. At decidePolicyForNavigationAction time, in case of process-swap, we now tell the previous process to simply ignore the load, while we create a ProvisionalPageProxy to do the new load in a new process. Suspension of the previous page in the old process, happens later, when a load is actually committed in the new process. * Sources.txt: Add new ProvisionalPageProxy file. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _killWebContentProcessAndResetState]): When calling _killWebContentProcessAndResetState on a WKWebView, kill both the current process and the provisional one, to maintain previous behavior in our API tests. * UIProcess/PageClient.h: Tiny build fix. * UIProcess/ProvisionalPageProxy.cpp: Added. (WebKit::ProvisionalPageProxy::ProvisionalPageProxy): (WebKit::ProvisionalPageProxy::~ProvisionalPageProxy): (WebKit::ProvisionalPageProxy::takeDrawingArea): (WebKit::ProvisionalPageProxy::cancel): (WebKit::ProvisionalPageProxy::initializeWebPage): (WebKit::ProvisionalPageProxy::loadDataWithNavigation): (WebKit::ProvisionalPageProxy::loadRequestWithNavigation): (WebKit::ProvisionalPageProxy::goToBackForwardItem): (WebKit::ProvisionalPageProxy::didCreateMainFrame): (WebKit::ProvisionalPageProxy::didStartProvisionalLoadForFrame): (WebKit::ProvisionalPageProxy::didFailProvisionalLoadForFrame): (WebKit::ProvisionalPageProxy::didCommitLoadForFrame): (WebKit::ProvisionalPageProxy::didReceiveMessage): (WebKit::ProvisionalPageProxy::didReceiveSyncMessage): * UIProcess/ProvisionalPageProxy.h: Added. (WebKit::ProvisionalPageProxy::page): (WebKit::ProvisionalPageProxy::mainFrame const): (WebKit::ProvisionalPageProxy::process): (WebKit::ProvisionalPageProxy::processSwapRequestedByClient const): (WebKit::ProvisionalPageProxy::navigationID const): Add new ProvisionalPageProxy class to wrap the provisional load in the new process after a swap. The provisional page is owned by the WebPageProxy and we only commit the provisional page when the load is committed. Until then, the WebPageProxy keeps using the old process and displaying the current content. * UIProcess/SuspendedPageProxy.cpp: (WebKit::SuspendedPageProxy::~SuspendedPageProxy): (WebKit::SuspendedPageProxy::unsuspend): (WebKit::SuspendedPageProxy::didProcessRequestToSuspend): Unregister the SuspendedPageProxy as an IPC message receiver a little bit earlier when we're going to unsuspend it. This avoids conflicting with the ProvisionalPageProxy which tries to register itself as an IPC message receiver for the same pageID when a process-swap occurs and we're switching to a suspended page. * UIProcess/WebFrameProxy.cpp: (WebKit::WebFrameProxy::isMainFrame const): WebFrameProxy::isMainFrame() relies on checking that the frame is the WebPageProxy's m_mainFrame. Now that the WebPageProxy can have a ProvisionalPageProxy, also check if it is the ProvisionalPageProxy's m_mainFrame to maintain previous behavior. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::swapToWebProcess): swapToWebProcess() no longer takes care of unsuspending the SuspendedPage because we now call swapToWebProcess() later, when a load is actually committed in the provisional page / process. swapToWebProcess() now also needs to initialize some data members such as the drawing area and the main frame as it is transferring them over from the ProvisionalPageProxy which started the provisional load. (WebKit::WebPageProxy::finishAttachingToWebProcess): We no longer need IsSwapFromSuspended parameter as this is called later now, after a load has actually been committed in the provisional process. (WebKit::WebPageProxy::initializeWebPage): - We no longer need IsSwapFromSuspended parameter as this is called later now, after a load has actually been committed in the provisional process. - Factor some code out to WebPageProxy::setDrawingArea() so that it can be shared with swapToWebProcess(). (WebKit::WebPageProxy::loadRequestWithNavigation): Only call setPendingAPIRequestURL() in loadRequestWithNavigation() only if ShouldTreatAsContinuingLoad is not Yes. This avoids hitting some assertions as this was already called during the first API call if needed. (WebKit::WebPageProxy::receivedNavigationPolicyDecision): In case of process swap, tell the previous process to ignore the load instead of suspending it right away. Suspension now happens later, only if we end up committing the provisional load in the new process. Also discard the SuspendedPage if it failed to suspend (we only reuse its process in this case). This used to happen a bit later but it is clearer if we do this as early as possible I think. (WebKit::WebPageProxy::commitProvisionalPage): When the load is committed in the new process, we call WebPageProxy::commitProvisionalPage(). It takes care of: - Actually swapping the WebPageProxy to the new process by calling processDidTerminate() / swapToWebProcess(). - Suspending the current page. - Letting the client know the load is comitted - Destroy the ProvisionalPageProxy. This work used to happen earlier in continueNavigationInNewProcess(). (WebKit::WebPageProxy::continueNavigationInNewProcess): Moved some of the logic to commitProvisionalPage(). We now merely start the load in a new ProvisionalPageProxy, without actually having the WebPageProxy switch to the new process yet. (WebKit::WebPageProxy::didCreateMainFrame): (WebKit::WebPageProxy::didCreateWindow): Drop some code that is no longer needed, now that the ProvisionalPageProxy takes care of this. (WebKit::WebPageProxy::didDestroyNavigation): On process-swap, when telling the previous process to ignore the load and starting the new load in a new ProvisionalPageProxy, the previous WebPage attempts to destroy the navigation. In this case, we ignore the call since the navigation is merely taken over by the ProvisionalPageProxy. (WebKit::WebPageProxy::didStartProvisionalLoadForFrame): Moved some PSON logic to the ProvisionalPageProxy instead. (WebKit::WebPageProxy::didFailProvisionalLoadForFrame): When didFailProvisionalLoadForFrame() is called for a ProvisionalPageProxy, destroy it. (WebKit::WebPageProxy::decidePolicyForNavigationActionAsync): (WebKit::WebPageProxy::decidePolicyForResponse): Capture the process in the lambda, to make sure we send the policy decision to the same process that asked for it, so as to not get confused by process swaps. (WebKit::WebPageProxy::resetState): Drop some code that is no longer needed. (WebKit::WebPageProxy::creationParameters): Move the hasRegisteredServiceWorkers flag initialization from the call site to here now that we have more than one call site. This was just some bad factoring. (WebKit::WebPageProxy::PageProcessOverride::PageProcessOverride): (WebKit::WebPageProxy::PageProcessOverride::~PageProcessOverride): * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::temporarilyOverrideProcess): Add utility class to temporarily override the WebPageProxy's m_process with the provisional one when the ProvisionalPageProxy interacts with the WebPageProxy. * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::hasProvisionalPageWithID const): (WebKit::WebProcessProxy::updateBackForwardItem): Before updating a BackForwardListItem, we normally make sure the process has a WebPageProxy with the item's pageID. We have to tweak the logic because there may now be no WebPageProxy with this pageID associated with this process yet, because it is still a ProvisionalPageProxy. (WebKit::WebProcessProxy::canTerminateChildProcess): Do not terminate the WebProcess if there are ProvisionalPageProxy objects using it. * UIProcess/WebProcessProxy.h: (WebKit::WebProcessProxy::addProvisionalPageProxy): (WebKit::WebProcessProxy::removeProvisionalPageProxy): * WebKit.xcodeproj/project.pbxproj: * WebProcess/WebPage/WebFrame.cpp: (WebKit::toPolicyAction): (WebKit::WebFrame::didReceivePolicyDecision): Stop dealing with WebPolicyAction::Suspend as it no longer exists. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::reinitializeWebPage): (WebKit::WebPage::didReceivePolicyDecision): (WebKit::WebPage::setIsSuspended): Suspend the Page when setIsSuspended(true) is called, now that there is no longer a WebPolicyAction::Suspend. setIsSuspended(true) IPC is sent when we actually commit the provisional page. * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm: (WebKit::TiledCoreAnimationDrawingArea::TiledCoreAnimationDrawingArea): Tools: Add API test coverage. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: (-[PSONNavigationDelegate webView:decidePolicyForNavigationResponse:decisionHandler:]): LayoutTests: Skip test testing the cross-process DOMWindow API as I broke it with this patch. The feature is far from ready and off by default anyway. I will add support back in a follow-up. * platform/wk2/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239993 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-15 Chris Dumez Regression(PSON) View becomes blank after click a cross-site download link https://bugs.webkit.org/show_bug.cgi?id=193361 Reviewed by Geoff Garen. The issue tracked by rdar://problem/47099573 is that a provisional load may get canceled (or converted into a download) *after* we've decided to process-swap. In such cases, the view should keep displaying the current site and it should still be interactive. However, with the previous PSON model, the view (pageProxy) would have already swapped to the new process and would end up displaying the initially empty document. To address the issue, this patch introduces the concept of a provisional load in the UIProcess, handled by a ProvisionalPageProxy which has its own privisional process. The WebPageProxy owns the ProvisionalPageProxy but we do not commit the provisional page until after the load was committed in the new process. This means that the view / WebPageProxy keeps using the old process and displays the current content until a load has committed in the provisional page. If no load commits in the provisional process (e.g. because the load is cancelled or converted into a download), then we merely destroy the ProvisionalPageProxy and terminate its process, without impacting the WebPageProxy. * Shared/WebPageCreationParameters.cpp: (WebKit::WebPageCreationParameters::encode const): (WebKit::WebPageCreationParameters::decode): * Shared/WebPageCreationParameters.h: Rename isSwapFromSuspended to isProcessSwap for clarity as we always want to delay attaching the drawing area in case of a process-swap, no matter what now that the previous process is kept alive until the provisional load is committed in the new process. * Shared/WebPolicyAction.h: Drop Suspend policy action. At decidePolicyForNavigationAction time, in case of process-swap, we now tell the previous process to simply ignore the load, while we create a ProvisionalPageProxy to do the new load in a new process. Suspension of the previous page in the old process, happens later, when a load is actually committed in the new process. * Sources.txt: Add new ProvisionalPageProxy file. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _killWebContentProcessAndResetState]): When calling _killWebContentProcessAndResetState on a WKWebView, kill both the current process and the provisional one, to maintain previous behavior in our API tests. * UIProcess/PageClient.h: Tiny build fix. * UIProcess/ProvisionalPageProxy.cpp: Added. (WebKit::ProvisionalPageProxy::ProvisionalPageProxy): (WebKit::ProvisionalPageProxy::~ProvisionalPageProxy): (WebKit::ProvisionalPageProxy::takeDrawingArea): (WebKit::ProvisionalPageProxy::cancel): (WebKit::ProvisionalPageProxy::initializeWebPage): (WebKit::ProvisionalPageProxy::loadDataWithNavigation): (WebKit::ProvisionalPageProxy::loadRequestWithNavigation): (WebKit::ProvisionalPageProxy::goToBackForwardItem): (WebKit::ProvisionalPageProxy::didCreateMainFrame): (WebKit::ProvisionalPageProxy::didStartProvisionalLoadForFrame): (WebKit::ProvisionalPageProxy::didFailProvisionalLoadForFrame): (WebKit::ProvisionalPageProxy::didCommitLoadForFrame): (WebKit::ProvisionalPageProxy::didReceiveMessage): (WebKit::ProvisionalPageProxy::didReceiveSyncMessage): * UIProcess/ProvisionalPageProxy.h: Added. (WebKit::ProvisionalPageProxy::page): (WebKit::ProvisionalPageProxy::mainFrame const): (WebKit::ProvisionalPageProxy::process): (WebKit::ProvisionalPageProxy::processSwapRequestedByClient const): (WebKit::ProvisionalPageProxy::navigationID const): Add new ProvisionalPageProxy class to wrap the provisional load in the new process after a swap. The provisional page is owned by the WebPageProxy and we only commit the provisional page when the load is committed. Until then, the WebPageProxy keeps using the old process and displaying the current content. * UIProcess/SuspendedPageProxy.cpp: (WebKit::SuspendedPageProxy::~SuspendedPageProxy): (WebKit::SuspendedPageProxy::unsuspend): (WebKit::SuspendedPageProxy::didProcessRequestToSuspend): Unregister the SuspendedPageProxy as an IPC message receiver a little bit earlier when we're going to unsuspend it. This avoids conflicting with the ProvisionalPageProxy which tries to register itself as an IPC message receiver for the same pageID when a process-swap occurs and we're switching to a suspended page. * UIProcess/WebFrameProxy.cpp: (WebKit::WebFrameProxy::isMainFrame const): WebFrameProxy::isMainFrame() relies on checking that the frame is the WebPageProxy's m_mainFrame. Now that the WebPageProxy can have a ProvisionalPageProxy, also check if it is the ProvisionalPageProxy's m_mainFrame to maintain previous behavior. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::swapToWebProcess): swapToWebProcess() no longer takes care of unsuspending the SuspendedPage because we now call swapToWebProcess() later, when a load is actually committed in the provisional page / process. swapToWebProcess() now also needs to initialize some data members such as the drawing area and the main frame as it is transferring them over from the ProvisionalPageProxy which started the provisional load. (WebKit::WebPageProxy::finishAttachingToWebProcess): We no longer need IsSwapFromSuspended parameter as this is called later now, after a load has actually been committed in the provisional process. (WebKit::WebPageProxy::initializeWebPage): - We no longer need IsSwapFromSuspended parameter as this is called later now, after a load has actually been committed in the provisional process. - Factor some code out to WebPageProxy::setDrawingArea() so that it can be shared with swapToWebProcess(). (WebKit::WebPageProxy::loadRequestWithNavigation): Only call setPendingAPIRequestURL() in loadRequestWithNavigation() only if ShouldTreatAsContinuingLoad is not Yes. This avoids hitting some assertions as this was already called during the first API call if needed. (WebKit::WebPageProxy::receivedNavigationPolicyDecision): In case of process swap, tell the previous process to ignore the load instead of suspending it right away. Suspension now happens later, only if we end up committing the provisional load in the new process. Also discard the SuspendedPage if it failed to suspend (we only reuse its process in this case). This used to happen a bit later but it is clearer if we do this as early as possible I think. (WebKit::WebPageProxy::commitProvisionalPage): When the load is committed in the new process, we call WebPageProxy::commitProvisionalPage(). It takes care of: - Actually swapping the WebPageProxy to the new process by calling processDidTerminate() / swapToWebProcess(). - Suspending the current page. - Letting the client know the load is comitted - Destroy the ProvisionalPageProxy. This work used to happen earlier in continueNavigationInNewProcess(). (WebKit::WebPageProxy::continueNavigationInNewProcess): Moved some of the logic to commitProvisionalPage(). We now merely start the load in a new ProvisionalPageProxy, without actually having the WebPageProxy switch to the new process yet. (WebKit::WebPageProxy::didCreateMainFrame): (WebKit::WebPageProxy::didCreateWindow): Drop some code that is no longer needed, now that the ProvisionalPageProxy takes care of this. (WebKit::WebPageProxy::didDestroyNavigation): On process-swap, when telling the previous process to ignore the load and starting the new load in a new ProvisionalPageProxy, the previous WebPage attempts to destroy the navigation. In this case, we ignore the call since the navigation is merely taken over by the ProvisionalPageProxy. (WebKit::WebPageProxy::didStartProvisionalLoadForFrame): Moved some PSON logic to the ProvisionalPageProxy instead. (WebKit::WebPageProxy::didFailProvisionalLoadForFrame): When didFailProvisionalLoadForFrame() is called for a ProvisionalPageProxy, destroy it. (WebKit::WebPageProxy::decidePolicyForNavigationActionAsync): (WebKit::WebPageProxy::decidePolicyForResponse): Capture the process in the lambda, to make sure we send the policy decision to the same process that asked for it, so as to not get confused by process swaps. (WebKit::WebPageProxy::resetState): Drop some code that is no longer needed. (WebKit::WebPageProxy::creationParameters): Move the hasRegisteredServiceWorkers flag initialization from the call site to here now that we have more than one call site. This was just some bad factoring. (WebKit::WebPageProxy::PageProcessOverride::PageProcessOverride): (WebKit::WebPageProxy::PageProcessOverride::~PageProcessOverride): * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::temporarilyOverrideProcess): Add utility class to temporarily override the WebPageProxy's m_process with the provisional one when the ProvisionalPageProxy interacts with the WebPageProxy. * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::hasProvisionalPageWithID const): (WebKit::WebProcessProxy::updateBackForwardItem): Before updating a BackForwardListItem, we normally make sure the process has a WebPageProxy with the item's pageID. We have to tweak the logic because there may now be no WebPageProxy with this pageID associated with this process yet, because it is still a ProvisionalPageProxy. (WebKit::WebProcessProxy::canTerminateChildProcess): Do not terminate the WebProcess if there are ProvisionalPageProxy objects using it. * UIProcess/WebProcessProxy.h: (WebKit::WebProcessProxy::addProvisionalPageProxy): (WebKit::WebProcessProxy::removeProvisionalPageProxy): * WebKit.xcodeproj/project.pbxproj: * WebProcess/WebPage/WebFrame.cpp: (WebKit::toPolicyAction): (WebKit::WebFrame::didReceivePolicyDecision): Stop dealing with WebPolicyAction::Suspend as it no longer exists. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::reinitializeWebPage): (WebKit::WebPage::didReceivePolicyDecision): (WebKit::WebPage::setIsSuspended): Suspend the Page when setIsSuspended(true) is called, now that there is no longer a WebPolicyAction::Suspend. setIsSuspended(true) IPC is sent when we actually commit the provisional page. * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm: (WebKit::TiledCoreAnimationDrawingArea::TiledCoreAnimationDrawingArea): 2019-01-18 Tim Horton REGRESSION (r236935): Holding down arrow key does not cause repeated DOM keydown events on device https://bugs.webkit.org/show_bug.cgi?id=191408 Rubber-stamped by Simon Fraser. * SourcesCocoa.txt: * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _scrollByContentOffset:]): * UIProcess/API/Cocoa/WKWebViewInternal.h: * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView setupInteraction]): (-[WKContentView cleanupInteraction]): (-[WKContentView scrollViewWillStartPanOrPinchGesture]): (-[WKContentView canPerformActionForWebView:withSender:]): (-[WKContentView keyCommands]): (-[WKContentView _arrowKeyForWebView:]): (-[WKContentView _didHandleKeyEvent:eventWasHandled:]): (-[WKContentView _scrollOffsetForEvent:]): (-[WKContentView _interpretKeyEvent:isCharEvent:]): (-[WKContentView isScrollableForKeyboardScrollViewAnimator:]): Deleted. (-[WKContentView keyboardScrollViewAnimator:distanceForIncrement:]): Deleted. (-[WKContentView keyboardScrollViewAnimatorWillScroll:]): Deleted. (-[WKContentView keyboardScrollViewAnimatorDidFinishScrolling:]): Deleted. * UIProcess/ios/WKKeyboardScrollingAnimator.h: Removed. * UIProcess/ios/WKKeyboardScrollingAnimator.mm: Removed. * UIProcess/ios/WKPDFView.mm: (-[WKPDFView dealloc]): (-[WKPDFView web_handleKeyEvent:]): (-[WKPDFView web_initWithFrame:webView:mimeType:]): * WebKit.xcodeproj/project.pbxproj: Revert WKKeyboardScrollingAnimator. 2019-01-16 Alan Coon Apply patch. rdar://problem/47260377 Cherry-pick r239887. rdar://problem/47260377 IndexedDB: leak WebIDBConnectionToClient for retain cycle https://bugs.webkit.org/show_bug.cgi?id=193097 Reviewed by Brady Eidson. Source/WebCore: Let IDBConnectionToClient hold a WeakPtr of IDBConnectionToClientDelegate. * Modules/indexeddb/server/IDBConnectionToClient.cpp: (WebCore::IDBServer::IDBConnectionToClient::IDBConnectionToClient): (WebCore::IDBServer::IDBConnectionToClient::identifier const): (WebCore::IDBServer::IDBConnectionToClient::didDeleteDatabase): (WebCore::IDBServer::IDBConnectionToClient::didOpenDatabase): (WebCore::IDBServer::IDBConnectionToClient::didAbortTransaction): (WebCore::IDBServer::IDBConnectionToClient::didCreateObjectStore): (WebCore::IDBServer::IDBConnectionToClient::didDeleteObjectStore): (WebCore::IDBServer::IDBConnectionToClient::didRenameObjectStore): (WebCore::IDBServer::IDBConnectionToClient::didClearObjectStore): (WebCore::IDBServer::IDBConnectionToClient::didCreateIndex): (WebCore::IDBServer::IDBConnectionToClient::didDeleteIndex): (WebCore::IDBServer::IDBConnectionToClient::didRenameIndex): (WebCore::IDBServer::IDBConnectionToClient::didPutOrAdd): (WebCore::IDBServer::IDBConnectionToClient::didGetRecord): (WebCore::IDBServer::IDBConnectionToClient::didGetAllRecords): (WebCore::IDBServer::IDBConnectionToClient::didGetCount): (WebCore::IDBServer::IDBConnectionToClient::didDeleteRecord): (WebCore::IDBServer::IDBConnectionToClient::didOpenCursor): (WebCore::IDBServer::IDBConnectionToClient::didIterateCursor): (WebCore::IDBServer::IDBConnectionToClient::didCommitTransaction): (WebCore::IDBServer::IDBConnectionToClient::fireVersionChangeEvent): (WebCore::IDBServer::IDBConnectionToClient::didStartTransaction): (WebCore::IDBServer::IDBConnectionToClient::didCloseFromServer): (WebCore::IDBServer::IDBConnectionToClient::notifyOpenDBRequestBlocked): (WebCore::IDBServer::IDBConnectionToClient::didGetAllDatabaseNames): * Modules/indexeddb/server/IDBConnectionToClient.h: * Modules/indexeddb/server/IDBConnectionToClientDelegate.h: Source/WebKit: Let WebIDBConnectionToClient hold reference to IPC::Connection instead of NetworkConnectionToWebProcess to break the cycle. * NetworkProcess/IndexedDB/WebIDBConnectionToClient.cpp: (WebKit::WebIDBConnectionToClient::create): (WebKit::WebIDBConnectionToClient::WebIDBConnectionToClient): (WebKit::WebIDBConnectionToClient::messageSenderConnection): * NetworkProcess/IndexedDB/WebIDBConnectionToClient.h: * NetworkProcess/NetworkConnectionToWebProcess.cpp: (WebKit::NetworkConnectionToWebProcess::establishIDBConnectionToServer): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@239887 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-16 David Kilzer Cherry-pick r239887. rdar://problem/47260377 2019-01-11 Sihui Liu IndexedDB: leak WebIDBConnectionToClient for retain cycle https://bugs.webkit.org/show_bug.cgi?id=193097 Reviewed by Brady Eidson. Let WebIDBConnectionToClient hold reference to IPC::Connection instead of NetworkConnectionToWebProcess to break the cycle. * NetworkProcess/IndexedDB/WebIDBConnectionToClient.cpp: (WebKit::WebIDBConnectionToClient::create): (WebKit::WebIDBConnectionToClient::WebIDBConnectionToClient): (WebKit::WebIDBConnectionToClient::messageSenderConnection): * NetworkProcess/IndexedDB/WebIDBConnectionToClient.h: * NetworkProcess/NetworkConnectionToWebProcess.cpp: (WebKit::NetworkConnectionToWebProcess::establishIDBConnectionToServer): 2019-01-16 Alan Coon Cherry-pick r239852. rdar://problem/47260195 [WebAuthN] Change the nonce in the CTAP kInit command to weak random values https://bugs.webkit.org/show_bug.cgi?id=192061 Reviewed by Chris Dumez. Change the nonce in the CTAP kInit command to weak random values as the nonce is mainly for being a probabilistically unique global identifier for hand shakes, instead of preventing replay attacks. Otherwise, it might exhaust system entropy unnecessarily. The patch also removes all logging when debugging the test case flakiness. * UIProcess/WebAuthentication/AuthenticatorManager.cpp: (WebKit::AuthenticatorManager::respondReceived): (WebKit::AuthenticatorManager::initTimeOutTimer): (WebKit::AuthenticatorManager::timeOutTimerFired): * UIProcess/WebAuthentication/Cocoa/HidService.mm: (WebKit::HidService::deviceAdded): * UIProcess/WebAuthentication/Mock/MockAuthenticatorManager.cpp: (WebKit::MockAuthenticatorManager::respondReceivedInternal): * UIProcess/WebAuthentication/Mock/MockHidConnection.cpp: (WebKit::MockHidConnection::send): * UIProcess/WebAuthentication/fido/CtapHidAuthenticator.cpp: (WebKit::CtapHidAuthenticator::makeCredential): (WebKit::CtapHidAuthenticator::getAssertion): * UIProcess/WebAuthentication/fido/CtapHidDriver.cpp: (WebKit::CtapHidDriver::Worker::write): (WebKit::CtapHidDriver::Worker::read): (WebKit::CtapHidDriver::Worker::returnMessage): (WebKit::CtapHidDriver::transact): (WebKit::CtapHidDriver::continueAfterChannelAllocated): (WebKit::CtapHidDriver::continueAfterResponseReceived): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239852 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-10 Jiewen Tan [WebAuthN] Change the nonce in the CTAP kInit command to weak random values https://bugs.webkit.org/show_bug.cgi?id=192061 Reviewed by Chris Dumez. Change the nonce in the CTAP kInit command to weak random values as the nonce is mainly for being a probabilistically unique global identifier for hand shakes, instead of preventing replay attacks. Otherwise, it might exhaust system entropy unnecessarily. The patch also removes all logging when debugging the test case flakiness. * UIProcess/WebAuthentication/AuthenticatorManager.cpp: (WebKit::AuthenticatorManager::respondReceived): (WebKit::AuthenticatorManager::initTimeOutTimer): (WebKit::AuthenticatorManager::timeOutTimerFired): * UIProcess/WebAuthentication/Cocoa/HidService.mm: (WebKit::HidService::deviceAdded): * UIProcess/WebAuthentication/Mock/MockAuthenticatorManager.cpp: (WebKit::MockAuthenticatorManager::respondReceivedInternal): * UIProcess/WebAuthentication/Mock/MockHidConnection.cpp: (WebKit::MockHidConnection::send): * UIProcess/WebAuthentication/fido/CtapHidAuthenticator.cpp: (WebKit::CtapHidAuthenticator::makeCredential): (WebKit::CtapHidAuthenticator::getAssertion): * UIProcess/WebAuthentication/fido/CtapHidDriver.cpp: (WebKit::CtapHidDriver::Worker::write): (WebKit::CtapHidDriver::Worker::read): (WebKit::CtapHidDriver::Worker::returnMessage): (WebKit::CtapHidDriver::transact): (WebKit::CtapHidDriver::continueAfterChannelAllocated): (WebKit::CtapHidDriver::continueAfterResponseReceived): 2019-01-16 Alan Coon Cherry-pick r239757. rdar://problem/47260195 [Mac] Layout Test http/wpt/webauthn/public-key-credential-create-success-hid.https.html and http/wpt/webauthn/public-key-credential-get-success-hid.https.html are flaky https://bugs.webkit.org/show_bug.cgi?id=192061 Reviewed by Dewei Zhu. Part 6. Add some additional temporary logging info to determine if data is actually sent. Once the bug is determined and fixed, we should remove all logging added in this patch. * UIProcess/WebAuthentication/Mock/MockHidConnection.cpp: (WebKit::MockHidConnection::send): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239757 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-08 Jiewen Tan [Mac] Layout Test http/wpt/webauthn/public-key-credential-create-success-hid.https.html and http/wpt/webauthn/public-key-credential-get-success-hid.https.html are flaky https://bugs.webkit.org/show_bug.cgi?id=192061 Reviewed by Dewei Zhu. Part 6. Add some additional temporary logging info to determine if data is actually sent. Once the bug is determined and fixed, we should remove all logging added in this patch. * UIProcess/WebAuthentication/Mock/MockHidConnection.cpp: (WebKit::MockHidConnection::send): 2019-01-10 Jiewen Tan [WebAuthN] Change the nonce in the CTAP kInit command to weak random values https://bugs.webkit.org/show_bug.cgi?id=192061 Reviewed by Chris Dumez. Change the nonce in the CTAP kInit command to weak random values as the nonce is mainly for being a probabilistically unique global identifier for hand shakes, instead of preventing replay attacks. Otherwise, it might exhaust system entropy unnecessarily. The patch also removes all logging when debugging the test case flakiness. * UIProcess/WebAuthentication/AuthenticatorManager.cpp: (WebKit::AuthenticatorManager::respondReceived): (WebKit::AuthenticatorManager::initTimeOutTimer): (WebKit::AuthenticatorManager::timeOutTimerFired): * UIProcess/WebAuthentication/Cocoa/HidService.mm: (WebKit::HidService::deviceAdded): * UIProcess/WebAuthentication/Mock/MockAuthenticatorManager.cpp: (WebKit::MockAuthenticatorManager::respondReceivedInternal): * UIProcess/WebAuthentication/Mock/MockHidConnection.cpp: (WebKit::MockHidConnection::send): * UIProcess/WebAuthentication/fido/CtapHidAuthenticator.cpp: (WebKit::CtapHidAuthenticator::makeCredential): (WebKit::CtapHidAuthenticator::getAssertion): * UIProcess/WebAuthentication/fido/CtapHidDriver.cpp: (WebKit::CtapHidDriver::Worker::write): (WebKit::CtapHidDriver::Worker::read): (WebKit::CtapHidDriver::Worker::returnMessage): (WebKit::CtapHidDriver::transact): (WebKit::CtapHidDriver::continueAfterChannelAllocated): (WebKit::CtapHidDriver::continueAfterResponseReceived): 2019-01-15 Alan Coon Cherry-pick r239904. rdar://problem/4726030 Have prefers-color-scheme: light always match on macOS versions before Mojave. https://bugs.webkit.org/show_bug.cgi?id=191655 rdar://problem/46074680 Reviewed by Megan Gardner. Source/JavaScriptCore: * Configurations/FeatureDefines.xcconfig: ENABLE_DARK_MODE_CSS_macosx for all OS versions. Source/WebCore: Tests: css-dark-mode/older-systems/prefers-color-scheme.html css-dark-mode/older-systems/supported-color-schemes-css.html css-dark-mode/older-systems/supported-color-schemes.html Use new HAVE(OS_DARK_MODE_SUPPORT) to make it easier to find code. Added HAVE(OS_DARK_MODE_SUPPORT) around more bits to make it work on older systems. * Configurations/FeatureDefines.xcconfig: * dom/Document.cpp: (WebCore::Document::useDarkAppearance const): * inspector/agents/InspectorPageAgent.cpp: (WebCore::InspectorPageAgent::enable): * page/Page.cpp: (WebCore::Page::setUseDarkAppearance): (WebCore::Page::useDarkAppearance const): (WebCore::Page::setUseDarkAppearanceOverride): * platform/mac/LocalDefaultSystemAppearance.h: (WebCore::LocalDefaultSystemAppearance::usingDarkAppearance const): * platform/mac/LocalDefaultSystemAppearance.mm: (WebCore::LocalDefaultSystemAppearance::LocalDefaultSystemAppearance): (WebCore::LocalDefaultSystemAppearance::~LocalDefaultSystemAppearance): * platform/mac/ScrollAnimatorMac.mm: * rendering/RenderThemeMac.mm: (-[WebCoreTextFieldCell _adjustedCoreUIDrawOptionsForDrawingBordersOnly:]): (-[WebListButtonCell drawWithFrame:inView:]): (WebCore::RenderThemeMac::platformInactiveSelectionBackgroundColor const): (WebCore::RenderThemeMac::platformInactiveSelectionForegroundColor const): (WebCore::RenderThemeMac::platformActiveListBoxSelectionBackgroundColor const): (WebCore::RenderThemeMac::platformInactiveListBoxSelectionBackgroundColor const): (WebCore::RenderThemeMac::platformInactiveListBoxSelectionForegroundColor const): (WebCore::RenderThemeMac::systemColor const): Source/WebCore/PAL: * Configurations/FeatureDefines.xcconfig: ENABLE_DARK_MODE_CSS_macosx for all OS versions. Source/WebKit: * Configurations/FeatureDefines.xcconfig: ENABLE_DARK_MODE_CSS_macosx for all OS versions. * UIProcess/Cocoa/WebViewImpl.mm: (WebKit::WebViewImpl::effectiveAppearanceIsDark): * UIProcess/RemoteLayerTree/mac/ScrollerMac.mm: Source/WebKitLegacy/mac: * Configurations/FeatureDefines.xcconfig: ENABLE_DARK_MODE_CSS_macosx for all OS versions. * WebView/WebView.mm: (-[WebView _effectiveAppearanceIsDark]): Source/WTF: * wtf/Platform.h: Define HAVE_OS_DARK_MODE_SUPPORT on macOS 10.14. Tools: * TestWebKitAPI/Configurations/FeatureDefines.xcconfig: ENABLE_DARK_MODE_CSS_macosx for all OS versions. * TestWebKitAPI/Tests/WebKit/mac/ForceLightAppearanceInBundle.mm: LayoutTests: * css-dark-mode/older-systems/prefers-color-scheme-expected.txt: Added. * css-dark-mode/older-systems/prefers-color-scheme.html: Added. * css-dark-mode/older-systems/supported-color-schemes-css-expected.txt: Added. * css-dark-mode/older-systems/supported-color-schemes-css.html: Added. * css-dark-mode/older-systems/supported-color-schemes-expected.txt: Added. * css-dark-mode/older-systems/supported-color-schemes.html: Added. * platform/mac/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239904 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-12 Timothy Hatcher Have prefers-color-scheme: light always match on macOS versions before Mojave. https://bugs.webkit.org/show_bug.cgi?id=191655 rdar://problem/46074680 Reviewed by Megan Gardner. * Configurations/FeatureDefines.xcconfig: ENABLE_DARK_MODE_CSS_macosx for all OS versions. * UIProcess/Cocoa/WebViewImpl.mm: (WebKit::WebViewImpl::effectiveAppearanceIsDark): * UIProcess/RemoteLayerTree/mac/ScrollerMac.mm: 2019-01-15 Alan Coon Cherry-pick r239888. rdar://problem/47260286 Compile out Web API Statistics Collection https://bugs.webkit.org/show_bug.cgi?id=193370 Reviewed by Brent Fulgham. Source/JavaScriptCore: * Configurations/FeatureDefines.xcconfig: Defined ENABLE_WEB_API_STATISTICS, off by default. Source/WebCore: No new tests. This patch disables functionality. The associated tests are skipped. These functions are now no-ops unless web API statistics is enabled. * Configurations/FeatureDefines.xcconfig: * loader/ResourceLoadObserver.cpp: (WebCore::ResourceLoadObserver::logFontLoad): (WebCore::ResourceLoadObserver::logCanvasRead): (WebCore::ResourceLoadObserver::logCanvasWriteOrMeasure): (WebCore::ResourceLoadObserver::logNavigatorAPIAccessed): (WebCore::ResourceLoadObserver::logScreenAPIAccessed): * loader/ResourceLoadStatistics.cpp: (WebCore::ResourceLoadStatistics::encode const): (WebCore::ResourceLoadStatistics::decode): (WebCore::ResourceLoadStatistics::toString const): (WebCore::ResourceLoadStatistics::merge): * loader/ResourceLoadStatistics.h: The associated struct members are skipped unless web API statistics is enabled. Source/WebCore/PAL: * Configurations/FeatureDefines.xcconfig: Defined ENABLE_WEB_API_STATISTICS, off by default. Source/WebKit: * Configurations/FeatureDefines.xcconfig: Defined ENABLE_WEB_API_STATISTICS, off by default. * Shared/WebCoreArgumentCoders.cpp: (IPC::ArgumentCoder::encode): Skipped encoding of web API statistics. (IPC::ArgumentCoder::decode): Skipped decoding of web API statistics. Source/WebKitLegacy/mac: * Configurations/FeatureDefines.xcconfig: Defined ENABLE_WEB_API_STATISTICS, off by default. Tools: * TestWebKitAPI/Configurations/FeatureDefines.xcconfig: Defined ENABLE_WEB_API_STATISTICS, off by default. LayoutTests: * platform/ios-wk2/TestExpectations: http/tests/webAPIStatistics skipped. * platform/mac-wk2/TestExpectations: http/tests/webAPIStatistics skipped. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239888 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-11 John Wilander Compile out Web API Statistics Collection https://bugs.webkit.org/show_bug.cgi?id=193370 Reviewed by Brent Fulgham. * Configurations/FeatureDefines.xcconfig: Defined ENABLE_WEB_API_STATISTICS, off by default. * Shared/WebCoreArgumentCoders.cpp: (IPC::ArgumentCoder::encode): Skipped encoding of web API statistics. (IPC::ArgumentCoder::decode): Skipped decoding of web API statistics. 2019-01-15 Alan Coon Cherry-pick r239880. rdar://problem/47260310 REGRESSION (PSON): Firefox app lacks Open in New Tab in menu https://bugs.webkit.org/show_bug.cgi?id=193366 Reviewed by Simon Fraser. Source/WebCore: * platform/RuntimeApplicationChecks.h: * platform/cocoa/RuntimeApplicationChecksCocoa.mm: (WebCore::IOSApplication::isFirefox): Add a Firefox Mobile bundle check. Source/WebKit: A pair of unrelated changes broke Firefox's use of WKWebView internals to override the long-press menu. Maintain binary compatibility by introducing linked-on-or-after checks. * UIProcess/Cocoa/VersionChecks.h: * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::createWebPage): Disable PSON in Firefox when linked against an SDK where PSON wasn't enabled by default. Because gestures are very stateful, we always swap them out when swapping processes (changing that behavior is fairly risky). Also, we don't always inform the client when we swap processes (only when the process actually crashes), so they currently don't re-adjust the gesture recognizers when a PSON swap occurs. * UIProcess/ios/WKContentView.mm: (-[WKContentView _commonInitializationWithProcessPool:configuration:]): Synchronously install gesture recognizers under -init when linked against an SDK before the version that introduces lazy gesture recognizer installation. r237331 is an optimization that made us lazily install gestures when the view is parented, but Firefox (and potentially other clients) depend on them being installed synchronously in order to find and override them. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239880 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-11 Tim Horton REGRESSION (PSON): Firefox app lacks Open in New Tab in menu https://bugs.webkit.org/show_bug.cgi?id=193366 Reviewed by Simon Fraser. A pair of unrelated changes broke Firefox's use of WKWebView internals to override the long-press menu. Maintain binary compatibility by introducing linked-on-or-after checks. * UIProcess/Cocoa/VersionChecks.h: * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::createWebPage): Disable PSON in Firefox when linked against an SDK where PSON wasn't enabled by default. Because gestures are very stateful, we always swap them out when swapping processes (changing that behavior is fairly risky). Also, we don't always inform the client when we swap processes (only when the process actually crashes), so they currently don't re-adjust the gesture recognizers when a PSON swap occurs. * UIProcess/ios/WKContentView.mm: (-[WKContentView _commonInitializationWithProcessPool:configuration:]): Synchronously install gesture recognizers under -init when linked against an SDK before the version that introduces lazy gesture recognizer installation. r237331 is an optimization that made us lazily install gestures when the view is parented, but Firefox (and potentially other clients) depend on them being installed synchronously in order to find and override them. 2019-01-15 Alan Coon Cherry-pick r239851. rdar://problem/47260326 Add WKBundlePage SPI to temporarily force light or dark appearance on a page. https://bugs.webkit.org/show_bug.cgi?id=193327 rdar://problem/47093222 Reviewed by Tim Horton. Source/WebKit: Tests: WebKit.ForceLightAppearanceInBundle API Test * WebProcess/InjectedBundle/API/c/WKBundlePage.cpp: (WKBundlePageSetUseDarkAppearance): Added. (WKBundlePageIsUsingDarkAppearance): Added. * WebProcess/InjectedBundle/API/c/WKBundlePagePrivate.h: Tools: * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKit/mac/ForceLightAppearanceInBundle.mm: Added. (TestWebKitAPI::didFinishNavigation): (TestWebKitAPI::didReceiveMessageFromInjectedBundle): (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/WebKit/mac/ForceLightAppearanceInBundle_Bundle.mm: Added. (TestWebKitAPI::ForceLightAppearanceInBundleTest::ForceLightAppearanceInBundleTest): (TestWebKitAPI::ForceLightAppearanceInBundleTest::didCreatePage): (TestWebKitAPI::ForceLightAppearanceInBundleTest::didReceiveMessage): * TestWebKitAPI/Tests/WebKit/mac/dark-mode.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239851 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-10 Timothy Hatcher Add WKBundlePage SPI to temporarily force light or dark appearance on a page. https://bugs.webkit.org/show_bug.cgi?id=193327 rdar://problem/47093222 Reviewed by Tim Horton. Tests: WebKit.ForceLightAppearanceInBundle API Test * WebProcess/InjectedBundle/API/c/WKBundlePage.cpp: (WKBundlePageSetUseDarkAppearance): Added. (WKBundlePageIsUsingDarkAppearance): Added. * WebProcess/InjectedBundle/API/c/WKBundlePagePrivate.h: 2019-01-15 Alan Coon Cherry-pick r239850. rdar://problem/47260243 DeviceID hash salt manager can be NULL https://bugs.webkit.org/show_bug.cgi?id=193334 Reviewed by Youenn Fablet. * UIProcess/UserMediaPermissionRequestManagerProxy.cpp: (WebKit::UserMediaPermissionRequestManagerProxy::userMediaAccessWasGranted): No need to NULL-check websiteDataStore.deviceIdHashSaltStorage, it is a Ref. (WebKit::UserMediaPermissionRequestManagerProxy::requestUserMediaPermissionForFrame): Ditto. (WebKit::UserMediaPermissionRequestManagerProxy::getUserMediaPermissionInfo): Ditto. (WebKit::UserMediaPermissionRequestManagerProxy::enumerateMediaDevicesForFrame): Ditto. * UIProcess/WebsiteData/WebsiteDataStore.cpp: (WebKit::WebsiteDataStore::WebsiteDataStore): m_deviceIdHashSaltStorage is a Ref. (WebKit::WebsiteDataStore::fetchDataAndApply): Ditto. (WebKit::WebsiteDataStore::removeData): Ditto. * UIProcess/WebsiteData/WebsiteDataStore.h: (WebKit::WebsiteDataStore::deviceIdHashSaltStorage): Ditto. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239850 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-10 Eric Carlson DeviceID hash salt manager can be NULL https://bugs.webkit.org/show_bug.cgi?id=193334 Reviewed by Youenn Fablet. * UIProcess/UserMediaPermissionRequestManagerProxy.cpp: (WebKit::UserMediaPermissionRequestManagerProxy::userMediaAccessWasGranted): No need to NULL-check websiteDataStore.deviceIdHashSaltStorage, it is a Ref. (WebKit::UserMediaPermissionRequestManagerProxy::requestUserMediaPermissionForFrame): Ditto. (WebKit::UserMediaPermissionRequestManagerProxy::getUserMediaPermissionInfo): Ditto. (WebKit::UserMediaPermissionRequestManagerProxy::enumerateMediaDevicesForFrame): Ditto. * UIProcess/WebsiteData/WebsiteDataStore.cpp: (WebKit::WebsiteDataStore::WebsiteDataStore): m_deviceIdHashSaltStorage is a Ref. (WebKit::WebsiteDataStore::fetchDataAndApply): Ditto. (WebKit::WebsiteDataStore::removeData): Ditto. * UIProcess/WebsiteData/WebsiteDataStore.h: (WebKit::WebsiteDataStore::deviceIdHashSaltStorage): Ditto. 2019-01-15 Alan Coon Cherry-pick r239843. rdar://problem/47260277 REGRESSION (r237658): Tap highlight limits cause the highlight to no longer show with legitimate button sizes https://bugs.webkit.org/show_bug.cgi?id=193294 Reviewed by Simon Fraser. Input type elements should always paint tap highlight (ignore size heuristic). * UIProcess/PageClient.h: * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/PageClientImplIOS.h: * UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::didGetTapHighlightGeometries): * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _showTapHighlight]): (-[WKContentView _didGetTapHighlightForRequest:color:quads:topLeftRadius:topRightRadius:bottomLeftRadius:bottomRightRadius:nodeHasBuiltInClickHandling:]): (-[WKContentView _didGetTapHighlightForRequest:color:quads:topLeftRadius:topRightRadius:bottomLeftRadius:bottomRightRadius:]): Deleted. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::didGetTapHighlightGeometries): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::sendTapHighlightForNodeIfNecessary): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239843 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-10 Zalan Bujtas REGRESSION (r237658): Tap highlight limits cause the highlight to no longer show with legitimate button sizes https://bugs.webkit.org/show_bug.cgi?id=193294 Reviewed by Simon Fraser. Input type elements should always paint tap highlight (ignore size heuristic). * UIProcess/PageClient.h: * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/PageClientImplIOS.h: * UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::didGetTapHighlightGeometries): * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _showTapHighlight]): (-[WKContentView _didGetTapHighlightForRequest:color:quads:topLeftRadius:topRightRadius:bottomLeftRadius:bottomRightRadius:nodeHasBuiltInClickHandling:]): (-[WKContentView _didGetTapHighlightForRequest:color:quads:topLeftRadius:topRightRadius:bottomLeftRadius:bottomRightRadius:]): Deleted. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::didGetTapHighlightGeometries): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::sendTapHighlightForNodeIfNecessary): 2019-01-15 Alan Coon Cherry-pick r239832. rdar://problem/47260343 Override the session configuration for cookieAcceptPolicy https://bugs.webkit.org/show_bug.cgi?id=190925 Patch by John Wilander on 2019-01-10 Reviewed by Alexey Proskuryakov and Alex Christensen. Source/WebCore/PAL: * pal/spi/cf/CFNetworkSPI.h: Declaration of _overrideSessionCookieAcceptPolicy on NSHTTPCookieStorage. Source/WebKit: * NetworkProcess/cocoa/NetworkSessionCocoa.mm: (WebKit::NetworkSessionCocoa::NetworkSessionCocoa): Now sets cookieStorage._overrideSessionCookieAcceptPolicy to YES. Source/WTF: * wtf/Platform.h: Definition of HAVE_CFNETWORK_OVERRIDE_SESSION_COOKIE_ACCEPT_POLICY. Tools: Test infrastructure for setting a first-party-only cookie policy. * DumpRenderTree/TestRunner.cpp: (setOnlyAcceptFirstPartyCookiesCallback): (TestRunner::staticFunctions): * DumpRenderTree/TestRunner.h: * DumpRenderTree/mac/TestRunnerMac.mm: (TestRunner::setOnlyAcceptFirstPartyCookies): * DumpRenderTree/win/TestRunnerWin.cpp: (TestRunner::setOnlyAcceptFirstPartyCookies): * WebKitTestRunner/InjectedBundle/Bindings/TestRunner.idl: * WebKitTestRunner/InjectedBundle/TestRunner.cpp: (WTR::TestRunner::setOnlyAcceptFirstPartyCookies): * WebKitTestRunner/InjectedBundle/TestRunner.h: * WebKitTestRunner/TestInvocation.cpp: (WTR::TestInvocation::didReceiveSynchronousMessageFromInjectedBundle): LayoutTests: * TestExpectations: Skipped since this cookie policy is only supported on Cocoa platforms. * http/tests/cookies/only-accept-first-party-cookies-expected.txt: Added. * http/tests/cookies/only-accept-first-party-cookies.html: Added. * http/tests/cookies/resources/reset-cookies.html: Added. To support reset of third-party cookies in an iframe. * http/tests/cookies/resources/set-cookie-and-redirect-back.php: Added. A simple bounce to set a cookie. * platform/ios/TestExpectations: Skipped for now. Will be fixed in . * platform/mac/TestExpectations: Skipped for now. Will be fixed in . git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239832 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-10 John Wilander Override the session configuration for cookieAcceptPolicy https://bugs.webkit.org/show_bug.cgi?id=190925 Reviewed by Alexey Proskuryakov and Alex Christensen. * NetworkProcess/cocoa/NetworkSessionCocoa.mm: (WebKit::NetworkSessionCocoa::NetworkSessionCocoa): Now sets cookieStorage._overrideSessionCookieAcceptPolicy to YES. 2019-01-15 Alan Coon Apply patch. rdar://problem/47260255 2019-01-15 Chris Dumez Better disable Automatic HTTPS upgrade Reviewed by Geoff Garen. Drop database file from the bundle as it is currently huge and increases our project size unnecessarily. Also hide the feature from the experimental feature menu since enabling it will not do anything without its database. * DerivedSources.make: * Shared/WebPreferences.yaml: * WebKit.xcodeproj/project.pbxproj: 2019-01-15 Alan Coon Revert r239446. rdar://problem/47125351 2019-01-09 Kocsen Chung Cherry-pick r239777. rdar://problem/47158629 [PSON] Flash of blank content while transitioning from page A to page B. https://bugs.webkit.org/show_bug.cgi?id=193283 Reviewed by Chris Dumez. Layer tree is not frozen during WebPage construction. If the flush timer (started for the initial empty document) manages to run before the actual page load starts, we'll get a flash. * Shared/WebPageCreationParameters.cpp: (WebKit::WebPageCreationParameters::encode const): (WebKit::WebPageCreationParameters::decode): * Shared/WebPageCreationParameters.h: Rename shouldDelayAttachingDrawingArea bit to isSwapFromSuspended and make it available on all platforms. * UIProcess/RemoteLayerTree/mac/ScrollerMac.h: Removed. * UIProcess/RemoteLayerTree/mac/ScrollerMac.mm: Removed. * UIProcess/RemoteLayerTree/mac/ScrollerPairMac.h: Removed. * UIProcess/RemoteLayerTree/mac/ScrollerPairMac.mm: Removed. * UIProcess/RemoteLayerTree/mac/ScrollingTreeFrameScrollingNodeRemoteMac.cpp: Removed. * UIProcess/RemoteLayerTree/mac/ScrollingTreeFrameScrollingNodeRemoteMac.h: Removed. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::swapToWebProcess): (WebKit::WebPageProxy::finishAttachingToWebProcess): (WebKit::WebPageProxy::initializeWebPage): (WebKit::WebPageProxy::continueNavigationInNewProcess): * UIProcess/WebPageProxy.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::m_shouldAttachDrawingAreaOnPageTransition): Freeze the layer tree in WebPage constructor if this is a swap from a suspended process. (WebKit::WebPage::reinitializeWebPage): (WebKit::WebPage::didCompletePageTransition): Unfreeze on first non-initial empty document page transition. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm: (WebKit::TiledCoreAnimationDrawingArea::TiledCoreAnimationDrawingArea): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239777 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-09 Antti Koivisto [PSON] Flash of blank content while transitioning from page A to page B. https://bugs.webkit.org/show_bug.cgi?id=193283 Reviewed by Chris Dumez. Layer tree is not frozen during WebPage construction. If the flush timer (started for the initial empty document) manages to run before the actual page load starts, we'll get a flash. * Shared/WebPageCreationParameters.cpp: (WebKit::WebPageCreationParameters::encode const): (WebKit::WebPageCreationParameters::decode): * Shared/WebPageCreationParameters.h: Rename shouldDelayAttachingDrawingArea bit to isSwapFromSuspended and make it available on all platforms. * UIProcess/RemoteLayerTree/mac/ScrollerMac.h: Removed. * UIProcess/RemoteLayerTree/mac/ScrollerMac.mm: Removed. * UIProcess/RemoteLayerTree/mac/ScrollerPairMac.h: Removed. * UIProcess/RemoteLayerTree/mac/ScrollerPairMac.mm: Removed. * UIProcess/RemoteLayerTree/mac/ScrollingTreeFrameScrollingNodeRemoteMac.cpp: Removed. * UIProcess/RemoteLayerTree/mac/ScrollingTreeFrameScrollingNodeRemoteMac.h: Removed. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::swapToWebProcess): (WebKit::WebPageProxy::finishAttachingToWebProcess): (WebKit::WebPageProxy::initializeWebPage): (WebKit::WebPageProxy::continueNavigationInNewProcess): * UIProcess/WebPageProxy.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::m_shouldAttachDrawingAreaOnPageTransition): Freeze the layer tree in WebPage constructor if this is a swap from a suspended process. (WebKit::WebPage::reinitializeWebPage): (WebKit::WebPage::didCompletePageTransition): Unfreeze on first non-initial empty document page transition. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm: (WebKit::TiledCoreAnimationDrawingArea::TiledCoreAnimationDrawingArea): 2019-01-09 Kocsen Chung Cherry-pick r239694. rdar://problem/47158722 Deactivate audio session whenever possible https://bugs.webkit.org/show_bug.cgi?id=193188 Reviewed by Jer Noble. Source/WebCore: Test: media/deactivate-audio-session.html * platform/audio/AudioSession.cpp: (WebCore::AudioSession::tryToSetActive): (WebCore::AudioSession::tryToSetActiveInternal): * platform/audio/AudioSession.h: (WebCore::AudioSession::isActive const): * platform/audio/PlatformMediaSessionManager.cpp: (WebCore::PlatformMediaSessionManager::removeSession): (WebCore::deactivateAudioSession): (WebCore::PlatformMediaSessionManager::shouldDeactivateAudioSession): (WebCore::PlatformMediaSessionManager::setShouldDeactivateAudioSession): * platform/audio/PlatformMediaSessionManager.h: * platform/audio/ios/AudioSessionIOS.mm: (WebCore::AudioSession::tryToSetActiveInternal): (WebCore::AudioSession::tryToSetActive): Deleted. * platform/audio/mac/AudioSessionMac.cpp: (WebCore::AudioSession::tryToSetActiveInternal): (WebCore::AudioSession::tryToSetActive): Deleted. * testing/Internals.cpp: (WebCore::Internals::audioSessionActive const): * testing/Internals.h: * testing/Internals.idl: Source/WebKit: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::WebPage): LayoutTests: * TestExpectations: Skip the new test. * media/deactivate-audio-session-expected.txt: Added. * media/deactivate-audio-session.html: Added. * platform/ios/TestExpectations: Run the new test. * platform/mac-wk2/TestExpectations: Ditto. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239694 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-07 Eric Carlson Deactivate audio session whenever possible https://bugs.webkit.org/show_bug.cgi?id=193188 Reviewed by Jer Noble. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::WebPage): 2019-01-09 Kocsen Chung Cherry-pick r239691. rdar://problem/47158674 [Cocoa] Add SPI to check if a WKWebView has an inspector frontend https://bugs.webkit.org/show_bug.cgi?id=193162 Patch by Joseph Pecoraro on 2019-01-07 Reviewed by Alex Christensen. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _hasInspectorFrontend]): * UIProcess/API/Cocoa/WKWebViewPrivate.h: * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::hasInspectorFrontend const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239691 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-07 Joseph Pecoraro [Cocoa] Add SPI to check if a WKWebView has an inspector frontend https://bugs.webkit.org/show_bug.cgi?id=193162 Reviewed by Alex Christensen. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _hasInspectorFrontend]): * UIProcess/API/Cocoa/WKWebViewPrivate.h: * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::hasInspectorFrontend const): 2019-01-09 Kocsen Chung Cherry-pick r239686. rdar://problem/47158659 Unwanted page navigation after showing & dismissing contextual menu with control-click https://bugs.webkit.org/show_bug.cgi?id=192912 Reviewed by Timothy Hatcher. After the conversion to use a mouse event queue, this behavior was observed rarely, especially when CPU is under load and lots of things are going on in the page. In other words, it's racy. Based on NSEvent logging, it seems that when the system is under load, we simply take too long to enter the nested runloop that AppKit uses to handle events when the context menu is present. AppKit doesn't care whether or not the MouseDown triggered a nested runloop; on my machine it delivers the MouseUp event about 130ms after the MouseDown event. If we haven't show the context menu in that time, then the MouseUp is enqueued as a normal mouse event. If the Ctrl-click is on a link, then the MouseUp will be interpreted by EventHandler as a click event, which in the simplest case will initiate a main frame navigation. When the context menu is dismissed and the nested runloop is torn down, the navigation IPC message is handled in UIProcess and the page navigates away. We can't do much to change AppKit's inherently racy behavior, but we can avoid processing mouse events that are delivered whilst we are processing the context menu-initiating event. From the WebProcess point of view, there is no race anymore because it does not receive the MouseUp event. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::showContextMenu): If new events come in, drop them on the floor. Based on testing, the nested runloop will discard the unpaired MouseUp event anyway, so this does not cause a change in behavior. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239686 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-07 Brian Burg Unwanted page navigation after showing & dismissing contextual menu with control-click https://bugs.webkit.org/show_bug.cgi?id=192912 Reviewed by Timothy Hatcher. After the conversion to use a mouse event queue, this behavior was observed rarely, especially when CPU is under load and lots of things are going on in the page. In other words, it's racy. Based on NSEvent logging, it seems that when the system is under load, we simply take too long to enter the nested runloop that AppKit uses to handle events when the context menu is present. AppKit doesn't care whether or not the MouseDown triggered a nested runloop; on my machine it delivers the MouseUp event about 130ms after the MouseDown event. If we haven't show the context menu in that time, then the MouseUp is enqueued as a normal mouse event. If the Ctrl-click is on a link, then the MouseUp will be interpreted by EventHandler as a click event, which in the simplest case will initiate a main frame navigation. When the context menu is dismissed and the nested runloop is torn down, the navigation IPC message is handled in UIProcess and the page navigates away. We can't do much to change AppKit's inherently racy behavior, but we can avoid processing mouse events that are delivered whilst we are processing the context menu-initiating event. From the WebProcess point of view, there is no race anymore because it does not receive the MouseUp event. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::showContextMenu): If new events come in, drop them on the floor. Based on testing, the nested runloop will discard the unpaired MouseUp event anyway, so this does not cause a change in behavior. 2019-01-09 Alan Coon Cherry-pick r239776. rdar://problem/47147610 WebKit Networking process crashes if the HTTPSUpgradeList is not found in the bundle https://bugs.webkit.org/show_bug.cgi?id=193285 Reviewed by Geoffrey Garen. * NetworkProcess/NetworkHTTPSUpgradeChecker.cpp: (WebKit::networkHTTPSUpgradeCheckerDatabasePath): (WebKit::NetworkHTTPSUpgradeChecker::NetworkHTTPSUpgradeChecker): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239776 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-09 Chris Dumez WebKit Networking process crashes if the HTTPSUpgradeList is not found in the bundle https://bugs.webkit.org/show_bug.cgi?id=193285 Reviewed by Geoffrey Garen. * NetworkProcess/NetworkHTTPSUpgradeChecker.cpp: (WebKit::networkHTTPSUpgradeCheckerDatabasePath): (WebKit::NetworkHTTPSUpgradeChecker::NetworkHTTPSUpgradeChecker): 2019-01-07 Alex Christensen Modernize CacheModel and disk cache fetching and clearing https://bugs.webkit.org/show_bug.cgi?id=193164 Reviewed by Joseph Pecoraro. fetchDiskCacheEntries and clearDiskCacheEntries now use an early-return model. CacheModel is now an enum class. * NetworkProcess/NetworkProcess.cpp: (WebKit::NetworkProcess::NetworkProcess): (WebKit::NetworkProcess::initializeNetworkProcess): (WebKit::fetchDiskCacheEntries): (WebKit::NetworkProcess::fetchWebsiteData): (WebKit::clearDiskCacheEntries): (WebKit::NetworkProcess::setCacheModel): * NetworkProcess/NetworkProcess.h: * NetworkProcess/NetworkProcess.messages.in: * NetworkProcess/NetworkProcessCreationParameters.h: * NetworkProcess/cache/NetworkCacheEntry.cpp: (WebKit::NetworkCache::Entry::initializeShareableResourceHandleFromStorageRecord const): * NetworkProcess/cocoa/NetworkProcessCocoa.mm: (WebKit::NetworkProcess::clearDiskCache): * Shared/CacheModel.cpp: (WebKit::calculateMemoryCacheSizes): (WebKit::calculateURLCacheSizes): * Shared/CacheModel.h: (): Deleted. * UIProcess/API/APIProcessPoolConfiguration.cpp: (API::ProcessPoolConfiguration::createWithLegacyOptions): * UIProcess/API/APIProcessPoolConfiguration.h: * UIProcess/API/C/WKAPICast.h: (WebKit::toCacheModel): (WebKit::toAPI): * UIProcess/API/Cocoa/_WKProcessPoolConfiguration.mm: (-[_WKProcessPoolConfiguration pageCacheEnabled]): (-[_WKProcessPoolConfiguration setPageCacheEnabled:]): * WebProcess/WebProcess.cpp: (WebKit::WebProcess::initializeWebProcess): (WebKit::WebProcess::setCacheModel): (WebKit::WebProcess::clearResourceCaches): * WebProcess/WebProcess.h: * WebProcess/WebProcess.messages.in: 2019-01-06 Jiewen Tan [WebAuthN] Import U2F command/response converters from Chromium https://bugs.webkit.org/show_bug.cgi?id=193150 Reviewed by Brent Fulgham. Moves helper functions to WebAuthenticationUtils. * UIProcess/WebAuthentication/Cocoa/LocalAuthenticator.mm: (WebKit::LocalAuthenticatorInternal::produceHashSet): (WebKit::LocalAuthenticator::continueMakeCredentialAfterAttested): (): Deleted. (WebKit::LocalAuthenticatorInternal::buildAuthData): Deleted. * UIProcess/WebAuthentication/Mock/MockHidConnection.cpp: (WebKit::MockHidConnection::feedReports): 2019-01-04 Joseph Pecoraro Web Inspector: Use save sheet instead of dialog where possible https://bugs.webkit.org/show_bug.cgi?id=193160 Reviewed by Devin Rousso. * UIProcess/mac/RemoteWebInspectorProxyMac.mm: (WebKit::RemoteWebInspectorProxy::platformSave): * UIProcess/mac/WebInspectorProxyMac.mm: (WebKit::WebInspectorProxy::platformSave): 2019-01-04 Jer Noble [WebKitLegacy] Media playback pauses on scroll https://bugs.webkit.org/show_bug.cgi?id=192829 Reviewed by Eric Carlson. Add a new WebPage, WebPageProxy, & WKWebView SPI to stop, suspend, and resume all existing media playback in the page. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _stopAllMediaPlayback]): (-[WKWebView _suspendAllMediaPlayback]): (-[WKWebView _resumeAllMediaPlayback]): * UIProcess/API/Cocoa/WKWebViewPrivate.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::stopAllMediaPlayback): (WebKit::WebPageProxy::suspendAllMediaPlayback): (WebKit::WebPageProxy::resumeAllMediaPlayback): * UIProcess/WebPageProxy.h: * UIProcess/ios/fullscreen/WKFullScreenViewController.mm: (-[WKFullScreenViewController _showPhishingAlert]): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::stopAllMediaPlayback): (WebKit::WebPage::suspendAllMediaPlayback): (WebKit::WebPage::resumeAllMediaPlayback): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: 2019-01-04 Chris Dumez Add support for toggling device orientation API support per site https://bugs.webkit.org/show_bug.cgi?id=193143 Reviewed by Alex Christensen. Add support for toggling device orientation API support per site via _WKWebsitePolicies. * Shared/WebsitePoliciesData.cpp: (WebKit::WebsitePoliciesData::encode const): (WebKit::WebsitePoliciesData::decode): (WebKit::WebsitePoliciesData::applyToDocumentLoader): * Shared/WebsitePoliciesData.h: * UIProcess/API/APIWebsitePolicies.cpp: (API::WebsitePolicies::data): * UIProcess/API/APIWebsitePolicies.h: * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _simulateDeviceOrientationChangeWithAlpha:beta:gamma:]): * UIProcess/API/Cocoa/WKWebViewPrivate.h: * UIProcess/API/Cocoa/_WKWebsitePolicies.h: * UIProcess/API/Cocoa/_WKWebsitePolicies.mm: (-[_WKWebsitePolicies setDeviceOrientationEventEnabled:]): (-[_WKWebsitePolicies deviceOrientationEventEnabled]): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::simulateDeviceOrientationChange): * UIProcess/WebPageProxy.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::simulateDeviceOrientationChange): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: 2019-01-04 Chris Dumez Crash under WebPageProxy::continueNavigationInNewProcess() https://bugs.webkit.org/show_bug.cgi?id=193113 Reviewed by Brady Eidson. The crash was happening in continueNavigationInNewProcess() when dereferencing the Optional<> value returned by API::Navigation::backForwardFrameLoadType(), after verifying that API::Navigation::targetItem() is not null. When constructing an API::Navigation object with a targetItem, you HAVE to pass in a backForwardFrameLoadType as well so this normally is not possible. However, it can happen because API::Navigation::setTargetItem() can get called later on and set a target item on a Navigation object which potentially does not have a backForwardFrameLoadType. This setter was only called in one place in decidePolicyForNavigationAction() to update an existing Navigation object using the targetItem provided by a NavigationAction. This logic was added with PSON support. Because I was unable to write a test case reproducing this and because I do not know how it can happen in practice that we'd have a NavigationAction with a targetItem even though the Navigation object itself is not for a back/forward navigation, I have chosen to drop the unsafe API::Navigation::setTargetItem() setter and the call site. When the call site was added, with ProcessSwap.NavigateToDataURLThenBack API test, the intention was to create a back/forward navigation object instead of a standard load navigation one if there is currently no existing Navigation object in the UIProcess. This can happen when the back/forward navigation is triggered by the WebProcess via JS (e.g. history.back()) and this is what the API test covers. The part of the logic that updates an existing Navigation object with a targetItem coming from the NavigationAction is untested and I have no evidence it does anything useful. However, we DO have evidence that it can cause crashes. * UIProcess/API/APINavigation.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::decidePolicyForNavigationAction): 2019-01-04 Tim Horton Remove some nonexistent files from the WebKit Xcode project * WebKit.xcodeproj/project.pbxproj: r238468 and r237205 forgot to remove some files from the project. 2019-01-04 Youenn Fablet CSP violation reports should bypass CSP checks https://bugs.webkit.org/show_bug.cgi?id=192857 Reviewed by Chris Dumez. * WebProcess/Network/WebLoaderStrategy.cpp: (WebKit::WebLoaderStrategy::startPingLoad): * WebProcess/Network/WebLoaderStrategy.h: 2019-01-04 Alex Christensen Use WebsiteDataStoreParameters instead of NetworkProcessCreationParameters for IndexedDB directories https://bugs.webkit.org/show_bug.cgi?id=193114 Reviewed by Brady Eidson. * NetworkProcess/NetworkProcess.cpp: (WebKit::NetworkProcess::initializeNetworkProcess): * NetworkProcess/NetworkProcessCreationParameters.cpp: (WebKit::NetworkProcessCreationParameters::encode const): (WebKit::NetworkProcessCreationParameters::decode): * NetworkProcess/NetworkProcessCreationParameters.h: * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::ensureNetworkProcess): 2019-01-04 Alex Christensen Deprecate WKContextCreate https://bugs.webkit.org/show_bug.cgi?id=193118 Reviewed by Brady Eidson. It has only one use that is being removed in rdar://problem/47030792 This is a step towards removing ProcessPoolConfiguration::createWithLegacyOptions. Also make WKContextCreateWithConfiguration accept a null configuration to make it easier to use. * UIProcess/API/C/WKContext.cpp: (WKContextCreateWithConfiguration): * UIProcess/API/C/WKContext.h: 2019-01-04 Tim Horton Fix the build * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView cleanupInteraction]): 2019-01-04 Tim Horton Share ink choice and ruler between all editable images https://bugs.webkit.org/show_bug.cgi?id=193130 Reviewed by Wenson Hsieh. * SourcesCocoa.txt: Add WKDrawingCoordinator, which maintains WKWebView-wide drawing state, and manages a single shared ink picker. * UIProcess/PageClient.h: (WebKit::PageClient::createDrawingView): * UIProcess/ios/EditableImageController.mm: (WebKit::EditableImageController::ensureEditableImage): * UIProcess/ios/PageClientImplIOS.h: * UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::createDrawingView): Plumb WKDrawingView creation through PageClient, so that it can be instantiated with knowledge of its owning WKContentView. * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _elementDidFocus:userIsInteracting:blurPreviousNode:changingActivityState:userObject:]): (-[WKContentView _elementDidBlur]): (-[WKContentView _drawingCoordinator]): (-[WKContentView _installInkPickerForDrawingViewWithID:]): Deleted. (-[WKContentView _uninstallInkPicker]): Deleted. Move ink picker management into WKDrawingCoordinator. * UIProcess/ios/WKDrawingView.h: * UIProcess/ios/WKDrawingView.mm: (-[WKDrawingView initWithEmbeddedViewID:contentView:]): (-[WKDrawingView _canvasViewWillBeginDrawing:]): (-[WKDrawingView invalidateAttachment]): (-[WKDrawingView didChangeRulerState:]): (-[WKDrawingView initWithEmbeddedViewID:webPageProxy:]): Deleted. (-[WKDrawingView canvasView]): Deleted. Use a shared ruler, owned by WKDrawingCoordinator. Update the editable image's ink when drawing begins. This way, we don't have to push ink changes to all drawings as they happen. * UIProcess/ios/WKInkPickerView.h: * UIProcess/ios/WKInkPickerView.mm: (-[WKInkPickerView initWithContentView:]): (-[WKInkPickerView inlineInkPickerDidToggleRuler:]): (-[WKInkPickerView viewControllerForPopoverPresentationFromInlineInkPicker:]): (-[WKInkPickerView setInk:]): (-[WKInkPickerView ink]): (-[WKInkPickerView initWithDrawingView:]): Deleted. (-[WKInkPickerView didPickInk]): Deleted. (-[WKInkPickerView inlineInkPicker:didSelectTool:]): Deleted. (-[WKInkPickerView inlineInkPicker:didSelectColor:]): Deleted. * WebKit.xcodeproj/project.pbxproj: 2019-01-04 Wenson Hsieh [Cocoa] Merge WebEditCommandProxy::nameForEditAction and undoNameForEditAction into a single function https://bugs.webkit.org/show_bug.cgi?id=193129 Reviewed by Tim Horton. Remove WebEditCommandProxy::nameForEditAction and use WebCore::nameForUndoRedo instead. * UIProcess/Cocoa/WebViewImpl.mm: (WebKit::WebViewImpl::registerEditCommand): * UIProcess/WebEditCommandProxy.cpp: (WebKit::WebEditCommandProxy::WebEditCommandProxy): (WebKit::WebEditCommandProxy::~WebEditCommandProxy): (WebKit::WebEditCommandProxy::nameForEditAction): Deleted. * UIProcess/WebEditCommandProxy.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::addEditCommand): (WebKit::WebPageProxy::removeEditCommand): (WebKit::WebPageProxy::isValidEditCommand): Deleted. Bit of drive-by refactoring: remove an unused function, and make addEditCommand and removeEditCommand take references instead of pointers, since these are assumed to be nonnull. * UIProcess/WebPageProxy.h: * UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::registerEditCommand): 2019-01-03 Matt Rajca Make DidPlayMediaPreventedFromPlaying autoplay event more generic. https://bugs.webkit.org/show_bug.cgi?id=193128 rdar://34554231 Reviewed by Jer Noble. Today, the "DidPlayMediaPreventedFromPlaying" autoplay event is only sent for media prevented from autoplaying. It could be generalized to a "DidPlayMediaWithUserGesture" event along with a flag that indicates whether or not autoplay was actually prevented. Tests: existing API tests were updated to reflect the new names. New API tests were added for the new case in which the "DidPlayMediaWithUserGesture" event is sent. * Shared/WebCoreArgumentCoders.h: Take into account new flags. * UIProcess/API/C/WKPage.cpp: Ditto. (WKPageSetPageUIClient): * UIProcess/API/C/WKPageUIClient.h: Ditto. * UIProcess/API/Cocoa/WKUIDelegatePrivate.h: Ditto. * UIProcess/Cocoa/UIDelegate.mm: Ditto. (WebKit::toWKAutoplayEventFlags): (WebKit::toWKAutoplayEvent): 2019-01-04 Fujii Hironori [curl] Move cookiePersistentStorageFile from NetworkProcessCreationParameters to NetworkSessionCreationParameters https://bugs.webkit.org/show_bug.cgi?id=192970 Reviewed by Alex Christensen. * NetworkProcess/NetworkProcessCreationParameters.cpp: (WebKit::NetworkProcessCreationParameters::encode const): Removed code for cookiePersistentStorageFile. (WebKit::NetworkProcessCreationParameters::decode): Ditto. * NetworkProcess/NetworkProcessCreationParameters.h: Ditto. * NetworkProcess/curl/NetworkProcessCurl.cpp: (WebKit::NetworkProcess::platformInitializeNetworkProcess): Ditto. * NetworkProcess/NetworkSessionCreationParameters.cpp: (WebKit::NetworkSessionCreationParameters::privateSessionParameters): Added code for cookiePersistentStorageFile. (WebKit::NetworkSessionCreationParameters::encode const): Ditto. (WebKit::NetworkSessionCreationParameters::decode): Ditto. * NetworkProcess/NetworkSessionCreationParameters.h: Ditto. * NetworkProcess/curl/NetworkSessionCurl.cpp: (WebKit::NetworkSessionCurl::NetworkSessionCurl): Ditto. * NetworkProcess/Cookies/WebCookieManager.h: Removed setCookiePersistentStorage method of curl port extension. * NetworkProcess/Cookies/curl/WebCookieManagerCurl.cpp: (WebKit::WebCookieManager::setCookiePersistentStorage): Deleted. 2019-01-04 Chris Dumez [PSON] Calling history.back() from inside the load event handler prevents process-swapping https://bugs.webkit.org/show_bug.cgi?id=193120 Reviewed by Alex Christensen. A HistoryItem is created only *after* we've fired the load event. As a result, if you call history.back() in JS from inside the load event handler, the current HistoryItem and and the target HistoryItem will be the same. This is normally not an issue. However, there was logic inside of WebProcessPool::processForNavigationInternal() which would compare the processID of the source and destination BackForwardListItems and which would force a process reuse if both BackForwardListItems came from the same WebContent process. So even though we swapped when doing a standard load from site A to site B, we would fail to swap if site B called history.back() from inside its load event handler. To address the issue, stop relying on the source backforward item's processID. Instead, just use the WebContent process matching the destination backforward item's processID if it still exists. * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::processForNavigationInternal): 2019-01-04 Keith Rollin Bring back parent processID for logging https://bugs.webkit.org/show_bug.cgi?id=193121 Reviewed by Alex Christensen. Bug 192961 removes presentingApplicationPID from NetworkProcessCreationParameters because it was (a) stored in some global state, the use of which is being minimized, and (b) it was largely unused. However, it was actually still being used in some useful logging in order to tie together child processes with their parent process. Re-introduce this value in NetworkLoadParameters so that we can log it. * NetworkProcess/NetworkLoadParameters.h: * NetworkProcess/NetworkResourceLoadParameters.cpp: (WebKit::NetworkResourceLoadParameters::encode const): (WebKit::NetworkResourceLoadParameters::decode): * NetworkProcess/NetworkResourceLoader.cpp: (WebKit::NetworkResourceLoader::start): * WebProcess/Network/WebLoaderStrategy.cpp: (WebKit::WebLoaderStrategy::scheduleLoadFromNetworkProcess): (WebKit::WebLoaderStrategy::loadResourceSynchronously): (WebKit::WebLoaderStrategy::startPingLoad): (WebKit::WebLoaderStrategy::preconnectTo): 2019-01-04 Youenn Fablet Make RestrictedHTTPResponseAccess an internal flag https://bugs.webkit.org/show_bug.cgi?id=193145 Reviewed by Chris Dumez. * Shared/WebPreferences.yaml: This will ease debugging. 2019-01-04 Per Arne Vollan [iOS] Enable logging for services in sandbox https://bugs.webkit.org/show_bug.cgi?id=192705 Reviewed by Brent Fulgham. When running layout tests, we didn’t see 107 services being looked up through launchd. We should add logging to these services to determine which services we actually need in the sandbox. * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb: 2019-01-04 Commit Queue Unreviewed, rolling out r239603. https://bugs.webkit.org/show_bug.cgi?id=193146 Breaks shipping tests (Requested by bfulgha__ on #webkit). Reverted changeset: "[iOS] Update sandbox profile to use iconservices instead of lsdiconservice" https://bugs.webkit.org/show_bug.cgi?id=193115 https://trac.webkit.org/changeset/239603 2019-01-04 Chris Dumez Crash under WebProcessPool::addSuspendedPage() https://bugs.webkit.org/show_bug.cgi?id=193110 Reviewed by Youenn Fablet. When PageCache is disabled, WebProcessPool::m_maxSuspendedPageCount is 0 and WebProcessPool::addSuspendedPage() would call m_suspendedPages.removeFirst() even though m_suspendedPages is empty, causing a crash. Do an early return when m_maxSuspendedPageCount is 0 since we do not want to add any suspended page in this case. * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::addSuspendedPage): 2019-01-03 Brent Fulgham [iOS] Silently deny access to mail settings triggered by MessageUI framework https://bugs.webkit.org/show_bug.cgi?id=193123 Reviewed by Alexey Proskuryakov. Remove unhelpful logging generated when we block access to non-WebKit preferences. These invalid checks are done by an system framework that we cannot modify. * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb: 2019-01-03 Brent Fulgham [iOS] Update sandbox profile to use iconservices instead of lsdiconservice https://bugs.webkit.org/show_bug.cgi?id=193115 Reviewed by Eric Carlson. * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb: 2019-01-03 Brent Fulgham Remove logic handling DNT header during redirects https://bugs.webkit.org/show_bug.cgi?id=193082 Reviewed by Chris Dumez. Test: http/wpt/fetch/dnt-header-after-redirection.html. Don't bother looking for (or passing along) DNT headers during redirects. * NetworkProcess/NetworkLoadChecker.cpp: (WebKit::NetworkLoadChecker::check): (WebKit::NetworkLoadChecker::prepareRedirectedRequest): Deleted. * NetworkProcess/NetworkLoadChecker.h: * NetworkProcess/NetworkResourceLoader.cpp: (WebKit::NetworkResourceLoader::restartNetworkLoad): (WebKit::NetworkResourceLoader::continueWillSendRequest): * NetworkProcess/PingLoad.cpp: (WebKit::PingLoad::willPerformHTTPRedirection): 2019-01-03 Chris Dumez Add release logging to help debug HTTPS upgrade issues https://bugs.webkit.org/show_bug.cgi?id=193075 Reviewed by Alex Christensen. Add release logging to help debug HTTPS upgrade issues like Bug 193026. * NetworkProcess/NetworkHTTPSUpgradeChecker.cpp: (WebKit::NetworkHTTPSUpgradeChecker::NetworkHTTPSUpgradeChecker): (WebKit::NetworkHTTPSUpgradeChecker::query): 2019-01-03 Alex Christensen NetworkProcess should initialize its default NetworkSession with parameters from the UIProcess https://bugs.webkit.org/show_bug.cgi?id=192967 Reviewed by Brent Fulgham. I moved 3 of the NetworkProcessCreationParameters to use corresponding values of a WebsiteDataStoreParameters. More will be moved in the near future, like indexedDatabaseDirectory. * NetworkProcess/NetworkProcess.cpp: (WebKit::NetworkProcess::initializeNetworkProcess): * NetworkProcess/NetworkProcessCreationParameters.cpp: (WebKit::NetworkProcessCreationParameters::encode const): (WebKit::NetworkProcessCreationParameters::decode): * NetworkProcess/NetworkProcessCreationParameters.h: * UIProcess/Cocoa/WebProcessPoolCocoa.mm: (WebKit::WebProcessPool::platformInitializeNetworkProcess): * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::ensureNetworkProcess): 2019-01-03 Wenson Hsieh [iOS] REGRESSION (r239441): Tab cycling to offscreen