2019-08-27 Alan Coon <alancoon@apple.com> Revert r249147. rdar://problem/54751753 2019-08-27 Alan Coon <alancoon@apple.com> Cherry-pick r249147. rdar://problem/54751753 Removing fullscreen element in rAF() callback after requestFullscreen() can leave fullscreen in inconsistent state. https://bugs.webkit.org/show_bug.cgi?id=201101 <rdar://problem/54164587> Reviewed by Eric Carlson. Source/WebCore: Test: fullscreen/full-screen-request-removed-with-raf.html Add a new state variable, m_pendingFullscreenElement, to track which element is about to become the fullscreen element, so that when elements are removed or cancelFullscreen() is called, the state machine inside the fullscreen algorithm can cancel effectively. * dom/FullscreenManager.cpp: (WebCore::FullscreenManager::requestFullscreenForElement): (WebCore::FullscreenManager::cancelFullscreen): (WebCore::FullscreenManager::exitFullscreen): (WebCore::FullscreenManager::willEnterFullscreen): (WebCore::FullscreenManager::willExitFullscreen): (WebCore::FullscreenManager::didExitFullscreen): (WebCore::FullscreenManager::adjustFullscreenElementOnNodeRemoval): (WebCore::FullscreenManager::clear): (WebCore::FullscreenManager::fullscreenElementRemoved): Deleted. * dom/FullscreenManager.h: Source/WebKit: Add more state to track in which direction the animation is flowing to allow in-process animations to be cancelled more gracefully. * UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm: (-[WKFullScreenWindowController enterFullScreen]): (-[WKFullScreenWindowController beganEnterFullScreenWithInitialFrame:finalFrame:]): (-[WKFullScreenWindowController requestExitFullScreen]): (-[WKFullScreenWindowController exitFullScreen]): * WebProcess/cocoa/VideoFullscreenManager.h: (WebKit::VideoFullscreenInterfaceContext::animationState const): (WebKit::VideoFullscreenInterfaceContext::setAnimationState): (WebKit::VideoFullscreenInterfaceContext::isAnimating const): Deleted. (WebKit::VideoFullscreenInterfaceContext::setIsAnimating): Deleted. * WebProcess/cocoa/VideoFullscreenManager.mm: (WebKit::VideoFullscreenManager::enterVideoFullscreenForVideoElement): (WebKit::VideoFullscreenManager::exitVideoFullscreenForVideoElement): (WebKit::VideoFullscreenManager::didEnterFullscreen): (WebKit::VideoFullscreenManager::didCleanupFullscreen): LayoutTests: * fullscreen/full-screen-request-removed-with-raf-expected.txt: Added. * fullscreen/full-screen-request-removed-with-raf.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249147 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-26 Jer Noble <jer.noble@apple.com> Removing fullscreen element in rAF() callback after requestFullscreen() can leave fullscreen in inconsistent state. https://bugs.webkit.org/show_bug.cgi?id=201101 <rdar://problem/54164587> Reviewed by Eric Carlson. Add more state to track in which direction the animation is flowing to allow in-process animations to be cancelled more gracefully. * UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm: (-[WKFullScreenWindowController enterFullScreen]): (-[WKFullScreenWindowController beganEnterFullScreenWithInitialFrame:finalFrame:]): (-[WKFullScreenWindowController requestExitFullScreen]): (-[WKFullScreenWindowController exitFullScreen]): * WebProcess/cocoa/VideoFullscreenManager.h: (WebKit::VideoFullscreenInterfaceContext::animationState const): (WebKit::VideoFullscreenInterfaceContext::setAnimationState): (WebKit::VideoFullscreenInterfaceContext::isAnimating const): Deleted. (WebKit::VideoFullscreenInterfaceContext::setIsAnimating): Deleted. * WebProcess/cocoa/VideoFullscreenManager.mm: (WebKit::VideoFullscreenManager::enterVideoFullscreenForVideoElement): (WebKit::VideoFullscreenManager::exitVideoFullscreenForVideoElement): (WebKit::VideoFullscreenManager::didEnterFullscreen): (WebKit::VideoFullscreenManager::didCleanupFullscreen): 2019-08-27 Alan Coon <alancoon@apple.com> Cherry-pick r249074. rdar://problem/54735492 [iOS] [WebKit2] Tapping on the “I’m” text suggestion after typing “i’” does nothing https://bugs.webkit.org/show_bug.cgi?id=201085 <rdar://problem/53056118> Reviewed by Tim Horton. Source/WebCore: Exposes an existing quote folding function as a helper on TextIterator, and also adjusts foldQuoteMarks to take a const String& rather than a String. See WebKit ChangeLog for more details. * editing/TextIterator.cpp: (WebCore::foldQuoteMarks): (WebCore::SearchBuffer::SearchBuffer): * editing/TextIterator.h: Source/WebKit: Currently, logic in applyAutocorrectionInternal only selects the range to autocorrect if the text of the range matches the string to replace (delivered to us from UIKit). In the case of changing "I’" to "I’m", the string to replace is "I'" (with a straight quote rather than an apostrophe), even though the DOM contains an apostrophe. This is because kbd believes that the document context contains straight quotes (rather than apostrophes). For native text views, this works out because UIKit uses relative UITextPositions to determine the replacement range rather than by checking against the contents of the document. However, WKWebView does not have the ability to synchronously compute and reason about arbitrary UITextPositions relative to the selection, so we instead search for the string near the current selection when applying autocorrections. Of course, this doesn't work in this scenario because the replacement string contains a straight quote, yet the text node contains an apostrophe, so we bail and don't end up replacing any text. To address this, we repurpose TextIterator helpers currently used to allow find-in-page to match straight quotes against apostrophes; instead of matching the replacement string exactly, we instead match the quote-folded versions of these strings when finding the range to replace. Test: fast/events/ios/autocorrect-with-apostrophe.html * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::applyAutocorrectionInternal): LayoutTests: Add a new layout test to verify that "I’" can be autocorrected to "I’m". * fast/events/ios/autocorrect-with-apostrophe-expected.txt: Added. * fast/events/ios/autocorrect-with-apostrophe.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249074 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-23 Wenson Hsieh <wenson_hsieh@apple.com> [iOS] [WebKit2] Tapping on the “I’m” text suggestion after typing “i’” does nothing https://bugs.webkit.org/show_bug.cgi?id=201085 <rdar://problem/53056118> Reviewed by Tim Horton. Currently, logic in applyAutocorrectionInternal only selects the range to autocorrect if the text of the range matches the string to replace (delivered to us from UIKit). In the case of changing "I’" to "I’m", the string to replace is "I'" (with a straight quote rather than an apostrophe), even though the DOM contains an apostrophe. This is because kbd believes that the document context contains straight quotes (rather than apostrophes). For native text views, this works out because UIKit uses relative UITextPositions to determine the replacement range rather than by checking against the contents of the document. However, WKWebView does not have the ability to synchronously compute and reason about arbitrary UITextPositions relative to the selection, so we instead search for the string near the current selection when applying autocorrections. Of course, this doesn't work in this scenario because the replacement string contains a straight quote, yet the text node contains an apostrophe, so we bail and don't end up replacing any text. To address this, we repurpose TextIterator helpers currently used to allow find-in-page to match straight quotes against apostrophes; instead of matching the replacement string exactly, we instead match the quote-folded versions of these strings when finding the range to replace. Test: fast/events/ios/autocorrect-with-apostrophe.html * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::applyAutocorrectionInternal): 2019-08-22 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r249006. rdar://problem/54600921 Typing Korean in title field after typing in the body inserts extraneous characters on blog.naver.com https://bugs.webkit.org/show_bug.cgi?id=201023 <rdar://problem/54294794> Reviewed by Ryosuke Niwa. Source/WebCore: Ensures that we recognize the blog editor on blog.naver.com to be a hidden editable area. This website places focus inside an editable body element of a subframe that is completely empty (width: 0 and border: 0). See the WebKit ChangeLog for more details. Test: editing/selection/ios/do-not-show-selection-in-empty-borderless-subframe.html * rendering/RenderLayer.cpp: (WebCore::RenderLayer::calculateClipRects const): Source/WebKit: After r242833, we began to avoid sending redundant ElementDidFocus updates in the case where a focused element was blurred and refocused within the same runloop. This was done to prevent the input view from flickering due to input view reloading, as well as scrolling to reveal the focused element, when tapping to change selection on Microsoft Word online. However, on blog.naver.com, these ElementDidFocus messages were necessary in order to ensure that the platform input context changes when moving between the title and body fields, or when tapping to change selection. This is because blog.naver.com uses a hidden contenteditable area under a subframe (see WebCore ChangeLog for more detail here). While text is never directly inserted into this hidden contenteditable, the events are observed and used to "play back" editing in the main visible content area. Thus, when moving between the title and body fields (or when changing selection within either), the only hint we get is that the hidden editable element is blurred and immediately refocused. Since we no longer send ElementDidFocus updates in this scenario, UIKeyboardImpl and kbd are not aware that the page has effectively changed input contexts. Combined with the fact that Korean IME on iOS may insert additional text given the document context (i.e. text that the input manager, kbd, thinks we've previously inserted), this means that when typing several characters into the body field on naver and then switching to edit the title, initial keystrokes may insert unexpected text in the title field. To fix this, we add some hooks to notify the UI process when an element that was blurred has been immediately refocused. Upon receiving this message, the UI process then tells UIKeyboardImpl to re-retrieve its input context, which calls into -requestAutocorrectionContextWithCompletionHandler: in WKContentView. While notorious for being synchronous IPC, this is mitigated by (1) being limiting to only instances where we have a hidden editable area, and (2) being limited by a batching mechanism in the web process, such that if the focused element is blurred, refocused, re-blurred, and refocused many times in the same runloop, we'll only send a single UpdateInputContextAfterBlurringAndRefocusingElement message (as opposed to the many ElementDidFocus messages we would've sent in previous releases). * Platform/spi/ios/UIKitSPI.h: * UIProcess/PageClient.h: * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: Add a new mechanism to update the platform input context (on iOS, UIKeyboardImpl's document state) when focus moves away from and immediately returns to a hidden editable element. * UIProcess/ios/PageClientImplIOS.h: * UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::updateInputContextAfterBlurringAndRefocusingElement): * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _updateInputContextAfterBlurringAndRefocusingElement]): Tell the active UIKeyboardImpl to refetch document state from the WKContentView. While this does result in a new autocorrection context request (which, unfortunately, triggers synchronous IPC to the web process), this request would've still happened anyways in the case where we would previously have sent an ElementDidFocus message. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::updateInputContextAfterBlurringAndRefocusingElement): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::elementDidFocus): In the case where we avoid sending a full ElementDidFocus message to the UI process due to refocusing the same element, we should still notify the UI process so that it can synchronize state between the application process and kbd. See above for more details. (WebKit::WebPage::elementDidBlur): (WebKit::WebPage::updateInputContextAfterBlurringAndRefocusingElementIfNeeded): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::updateInputContextAfterBlurringAndRefocusingElementIfNeeded): LayoutTests: Add a new layout test to verify that we suppress text interactions when focusing an editable element inside an empty, borderless subframe. * editing/selection/ios/do-not-show-selection-in-empty-borderless-subframe-expected.txt: Added. * editing/selection/ios/do-not-show-selection-in-empty-borderless-subframe.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249006 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-22 Wenson Hsieh <wenson_hsieh@apple.com> Typing Korean in title field after typing in the body inserts extraneous characters on blog.naver.com https://bugs.webkit.org/show_bug.cgi?id=201023 <rdar://problem/54294794> Reviewed by Ryosuke Niwa. After r242833, we began to avoid sending redundant ElementDidFocus updates in the case where a focused element was blurred and refocused within the same runloop. This was done to prevent the input view from flickering due to input view reloading, as well as scrolling to reveal the focused element, when tapping to change selection on Microsoft Word online. However, on blog.naver.com, these ElementDidFocus messages were necessary in order to ensure that the platform input context changes when moving between the title and body fields, or when tapping to change selection. This is because blog.naver.com uses a hidden contenteditable area under a subframe (see WebCore ChangeLog for more detail here). While text is never directly inserted into this hidden contenteditable, the events are observed and used to "play back" editing in the main visible content area. Thus, when moving between the title and body fields (or when changing selection within either), the only hint we get is that the hidden editable element is blurred and immediately refocused. Since we no longer send ElementDidFocus updates in this scenario, UIKeyboardImpl and kbd are not aware that the page has effectively changed input contexts. Combined with the fact that Korean IME on iOS may insert additional text given the document context (i.e. text that the input manager, kbd, thinks we've previously inserted), this means that when typing several characters into the body field on naver and then switching to edit the title, initial keystrokes may insert unexpected text in the title field. To fix this, we add some hooks to notify the UI process when an element that was blurred has been immediately refocused. Upon receiving this message, the UI process then tells UIKeyboardImpl to re-retrieve its input context, which calls into -requestAutocorrectionContextWithCompletionHandler: in WKContentView. While notorious for being synchronous IPC, this is mitigated by (1) being limiting to only instances where we have a hidden editable area, and (2) being limited by a batching mechanism in the web process, such that if the focused element is blurred, refocused, re-blurred, and refocused many times in the same runloop, we'll only send a single UpdateInputContextAfterBlurringAndRefocusingElement message (as opposed to the many ElementDidFocus messages we would've sent in previous releases). * Platform/spi/ios/UIKitSPI.h: * UIProcess/PageClient.h: * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: Add a new mechanism to update the platform input context (on iOS, UIKeyboardImpl's document state) when focus moves away from and immediately returns to a hidden editable element. * UIProcess/ios/PageClientImplIOS.h: * UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::updateInputContextAfterBlurringAndRefocusingElement): * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _updateInputContextAfterBlurringAndRefocusingElement]): Tell the active UIKeyboardImpl to refetch document state from the WKContentView. While this does result in a new autocorrection context request (which, unfortunately, triggers synchronous IPC to the web process), this request would've still happened anyways in the case where we would previously have sent an ElementDidFocus message. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::updateInputContextAfterBlurringAndRefocusingElement): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::elementDidFocus): In the case where we avoid sending a full ElementDidFocus message to the UI process due to refocusing the same element, we should still notify the UI process so that it can synchronize state between the application process and kbd. See above for more details. (WebKit::WebPage::elementDidBlur): (WebKit::WebPage::updateInputContextAfterBlurringAndRefocusingElementIfNeeded): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::updateInputContextAfterBlurringAndRefocusingElementIfNeeded): 2019-08-21 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r248974. rdar://problem/54579634 [Mail] Tapping top of message scrolls back to copied text instead of top of the message https://bugs.webkit.org/show_bug.cgi?id=200999 <rdar://problem/54564878> Reviewed by Wenson Hsieh. Source/WebCore: Test: editing/selection/ios/change-selection-by-tapping-with-existing-selection.html * page/EditorClient.h: (WebCore::EditorClient::shouldAllowSingleClickToChangeSelection const): * page/EventHandler.cpp: (WebCore::EventHandler::handleMousePressEventSingleClick): Instead of encoding platform behaviors in EventHandler, defer to EditorClient. Source/WebKit: In the case where you have a WebCore selection but are not first responder, when you tap the WKWebView to become first responder, EventHandler would bail from setting the selection, assuming UIKit was going to do it. This behavior was introduced in r233311. However, since we are not first responder, UIKit does not change the selection, since it considers the view to not be editable. Fix this by letting WebCore set the selection in this case, as it used to. * WebProcess/WebCoreSupport/WebEditorClient.h: * WebProcess/WebCoreSupport/ios/WebEditorClientIOS.mm: (WebKit::WebEditorClient::shouldAllowSingleClickToChangeSelection const): * WebProcess/WebPage/WebPage.h: (WebKit::WebPage::isShowingInputViewForFocusedElement const): Copy the logic from EventHandler, with the added caveat (which fixes the aforementioned behavior) that we will allow EventHandler to change the selection if we don't have a focused node in the UIKit sense, because we know that the platform text interaction code will *not* change the selection if that is the case, so it's up to us. Source/WebKitLegacy/mac: * WebCoreSupport/WebEditorClient.h: * WebCoreSupport/WebEditorClient.mm: (WebEditorClient::shouldAllowSingleClickToChangeSelection const): Copy the existing behavior from EventHandler. We do not fix the bug in WebKitLegacy for a multitude of reasons, primarily because we do not know of any user impact. LayoutTests: * editing/selection/ios/change-selection-by-tapping-with-existing-selection-expected.txt: Added. * editing/selection/ios/change-selection-by-tapping-with-existing-selection.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248974 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-21 Tim Horton <timothy_horton@apple.com> [Mail] Tapping top of message scrolls back to copied text instead of top of the message https://bugs.webkit.org/show_bug.cgi?id=200999 <rdar://problem/54564878> Reviewed by Wenson Hsieh. In the case where you have a WebCore selection but are not first responder, when you tap the WKWebView to become first responder, EventHandler would bail from setting the selection, assuming UIKit was going to do it. This behavior was introduced in r233311. However, since we are not first responder, UIKit does not change the selection, since it considers the view to not be editable. Fix this by letting WebCore set the selection in this case, as it used to. * WebProcess/WebCoreSupport/WebEditorClient.h: * WebProcess/WebCoreSupport/ios/WebEditorClientIOS.mm: (WebKit::WebEditorClient::shouldAllowSingleClickToChangeSelection const): * WebProcess/WebPage/WebPage.h: (WebKit::WebPage::isShowingInputViewForFocusedElement const): Copy the logic from EventHandler, with the added caveat (which fixes the aforementioned behavior) that we will allow EventHandler to change the selection if we don't have a focused node in the UIKit sense, because we know that the platform text interaction code will *not* change the selection if that is the case, so it's up to us. 2019-08-21 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r248959. rdar://problem/54579630 Crash under StringImpl::~StringImpl() in NetworkProcess::deleteWebsiteDataForRegistrableDomains() https://bugs.webkit.org/show_bug.cgi?id=200986 <rdar://problem/32850192> Reviewed by Brent Fulgham. Code was calling postStorageTask() with a lambda that captures Strings that are not isolated copied. The lambda would get executed on another thread so this is not safe. The CrossThreadTask constructor does not take care of this for you, despite its name (the createCrossThreadTask() function does though). * NetworkProcess/NetworkProcess.cpp: (WebKit::NetworkProcess::fetchWebsiteData): (WebKit::NetworkProcess::deleteWebsiteDataForRegistrableDomains): (WebKit::NetworkProcess::registrableDomainsWithWebsiteData): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248959 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-21 Chris Dumez <cdumez@apple.com> Crash under StringImpl::~StringImpl() in NetworkProcess::deleteWebsiteDataForRegistrableDomains() https://bugs.webkit.org/show_bug.cgi?id=200986 <rdar://problem/32850192> Reviewed by Brent Fulgham. Code was calling postStorageTask() with a lambda that captures Strings that are not isolated copied. The lambda would get executed on another thread so this is not safe. The CrossThreadTask constructor does not take care of this for you, despite its name (the createCrossThreadTask() function does though). * NetworkProcess/NetworkProcess.cpp: (WebKit::NetworkProcess::fetchWebsiteData): (WebKit::NetworkProcess::deleteWebsiteDataForRegistrableDomains): (WebKit::NetworkProcess::registrableDomainsWithWebsiteData): 2019-08-20 Babak Shafiei <bshafiei@apple.com> Cherry-pick r248928. rdar://problem/54543351 [iOS] REGRESSION (248501): gmail.com images are still not shown on some versions of iPhone iOS13 https://bugs.webkit.org/show_bug.cgi?id=200948 Patch by Said Abou-Hallawa <sabouhallawa@apple.com> on 2019-08-20 Reviewed by Tim Horton. Apply the gmail.com quirk for all iPhone iOS versions till the gmail.com bug is fixed. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::platformUserAgent const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248928 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-20 Said Abou-Hallawa <sabouhallawa@apple.com> [iOS] REGRESSION (248501): gmail.com images are still not shown on some versions of iPhone iOS13 https://bugs.webkit.org/show_bug.cgi?id=200948 Reviewed by Tim Horton. Apply the gmail.com quirk for all iPhone iOS versions till the gmail.com bug is fixed. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::platformUserAgent const): 2019-08-20 Babak Shafiei <bshafiei@apple.com> Cherry-pick r248902. rdar://problem/54543355 Unsafe usage of CookieStorageObserver from a background thread https://bugs.webkit.org/show_bug.cgi?id=200920 Reviewed by Alex Christensen. Source/WebCore: Unsafe usage of CookieStorageObserver from a background thread. CookieStorageObserver gets constructed / destructed on the main thread. However, CookieStorageObserver::cookiesDidChange() gets called on a background thread and tries to ref |this|. Even though CookieStorageObserver is ThreadSafeRefCounted, this is still unsafe because the CookieStorageObserver destructor may already be running on the main thread when CookieStorageObserver::cookiesDidChange() gets called on the background thread. * platform/network/NetworkStorageSession.h: * platform/network/cocoa/CookieStorageObserver.h: * platform/network/cocoa/CookieStorageObserver.mm: (WebCore::CookieStorageObserver::CookieStorageObserver): (WebCore::CookieStorageObserver::cookiesDidChange): (WebCore::CookieStorageObserver::create): Deleted. * platform/network/cocoa/NetworkStorageSessionCocoa.mm: (WebCore::NetworkStorageSession::cookieStorageObserver const): Source/WebKit: * UIProcess/API/APIHTTPCookieStore.h: * UIProcess/API/Cocoa/APIHTTPCookieStoreCocoa.mm: (API::HTTPCookieStore::startObservingChangesToDefaultUIProcessCookieStore): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248902 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-20 Chris Dumez <cdumez@apple.com> Unsafe usage of CookieStorageObserver from a background thread https://bugs.webkit.org/show_bug.cgi?id=200920 Reviewed by Alex Christensen. * UIProcess/API/APIHTTPCookieStore.h: * UIProcess/API/Cocoa/APIHTTPCookieStoreCocoa.mm: (API::HTTPCookieStore::startObservingChangesToDefaultUIProcessCookieStore): 2019-08-18 Babak Shafiei <bshafiei@apple.com> Cherry-pick r248832. rdar://problem/54454547 [Mac] Use the PID of the WebContent process when issuing local file read sandbox extensions https://bugs.webkit.org/show_bug.cgi?id=200543 <rdar://problem/49394015> Source/WebKit: Reviewed by Brent Fulgham. Adopt SPI to issue a process-specific sandbox extension for local file read, passing it the process identifier of the WebContent process. * Shared/Cocoa/SandboxExtensionCocoa.mm: (WebKit::SandboxExtensionImpl::sandboxExtensionForType): (WebKit::SandboxExtension::createHandleForReadByPid): * Shared/SandboxExtension.h: * UIProcess/Cocoa/WebPageProxyCocoa.mm: (WebKit::WebPageProxy::createSandboxExtensionsIfNeeded): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle): (WebKit::WebPageProxy::loadFile): Source/WTF: Reviewed by Brent Fulgham. Add new SPI. * wtf/Platform.h: * wtf/spi/darwin/SandboxSPI.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248832 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-18 Per Arne Vollan <pvollan@apple.com> [Mac] Use the PID of the WebContent process when issuing local file read sandbox extensions https://bugs.webkit.org/show_bug.cgi?id=200543 <rdar://problem/49394015> Reviewed by Brent Fulgham. Adopt SPI to issue a process-specific sandbox extension for local file read, passing it the process identifier of the WebContent process. * Shared/Cocoa/SandboxExtensionCocoa.mm: (WebKit::SandboxExtensionImpl::sandboxExtensionForType): (WebKit::SandboxExtension::createHandleForReadByPid): * Shared/SandboxExtension.h: * UIProcess/Cocoa/WebPageProxyCocoa.mm: (WebKit::WebPageProxy::createSandboxExtensionsIfNeeded): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle): (WebKit::WebPageProxy::loadFile): 2019-08-18 Babak Shafiei <bshafiei@apple.com> Cherry-pick r248823. rdar://problem/54454713 Source/WebKit: Use bundlePath SPI in AccessibilitySupport for WebProcessLoader https://bugs.webkit.org/show_bug.cgi?id=200367 Patch by Eric Liang <ericliang@apple.com> on 2019-08-17 Reviewed by Darin Adler. * Platform/spi/ios/AccessibilitySupportSPI.h: * WebProcess/cocoa/WebProcessCocoa.mm: (WebKit::accessibilityWebProcessLoaderBundlePath): (WebKit::registerWithAccessibility): Source/WTF: Added HAVE_ACCESSIBILITY_BUNDLES_PATH https://bugs.webkit.org/show_bug.cgi?id=200367 Patch by Eric Liang <ericliang@apple.com> on 2019-08-17 Reviewed by Darin Adler. * wtf/Platform.h: Tools: Tested that accessibility WebProcessLoader bundle is loaded for the correct path. https://bugs.webkit.org/show_bug.cgi?id=200367 Patch by Eric Liang <ericliang@apple.com> on 2019-08-17 Reviewed by Darin Adler. Added AccessibilityTestPlugin on the web process to report whether a bundle is loaded and its path, so that it can be tested on WKContentView. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKitCocoa/AccessibilityTestPlugin.mm: Added. (-[AccessibilityTestPlugin webProcessPlugIn:didCreateBrowserContextController:]): (-[AccessibilityTestPlugin checkAccessibilityWebProcessLoaderBundleIsLoaded:]): * TestWebKitAPI/Tests/WebKitCocoa/AccessibilityTestSupportProtocol.h: Added. * TestWebKitAPI/Tests/ios/AccessibilityTestsIOS.mm: (TestWebKitAPI::TEST): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248823 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-17 Eric Liang <ericliang@apple.com> Use bundlePath SPI in AccessibilitySupport for WebProcessLoader https://bugs.webkit.org/show_bug.cgi?id=200367 Reviewed by Darin Adler. * Platform/spi/ios/AccessibilitySupportSPI.h: * WebProcess/cocoa/WebProcessCocoa.mm: (WebKit::accessibilityWebProcessLoaderBundlePath): (WebKit::registerWithAccessibility): 2019-08-18 Babak Shafiei <bshafiei@apple.com> Cherry-pick r248819. rdar://problem/54455005 Content in <iframe> should override "touch-action" set in embedding document https://bugs.webkit.org/show_bug.cgi?id=200204 <rdar://problem/54355249> Reviewed by Antoine Quint. Source/WebKit: Subframes where content doesn't use any touch-action properties won't generate event region for their main layer. As a result the touch-action property gets computed in UI process to the parent frames touch-action (instead of 'auto'). * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm: (WebKit::touchActionsForPoint): If the topmost layer hit is a WKChildScrollView we know its content layer didn't have an event region. This means we should return the default value 'auto'. LayoutTests: * pointerevents/ios/touch-action-none-with-frame-inside-expected.txt: Added. * pointerevents/ios/touch-action-none-with-frame-inside.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248819 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-17 Antti Koivisto <antti@apple.com> Content in <iframe> should override "touch-action" set in embedding document https://bugs.webkit.org/show_bug.cgi?id=200204 <rdar://problem/54355249> Reviewed by Antoine Quint. Subframes where content doesn't use any touch-action properties won't generate event region for their main layer. As a result the touch-action property gets computed in UI process to the parent frames touch-action (instead of 'auto'). * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm: (WebKit::touchActionsForPoint): If the topmost layer hit is a WKChildScrollView we know its content layer didn't have an event region. This means we should return the default value 'auto'. 2019-08-18 Babak Shafiei <bshafiei@apple.com> Cherry-pick r248791. rdar://problem/54455008 Long pressing images with transparent backgrounds in dark mode causes a black background to appear around the image content https://bugs.webkit.org/show_bug.cgi?id=200827 <rdar://53933379> Reviewed by Tim Horton. Set a clear color when there is no provided background. * UIProcess/ios/WKContentViewInteraction.mm: (createTargetedPreview): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248791 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-16 Dean Jackson <dino@apple.com> Long pressing images with transparent backgrounds in dark mode causes a black background to appear around the image content https://bugs.webkit.org/show_bug.cgi?id=200827 <rdar://53933379> Reviewed by Tim Horton. Set a clear color when there is no provided background. * UIProcess/ios/WKContentViewInteraction.mm: (createTargetedPreview): 2019-08-18 Babak Shafiei <bshafiei@apple.com> Cherry-pick r248776. rdar://problem/54455007 REGRESSION (r248436): WKWebView doesn’t respect isOpaque setting in NIB. https://bugs.webkit.org/show_bug.cgi?id=200802 rdar://problem/54357818 Reviewed by Tim Horton. Source/WebKit: Tests: WKWebView.IsOpaqueDefault, WKWebView.SetOpaqueYes, WKWebView.SetOpaqueNo, WKWebView.IsOpaqueYesSubclassOverridden, WKWebView.IsOpaqueNoSubclassOverridden, WKWebView.IsOpaqueYesDecodedFromArchive, WKWebView.IsOpaqueNoDecodedFromArchive, WKWebView.IsOpaqueDrawsBackgroundYesConfiguration, WKWebView.IsOpaqueDrawsBackgroundNoConfiguration. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _initializeWithConfiguration:]): Call _setOpaqueInternal:NO instead of self.opaque = NO. (-[WKWebView _setOpaqueInternal:]): Added. Moved code from setOpaque:. (-[WKWebView setOpaque:]): Call _setOpaqueInternal:. Tools: * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: Added WKWebViewOpaque.mm. * TestWebKitAPI/Tests/ios/WKWebViewOpaque.mm: Added. (-[OpaqueTestWKWebView isOpaque]): Added. (-[NonOpaqueTestWKWebView isOpaque]): Added. (isOpaque): Added. (TEST): Added WKWebView.IsOpaqueDefault, WKWebView.SetOpaqueYes, WKWebView.SetOpaqueNo, WKWebView.IsOpaqueYesSubclassOverridden, WKWebView.IsOpaqueNoSubclassOverridden, WKWebView.IsOpaqueYesDecodedFromArchive, WKWebView.IsOpaqueNoDecodedFromArchive, WKWebView.IsOpaqueDrawsBackgroundYesConfiguration, WKWebView.IsOpaqueDrawsBackgroundNoConfiguration. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248776 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-16 Timothy Hatcher <timothy@apple.com> REGRESSION (r248436): WKWebView doesn’t respect isOpaque setting in NIB. https://bugs.webkit.org/show_bug.cgi?id=200802 rdar://problem/54357818 Reviewed by Tim Horton. Tests: WKWebView.IsOpaqueDefault, WKWebView.SetOpaqueYes, WKWebView.SetOpaqueNo, WKWebView.IsOpaqueYesSubclassOverridden, WKWebView.IsOpaqueNoSubclassOverridden, WKWebView.IsOpaqueYesDecodedFromArchive, WKWebView.IsOpaqueNoDecodedFromArchive, WKWebView.IsOpaqueDrawsBackgroundYesConfiguration, WKWebView.IsOpaqueDrawsBackgroundNoConfiguration. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _initializeWithConfiguration:]): Call _setOpaqueInternal:NO instead of self.opaque = NO. (-[WKWebView _setOpaqueInternal:]): Added. Moved code from setOpaque:. (-[WKWebView setOpaque:]): Call _setOpaqueInternal:. 2019-08-18 Babak Shafiei <bshafiei@apple.com> Cherry-pick r248733. rdar://problem/54454989 Occasional hang under -[UIKeyboardTaskQueue lockWhenReadyForMainThread] when long-pressing non-editable text https://bugs.webkit.org/show_bug.cgi?id=200731 <rdar://problem/54315371> Reviewed by Tim Horton. Source/WebKit: When handling a single tap in non-editable content, keyboards logic in UIKit may attempt to wait for all pending tasks in UIKeyboardTaskQueue to finish executing (e.g. by calling -waitUntilAllTasksAreFinished]). If the task queue has a pending task at this moment - for example, a text selection update that is waiting for a response from the web process - this will result in a permanent deadlock, since the main thread will be blocked, and therefore cannot receive any IPC communication from the web process. One way to trigger this is to activate both the loupe gesture and non-editable text tap gesture simultaneously, by tapping in a non-editable part of the web page, while an ongoing loupe gesture is driving selection updates (see the layout test for more details). To avoid getting into this scenario, prevent the text tap gesture recognizer from firing in a few edge cases that could lead to hangs under keyboard code in UIKit. See comments below. Test: editing/selection/ios/tap-during-loupe-gesture.html * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView textInteractionGesture:shouldBeginAtPoint:]): Don't allow the text tap gesture recognizer to fire if the user is actively modifying the text selection using the loupe gesture, or if there's other pending selection change updates that are pending responses from the web content process. (-[WKContentView selectTextWithGranularity:atPoint:completionHandler:]): (-[WKContentView updateSelectionWithExtentPoint:withBoundary:completionHandler:]): Increment and decrement _suppressNonEditableSingleTapTextInteractionCount while handling these selection updates. LayoutTests: Add a layout test to verify that tapping the page while handling a text loupe gesture doesn't cause the UI process to hang indefinitely. * editing/selection/ios/tap-during-loupe-gesture-expected.txt: Added. * editing/selection/ios/tap-during-loupe-gesture.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248733 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-15 Wenson Hsieh <wenson_hsieh@apple.com> Occasional hang under -[UIKeyboardTaskQueue lockWhenReadyForMainThread] when long-pressing non-editable text https://bugs.webkit.org/show_bug.cgi?id=200731 <rdar://problem/54315371> Reviewed by Tim Horton. When handling a single tap in non-editable content, keyboards logic in UIKit may attempt to wait for all pending tasks in UIKeyboardTaskQueue to finish executing (e.g. by calling -waitUntilAllTasksAreFinished]). If the task queue has a pending task at this moment - for example, a text selection update that is waiting for a response from the web process - this will result in a permanent deadlock, since the main thread will be blocked, and therefore cannot receive any IPC communication from the web process. One way to trigger this is to activate both the loupe gesture and non-editable text tap gesture simultaneously, by tapping in a non-editable part of the web page, while an ongoing loupe gesture is driving selection updates (see the layout test for more details). To avoid getting into this scenario, prevent the text tap gesture recognizer from firing in a few edge cases that could lead to hangs under keyboard code in UIKit. See comments below. Test: editing/selection/ios/tap-during-loupe-gesture.html * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView textInteractionGesture:shouldBeginAtPoint:]): Don't allow the text tap gesture recognizer to fire if the user is actively modifying the text selection using the loupe gesture, or if there's other pending selection change updates that are pending responses from the web content process. (-[WKContentView selectTextWithGranularity:atPoint:completionHandler:]): (-[WKContentView updateSelectionWithExtentPoint:withBoundary:completionHandler:]): Increment and decrement _suppressNonEditableSingleTapTextInteractionCount while handling these selection updates. 2019-08-18 Babak Shafiei <bshafiei@apple.com> Cherry-pick r248696. rdar://problem/54333944 REGRESSION(r245320): Web Automation: Perform Actions hangs when pointerdown happens near top of page https://bugs.webkit.org/show_bug.cgi?id=200728 <rdar://problem/54260518> Reviewed by Devin Rousso. In the last major refactoring for this code, it seems that the argument to platformSimulateMouseInteraction was not unified to use viewport coordinates in all code paths. This patch fixes both callers to *not* add in topContentInset, and instead this is added back in when doing platform-specific event simulation. This has no effect on iOS since it's guarded by ENABLE(WEBDRIVER_MOUSE_INTERACTIONS), which is only built on macOS. * UIProcess/Automation/WebAutomationSession.h: * UIProcess/Automation/WebAutomationSession.cpp: (WebKit::WebAutomationSession::performMouseInteraction): * UIProcess/Automation/mac/WebAutomationSessionMac.mm: (WebKit::WebAutomationSession::platformSimulateMouseInteraction): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248696 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-14 Brian Burg <bburg@apple.com> REGRESSION(r245320): Web Automation: Perform Actions hangs when pointerdown happens near top of page https://bugs.webkit.org/show_bug.cgi?id=200728 <rdar://problem/54260518> Reviewed by Devin Rousso. In the last major refactoring for this code, it seems that the argument to platformSimulateMouseInteraction was not unified to use viewport coordinates in all code paths. This patch fixes both callers to *not* add in topContentInset, and instead this is added back in when doing platform-specific event simulation. This has no effect on iOS since it's guarded by ENABLE(WEBDRIVER_MOUSE_INTERACTIONS), which is only built on macOS. * UIProcess/Automation/WebAutomationSession.h: * UIProcess/Automation/WebAutomationSession.cpp: (WebKit::WebAutomationSession::performMouseInteraction): * UIProcess/Automation/mac/WebAutomationSessionMac.mm: (WebKit::WebAutomationSession::platformSimulateMouseInteraction): 2019-08-15 Alan Coon <alancoon@apple.com> Cherry-pick r248731. rdar://problem/54360857 Unreviewed, rolling out r248440. https://bugs.webkit.org/show_bug.cgi?id=200772 Introduced regressions related to loading of local files. (Requested by perarne on #webkit). Reverted changeset: "[Mac] Use the PID of the WebContent process when issuing local file read sandbox extensions" https://bugs.webkit.org/show_bug.cgi?id=200543 https://trac.webkit.org/changeset/248440 git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248731 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-15 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r248440. https://bugs.webkit.org/show_bug.cgi?id=200772 Introduced regressions related to loading of local files. (Requested by perarne on #webkit). Reverted changeset: "[Mac] Use the PID of the WebContent process when issuing local file read sandbox extensions" https://bugs.webkit.org/show_bug.cgi?id=200543 https://trac.webkit.org/changeset/248440 2019-08-15 Alan Coon <alancoon@apple.com> Cherry-pick r248717. rdar://problem/54360854 WKUIDelegate's webView:contextMenuDidEndForElement: should be called when context menus end https://bugs.webkit.org/show_bug.cgi?id=200750 <rdar://problem/54232261> and <rdar://problem/52355829> Patch by Alex Christensen <achristensen@webkit.org> on 2019-08-15 Reviewed by Tim Horton. Source/WebKit: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView contextMenuInteraction:willEndForConfiguration:animator:]): Tools: * TestWebKitAPI/Tests/WebKitCocoa/ContextMenus.mm: (-[TestContextMenuUIDelegate webView:contextMenuConfigurationForElement:completionHandler:]): (-[TestContextMenuUIDelegate webView:contextMenuForElement:willCommitWithAnimator:]): (-[TestContextMenuUIDelegate webView:contextMenuDidEndForElement:]): (contextMenuWebViewDriver): (TEST): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248717 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-15 Alex Christensen <achristensen@webkit.org> WKUIDelegate's webView:contextMenuDidEndForElement: should be called when context menus end https://bugs.webkit.org/show_bug.cgi?id=200750 <rdar://problem/54232261> and <rdar://problem/52355829> Reviewed by Tim Horton. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView contextMenuInteraction:willEndForConfiguration:animator:]): 2019-08-15 Alan Coon <alancoon@apple.com> Cherry-pick r248690. rdar://problem/54333950 v3: CrashTracer: Regression : MobileSafari at UIKitCore: -[UITargetedPreview initWithView:parameters:] https://bugs.webkit.org/show_bug.cgi?id=200634 Patch by Luming Yin <luming_yin@apple.com> on 2019-08-14 Reviewed by Simon Fraser. Under rare race conditions, the WKContentView may no longer have an associated window. However, UIContextMenuInteraction may still attempt initialize a UITargetedPreview with the orphaned WKContentView. Speculative fix for crashes under such scenarios, so that we can continue without a context menu configuration to prevent the UIKit exception. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView continueContextMenuInteraction:]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248690 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-14 Luming Yin <luming_yin@apple.com> v3: CrashTracer: Regression : MobileSafari at UIKitCore: -[UITargetedPreview initWithView:parameters:] https://bugs.webkit.org/show_bug.cgi?id=200634 Reviewed by Simon Fraser. Under rare race conditions, the WKContentView may no longer have an associated window. However, UIContextMenuInteraction may still attempt initialize a UITargetedPreview with the orphaned WKContentView. Speculative fix for crashes under such scenarios, so that we can continue without a context menu configuration to prevent the UIKit exception. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView continueContextMenuInteraction:]): 2019-08-13 Alan Coon <alancoon@apple.com> Cherry-pick r248634. rdar://problem/54282811 Fix potential thread safety issue under WebResourceLoadStatisticsStore::hasHadUserInteraction() https://bugs.webkit.org/show_bug.cgi?id=200688 Reviewed by Alex Christensen. Fix potential thread safety issue under WebResourceLoadStatisticsStore::hasHadUserInteraction(). It passes a RegistrableDomain to another thread without isolated copying it. * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp: (WebKit::WebResourceLoadStatisticsStore::hasHadUserInteraction): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248634 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-13 Chris Dumez <cdumez@apple.com> Fix potential thread safety issue under WebResourceLoadStatisticsStore::hasHadUserInteraction() https://bugs.webkit.org/show_bug.cgi?id=200688 Reviewed by Alex Christensen. Fix potential thread safety issue under WebResourceLoadStatisticsStore::hasHadUserInteraction(). It passes a RegistrableDomain to another thread without isolated copying it. * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp: (WebKit::WebResourceLoadStatisticsStore::hasHadUserInteraction): 2019-08-13 Alan Coon <alancoon@apple.com> Cherry-pick r248633. rdar://problem/54282803 Fix potential thread safety issue under StorageManager::getSessionStorageOrigins() https://bugs.webkit.org/show_bug.cgi?id=200684 Reviewed by Geoffrey Garen. Fix potential thread safety issue under StorageManager::getSessionStorageOrigins(). The origins are being passed from the background queue to the main thread without isolated copy. * NetworkProcess/WebStorage/StorageManager.cpp: (WebKit::StorageManager::getSessionStorageOrigins): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248633 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-13 Chris Dumez <cdumez@apple.com> Fix potential thread safety issue under StorageManager::getSessionStorageOrigins() https://bugs.webkit.org/show_bug.cgi?id=200684 Reviewed by Geoffrey Garen. Fix potential thread safety issue under StorageManager::getSessionStorageOrigins(). The origins are being passed from the background queue to the main thread without isolated copy. * NetworkProcess/WebStorage/StorageManager.cpp: (WebKit::StorageManager::getSessionStorageOrigins): 2019-08-13 Alan Coon <alancoon@apple.com> Cherry-pick r248598. rdar://problem/54282797 Crash under IPC::Connection::markCurrentlyDispatchedMessageAsInvalid() https://bugs.webkit.org/show_bug.cgi?id=200674 <rdar://problem/50692748> Reviewed by Geoff Garen. Source/WebKit: When the client terminates a provisional process (e.g. via the [WKWebView _killWebContentProcessAndResetState] SPI), the WebProcessProxy would notify its associated WebPageProxy objects that it had terminated but would fail to notify its associated ProvisionalPageProxy objects. As a result, those objects would not get destroyed and would still think that they were in the middle of a provisional load the next time a load started. This inconsistent state would lead to crashes such as the one in the radar. * UIProcess/ProvisionalPageProxy.cpp: (WebKit::ProvisionalPageProxy::cancel): * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::requestTermination): Tools: Add API test coverage. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248598 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-13 Chris Dumez <cdumez@apple.com> Crash under IPC::Connection::markCurrentlyDispatchedMessageAsInvalid() https://bugs.webkit.org/show_bug.cgi?id=200674 <rdar://problem/50692748> Reviewed by Geoff Garen. When the client terminates a provisional process (e.g. via the [WKWebView _killWebContentProcessAndResetState] SPI), the WebProcessProxy would notify its associated WebPageProxy objects that it had terminated but would fail to notify its associated ProvisionalPageProxy objects. As a result, those objects would not get destroyed and would still think that they were in the middle of a provisional load the next time a load started. This inconsistent state would lead to crashes such as the one in the radar. * UIProcess/ProvisionalPageProxy.cpp: (WebKit::ProvisionalPageProxy::cancel): * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::requestTermination): 2019-08-13 Alan Coon <alancoon@apple.com> Apply patch. rdar://problem/54236234 2019-08-13 Chris Dumez <cdumez@apple.com> Crash under NetworkResourceLoader::start() https://bugs.webkit.org/show_bug.cgi?id=200628 <rdar://problem/54220519> Reviewed by Youenn Fablet. Simplified version of r248540 for the branch. * NetworkProcess/NetworkResourceLoader.cpp: (WebKit::NetworkResourceLoader::start): * NetworkProcess/NetworkResourceLoader.h: 2019-08-13 Alan Coon <alancoon@apple.com> Cherry-pick r248440. rdar://problem/54237795 [Mac] Use the PID of the WebContent process when issuing local file read sandbox extensions https://bugs.webkit.org/show_bug.cgi?id=200543 Source/WebKit: Reviewed by Brent Fulgham. Adopt SPI to issue a process-specific sandbox extension for local file read, passing it the process identifier of the WebContent process. * Shared/Cocoa/SandboxExtensionCocoa.mm: (WebKit::SandboxExtensionImpl::sandboxExtensionForType): (WebKit::SandboxExtension::createHandleForReadByPid): * Shared/SandboxExtension.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle): Source/WTF: <rdar://problem/49394015> Reviewed by Brent Fulgham. Add new SPI. * wtf/Platform.h: * wtf/spi/darwin/SandboxSPI.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248440 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-08 Per Arne Vollan <pvollan@apple.com> [Mac] Use the PID of the WebContent process when issuing local file read sandbox extensions https://bugs.webkit.org/show_bug.cgi?id=200543 Reviewed by Brent Fulgham. Adopt SPI to issue a process-specific sandbox extension for local file read, passing it the process identifier of the WebContent process. * Shared/Cocoa/SandboxExtensionCocoa.mm: (WebKit::SandboxExtensionImpl::sandboxExtensionForType): (WebKit::SandboxExtension::createHandleForReadByPid): * Shared/SandboxExtension.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle): 2019-08-13 Alan Coon <alancoon@apple.com> Cherry-pick r248548. rdar://problem/54237813 Fix Crash in Mail Search https://bugs.webkit.org/show_bug.cgi?id=200589 Source/WebKit: <rdar://problem/53666720> Reviewed by Tim Horton. If we search in Mail backwards first, for AppKit reasons we get a -1 for the index of the found item. Do not try and insert data in this case. * UIProcess/mac/WKTextFinderClient.mm: Tools: Reviewed by Tim Horton. If you search backwards first in mail, we would crash, this tests that codepath. * TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm: (TEST): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248548 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-12 Megan Gardner <megan_gardner@apple.com> Fix Crash in Mail Search https://bugs.webkit.org/show_bug.cgi?id=200589 <rdar://problem/53666720> Reviewed by Tim Horton. If we search in Mail backwards first, for AppKit reasons we get a -1 for the index of the found item. Do not try and insert data in this case. * UIProcess/mac/WKTextFinderClient.mm: 2019-08-13 Alan Coon <alancoon@apple.com> Cherry-pick r248543. rdar://problem/54237801 Clear m_sessionStorageNamespaces on the background thread https://bugs.webkit.org/show_bug.cgi?id=200631 <rdar://problem/54149638> Reviewed by Chris Dumez. Network process receives messages about web page state from web process and destroys sessionStorageNamespace if needed. It also receives messages about session state from UI process and destroys StorageManager, which owns SessionStorageNamespaces, if needed. Because of the race in receiving the messages from different processes, network process may decide to destroy StorageManager before destroying all SessionStorageNamespaces, and SessionStorageNamespaces are destroyed with StorageManager on the main thread. * NetworkProcess/WebStorage/StorageManager.cpp: (WebKit::StorageManager::waitUntilTasksFinished): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248543 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-12 Sihui Liu <sihui_liu@apple.com> Clear m_sessionStorageNamespaces on the background thread https://bugs.webkit.org/show_bug.cgi?id=200631 <rdar://problem/54149638> Reviewed by Chris Dumez. Network process receives messages about web page state from web process and destroys sessionStorageNamespace if needed. It also receives messages about session state from UI process and destroys StorageManager, which owns SessionStorageNamespaces, if needed. Because of the race in receiving the messages from different processes, network process may decide to destroy StorageManager before destroying all SessionStorageNamespaces, and SessionStorageNamespaces are destroyed with StorageManager on the main thread. * NetworkProcess/WebStorage/StorageManager.cpp: (WebKit::StorageManager::waitUntilTasksFinished): 2019-08-13 Alan Coon <alancoon@apple.com> Cherry-pick r248166. rdar://problem/54237837 [macOS 10.15] Image dragged from Safari does not appear in Notes https://bugs.webkit.org/show_bug.cgi?id=188490 <rdar://problem/39462717> Reviewed by Andy Estes. Source/WebKit: Removes some logic that clears out the cached promised drag image in the UI process when WebKit is asked to provide TIFF image data. This prevents the drop destination from asking for promised image data, if anything else (e.g. the system) also asks the web view to provide the same data. Additionally, this logic didn't previously guarantee that the promised image would be cleared anyways, since it is dependent on the drop target actually requesting the promised image in order to perform the cleanup. In lieu of clearing the promised drag image when it's requested, we instead clear it out upon mainframe navigation, in PageClientImpl::didCommitLoadForMainFrame. Test: DragAndDropTests.MultiplePromisedImageDataRequests * UIProcess/Cocoa/WebViewImpl.h: * UIProcess/Cocoa/WebViewImpl.mm: (WebKit::WebViewImpl::clearPromisedDragImage): (WebKit::WebViewImpl::pasteboardChangedOwner): (WebKit::WebViewImpl::provideDataForPasteboard): Fix the bug by not immediately clearing out the promised drag image. * UIProcess/mac/PageClientImplMac.mm: (WebKit::PageClientImpl::didCommitLoadForMainFrame): Tools: Add a test to verify that promised image data can be delivered to multiple pasteboards when performing a drop. * TestWebKitAPI/Tests/mac/DragAndDropTestsMac.mm: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248166 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-02 Wenson Hsieh <wenson_hsieh@apple.com> [macOS 10.15] Image dragged from Safari does not appear in Notes https://bugs.webkit.org/show_bug.cgi?id=188490 <rdar://problem/39462717> Reviewed by Andy Estes. Removes some logic that clears out the cached promised drag image in the UI process when WebKit is asked to provide TIFF image data. This prevents the drop destination from asking for promised image data, if anything else (e.g. the system) also asks the web view to provide the same data. Additionally, this logic didn't previously guarantee that the promised image would be cleared anyways, since it is dependent on the drop target actually requesting the promised image in order to perform the cleanup. In lieu of clearing the promised drag image when it's requested, we instead clear it out upon mainframe navigation, in PageClientImpl::didCommitLoadForMainFrame. Test: DragAndDropTests.MultiplePromisedImageDataRequests * UIProcess/Cocoa/WebViewImpl.h: * UIProcess/Cocoa/WebViewImpl.mm: (WebKit::WebViewImpl::clearPromisedDragImage): (WebKit::WebViewImpl::pasteboardChangedOwner): (WebKit::WebViewImpl::provideDataForPasteboard): Fix the bug by not immediately clearing out the promised drag image. * UIProcess/mac/PageClientImplMac.mm: (WebKit::PageClientImpl::didCommitLoadForMainFrame): 2019-08-13 Alan Coon <alancoon@apple.com> Cherry-pick r248550. rdar://problem/54237677 Contextual menu Hide and Show Link Previews should not have a symbol https://bugs.webkit.org/show_bug.cgi?id=200645 <rdar://problem/54129647> Reviewed by Wenson Hsieh. Don't use an image on the UIMenuItem. * UIProcess/API/Cocoa/_WKElementAction.mm: (+[_WKElementAction imageForElementActionType:]): Return nil for Show/Hide Link Previews. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248550 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-12 Dean Jackson <dino@apple.com> Contextual menu Hide and Show Link Previews should not have a symbol https://bugs.webkit.org/show_bug.cgi?id=200645 <rdar://problem/54129647> Reviewed by Wenson Hsieh. Don't use an image on the UIMenuItem. * UIProcess/API/Cocoa/_WKElementAction.mm: (+[_WKElementAction imageForElementActionType:]): Return nil for Show/Hide Link Previews. 2019-08-13 Alan Coon <alancoon@apple.com> Cherry-pick r248541. rdar://problem/54237768 [iPadOS] Web pages sometimes load at half width in Safari https://bugs.webkit.org/show_bug.cgi?id=200624 <rdar://problem/52694257> Reviewed by Simon Fraser. Source/WebKit: Whenever WKWebView's size changes, it normally notifies the web content process by calling into WebPageProxy:: setViewportConfigurationViewLayoutSize, which remembers this view layout size using a member variable, m_viewportConfigurationViewLayoutSize. Later, m_viewportConfigurationViewLayoutSize is consulted as a part of constructing the creation parameters used to set up a new page. However, during animated resize, WKWebView avoids these calls to setViewportConfigurationViewLayoutSize via the dynamic viewport update mode check in -[WKWebView _frameOrBoundsChanged]. Instead, the new view layout size is pushed to the web process by calling WebPageProxy::dynamicViewportSizeUpdate. Since dynamicViewportSizeUpdate doesn't update m_viewportConfigurationViewLayoutSize, the next WebPageCreationParameters that are created with this WebPageProxy (e.g. after a process swap, or after reloading, if the process was terminated) will use the size of the WKWebView prior to the most recent animated resize. To fix the bug, we simply make sure that m_viewportConfigurationViewLayoutSize is updated in the dynamic viewport size update (i.e. animated resize) case as well. Test: WebKit.CreateWebPageAfterAnimatedResize * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::dynamicViewportSizeUpdate): Tools: Add an API test to verify that after performing an animated resize and killing the web process, the subsequent web page is created using the post-animated-resize web view dimensions, rather than the original layout dimensions. * TestWebKitAPI/Tests/WebKitCocoa/AnimatedResize.mm: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248541 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-12 Wenson Hsieh <wenson_hsieh@apple.com> [iPadOS] Web pages sometimes load at half width in Safari https://bugs.webkit.org/show_bug.cgi?id=200624 <rdar://problem/52694257> Reviewed by Simon Fraser. Whenever WKWebView's size changes, it normally notifies the web content process by calling into WebPageProxy:: setViewportConfigurationViewLayoutSize, which remembers this view layout size using a member variable, m_viewportConfigurationViewLayoutSize. Later, m_viewportConfigurationViewLayoutSize is consulted as a part of constructing the creation parameters used to set up a new page. However, during animated resize, WKWebView avoids these calls to setViewportConfigurationViewLayoutSize via the dynamic viewport update mode check in -[WKWebView _frameOrBoundsChanged]. Instead, the new view layout size is pushed to the web process by calling WebPageProxy::dynamicViewportSizeUpdate. Since dynamicViewportSizeUpdate doesn't update m_viewportConfigurationViewLayoutSize, the next WebPageCreationParameters that are created with this WebPageProxy (e.g. after a process swap, or after reloading, if the process was terminated) will use the size of the WKWebView prior to the most recent animated resize. To fix the bug, we simply make sure that m_viewportConfigurationViewLayoutSize is updated in the dynamic viewport size update (i.e. animated resize) case as well. Test: WebKit.CreateWebPageAfterAnimatedResize * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::dynamicViewportSizeUpdate): 2019-08-13 Alan Coon <alancoon@apple.com> Cherry-pick r248487. rdar://problem/54237679 [iOS 13] Google Docs/Slides/Sheets: paste often doesn't work and sometimes produces an error https://bugs.webkit.org/show_bug.cgi?id=200591 <rdar://problem/54102238> Reviewed by Ryosuke Niwa and Tim Horton. Source/WebKit: Adopts UIKit SPI to avoid incrementing the general pasteboard's change count whenever an editable element is focused. This is due to how, in iOS 13, UIKit temporarily writes an image to the pasteboard when showing the keyboard, to determine whether or not to show the Memojis in the input view. This causes UIPasteboard's changeCount to increment twice due to adding and then removing the image, which means that the changeCount sanity checks in the web process will race against the pasteboard gaining and then losing this temporary image. Instead, the new -supportsImagePaste SPI may be used to short-circuit this step, and avoid updating the changeCount when UIKeyboardImpl's delegate changes. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView supportsImagePaste]): Tools: Add a new API test to exercise -supportsImagePaste. * TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm: (TestWebKitAPI::TEST): * TestWebKitAPI/ios/UIKitSPI.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248487 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-09 Wenson Hsieh <wenson_hsieh@apple.com> [iOS 13] Google Docs/Slides/Sheets: paste often doesn't work and sometimes produces an error https://bugs.webkit.org/show_bug.cgi?id=200591 <rdar://problem/54102238> Reviewed by Ryosuke Niwa and Tim Horton. Adopts UIKit SPI to avoid incrementing the general pasteboard's change count whenever an editable element is focused. This is due to how, in iOS 13, UIKit temporarily writes an image to the pasteboard when showing the keyboard, to determine whether or not to show the Memojis in the input view. This causes UIPasteboard's changeCount to increment twice due to adding and then removing the image, which means that the changeCount sanity checks in the web process will race against the pasteboard gaining and then losing this temporary image. Instead, the new -supportsImagePaste SPI may be used to short-circuit this step, and avoid updating the changeCount when UIKeyboardImpl's delegate changes. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView supportsImagePaste]): 2019-08-13 Alan Coon <alancoon@apple.com> Cherry-pick r248433. rdar://problem/54237689 [iOS 13] Taps that interrupt momentum scrolling are recognized as clicks https://bugs.webkit.org/show_bug.cgi?id=200516 <rdar://problem/53889373> Reviewed by Tim Horton. Source/WebKit: After <https://trac.webkit.org/r247656>, the -tracksImmediatelyWhileDecelerating property of WKScrollView and WKChildScrollView is set to NO. This means that if a user interacts with the page while the scroll view is decelerating (e.g. after momentum scrolling), the pan gesture recognizer will not be immediately recognized. This gives other gesture recognizers, such as the synthetic click (single tap) gesture a chance to instead recognize first. In this particular bug, this causes taps on the web view that are intended to only stop momentum scrolling to instead activate clickable elements beneath the touch, such as links and buttons. To mitigate this, we add some logic to prevent the click gesture recognizer from firing in the case where the tap also causes the scroll view to decelerate. This heuristic is similar to the one introduced in r219310, which has the same purpose of hiding gestures that stop momentum scrolling from the page, and also consults -[UIScrollView _isInterruptingDeceleration]. Tests: fast/scrolling/ios/click-events-during-momentum-scroll-in-main-frame.html fast/scrolling/ios/click-events-during-momentum-scroll-in-overflow-after-tap-on-body.html fast/scrolling/ios/click-events-during-momentum-scroll-in-overflow.html * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView gestureRecognizerShouldBegin:]): Return NO in the case of the single tap gesture if the UIScrollView most recently touched by the single tap gesture (or one of its enclosing scroll views, up to the main WKScrollView) is being interrupted while decelerating. * UIProcess/ios/WKSyntheticTapGestureRecognizer.h: * UIProcess/ios/WKSyntheticTapGestureRecognizer.mm: (-[WKSyntheticTapGestureRecognizer reset]): (-[WKSyntheticTapGestureRecognizer touchesBegan:withEvent:]): Teach WKSyntheticTapGestureRecognizer to keep track of the last WKScrollView that was touched, for later use in -gestureRecognizerShouldBegin:. To do this, we keep a weak reference to the first UIScrollView we find in the set of touches. (-[WKSyntheticTapGestureRecognizer lastTouchedScrollView]): LayoutTests: Add new layout tests. See below for details. * fast/scrolling/ios/click-events-during-momentum-scroll-in-main-frame-expected.txt: Added. * fast/scrolling/ios/click-events-during-momentum-scroll-in-main-frame.html: Added. Add a test to verify that interrupting scrolling in the main frame using a tap doesn't fire a click event. * fast/scrolling/ios/click-events-during-momentum-scroll-in-overflow-after-tap-on-body-expected.txt: Added. * fast/scrolling/ios/click-events-during-momentum-scroll-in-overflow-after-tap-on-body.html: Added. Add a test to verify that after triggering momentum scrolling in a fast subscrollable region, tapping outside of the scroller will still fire a click event. * fast/scrolling/ios/click-events-during-momentum-scroll-in-overflow-expected.txt: Added. * fast/scrolling/ios/click-events-during-momentum-scroll-in-overflow.html: Added. Add a test to verify that interrupting scrolling in a fast subscrollable region using a tap doesn't fire a click event. * resources/ui-helper.js: (window.UIHelper.dragFromPointToPoint): (window.UIHelper): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248433 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-08 Wenson Hsieh <wenson_hsieh@apple.com> [iOS 13] Taps that interrupt momentum scrolling are recognized as clicks https://bugs.webkit.org/show_bug.cgi?id=200516 <rdar://problem/53889373> Reviewed by Tim Horton. After <https://trac.webkit.org/r247656>, the -tracksImmediatelyWhileDecelerating property of WKScrollView and WKChildScrollView is set to NO. This means that if a user interacts with the page while the scroll view is decelerating (e.g. after momentum scrolling), the pan gesture recognizer will not be immediately recognized. This gives other gesture recognizers, such as the synthetic click (single tap) gesture a chance to instead recognize first. In this particular bug, this causes taps on the web view that are intended to only stop momentum scrolling to instead activate clickable elements beneath the touch, such as links and buttons. To mitigate this, we add some logic to prevent the click gesture recognizer from firing in the case where the tap also causes the scroll view to decelerate. This heuristic is similar to the one introduced in r219310, which has the same purpose of hiding gestures that stop momentum scrolling from the page, and also consults -[UIScrollView _isInterruptingDeceleration]. Tests: fast/scrolling/ios/click-events-during-momentum-scroll-in-main-frame.html fast/scrolling/ios/click-events-during-momentum-scroll-in-overflow-after-tap-on-body.html fast/scrolling/ios/click-events-during-momentum-scroll-in-overflow.html * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView gestureRecognizerShouldBegin:]): Return NO in the case of the single tap gesture if the UIScrollView most recently touched by the single tap gesture (or one of its enclosing scroll views, up to the main WKScrollView) is being interrupted while decelerating. * UIProcess/ios/WKSyntheticTapGestureRecognizer.h: * UIProcess/ios/WKSyntheticTapGestureRecognizer.mm: (-[WKSyntheticTapGestureRecognizer reset]): (-[WKSyntheticTapGestureRecognizer touchesBegan:withEvent:]): Teach WKSyntheticTapGestureRecognizer to keep track of the last WKScrollView that was touched, for later use in -gestureRecognizerShouldBegin:. To do this, we keep a weak reference to the first UIScrollView we find in the set of touches. (-[WKSyntheticTapGestureRecognizer lastTouchedScrollView]): 2019-08-13 Alan Coon <alancoon@apple.com> Cherry-pick r248430. rdar://problem/54237652 Use "safari" glyph for "Show Link Previews" contextual menu https://bugs.webkit.org/show_bug.cgi?id=200544 <rdar://problem/54087842> Reviewed by Tim Horton. Use the system image for the compass. * UIProcess/API/Cocoa/_WKElementAction.mm: (+[_WKElementAction imageForElementActionType:]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248430 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-08 Dean Jackson <dino@apple.com> Use "safari" glyph for "Show Link Previews" contextual menu https://bugs.webkit.org/show_bug.cgi?id=200544 <rdar://problem/54087842> Reviewed by Tim Horton. Use the system image for the compass. * UIProcess/API/Cocoa/_WKElementAction.mm: (+[_WKElementAction imageForElementActionType:]): 2019-08-13 Alan Coon <alancoon@apple.com> Cherry-pick r248338. rdar://problem/54237654 [iPadOS] slides.google.com: tapping near cursor in a slide title focuses the speaker notes https://bugs.webkit.org/show_bug.cgi?id=200216 Reviewed by Wenson Hsieh. Source/WebKit: The bug was caused by a race condition between Google slides removing inputmode="none" from the hidden content editable and updating the focused region upon receiving a pointerup event, which happens after the Google slides had already updated its page layout & coordinates based on new visual viewport with the software keyboard's boudning rect taken into account. Delay bringing up the software keyboard for a inputmode change until all touches are released. In the future, we could consider also delaying the software keyboard to be brought in general until touchend / pointerup events are dispatched but this is rather risky since that could affact random other websites while Google suites is the only major site to make use of inputmode="none". This patch also reverts r243044, which was added for Google slides, since it's no longer needed and interferes with this patch by adding another way to bring up the software keyboard. Note: Adjusting touchend / pointerup coordinates while the keyboard is being brought up doesn't work because the page had already updated the layout by then based on new visual viewport size. Test: fast/forms/ios/inputmode-change-update-keyboard-after-pointerup.html * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::handleTouchEventSynchronously): Call didReleaseAllTouchPoints when all touches are released. (WebKit::WebPageProxy::handleTouchEventAsynchronously): Ditto. (WebKit::WebPageProxy::handleTouchEvent): Ditto. * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::didReleaseAllTouchPoints): Added for non-iOS platforms. (WebKit::WebPageProxy::m_pendingInputModeChange): Added. Used when inputmode is changed while there is an on-going touch interaction. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::elementDidFocus): Clear m_pendingInputModeChange when a new element is focused. (WebKit::WebPageProxy::elementDidBlur): Ditto for bluring. (WebKit::WebPageProxy::focusedElementDidChangeInputMode): Don't bring up the software keyboard now if there are on-going touches by exiting early after setting m_pendingInputModeChange. (WebKit::WebPageProxy::didReleaseAllTouchPoints): Bring up the software keyboard if inputmode had changed from "none" to something else. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::dispatchTouchEvent): Removed the code added by r243044. LayoutTests: Added a new regression test and removed the one added for r243044. * fast/events/touch/ios/show-keyboard-after-preventing-touchstart-expected.txt: Removed. * fast/events/touch/ios/show-keyboard-after-preventing-touchstart.html: Removed. * fast/forms/ios/inputmode-change-update-keyboard-after-pointerup-expected.txt: Added. * fast/forms/ios/inputmode-change-update-keyboard-after-pointerup.html: Added. * fast/forms/ios/inputmode-change-update-keyboard.html: Fixed the test for manual testing. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248338 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-06 Ryosuke Niwa <rniwa@webkit.org> [iPadOS] slides.google.com: tapping near cursor in a slide title focuses the speaker notes https://bugs.webkit.org/show_bug.cgi?id=200216 Reviewed by Wenson Hsieh. The bug was caused by a race condition between Google slides removing inputmode="none" from the hidden content editable and updating the focused region upon receiving a pointerup event, which happens after the Google slides had already updated its page layout & coordinates based on new visual viewport with the software keyboard's boudning rect taken into account. Delay bringing up the software keyboard for a inputmode change until all touches are released. In the future, we could consider also delaying the software keyboard to be brought in general until touchend / pointerup events are dispatched but this is rather risky since that could affact random other websites while Google suites is the only major site to make use of inputmode="none". This patch also reverts r243044, which was added for Google slides, since it's no longer needed and interferes with this patch by adding another way to bring up the software keyboard. Note: Adjusting touchend / pointerup coordinates while the keyboard is being brought up doesn't work because the page had already updated the layout by then based on new visual viewport size. Test: fast/forms/ios/inputmode-change-update-keyboard-after-pointerup.html * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::handleTouchEventSynchronously): Call didReleaseAllTouchPoints when all touches are released. (WebKit::WebPageProxy::handleTouchEventAsynchronously): Ditto. (WebKit::WebPageProxy::handleTouchEvent): Ditto. * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::didReleaseAllTouchPoints): Added for non-iOS platforms. (WebKit::WebPageProxy::m_pendingInputModeChange): Added. Used when inputmode is changed while there is an on-going touch interaction. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::elementDidFocus): Clear m_pendingInputModeChange when a new element is focused. (WebKit::WebPageProxy::elementDidBlur): Ditto for bluring. (WebKit::WebPageProxy::focusedElementDidChangeInputMode): Don't bring up the software keyboard now if there are on-going touches by exiting early after setting m_pendingInputModeChange. (WebKit::WebPageProxy::didReleaseAllTouchPoints): Bring up the software keyboard if inputmode had changed from "none" to something else. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::dispatchTouchEvent): Removed the code added by r243044. 2019-08-13 Alan Coon <alancoon@apple.com> Cherry-pick r248281. rdar://problem/54237787 iOS 13: Overflow:hidden on body prevents PDF scroll https://bugs.webkit.org/show_bug.cgi?id=200435 rdar://problem/53942888 Reviewed by Tim Horton. Source/WebKit: When we navigate from an overflow:hidden HTML page to a custom view (like PDF), we need to make sure that the scroll view is scrollable. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _setHasCustomContentView:loadedMIMEType:]): Tools: When we navigate from an overflow:hidden HTML page to a custom view (like PDF), we need to make sure that the scroll view is scrollable. * TestWebKitAPI/Tests/ios/ScrollViewScrollabilityTests.mm: (TestWebKitAPI::TEST): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248281 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-05 Simon Fraser <simon.fraser@apple.com> iOS 13: Overflow:hidden on body prevents PDF scroll https://bugs.webkit.org/show_bug.cgi?id=200435 rdar://problem/53942888 Reviewed by Tim Horton. When we navigate from an overflow:hidden HTML page to a custom view (like PDF), we need to make sure that the scroll view is scrollable. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _setHasCustomContentView:loadedMIMEType:]): 2019-08-13 Alan Coon <alancoon@apple.com> Cherry-pick r248174. rdar://problem/54237758 [iPadOS] slides.google.com: Full Screen API warning is presented when swiping through slides https://bugs.webkit.org/show_bug.cgi?id=200313 <rdar://problem/53777001> Reviewed by Eric Carlson. Only run the secheuristic scoring during UIGestureRecognizerStateEnded, rather than both UIGestureRecognizerStateEnded and UIGestureRecognizerStateBegan. The goal of the heuristic is to detect fake on-screen keyboards by detecting gestures that look like "typing". Using only UIGestureRecognizerStateEnded still allows us to do this (as typing will usually have identical geometries for both Ended and Began) without generating false-positives during swipe gestures. * UIProcess/ios/fullscreen/WKFullScreenViewController.mm: (-[WKFullScreenViewController _touchDetected:]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248174 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-02 Jer Noble <jer.noble@apple.com> [iPadOS] slides.google.com: Full Screen API warning is presented when swiping through slides https://bugs.webkit.org/show_bug.cgi?id=200313 <rdar://problem/53777001> Reviewed by Eric Carlson. Only run the secheuristic scoring during UIGestureRecognizerStateEnded, rather than both UIGestureRecognizerStateEnded and UIGestureRecognizerStateBegan. The goal of the heuristic is to detect fake on-screen keyboards by detecting gestures that look like "typing". Using only UIGestureRecognizerStateEnded still allows us to do this (as typing will usually have identical geometries for both Ended and Began) without generating false-positives during swipe gestures. * UIProcess/ios/fullscreen/WKFullScreenViewController.mm: (-[WKFullScreenViewController _touchDetected:]): 2019-08-12 Alan Coon <alancoon@apple.com> Cherry-pick r248502. rdar://problem/54130670 Disable ContentChangeObserver TouchEvent adjustment on youtube.com on iOS in mobile browsing mode https://bugs.webkit.org/show_bug.cgi?id=200609 <rdar://problem/54015403> Reviewed by Maciej Stachowiak. Source/WebCore: When watching a youtube video on iOS with "Autoplay" switched to off, upon finishing the video all clicks anywhere on the page are effectively ignored. Disabling ContentChangeObserver's TouchEvent adjustment fixes this bug. I verified this manually. This switch was introduced in r242621, and it disables part of a new feature, so there is low risk of fallout. * loader/DocumentLoader.h: (WebCore::DocumentLoader::setAllowContentChangeObserverQuirk): (WebCore::DocumentLoader::allowContentChangeObserverQuirk const): * page/Quirks.cpp: (WebCore::Quirks::shouldDisableContentChangeObserverTouchEventAdjustment const): * page/Quirks.h: * page/ios/ContentChangeObserver.cpp: (WebCore::ContentChangeObserver::touchEventDidStart): Source/WebKit: * Shared/WebsitePoliciesData.cpp: (WebKit::WebsitePoliciesData::encode const): (WebKit::WebsitePoliciesData::decode): (WebKit::WebsitePoliciesData::applyToDocumentLoader): * Shared/WebsitePoliciesData.h: * UIProcess/API/APIWebsitePolicies.cpp: (API::WebsitePolicies::copy const): (API::WebsitePolicies::data): * UIProcess/API/APIWebsitePolicies.h: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::effectiveContentModeAfterAdjustingPolicies): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248502 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-10 Alex Christensen <achristensen@webkit.org> Disable ContentChangeObserver TouchEvent adjustment on youtube.com on iOS in mobile browsing mode https://bugs.webkit.org/show_bug.cgi?id=200609 <rdar://problem/54015403> Reviewed by Maciej Stachowiak. * Shared/WebsitePoliciesData.cpp: (WebKit::WebsitePoliciesData::encode const): (WebKit::WebsitePoliciesData::decode): (WebKit::WebsitePoliciesData::applyToDocumentLoader): * Shared/WebsitePoliciesData.h: * UIProcess/API/APIWebsitePolicies.cpp: (API::WebsitePolicies::copy const): (API::WebsitePolicies::data): * UIProcess/API/APIWebsitePolicies.h: * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::effectiveContentModeAfterAdjustingPolicies): 2019-08-12 Alan Coon <alancoon@apple.com> Cherry-pick r248501. rdar://problem/54130614 [iOS] Add a quirk for gmail.com messages on iPhone iOS13 https://bugs.webkit.org/show_bug.cgi?id=200605 Patch by Said Abou-Hallawa <sabouhallawa@apple.com> on 2019-08-10 Reviewed by Maciej Stachowiak. Source/WebCore: Add a quirk which sets the user agent for gmail.com messages on iPhone OS 13 to be iPhone OS 12. This is a workaround for a gmail.com bug till it is fixed. * page/Quirks.cpp: (WebCore::Quirks::shouldAvoidUsingIOS13ForGmail const): * page/Quirks.h: * platform/UserAgent.h: * platform/ios/UserAgentIOS.mm: (WebCore::osNameForUserAgent): (WebCore::standardUserAgentWithApplicationName): * platform/mac/UserAgentMac.mm: (WebCore::standardUserAgentWithApplicationName): Source/WebKit: Use WebPage::platformUserAgent() to add the gmail.com quirk. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::effectiveContentModeAfterAdjustingPolicies): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::platformUserAgent const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248501 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-10 Said Abou-Hallawa <sabouhallawa@apple.com> [iOS] Add a quirk for gmail.com messages on iPhone iOS13 https://bugs.webkit.org/show_bug.cgi?id=200605 Reviewed by Maciej Stachowiak. Use WebPage::platformUserAgent() to add the gmail.com quirk. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::effectiveContentModeAfterAdjustingPolicies): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::platformUserAgent const): 2019-08-12 Alan Coon <alancoon@apple.com> Cherry-pick r248481. rdar://problem/54130658 [iOS WK2] Remove context menu hints on navigation https://bugs.webkit.org/show_bug.cgi?id=200588 rdar://problem/54061796 Reviewed by Tim Horton. Make sure the context menu hint doesn't linger across navigations by hosting it in its own container view (shared with drag previews), and hiding that view on navigation (unparenting may have bad consequences). We remove the view when the animation ends. * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _didCommitLoadForMainFrame]): (-[WKContentView containerViewForTargetedPreviews]): (-[WKContentView _hideContextMenu]): (-[WKContentView contextMenuInteraction:willEndForConfiguration:animator:]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248481 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-09 Simon Fraser <simon.fraser@apple.com> [iOS WK2] Remove context menu hints on navigation https://bugs.webkit.org/show_bug.cgi?id=200588 rdar://problem/54061796 Reviewed by Tim Horton. Make sure the context menu hint doesn't linger across navigations by hosting it in its own container view (shared with drag previews), and hiding that view on navigation (unparenting may have bad consequences). We remove the view when the animation ends. * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _didCommitLoadForMainFrame]): (-[WKContentView containerViewForTargetedPreviews]): (-[WKContentView _hideContextMenu]): (-[WKContentView contextMenuInteraction:willEndForConfiguration:animator:]): 2019-08-12 Alan Coon <alancoon@apple.com> Cherry-pick r248471. rdar://problem/54130624 Disable CSSOM View Scrolling API for IMDb iOS app https://bugs.webkit.org/show_bug.cgi?id=200586 <rdar://problem/53645833> Patch by Alex Christensen <achristensen@webkit.org> on 2019-08-09 Reviewed by Simon Fraser. Source/WebCore: They are calling scrollHeight on the HTML element and it is running new code introduced in r235806 Disable this new feature until they update their app to use the iOS13 SDK. * platform/RuntimeApplicationChecks.h: * platform/cocoa/RuntimeApplicationChecksCocoa.mm: (WebCore::IOSApplication::isIMDb): Source/WebKit: Change the CSSOMViewScrollingAPIEnabled default value to be off for the IMDb app's WKWebViews. I manually verified this is effective in those WKWebViews but no other WKWebViews and that it fixes the radar. * Shared/WebPreferences.yaml: * Shared/WebPreferencesDefaultValues.cpp: (WebKit::defaultCSSOMViewScrollingAPIEnabled): * Shared/WebPreferencesDefaultValues.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248471 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-09 Alex Christensen <achristensen@webkit.org> Disable CSSOM View Scrolling API for IMDb iOS app https://bugs.webkit.org/show_bug.cgi?id=200586 <rdar://problem/53645833> Reviewed by Simon Fraser. Change the CSSOMViewScrollingAPIEnabled default value to be off for the IMDb app's WKWebViews. I manually verified this is effective in those WKWebViews but no other WKWebViews and that it fixes the radar. * Shared/WebPreferences.yaml: * Shared/WebPreferencesDefaultValues.cpp: (WebKit::defaultCSSOMViewScrollingAPIEnabled): * Shared/WebPreferencesDefaultValues.h: 2019-08-12 Alan Coon <alancoon@apple.com> Cherry-pick r248469. rdar://problem/54130688 Tapping buttons in Data Detectors lookup previews doesn't work https://bugs.webkit.org/show_bug.cgi?id=200579 <rdar://problem/54056519> Reviewed by Megan Gardner. Source/WebCore/PAL: * pal/spi/ios/DataDetectorsUISPI.h: Source/WebKit: * Platform/spi/ios/UIKitSPI.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _contextMenuInteraction:styleForMenuWithConfiguration:]): If a Data Detectors context menu wants the action menu style, provide it. (-[WKContentView contextMenuInteraction:willPerformPreviewActionForMenuWithConfiguration:animator:]): If a Data Detectors context menu provides a view controller to present on context menu commit, present it. We present on top of the same view controller that is currently presenting the context menu, but modally instead of inside the context menu. If a Data Detectors context menu instead provides a URL to launch on context menu commit, call openURL. In both cases, change the commit style to pop, since we're committing instead of dismissing. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248469 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-09 Tim Horton <timothy_horton@apple.com> Tapping buttons in Data Detectors lookup previews doesn't work https://bugs.webkit.org/show_bug.cgi?id=200579 <rdar://problem/54056519> Reviewed by Megan Gardner. * Platform/spi/ios/UIKitSPI.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _contextMenuInteraction:styleForMenuWithConfiguration:]): If a Data Detectors context menu wants the action menu style, provide it. (-[WKContentView contextMenuInteraction:willPerformPreviewActionForMenuWithConfiguration:animator:]): If a Data Detectors context menu provides a view controller to present on context menu commit, present it. We present on top of the same view controller that is currently presenting the context menu, but modally instead of inside the context menu. If a Data Detectors context menu instead provides a URL to launch on context menu commit, call openURL. In both cases, change the commit style to pop, since we're committing instead of dismissing. 2019-08-12 Alan Coon <alancoon@apple.com> Cherry-pick r248456. rdar://problem/54109877 REGRESSION (52279987): Most of the WKUIDelegate contextMenu delegate methods are not being called https://bugs.webkit.org/show_bug.cgi?id=200557 <rdar://problem/53717962> Reviewed by Wenson Hsieh. UIKit changed the name of delegates recently. We ignored the warning because it was still calling the old methods. However, it will only do so for applications authored by Apple, breaking 3rd parties. The change here is just adopting the new methods in place of the old ones. It does not change the API that WebKit vends (they still use the older names). * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView contextMenuInteraction:willDisplayMenuForConfiguration:animator:]): (-[WKContentView contextMenuInteraction:willPerformPreviewActionForMenuWithConfiguration:animator:]): (-[WKContentView contextMenuInteraction:willEndForConfiguration:animator:]): (-[WKContentView contextMenuInteractionWillPresent:]): Deleted. (-[WKContentView contextMenuInteraction:willCommitWithAnimator:]): Deleted. (-[WKContentView contextMenuInteractionDidEnd:]): Deleted. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248456 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-08 Dean Jackson <dino@apple.com> REGRESSION (52279987): Most of the WKUIDelegate contextMenu delegate methods are not being called https://bugs.webkit.org/show_bug.cgi?id=200557 <rdar://problem/53717962> Reviewed by Wenson Hsieh. UIKit changed the name of delegates recently. We ignored the warning because it was still calling the old methods. However, it will only do so for applications authored by Apple, breaking 3rd parties. The change here is just adopting the new methods in place of the old ones. It does not change the API that WebKit vends (they still use the older names). * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView contextMenuInteraction:willDisplayMenuForConfiguration:animator:]): (-[WKContentView contextMenuInteraction:willPerformPreviewActionForMenuWithConfiguration:animator:]): (-[WKContentView contextMenuInteraction:willEndForConfiguration:animator:]): (-[WKContentView contextMenuInteractionWillPresent:]): Deleted. (-[WKContentView contextMenuInteraction:willCommitWithAnimator:]): Deleted. (-[WKContentView contextMenuInteractionDidEnd:]): Deleted. 2019-08-12 Alan Coon <alancoon@apple.com> Cherry-pick r248455. rdar://problem/54109872 [iOS WK2] Hide previews when an inner overflow or frame scrollview scrolls https://bugs.webkit.org/show_bug.cgi?id=200552 rdar://problem/54086338 Reviewed by Wenson Hsieh. Give UITargetedPreview the UIScrollView that the target element is inside of, so it can clean up if the user starts to scroll that view. * Platform/spi/ios/UIKitSPI.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _createTargetedPreviewIfPossible]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248455 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-08 Simon Fraser <simon.fraser@apple.com> [iOS WK2] Hide previews when an inner overflow or frame scrollview scrolls https://bugs.webkit.org/show_bug.cgi?id=200552 rdar://problem/54086338 Reviewed by Wenson Hsieh. Give UITargetedPreview the UIScrollView that the target element is inside of, so it can clean up if the user starts to scroll that view. * Platform/spi/ios/UIKitSPI.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _createTargetedPreviewIfPossible]): 2019-08-12 Alan Coon <alancoon@apple.com> Cherry-pick r248438. rdar://problem/54093220 [iOS] Position image information should respect the image orientation https://bugs.webkit.org/show_bug.cgi?id=200487 Patch by Said Abou-Hallawa <sabouhallawa@apple.com> on 2019-08-08 Reviewed by Simon Fraser. Source/WebCore: Re-factor CachedImage::imageSizeForRenderer() into another overriding function which does not scale the imageSize. Therefore the new function returns FloatSize while the original function returns LayoutSize. * loader/cache/CachedImage.cpp: (WebCore::CachedImage::imageSizeForRenderer const): * loader/cache/CachedImage.h: * rendering/RenderElement.h: Source/WebKit: imagePositionInformation() should respect the image orientation when drawing an Image to a ShareableBitmap context. boundsPositionInformation() already takes care of the image orientation because it gets RenderImage::enclosingBoundingBox(). * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::imagePositionInformation): Tools: Add an API test to verify the position image information is drawn rotated because of respecting its image orientation. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKitCocoa/WKRequestActivatedElementInfo.mm: (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/WebKitCocoa/exif-orientation-8-llo.jpg: Added. * TestWebKitAPI/Tests/WebKitCocoa/img-with-rotated-image.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248438 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-08 Said Abou-Hallawa <sabouhallawa@apple.com> [iOS] Position image information should respect the image orientation https://bugs.webkit.org/show_bug.cgi?id=200487 Reviewed by Simon Fraser. imagePositionInformation() should respect the image orientation when drawing an Image to a ShareableBitmap context. boundsPositionInformation() already takes care of the image orientation because it gets RenderImage::enclosingBoundingBox(). * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::imagePositionInformation): 2019-08-12 Alan Coon <alancoon@apple.com> Cherry-pick r248436. rdar://problem/54093228 Set WKWebView opaque based on drawsBackground in PageConfiguration. https://bugs.webkit.org/show_bug.cgi?id=200528 Reviewed by Tim Horton. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _initializeWithConfiguration:]): Set self.opaque = NO when !self.opaque || !pageConfiguration->drawsBackground(). It is almost impossible to have !self.opaque be NO at this point, since we are still inside initWithFrame:. A subclass could override opaque and return NO, but checking pageConfiguration's drawsBackground is a good alternative. * WebProcess/WebPage/WebPage.h: Remove unused m_drawsBackground member. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248436 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-08 Timothy Hatcher <timothy@apple.com> Set WKWebView opaque based on drawsBackground in PageConfiguration. https://bugs.webkit.org/show_bug.cgi?id=200528 Reviewed by Tim Horton. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _initializeWithConfiguration:]): Set self.opaque = NO when !self.opaque || !pageConfiguration->drawsBackground(). It is almost impossible to have !self.opaque be NO at this point, since we are still inside initWithFrame:. A subclass could override opaque and return NO, but checking pageConfiguration's drawsBackground is a good alternative. * WebProcess/WebPage/WebPage.h: Remove unused m_drawsBackground member. 2019-08-12 Alan Coon <alancoon@apple.com> Cherry-pick r248393. rdar://problem/54066682 Regression(r247784) ResourceLoadStatisticsMemoryStore / ResourceLoadStatisticsPersistentStorage may get destroyed on the wrong thread https://bugs.webkit.org/show_bug.cgi?id=200517 Reviewed by Geoffrey Garen. The issue is that WebResourceLoadStatisticsStore::flushAndDestroyPersistentStore() is null checking m_persistentStorage and m_statisticsStore on the main thread, even though those members are initialized and destroyed on the background thread. As a result, if flushAndDestroyPersistentStore() is called *before* the background task to initialize those members has had a chance to run, then we'd return early without destroying those members. Later on, the background task would then initialize those data members and we would then destroy them on the main thread when the WebResourceLoadStatisticsStore is destroyed on the main thread. * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp: (WebKit::WebResourceLoadStatisticsStore::flushAndDestroyPersistentStore): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248393 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-07 Chris Dumez <cdumez@apple.com> Regression(r247784) ResourceLoadStatisticsMemoryStore / ResourceLoadStatisticsPersistentStorage may get destroyed on the wrong thread https://bugs.webkit.org/show_bug.cgi?id=200517 Reviewed by Geoffrey Garen. The issue is that WebResourceLoadStatisticsStore::flushAndDestroyPersistentStore() is null checking m_persistentStorage and m_statisticsStore on the main thread, even though those members are initialized and destroyed on the background thread. As a result, if flushAndDestroyPersistentStore() is called *before* the background task to initialize those members has had a chance to run, then we'd return early without destroying those members. Later on, the background task would then initialize those data members and we would then destroy them on the main thread when the WebResourceLoadStatisticsStore is destroyed on the main thread. * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp: (WebKit::WebResourceLoadStatisticsStore::flushAndDestroyPersistentStore): 2019-08-12 Alan Coon <alancoon@apple.com> Cherry-pick r248380. rdar://problem/54018115 Context menu on a universal link produces a blank preview https://bugs.webkit.org/show_bug.cgi?id=200485 <rdar://problem/53699620> Reviewed by Dean Jackson. Source/WebCore/PAL: Define iTunesStoreURL from CoreServices. * pal/spi/cocoa/LaunchServicesSPI.h: Source/WebKit: If the context menu is activated on an iTunesStore URL, pass it on to DataDetectors, who should know how to handle it. Two drive-by fixes: - make it clear that early returns do not produce a value. Instead call the completion handler first, then return. - The new API DataDetectors case doesn't need to worry about hiding link previews as DataDetectors itself will handle that. * UIProcess/ios/WKContentViewInteraction.mm: If the URL is an iTunesStoreURL (as defined by CoreServices), let DataDetectors handle it. (-[WKContentView assignLegacyDataForContextMenuInteraction]): (-[WKContentView continueContextMenuInteraction:]): (-[WKContentView continueContextMenuInteractionWithDataDetectors:]): New method to use DataDetectors if possible. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248380 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-06 Dean Jackson <dino@apple.com> Context menu on a universal link produces a blank preview https://bugs.webkit.org/show_bug.cgi?id=200485 <rdar://problem/53699620> Reviewed by Tim Horton. If the context menu is activated on an iTunesStore URL, pass it on to DataDetectors, who should know how to handle it. Two drive-by fixes: - make it clear that early returns do not produce a value. Instead call the completion handler first, then return. - The new API DataDetectors case doesn't need to worry about hiding link previews as DataDetectors itself will handle that. * UIProcess/ios/WKContentViewInteraction.mm: If the URL is an iTunesStoreURL (as defined by CoreServices), let DataDetectors handle it. (-[WKContentView assignLegacyDataForContextMenuInteraction]): (-[WKContentView continueContextMenuInteraction:]): (-[WKContentView continueContextMenuInteractionWithDataDetectors:]): New method to use DataDetectors if possible. 2019-08-12 Alan Coon <alancoon@apple.com> Cherry-pick r248129. rdar://problem/53836595 REGRESSION: HSBC Personal Banking download/print dialog is usually positioned off screen on iPad https://bugs.webkit.org/show_bug.cgi?id=200356 <rdar://problem/51885199> Reviewed by Beth Dakin. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::desktopClassBrowsingRecommendedForRequest): Add HSBC domains to the list of sites that recommend mobile mode by default. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248129 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-01 Tim Horton <timothy_horton@apple.com> REGRESSION: HSBC Personal Banking download/print dialog is usually positioned off screen on iPad https://bugs.webkit.org/show_bug.cgi?id=200356 <rdar://problem/51885199> Reviewed by Beth Dakin. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::desktopClassBrowsingRecommendedForRequest): Add HSBC domains to the list of sites that recommend mobile mode by default. 2019-08-12 Alan Coon <alancoon@apple.com> Cherry-pick r248104. rdar://problem/53836566 UserMediaPermissionRequestManagerProxy should not use audio+video denied requests to deny audio-only or video-only requests https://bugs.webkit.org/show_bug.cgi?id=200317 Reviewed by Eric Carlson. Source/WebKit: Only match audio+video denied requests with new audio+video requests. That will ensure that audio can still be captured if user denied access to the camera through preferences and website started with a getUserMedia({audio: true, video: true}) call. Covered by added API test. * UIProcess/UserMediaPermissionRequestManagerProxy.cpp: (WebKit::UserMediaPermissionRequestManagerProxy::wasRequestDenied): Tools: * TestWebKitAPI/Tests/WebKit/getUserMediaAudioVideoCapture.html: Added * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKit/GetUserMediaReprompt.mm: (-[GetUserMediaOnlyAudioUIDelegate _webView:requestMediaCaptureAuthorization:decisionHandler:]): (-[GetUserMediaOnlyAudioUIDelegate _webView:checkUserMediaPermissionForURL:mainFrameURL:frameIdentifier:decisionHandler:]): (TestWebKitAPI::TEST): LayoutTests: Update existing test with new behavior. Added new test for the case where video is blocked but not audio. * fast/mediastream/getUserMedia-deny-persistency3-expected.txt: * fast/mediastream/getUserMedia-deny-persistency3.html: * fast/mediastream/getUserMedia-deny-persistency4-expected.txt: Added. * fast/mediastream/getUserMedia-deny-persistency4.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248104 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-01 Youenn Fablet <youenn@apple.com> UserMediaPermissionRequestManagerProxy should not use audio+video denied requests to deny audio-only or video-only requests https://bugs.webkit.org/show_bug.cgi?id=200317 Reviewed by Eric Carlson. Only match audio+video denied requests with new audio+video requests. That will ensure that audio can still be captured if user denied access to the camera through preferences and website started with a getUserMedia({audio: true, video: true}) call. Covered by added API test. * UIProcess/UserMediaPermissionRequestManagerProxy.cpp: (WebKit::UserMediaPermissionRequestManagerProxy::wasRequestDenied): 2019-08-12 Alan Coon <alancoon@apple.com> Cherry-pick r247914. rdar://problem/53762618 UI process occasionally hangs in -[UIKeyboardTaskQueue lockWhenReadyForMainThread] https://bugs.webkit.org/show_bug.cgi?id=200215 <rdar://problem/52976965> Reviewed by Tim Horton. To implement autocorrection on iOS, UIKit sometimes needs to request contextual information from WebKit. This is handled as a sync IPC message in WebKit, since UIKit would otherwise proceed to block the main thread after sending the request, preventing WebKit from handling any IPC responses in the UI process (potentially resulting in deadlock if any other sync IPC messages were to arrive in the UI process during this time). The synchronous nature of this autocorrection request means that if any sync IPC message were to be simultaneously dispatched in the opposite direction (i.e. web to UI process), we need to immediately handle the incoming sync message in the UI process (otherwise, we'd end up deadlocking for 1 second until the autocorrection context request hits a 1-second IPC timeout). One such synchronous message from the web process to the UI process is WebPageProxy::CreateNewPage, triggered as a result of synchronously opening a new window. Due to Safari changes in iOS 13 (<rdar://problem/51755088>), this message now calls into code which then causes UIKit to call *back into* -[WKContentView requestAutocorrectionContextWithCompletionHandler:] for the newly opened web view, under the scope of the call to -requestAutocorrectionContextWithCompletionHandler: in the original web view. This caused a crash, which was tracked in <rdar://problem/52590170>. There was an attempt to fix this in r247345 by invoking the existing handler well before storing the new one; while this avoided the crash, it didn't solve the root problem, which was that keyboard task queues would get into a bad state after this scenario; this would manifest in a UI process hang under -[UIKeyboardTaskQueue lockWhenReadyForMainThread] during the next user gesture, which is tracked by this bug (<rdar://problem/52976965>). As it turns out, the keyboard task queue gets into a bad state because it is architected in such a way that tasks added to the queue under the scope of parent task must be finished executing before their parents; otherwise, the call to -[UIKeyboardTaskExecutionContext returnExecutionToParentWithInfo:] never happens when handling the child task. This has the effect of causing the keyboard task queue to end up with a UIKeyboardTaskExecutionContext that can never return execution to its parent context, such that if the task queue is then told to wait until any future task is finished executing, it will hang forever, waiting for these stuck tasks to finish executing (which never happens, because they're all waiting to return execution to their parents which are already done executing!) To fix this hang and avoid ever getting into this bad state, we need to invoke the autocorrection request handlers in this order: (1) Receive outer autocorrection context request. (2) Receive inner autocorrection context request. (3) Invoke inner autocorrection context request completion handler. (4) Invoke outer autocorrection context request completion handler. ...instead of swapping (3) and (4), like we do currently. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView resignFirstResponderForWebView]): Remove the hack added in r247345 to try and avoid reentrant autocorrection context requests; we don't need this anymore, since we should now be able to handle these reentrant requests in the way UIKit expects. (-[WKContentView requestAutocorrectionContextWithCompletionHandler:]): Add an early return in the case where the request is synchronous and there's already a pending autocorrection context to ensure that the completion handler for the nested request is invoked before the outer request is finished. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247914 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-29 Wenson Hsieh <wenson_hsieh@apple.com> UI process occasionally hangs in -[UIKeyboardTaskQueue lockWhenReadyForMainThread] https://bugs.webkit.org/show_bug.cgi?id=200215 <rdar://problem/52976965> Reviewed by Tim Horton. To implement autocorrection on iOS, UIKit sometimes needs to request contextual information from WebKit. This is handled as a sync IPC message in WebKit, since UIKit would otherwise proceed to block the main thread after sending the request, preventing WebKit from handling any IPC responses in the UI process (potentially resulting in deadlock if any other sync IPC messages were to arrive in the UI process during this time). The synchronous nature of this autocorrection request means that if any sync IPC message were to be simultaneously dispatched in the opposite direction (i.e. web to UI process), we need to immediately handle the incoming sync message in the UI process (otherwise, we'd end up deadlocking for 1 second until the autocorrection context request hits a 1-second IPC timeout). One such synchronous message from the web process to the UI process is WebPageProxy::CreateNewPage, triggered as a result of synchronously opening a new window. Due to Safari changes in iOS 13 (<rdar://problem/51755088>), this message now calls into code which then causes UIKit to call *back into* -[WKContentView requestAutocorrectionContextWithCompletionHandler:] for the newly opened web view, under the scope of the call to -requestAutocorrectionContextWithCompletionHandler: in the original web view. This caused a crash, which was tracked in <rdar://problem/52590170>. There was an attempt to fix this in r247345 by invoking the existing handler well before storing the new one; while this avoided the crash, it didn't solve the root problem, which was that keyboard task queues would get into a bad state after this scenario; this would manifest in a UI process hang under -[UIKeyboardTaskQueue lockWhenReadyForMainThread] during the next user gesture, which is tracked by this bug (<rdar://problem/52976965>). As it turns out, the keyboard task queue gets into a bad state because it is architected in such a way that tasks added to the queue under the scope of parent task must be finished executing before their parents; otherwise, the call to -[UIKeyboardTaskExecutionContext returnExecutionToParentWithInfo:] never happens when handling the child task. This has the effect of causing the keyboard task queue to end up with a UIKeyboardTaskExecutionContext that can never return execution to its parent context, such that if the task queue is then told to wait until any future task is finished executing, it will hang forever, waiting for these stuck tasks to finish executing (which never happens, because they're all waiting to return execution to their parents which are already done executing!) To fix this hang and avoid ever getting into this bad state, we need to invoke the autocorrection request handlers in this order: (1) Receive outer autocorrection context request. (2) Receive inner autocorrection context request. (3) Invoke inner autocorrection context request completion handler. (4) Invoke outer autocorrection context request completion handler. ...instead of swapping (3) and (4), like we do currently. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView resignFirstResponderForWebView]): Remove the hack added in r247345 to try and avoid reentrant autocorrection context requests; we don't need this anymore, since we should now be able to handle these reentrant requests in the way UIKit expects. (-[WKContentView requestAutocorrectionContextWithCompletionHandler:]): Add an early return in the case where the request is synchronous and there's already a pending autocorrection context to ensure that the completion handler for the nested request is invoked before the outer request is finished. 2019-08-12 Alan Coon <alancoon@apple.com> Cherry-pick r248447. rdar://problem/54218162 Add to InteractionInformationAtPosition information about whether the element is in a subscrollable region https://bugs.webkit.org/show_bug.cgi?id=200374 rdar://problem/54095519 Reviewed by Tim Horton. Source/WebCore: Add to InteractionInformationAtPosition a ScrollingNodeID which represents the enclosing scrolling node that affects the targeted element's position. We use this to find a UIScrollView in the UI process. The entrypoint to finding the enclosing scrolling node is ScrollingCoordinator::scrollableContainerNodeID(), which calls RenderLayerCompositor::asyncScrollableContainerNodeID() to look for a scrolling ancestor in the current frame, and then looks for an enclosing scrollable frame, or a scrolling ancestor in the enclosing frame. There's a bit of subtlety in RenderLayerCompositor::asyncScrollableContainerNodeID() because if you're asking for the node that scrolls the renderer, if the renderer itself has a layer and is scrollable, you want its enclosing scroller. * page/scrolling/AsyncScrollingCoordinator.cpp: (WebCore::AsyncScrollingCoordinator::scrollableContainerNodeID const): * page/scrolling/AsyncScrollingCoordinator.h: * page/scrolling/ScrollingCoordinator.cpp: (WebCore::scrollableContainerNodeID const): * page/scrolling/ScrollingCoordinator.h: * rendering/RenderLayer.h: * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::asyncScrollableContainerNodeID): * rendering/RenderLayerCompositor.h: Source/WebKit: Add InteractionInformationAtPosition.containerScrollingNodeID and initialize it in elementPositionInformation() by asking the scrolling coordinator. Also add a way to get from a ScrollingNodeID to a UIScrollView to RemoteScrollingCoordinatorProxy, which gets the scrolling node and asks the delegate for the UIView. * Shared/ios/InteractionInformationAtPosition.h: * Shared/ios/InteractionInformationAtPosition.mm: (WebKit::InteractionInformationAtPosition::encode const): (WebKit::InteractionInformationAtPosition::decode): * UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.h: * UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.mm: (WebKit::RemoteScrollingCoordinatorProxy::scrollViewForScrollingNodeID const): * UIProcess/RemoteLayerTree/ios/ScrollingTreeOverflowScrollingNodeIOS.h: * UIProcess/RemoteLayerTree/ios/ScrollingTreeOverflowScrollingNodeIOS.mm: (WebKit::ScrollingTreeOverflowScrollingNodeIOS::scrollView const): * UIProcess/RemoteLayerTree/ios/ScrollingTreeScrollingNodeDelegateIOS.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::elementPositionInformation): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248447 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-06 Alan Coon <alancoon@apple.com> Apply patch. rdar://problem/53992160 2019-08-06 Per Arne Vollan <pvollan@apple.com> [Win] Fix AppleWin build https://bugs.webkit.org/show_bug.cgi?id=200414 Reviewed by Brent Fulgham. * CMakeLists.txt: 2019-08-01 Alan Coon <alancoon@apple.com> Cherry-pick r248085. rdar://problem/53825741 WKImagePreviewViewController not being autoreleased https://bugs.webkit.org/show_bug.cgi?id=200325 <rdar://problem/53788214> Reviewed by Wenson Hsieh. Wenson noticed I wasn't autoreleasing the WKImagePreviewViewController. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView continueContextMenuInteraction:]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248085 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-31 Dean Jackson <dino@apple.com> WKImagePreviewViewController not being autoreleased https://bugs.webkit.org/show_bug.cgi?id=200325 <rdar://problem/53788214> Reviewed by Wenson Hsieh. Wenson noticed I wasn't autoreleasing the WKImagePreviewViewController. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView continueContextMenuInteraction:]): 2019-07-31 Alan Coon <alancoon@apple.com> Cherry-pick r248039. rdar://problem/53788996 [iOS 13] Safari crashes when closing a tab with a focused element if the unified field has focus https://bugs.webkit.org/show_bug.cgi?id=200291 <rdar://problem/53717946> Reviewed by Megan Gardner. Source/WebKit: Makes -requestAutocorrectionContextWithCompletionHandler: robust in the case where the web page has been closed, and there is no Connection object to use when waiting for a sync IPC response. Test: AutocorrectionTests.RequestAutocorrectionContextAfterClosingPage * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView requestAutocorrectionContextWithCompletionHandler:]): Tools: Add an API test to exercise the scenario of synchronously requesting the autocorrection context immediately after closing the web view, while the web view's content view isn't the first responder. * TestWebKitAPI/Tests/ios/AutocorrectionTestsIOS.mm: * TestWebKitAPI/ios/UIKitSPI.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248039 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-31 Wenson Hsieh <wenson_hsieh@apple.com> [iOS 13] Safari crashes when closing a tab with a focused element if the unified field has focus https://bugs.webkit.org/show_bug.cgi?id=200291 <rdar://problem/53717946> Reviewed by Megan Gardner. Makes -requestAutocorrectionContextWithCompletionHandler: robust in the case where the web page has been closed, and there is no Connection object to use when waiting for a sync IPC response. Test: AutocorrectionTests.RequestAutocorrectionContextAfterClosingPage * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView requestAutocorrectionContextWithCompletionHandler:]): 2019-07-31 Alan Coon <alancoon@apple.com> Cherry-pick r247700. rdar://problem/53456055 WebKit SPI fix for [ClickyOrb] Audio continues playing after dismissing a video preview in Safari https://bugs.webkit.org/show_bug.cgi?id=200011 <rdar://problem/53409457> Reviewed by Tim Horton. Don't check for the SPI @selector(_webView:contextMenuDidEndForElement:) on the WKUIDelegate so that clients that got caught implementing the SPI before moving to the real API can still clean-up state. In other words, don't force a client that only implements that method to move completely to the new API. * UIProcess/ios/WKContentViewInteraction.mm: (needsDeprecatedPreviewAPI): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247700 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-22 Dean Jackson <dino@apple.com> WebKit SPI fix for [ClickyOrb] Audio continues playing after dismissing a video preview in Safari https://bugs.webkit.org/show_bug.cgi?id=200011 <rdar://problem/53409457> Reviewed by Tim Horton. Don't check for the SPI @selector(_webView:contextMenuDidEndForElement:) on the WKUIDelegate so that clients that got caught implementing the SPI before moving to the real API can still clean-up state. In other words, don't force a client that only implements that method to move completely to the new API. * UIProcess/ios/WKContentViewInteraction.mm: (needsDeprecatedPreviewAPI): 2019-07-31 Alan Coon <alancoon@apple.com> Cherry-pick r248038. rdar://problem/53764075 AX: com.apple.WebKit.WebContent at com.apple.WebKit: -[WKAccessibilityWebPageObject accessibilityParameterizedAttributeNames] https://bugs.webkit.org/show_bug.cgi?id=200277 <rdar://problem/49475009> Reviewed by Per Arne Vollan. Verify Page is available before calling into it. * WebProcess/WebPage/mac/WKAccessibilityWebPageObjectMac.mm: (-[WKAccessibilityWebPageObject ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248038 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-31 Chris Fleizach <cfleizach@apple.com> AX: com.apple.WebKit.WebContent at com.apple.WebKit: -[WKAccessibilityWebPageObject accessibilityParameterizedAttributeNames] https://bugs.webkit.org/show_bug.cgi?id=200277 <rdar://problem/49475009> Reviewed by Per Arne Vollan. Verify Page is available before calling into it. * WebProcess/WebPage/mac/WKAccessibilityWebPageObjectMac.mm: (-[WKAccessibilityWebPageObject ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): 2019-07-31 Alan Coon <alancoon@apple.com> Cherry-pick r248015. rdar://problem/53764191 Can't scroll on yummly.co.uk recipe (scale(0) div covers the content and hit-tests) https://bugs.webkit.org/show_bug.cgi?id=200263 rdar://problem/53679408 Reviewed by Antti Koivisto. Source/WebKit: The content on this page had a scale(0) div overlaying an overflow:scroll element, and our UI-side hit-testing code would find this scale(0) element, because apparently -[UIView convertPoint:fromView:] will happily work with non-invertible matrices, and -[UIView pointInside:withEvent:] just compares the point with the view bounds. Since the view frame takes the transform into account, we can look for an empty frame to detect these non-invertible transforms. * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm: (WebKit::collectDescendantViewsAtPoint): LayoutTests: * fast/scrolling/ios/non-invertible-transformed-over-scroller-expected.txt: Added. * fast/scrolling/ios/non-invertible-transformed-over-scroller.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248015 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-31 Alan Coon <alancoon@apple.com> Cherry-pick r247936. rdar://problem/53764217 YouTube search field shows RTL text outside its border on iPadOS https://bugs.webkit.org/show_bug.cgi?id=200253 <rdar://problem/53680603> Reviewed by Beth Dakin. Source/WebKit: Limits code added in r238939 to respect the current keyboard's writing mode to only editable web views. This behavior was only intended for Mail, and isn't generally compatible with web content. While the call to -setInitialDirection is correctly gated on an web view editability check, it appears that other changes in iOS 13 now cause -setBaseWritingDirection:forRange: to be invoked directly from keyboards code. This means that -setBaseWritingDirection:forRange: should additionally be guarded with the same check. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView setBaseWritingDirection:forRange:]): LayoutTests: * editing/input/ios/rtl-keyboard-input-on-focus-in-editable-page-expected.txt: Renamed from LayoutTests/editing/input/ios/rtl-keyboard-input-on-focus-expected.txt. * editing/input/ios/rtl-keyboard-input-on-focus-in-editable-page.html: Renamed from LayoutTests/editing/input/ios/rtl-keyboard-input-on-focus.html. Rename an existing test, rtl-keyboard-input-on-focus.html, to rtl-keyboard-input-on-focus-in-editable-page.html to emphasize the fact that it requires an editable web view. * editing/input/ios/rtl-keyboard-input-on-focus-in-non-editable-page-expected.txt: Added. * editing/input/ios/rtl-keyboard-input-on-focus-in-non-editable-page.html: Added. Add a new layout test to ensure that we don't automatically apply an RTL attribute when focusing fields in a non-editable web view. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247936 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-29 Wenson Hsieh <wenson_hsieh@apple.com> YouTube search field shows RTL text outside its border on iPadOS https://bugs.webkit.org/show_bug.cgi?id=200253 <rdar://problem/53680603> Reviewed by Beth Dakin. Limits code added in r238939 to respect the current keyboard's writing mode to only editable web views. This behavior was only intended for Mail, and isn't generally compatible with web content. While the call to -setInitialDirection is correctly gated on an web view editability check, it appears that other changes in iOS 13 now cause -setBaseWritingDirection:forRange: to be invoked directly from keyboards code. This means that -setBaseWritingDirection:forRange: should additionally be guarded with the same check. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView setBaseWritingDirection:forRange:]): 2019-07-31 Alan Coon <alancoon@apple.com> Cherry-pick r247933. rdar://problem/53764069 Try fixing crash at com.apple.WebKit.Networking: NetworkProcess::setSharedHTTPCookieStorage https://bugs.webkit.org/show_bug.cgi?id=200189 <rdar://problem/41325767> Reviewed by Chris Dumez. The crash indicates that sharedCookieStorage is accessed before being set in network process. sharedCookieStorage is set during the processing of InitializeNetworkProcess message, and access to sharedCookieStorage is supposed to happen after that. Therefore, it is likely some message is received and handled before InitializeNetworkProcess. One possible explanation is WebKit APIs get called on different threads. Because of the race in checking and setting m_networkProcess, some message is sent between network process gets launched (m_networkProcess is set) and InitializeNetworkProcess message is sent. To mitigate this issue, we make sure m_networkProcess is set only in the main runloop and only after InitializeNetworkProcess is sent. * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::ensureNetworkProcess): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247933 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-29 Sihui Liu <sihui_liu@apple.com> Try fixing crash at com.apple.WebKit.Networking: NetworkProcess::setSharedHTTPCookieStorage https://bugs.webkit.org/show_bug.cgi?id=200189 <rdar://problem/41325767> Reviewed by Chris Dumez. The crash indicates that sharedCookieStorage is accessed before being set in network process. sharedCookieStorage is set during the processing of InitializeNetworkProcess message, and access to sharedCookieStorage is supposed to happen after that. Therefore, it is likely some message is received and handled before InitializeNetworkProcess. One possible explanation is WebKit APIs get called on different threads. Because of the race in checking and setting m_networkProcess, some message is sent between network process gets launched (m_networkProcess is set) and InitializeNetworkProcess message is sent. To mitigate this issue, we make sure m_networkProcess is set only in the main runloop and only after InitializeNetworkProcess is sent. * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::ensureNetworkProcess): 2019-07-31 Alan Coon <alancoon@apple.com> Cherry-pick r247923. rdar://problem/53764209 REGRESSION: WebSockets no longer work in Service Workers https://bugs.webkit.org/show_bug.cgi?id=199906 <rdar://problem/53516732> Reviewed by Geoffrey Garen. Source/WebKit: Use WebSocketProvider so that network calls are done in the network process. * WebProcess/Storage/WebSWContextManagerConnection.cpp: (WebKit::WebSWContextManagerConnection::installServiceWorker): LayoutTests: 2019-08-08 Simon Fraser <simon.fraser@apple.com> Add to InteractionInformationAtPosition information about whether the element is in a subscrollable region https://bugs.webkit.org/show_bug.cgi?id=200374 rdar://problem/54095519 Reviewed by Tim Horton. Add InteractionInformationAtPosition.containerScrollingNodeID and initialize it in elementPositionInformation() by asking the scrolling coordinator. Also add a way to get from a ScrollingNodeID to a UIScrollView to RemoteScrollingCoordinatorProxy, which gets the scrolling node and asks the delegate for the UIView. * Shared/ios/InteractionInformationAtPosition.h: * Shared/ios/InteractionInformationAtPosition.mm: (WebKit::InteractionInformationAtPosition::encode const): (WebKit::InteractionInformationAtPosition::decode): * UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.h: * UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.mm: (WebKit::RemoteScrollingCoordinatorProxy::scrollViewForScrollingNodeID const): * UIProcess/RemoteLayerTree/ios/ScrollingTreeOverflowScrollingNodeIOS.h: * UIProcess/RemoteLayerTree/ios/ScrollingTreeOverflowScrollingNodeIOS.mm: (WebKit::ScrollingTreeOverflowScrollingNodeIOS::scrollView const): * UIProcess/RemoteLayerTree/ios/ScrollingTreeScrollingNodeDelegateIOS.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::elementPositionInformation): Fix test and make sure messages are exchanged for the test to succeed. * http/tests/workers/service/resources/serviceworker-websocket-worker.js: (async.doTest): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247923 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-29 Youenn Fablet <youenn@apple.com> REGRESSION: WebSockets no longer work in Service Workers https://bugs.webkit.org/show_bug.cgi?id=199906 <rdar://problem/53516732> Reviewed by Geoffrey Garen. Use WebSocketProvider so that network calls are done in the network process. * WebProcess/Storage/WebSWContextManagerConnection.cpp: (WebKit::WebSWContextManagerConnection::installServiceWorker): 2019-07-31 Alan Coon <alancoon@apple.com> Cherry-pick r247920. rdar://problem/53764045 Contextual menu does not present when holding an embedded photo but works with link and attachments https://bugs.webkit.org/show_bug.cgi?id=200239 <rdar://problem/53318733> Reviewed by Tim Horton. If the user long-pressed on an image, and the client implemented the new API but did not provide a configuration, we were not falling back to the default behaviour of giving a menu allowing the user to copy/share/save the image. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView continueContextMenuInteraction:]): If we get through the delegates, and the element is an image, return the default configuration. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247920 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-29 Dean Jackson <dino@apple.com> Contextual menu does not present when holding an embedded photo but works with link and attachments https://bugs.webkit.org/show_bug.cgi?id=200239 <rdar://problem/53318733> Reviewed by Tim Horton. If the user long-pressed on an image, and the client implemented the new API but did not provide a configuration, we were not falling back to the default behaviour of giving a menu allowing the user to copy/share/save the image. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView continueContextMenuInteraction:]): If we get through the delegates, and the element is an image, return the default configuration. 2019-07-31 Alan Coon <alancoon@apple.com> Cherry-pick r247905. rdar://problem/53764224 Possible use-after-move under NetworkConnectionToWebProcess::resourceLoadStatisticsUpdated() https://bugs.webkit.org/show_bug.cgi?id=200225 Reviewed by Brent Fulgham. The code was WTFMove()-ing the method parameter inside of a loop, which means that it could move it several times. Instead of copying the parameters, I opted into sending the statistics only to the network session that matches this WebProcess connection. * NetworkProcess/NetworkConnectionToWebProcess.cpp: (WebKit::NetworkConnectionToWebProcess::resourceLoadStatisticsUpdated): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247905 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-29 Chris Dumez <cdumez@apple.com> Possible use-after-move under NetworkConnectionToWebProcess::resourceLoadStatisticsUpdated() https://bugs.webkit.org/show_bug.cgi?id=200225 Reviewed by Brent Fulgham. The code was WTFMove()-ing the method parameter inside of a loop, which means that it could move it several times. Instead of copying the parameters, I opted into sending the statistics only to the network session that matches this WebProcess connection. * NetworkProcess/NetworkConnectionToWebProcess.cpp: (WebKit::NetworkConnectionToWebProcess::resourceLoadStatisticsUpdated): 2019-07-31 Alan Coon <alancoon@apple.com> Apply patch. rdar://problem/53764240 2019-07-31 Ryosuke Niwa <rniwa@webkit.org> Add a missing null check to ShareableBitmap::makeCGImageCopy() https://bugs.webkit.org/show_bug.cgi?id=200184 Reviewed by Wenson Hsieh. Added a null check to makeCGImageCopy to when either GraphicsContext or its platform context is null. Added the same platform context null check to convertImageToBitmap and convertCGImageToBitmap since the crash intendeed to be fixed in r247134 is still happening. * Shared/cg/ShareableBitmapCG.cpp: (WebKit::ShareableBitmap::makeCGImageCopy): * WebProcess/WebCoreSupport/mac/WebDragClientMac.mm: (WebKit::convertImageToBitmap): (WebKit::convertCGImageToBitmap): 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247823. rdar://problem/53449739 Unreviewed, fix -Wredundant-move warning spam after r247672 https://bugs.webkit.org/show_bug.cgi?id=199967 <rdar://problem/53351435> * Platform/IPC/ArgumentCoders.cpp: (IPC::decodeStringText): * Platform/IPC/ArgumentCoders.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247823 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-25 Michael Catanzaro <mcatanzaro@igalia.com> Unreviewed, fix -Wredundant-move warning spam after r247672 https://bugs.webkit.org/show_bug.cgi?id=199967 <rdar://problem/53351435> * Platform/IPC/ArgumentCoders.cpp: (IPC::decodeStringText): * Platform/IPC/ArgumentCoders.h: 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247673. rdar://problem/53449723 Speed up HashTable decoding by reserving capacity and avoiding rehashing https://bugs.webkit.org/show_bug.cgi?id=199982 Reviewed by Saam Barati. Source/WebKit: Use HashMap::reserveInitialCapacity() in the HashMap IPC decoder for performance. I measured a ~35% improvement when decoding a very large HashMap of Strings (~160k entries) in the context of the StorageManager::GetValues IPC. * Platform/IPC/ArgumentCoders.h: * Shared/API/c/WKDictionary.cpp: (WKDictionaryCreate): Source/WTF: Introduce reserveInitialCapacity() on HashMap to reserve capacity on a HashMap and cut down on rehashing cost when possible. * wtf/HashMap.h: * wtf/HashTable.h: (WTF::HashTable::reserveInitialCapacity): * wtf/persistence/PersistentCoders.h: Use HashMap::reserveInitialCapacity() in the HashMap persistent decoder for performance. Tools: Add API test coverage. * TestWebKitAPI/Tests/WTF/HashMap.cpp: (TestWebKitAPI::TEST): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247673 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-20 Chris Dumez <cdumez@apple.com> Speed up HashTable decoding by reserving capacity and avoiding rehashing https://bugs.webkit.org/show_bug.cgi?id=199982 Reviewed by Saam Barati. Use HashMap::reserveInitialCapacity() in the HashMap IPC decoder for performance. I measured a ~35% improvement when decoding a very large HashMap of Strings (~160k entries) in the context of the StorageManager::GetValues IPC. * Platform/IPC/ArgumentCoders.h: * Shared/API/c/WKDictionary.cpp: (WKDictionaryCreate): 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247672. rdar://problem/53449739 2019-07-29 Simon Fraser <simon.fraser@apple.com> Can't scroll on yummly.co.uk recipe (scale(0) div covers the content and hit-tests) https://bugs.webkit.org/show_bug.cgi?id=200263 rdar://problem/53679408 Reviewed by Antti Koivisto. The content on this page had a scale(0) div overlaying an overflow:scroll element, and our UI-side hit-testing code would find this scale(0) element, because apparently -[UIView convertPoint:fromView:] will happily work with non-invertible matrices, and -[UIView pointInside:withEvent:] just compares the point with the view bounds. Since the view frame takes the transform into account, we can look for an empty frame to detect these non-invertible transforms. * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm: (WebKit::collectDescendantViewsAtPoint): Micro-optimize HashMap & String IPC decoding https://bugs.webkit.org/show_bug.cgi?id=199967 Reviewed by Geoffrey Garen. The legacy HashMap decoder (returning a boolean) was failing to WTFMove() the key & value when calling HashMap::add(). The modern decoder (returning an Optional) was properly using WTFMove(). Rewrite the legacy HashMap decoder to call the modern one to reduce code duplication and to get this optimization. Also, encode HashMap::size() as a uint32_t instead of a uint64_t since HashMap::size() returns an 'unsigned int' type. Finally, update the modern decoder to WTFMove(hashMap) when returning. Because the function returns an Optional<HashMap> and not a HashMap, I do not believe we get return value optimization (RVO). Do similar changes to String IPC coders. * Platform/IPC/ArgumentCoders.cpp: (IPC::decodeStringText): (IPC::ArgumentCoder<String>::decode): * Platform/IPC/ArgumentCoders.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247672 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-20 Chris Dumez <cdumez@apple.com> Micro-optimize HashMap & String IPC decoding https://bugs.webkit.org/show_bug.cgi?id=199967 Reviewed by Geoffrey Garen. The legacy HashMap decoder (returning a boolean) was failing to WTFMove() the key & value when calling HashMap::add(). The modern decoder (returning an Optional) was properly using WTFMove(). Rewrite the legacy HashMap decoder to call the modern one to reduce code duplication and to get this optimization. Also, encode HashMap::size() as a uint32_t instead of a uint64_t since HashMap::size() returns an 'unsigned int' type. Finally, update the modern decoder to WTFMove(hashMap) when returning. Because the function returns an Optional<HashMap> and not a HashMap, I do not believe we get return value optimization (RVO). Do similar changes to String IPC coders. * Platform/IPC/ArgumentCoders.cpp: (IPC::decodeStringText): (IPC::ArgumentCoder<String>::decode): * Platform/IPC/ArgumentCoders.h: 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247890. rdar://problem/53647283 Allow more syscalls in the WebContent process' sandbox profile https://bugs.webkit.org/show_bug.cgi?id=200182 <rdar://problem/53594973> Reviewed by Geoffrey Garen. I reviewed all crash traces attached to the radar and found the following syscalls that we not yet allowed by the WebContent process's sandbox profile. * WebProcess/com.apple.WebProcess.sb.in: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247890 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-27 Chris Dumez <cdumez@apple.com> Allow more syscalls in the WebContent process' sandbox profile https://bugs.webkit.org/show_bug.cgi?id=200182 <rdar://problem/53594973> Reviewed by Geoffrey Garen. I reviewed all crash traces attached to the radar and found the following syscalls that we not yet allowed by the WebContent process's sandbox profile. * WebProcess/com.apple.WebProcess.sb.in: 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247885. rdar://problem/53648025 NavigationSOAuthorizationSession should check the active URL of the responding page after waking up from waiting https://bugs.webkit.org/show_bug.cgi?id=200150 <rdar://problem/53280170> Reviewed by Brent Fulgham. Source/WebKit: NavigationSOAuthorizationSession should check the active URL of the responding page after waking up from waiting as the page might have already changed the location. * UIProcess/Cocoa/SOAuthorization/NavigationSOAuthorizationSession.h: * UIProcess/Cocoa/SOAuthorization/NavigationSOAuthorizationSession.mm: (WebKit::NavigationSOAuthorizationSession::shouldStartInternal): (WebKit::NavigationSOAuthorizationSession::webViewDidMoveToWindow): (WebKit::NavigationSOAuthorizationSession::pageActiveURLDidChangeDuringWaiting const): * UIProcess/Cocoa/SOAuthorization/SubFrameSOAuthorizationSession.mm: (WebKit::SubFrameSOAuthorizationSession::abortInternal): Tools: * TestWebKitAPI/Tests/WebKitCocoa/TestSOAuthorization.mm: (TestWebKitAPI::TEST): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247885 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-26 Jiewen Tan <jiewen_tan@apple.com> NavigationSOAuthorizationSession should check the active URL of the responding page after waking up from waiting https://bugs.webkit.org/show_bug.cgi?id=200150 <rdar://problem/53280170> Reviewed by Brent Fulgham. NavigationSOAuthorizationSession should check the active URL of the responding page after waking up from waiting as the page might have already changed the location. * UIProcess/Cocoa/SOAuthorization/NavigationSOAuthorizationSession.h: * UIProcess/Cocoa/SOAuthorization/NavigationSOAuthorizationSession.mm: (WebKit::NavigationSOAuthorizationSession::shouldStartInternal): (WebKit::NavigationSOAuthorizationSession::webViewDidMoveToWindow): (WebKit::NavigationSOAuthorizationSession::pageActiveURLDidChangeDuringWaiting const): * UIProcess/Cocoa/SOAuthorization/SubFrameSOAuthorizationSession.mm: (WebKit::SubFrameSOAuthorizationSession::abortInternal): 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247876. rdar://problem/53647283 Crashes under XPCServiceMain() / mach_msg_trap() due to sandboxing https://bugs.webkit.org/show_bug.cgi?id=200173 <rdar://problem/53594973> Reviewed by Per Arne Vollan. Allow a few more syscalls as they appear to be needed by mach_msg_trap(). * WebProcess/com.apple.WebProcess.sb.in: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247876 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-26 Chris Dumez <cdumez@apple.com> Crashes under XPCServiceMain() / mach_msg_trap() due to sandboxing https://bugs.webkit.org/show_bug.cgi?id=200173 <rdar://problem/53594973> Reviewed by Per Arne Vollan. Allow a few more syscalls as they appear to be needed by mach_msg_trap(). * WebProcess/com.apple.WebProcess.sb.in: 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247875. rdar://problem/53648065 [iOS] REGRESSION: Keyboard dismisses and reappears when typing 2FA pin on appleid.apple.com https://bugs.webkit.org/show_bug.cgi?id=200171 <rdar://problem/50245251> Reviewed by Wenson Hsieh. Take out an InputViewUpdateDeferrer token (if we don't already have one) to temporarily defer tearing down the input view (keyboard) before bluring the previously focused element as part of switching between focused elements. This avoid a noticeable flash caused by UIKit animating out and animating in the keyboard should the newly focused element require the keyboard. We only take out the InputViewUpdateDeferrer until we fall off the end of _elementDidFocus: (or bail early). Once we fall of the end UIKit will update input view UI. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _elementDidFocus:userIsInteracting:blurPreviousNode:activityStateChanges:userObject:]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247875 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-26 Daniel Bates <dabates@apple.com> [iOS] REGRESSION: Keyboard dismisses and reappears when typing 2FA pin on appleid.apple.com https://bugs.webkit.org/show_bug.cgi?id=200171 <rdar://problem/50245251> Reviewed by Wenson Hsieh. Take out an InputViewUpdateDeferrer token (if we don't already have one) to temporarily defer tearing down the input view (keyboard) before bluring the previously focused element as part of switching between focused elements. This avoid a noticeable flash caused by UIKit animating out and animating in the keyboard should the newly focused element require the keyboard. We only take out the InputViewUpdateDeferrer until we fall off the end of _elementDidFocus: (or bail early). Once we fall of the end UIKit will update input view UI. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _elementDidFocus:userIsInteracting:blurPreviousNode:activityStateChanges:userObject:]): 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247872. rdar://problem/53647297 Avoid WebContent process SIGKILL when using kevent() https://bugs.webkit.org/show_bug.cgi?id=200170 <rdar://problem/51559921> Reviewed by Per Arne Vollan. Avoid WebContent process SIGKILL when using kevent() by updated its sandboxing profile. * WebProcess/com.apple.WebProcess.sb.in: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247872 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-26 Chris Dumez <cdumez@apple.com> Avoid WebContent process SIGKILL when using kevent() https://bugs.webkit.org/show_bug.cgi?id=200170 <rdar://problem/51559921> Reviewed by Per Arne Vollan. Avoid WebContent process SIGKILL when using kevent() by updated its sandboxing profile. * WebProcess/com.apple.WebProcess.sb.in: 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247868. rdar://problem/53648207 [iOS] WebPage::TouchEventSync() & WebPage::GetPositionInformation() sync IPC causes UIProcess hangs https://bugs.webkit.org/show_bug.cgi?id=200138 <rdar://problem/52698157> Reviewed by Geoffrey Garen. Source/WebKit: Revert most of r247822 and use an alternative approach to address hangs. In this patch, the proposal is to add a SendSyncOption::ForceDispatchWhenDestinationIsWaitingForUnboundedSyncReply flag on the WebPage::TouchEventSync() & WebPage::GetPositionInformation() sendSync() calls in the UIProcess. Those will cause this IPCs to get dispatched right away in the WebContent process, even if the WebContent process is itself currently stuck on unbounded (i.e. potentially slow) synchronous IPC (JS alerts / prompts & sync XHR). Because re-entering WebCore on sync IPC is generally unsafe, this patch also updates the WebPage::getPositionInformation() & WebPage::touchEventSync() to return early (i.e. cancelled) if they get called while the WebContent process is stuck on a slow sendSync. This approach should address the UIProcess hangs caused by the WebPage::TouchEventSync() and WebPage::GetPositionInformation() sync IPC messages when the WebContent process is busy on a slow XHR or a JS prompt / alert. It should be safe because we do not re-enter WebCore. The only drawback is that those IPCs will be cancelled (early return with default value) when the WebContent process is busy. However, I am being told that this is likely acceptable in practice. * Platform/IPC/Connection.cpp: (IPC::Connection::SyncMessageState::processIncomingMessage): (IPC::Connection::sendMessage): (IPC::Connection::sendSyncMessage): (IPC::Connection::dispatchMessage): * Platform/IPC/Connection.h: (IPC::UnboundedSynchronousIPCScope::UnboundedSynchronousIPCScope): (IPC::UnboundedSynchronousIPCScope::~UnboundedSynchronousIPCScope): (IPC::UnboundedSynchronousIPCScope::hasOngoingUnboundedSyncIPC): * Platform/IPC/Decoder.cpp: (IPC::Decoder::shouldDispatchMessageWhenWaitingForSyncReply const): * Platform/IPC/Decoder.h: * Platform/IPC/Encoder.cpp: (IPC::Encoder::shouldDispatchMessageWhenWaitingForSyncReply const): (IPC::Encoder::setShouldDispatchMessageWhenWaitingForSyncReply): (IPC::Encoder::wrapForTesting): * Platform/IPC/Encoder.h: * Platform/IPC/MessageFlags.h: * UIProcess/Network/NetworkProcessProxy.cpp: (WebKit::NetworkProcessProxy::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::handleTouchEventSynchronously): * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView ensurePositionInformationIsUpToDate:]): * WebProcess/Network/WebLoaderStrategy.cpp: (WebKit::WebLoaderStrategy::loadResourceSynchronously): * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): (WebKit::WebChromeClient::runJavaScriptAlert): (WebKit::WebChromeClient::runJavaScriptConfirm): (WebKit::WebChromeClient::runJavaScriptPrompt): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::layerVolatilityTimerFired): (WebKit::WebPage::markLayersVolatile): (WebKit::WebPage::cancelMarkLayersVolatile): (WebKit::WebPage::touchEventSync): (WebKit::WebPage::didCompletePageTransition): (WebKit::WebPage::updatePreferences): (WebKit::WebPage::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * WebProcess/WebPage/WebPage.h: (WebKit::WebPage::sendSyncWithDelayedReply): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::getPositionInformation): LayoutTests: Update existing layout test accordingly. * fast/misc/{testProcessIncomingSyncMessagesWhenWaitingForUnboundedReply-expected.txt: Renamed from LayoutTests/fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply-expected.txt. * fast/misc/{testProcessIncomingSyncMessagesWhenWaitingForUnboundedReply.html: Renamed from LayoutTests/fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply.html. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247868 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-26 Chris Dumez <cdumez@apple.com> [iOS] WebPage::TouchEventSync() & WebPage::GetPositionInformation() sync IPC causes UIProcess hangs https://bugs.webkit.org/show_bug.cgi?id=200138 <rdar://problem/52698157> Reviewed by Geoffrey Garen. Revert most of r247822 and use an alternative approach to address hangs. In this patch, the proposal is to add a SendSyncOption::ForceDispatchWhenDestinationIsWaitingForUnboundedSyncReply flag on the WebPage::TouchEventSync() & WebPage::GetPositionInformation() sendSync() calls in the UIProcess. Those will cause this IPCs to get dispatched right away in the WebContent process, even if the WebContent process is itself currently stuck on unbounded (i.e. potentially slow) synchronous IPC (JS alerts / prompts & sync XHR). Because re-entering WebCore on sync IPC is generally unsafe, this patch also updates the WebPage::getPositionInformation() & WebPage::touchEventSync() to return early (i.e. cancelled) if they get called while the WebContent process is stuck on a slow sendSync. This approach should address the UIProcess hangs caused by the WebPage::TouchEventSync() and WebPage::GetPositionInformation() sync IPC messages when the WebContent process is busy on a slow XHR or a JS prompt / alert. It should be safe because we do not re-enter WebCore. The only drawback is that those IPCs will be cancelled (early return with default value) when the WebContent process is busy. However, I am being told that this is likely acceptable in practice. * Platform/IPC/Connection.cpp: (IPC::Connection::SyncMessageState::processIncomingMessage): (IPC::Connection::sendMessage): (IPC::Connection::sendSyncMessage): (IPC::Connection::dispatchMessage): * Platform/IPC/Connection.h: (IPC::UnboundedSynchronousIPCScope::UnboundedSynchronousIPCScope): (IPC::UnboundedSynchronousIPCScope::~UnboundedSynchronousIPCScope): (IPC::UnboundedSynchronousIPCScope::hasOngoingUnboundedSyncIPC): * Platform/IPC/Decoder.cpp: (IPC::Decoder::shouldDispatchMessageWhenWaitingForSyncReply const): * Platform/IPC/Decoder.h: * Platform/IPC/Encoder.cpp: (IPC::Encoder::shouldDispatchMessageWhenWaitingForSyncReply const): (IPC::Encoder::setShouldDispatchMessageWhenWaitingForSyncReply): (IPC::Encoder::wrapForTesting): * Platform/IPC/Encoder.h: * Platform/IPC/MessageFlags.h: * UIProcess/Network/NetworkProcessProxy.cpp: (WebKit::NetworkProcessProxy::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::handleTouchEventSynchronously): * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView ensurePositionInformationIsUpToDate:]): * WebProcess/Network/WebLoaderStrategy.cpp: (WebKit::WebLoaderStrategy::loadResourceSynchronously): * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): (WebKit::WebChromeClient::runJavaScriptAlert): (WebKit::WebChromeClient::runJavaScriptConfirm): (WebKit::WebChromeClient::runJavaScriptPrompt): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::layerVolatilityTimerFired): (WebKit::WebPage::markLayersVolatile): (WebKit::WebPage::cancelMarkLayersVolatile): (WebKit::WebPage::touchEventSync): (WebKit::WebPage::didCompletePageTransition): (WebKit::WebPage::updatePreferences): (WebKit::WebPage::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * WebProcess/WebPage/WebPage.h: (WebKit::WebPage::sendSyncWithDelayedReply): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::getPositionInformation): 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247864. rdar://problem/53647289 AX: web process should load correct bundle path for MACCATALYST https://bugs.webkit.org/show_bug.cgi?id=200122 Patch by Eric Liang <ericliang@apple.com> on 2019-07-26 Reviewed by Brent Fulgham. Added the path to accessibility bundle for Mac Catalyst. Added sandbox profile to read accessibility settings. * WebProcess/cocoa/WebProcessCocoa.mm: (WebKit::registerWithAccessibility): * WebProcess/com.apple.WebProcess.sb.in: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247864 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-26 Eric Liang <ericliang@apple.com> AX: web process should load correct bundle path for MACCATALYST https://bugs.webkit.org/show_bug.cgi?id=200122 Reviewed by Brent Fulgham. Added the path to accessibility bundle for Mac Catalyst. Added sandbox profile to read accessibility settings. * WebProcess/cocoa/WebProcessCocoa.mm: (WebKit::registerWithAccessibility): * WebProcess/com.apple.WebProcess.sb.in: 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247853. rdar://problem/53648225 Unreviewed, build fix after r247851 * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::decidePolicyForNavigationAction): Reverts an unnecessary change. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247853 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-25 Jiewen Tan <jiewen_tan@apple.com> Unreviewed, build fix after r247851 * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::decidePolicyForNavigationAction): Reverts an unnecessary change. 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247851. rdar://problem/53648225 WebPageProxy::receivedPolicyDecision should check navigation ID before clear pendingAPIRequest https://bugs.webkit.org/show_bug.cgi?id=200108 <rdar://problem/53521238> Reviewed by Chris Dumez. Source/WebKit: Assuming there are two loads happening one after another. There is an issue when clients save the first decisionHandler and then call WKNavigationActionPolicyCancel for it right after the second decisionHandler received, -[WKWebView URL] could return a null string even though it is loading the second one. To solve that, this patch pairs a navigationID with the pendingAPIRequestURL such that WebPageProxy::receivedPolicyDecision could clear the pendingAPIRequestURL only if the passed navigation ID matches the current one. * UIProcess/PageLoadState.cpp: (WebKit::PageLoadState::reset): (WebKit::PageLoadState::activeURL): (WebKit::PageLoadState::estimatedProgress): (WebKit::PageLoadState::pendingAPIRequestURL const): (WebKit::PageLoadState::pendingAPIRequest const): (WebKit::PageLoadState::setPendingAPIRequest): (WebKit::PageLoadState::clearPendingAPIRequest): (WebKit::PageLoadState::isLoading): (WebKit::PageLoadState::setPendingAPIRequestURL): Deleted. (WebKit::PageLoadState::clearPendingAPIRequestURL): Deleted. * UIProcess/PageLoadState.h: (WebKit::PageLoadState::setPendingAPIRequest): (WebKit::PageLoadState::setPendingAPIRequestURL): Deleted. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::launchProcessForReload): (WebKit::WebPageProxy::loadRequestWithNavigationShared): (WebKit::WebPageProxy::loadFile): (WebKit::WebPageProxy::loadDataWithNavigationShared): (WebKit::WebPageProxy::loadAlternateHTML): (WebKit::WebPageProxy::loadWebArchiveData): (WebKit::WebPageProxy::reload): (WebKit::WebPageProxy::goToBackForwardItem): (WebKit::WebPageProxy::receivedPolicyDecision): (WebKit::WebPageProxy::continueNavigationInNewProcess): (WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared): (WebKit::WebPageProxy::didSameDocumentNavigationForFrame): (WebKit::WebPageProxy::decidePolicyForNavigationAction): Tools: Added an API test. * TestWebKitAPI/Tests/WebKitCocoa/DecidePolicyForNavigationAction.mm: (-[DecidePolicyForNavigationActionController webView:decidePolicyForNavigationAction:decisionHandler:]): (TEST): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247851 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-25 Jiewen Tan <jiewen_tan@apple.com> WebPageProxy::receivedPolicyDecision should check navigation ID before clear pendingAPIRequest https://bugs.webkit.org/show_bug.cgi?id=200108 <rdar://problem/53521238> Reviewed by Chris Dumez. Assuming there are two loads happening one after another. There is an issue when clients save the first decisionHandler and then call WKNavigationActionPolicyCancel for it right after the second decisionHandler received, -[WKWebView URL] could return a null string even though it is loading the second one. To solve that, this patch pairs a navigationID with the pendingAPIRequestURL such that WebPageProxy::receivedPolicyDecision could clear the pendingAPIRequestURL only if the passed navigation ID matches the current one. * UIProcess/PageLoadState.cpp: (WebKit::PageLoadState::reset): (WebKit::PageLoadState::activeURL): (WebKit::PageLoadState::estimatedProgress): (WebKit::PageLoadState::pendingAPIRequestURL const): (WebKit::PageLoadState::pendingAPIRequest const): (WebKit::PageLoadState::setPendingAPIRequest): (WebKit::PageLoadState::clearPendingAPIRequest): (WebKit::PageLoadState::isLoading): (WebKit::PageLoadState::setPendingAPIRequestURL): Deleted. (WebKit::PageLoadState::clearPendingAPIRequestURL): Deleted. * UIProcess/PageLoadState.h: (WebKit::PageLoadState::setPendingAPIRequest): (WebKit::PageLoadState::setPendingAPIRequestURL): Deleted. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::launchProcessForReload): (WebKit::WebPageProxy::loadRequestWithNavigationShared): (WebKit::WebPageProxy::loadFile): (WebKit::WebPageProxy::loadDataWithNavigationShared): (WebKit::WebPageProxy::loadAlternateHTML): (WebKit::WebPageProxy::loadWebArchiveData): (WebKit::WebPageProxy::reload): (WebKit::WebPageProxy::goToBackForwardItem): (WebKit::WebPageProxy::receivedPolicyDecision): (WebKit::WebPageProxy::continueNavigationInNewProcess): (WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared): (WebKit::WebPageProxy::didSameDocumentNavigationForFrame): (WebKit::WebPageProxy::decidePolicyForNavigationAction): 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247839. rdar://problem/53647896 [iOS WK2] A top fixed bar can flicker when scrolling with the keyboard up https://bugs.webkit.org/show_bug.cgi?id=200105 rdar://problem/52871975 Reviewed by Wenson Hsieh. Source/WebCore: ScrollingTreeFrameScrollingNode::layoutViewportForScrollPosition() computes a visual viewport from the current scroll position and scrollableAreaSize(). This doesn't know anything about the impact of keyboards on the visual viewport, so it computes a too-large visual viewport when the keyboard is up, triggering incorrect manipulations of the layout viewport. This leads to the top bar flashing to position 0 when it should be hidden off the top. Fix by feeding into the scrolling tree the height of the visual viewport which takes FrameView::visualViewportOverrideRect() into account. This is stored on ScrollingStateFrameScrollingNode/ ScrollingTreeFrameScrollingNode. Test: scrollingcoordinator/ios/fixed-scrolling-with-keyboard.html * page/FrameView.h: * page/scrolling/AsyncScrollingCoordinator.cpp: (WebCore::AsyncScrollingCoordinator::setFrameScrollingNodeState): * page/scrolling/ScrollingStateFrameScrollingNode.cpp: (WebCore::ScrollingStateFrameScrollingNode::ScrollingStateFrameScrollingNode): (WebCore::ScrollingStateFrameScrollingNode::setPropertyChangedBitsAfterReattach): (WebCore::ScrollingStateFrameScrollingNode::setOverrideVisualViewportSize): (WebCore::ScrollingStateFrameScrollingNode::dumpProperties const): * page/scrolling/ScrollingStateFrameScrollingNode.h: * page/scrolling/ScrollingTree.cpp: (WebCore::ScrollingTree::commitTreeState): LOG_WITH_STREAM() doesn't evaluate scrollingTreeAsText() every time. * page/scrolling/ScrollingTreeFrameScrollingNode.cpp: (WebCore::ScrollingTreeFrameScrollingNode::commitStateBeforeChildren): (WebCore::ScrollingTreeFrameScrollingNode::layoutViewportForScrollPosition const): (WebCore::ScrollingTreeFrameScrollingNode::dumpProperties const): * page/scrolling/ScrollingTreeFrameScrollingNode.h: Source/WebKit: ScrollingTreeFrameScrollingNode::layoutViewportForScrollPosition() computes a visual viewport from the current scroll position and scrollableAreaSize(). This doesn't know anything about the impact of keyboards on the visual viewport, so it computes a too-large visual viewport when the keyboard is up, triggering incorrect manipulations of the layout viewport. This leads to the top bar flashing to position 0 when it should be hidden off the top. Fix by feeding into the scrolling tree the height of the visual viewport which takes FrameView::visualViewportOverrideRect() into account. This is stored on ScrollingStateFrameScrollingNode/ ScrollingTreeFrameScrollingNode. * Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.cpp: (ArgumentCoder<ScrollingStateFrameScrollingNode>::encode): (ArgumentCoder<ScrollingStateFrameScrollingNode>::decode): LayoutTests: * resources/ui-helper.js: (window.UIHelper.ensureStablePresentationUpdate.return.new.Promise): (window.UIHelper.ensureStablePresentationUpdate): * scrollingcoordinator/ios/fixed-scrolling-with-keyboard-expected.txt: Added. * scrollingcoordinator/ios/fixed-scrolling-with-keyboard.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247839 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247838. rdar://problem/53648220 WebKit/UIProcess/ios/WKContentViewInteraction.mm: error: implementing deprecated method contextMenuInteractionWillPresent https://bugs.webkit.org/show_bug.cgi?id=200136 <rdar://problem/53547698> Reviewed by Wenson Hsieh. Ignore deprecation warnings for these UIContextMenuInteraction delegates. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView contextMenuInteractionWillPresent:]): (-[WKContentView contextMenuInteraction:willCommitWithAnimator:]): (-[WKContentView contextMenuInteractionDidEnd:]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247838 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-25 Dean Jackson <dino@apple.com> WebKit/UIProcess/ios/WKContentViewInteraction.mm: error: implementing deprecated method contextMenuInteractionWillPresent https://bugs.webkit.org/show_bug.cgi?id=200136 <rdar://problem/53547698> Reviewed by Wenson Hsieh. Ignore deprecation warnings for these UIContextMenuInteraction delegates. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView contextMenuInteractionWillPresent:]): (-[WKContentView contextMenuInteraction:willCommitWithAnimator:]): (-[WKContentView contextMenuInteractionDidEnd:]): 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247837. rdar://problem/53648220 Add helper for ignoring deprecated implementation warnings https://bugs.webkit.org/show_bug.cgi?id=200135 Reviewed by Wenson Hsieh. Add ALLOW_DEPRECATED_IMPLEMENTATIONS_BEGIN/END macro which is IGNORE_WARNINGS_BEGIN("deprecated-implementations") Source/WebCore: * accessibility/mac/WebAccessibilityObjectWrapperMac.mm: (-[WebAccessibilityObjectWrapper ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WebAccessibilityObjectWrapper accessibilityAttributeValue:]): (-[WebAccessibilityObjectWrapper accessibilityIsAttributeSettable:]): (-[WebAccessibilityObjectWrapper accessibilityPerformAction:]): (-[WebAccessibilityObjectWrapper accessibilitySetValue:forAttribute:]): (-[WebAccessibilityObjectWrapper accessibilityActionDescription:]): (-[WebAccessibilityObjectWrapper accessibilityAttributeValue:forParameter:]): (-[WebAccessibilityObjectWrapper IGNORE_WARNINGS_END]): Deleted. * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm: (-[WebAVStreamDataParserListener streamDataParserWillProvideContentKeyRequestInitializationData:forTrackID:]): (-[WebAVStreamDataParserListener streamDataParser:didProvideContentKeyRequestInitializationData:forTrackID:]): * platform/network/mac/WebCoreResourceHandleAsOperationQueueDelegate.mm: (-[WebCoreResourceHandleAsOperationQueueDelegate connection:didReceiveAuthenticationChallenge:]): (-[WebCoreResourceHandleAsOperationQueueDelegate connection:canAuthenticateAgainstProtectionSpace:]): Source/WebKit: * UIProcess/API/Cocoa/LegacyBundleForClass.mm: * UIProcess/API/Cocoa/WKBrowsingContextController.mm: (IGNORE_WARNINGS_BEGIN): Deleted. * UIProcess/API/Cocoa/WKBrowsingContextGroup.mm: (IGNORE_WARNINGS_BEGIN): Deleted. * UIProcess/API/Cocoa/WKConnection.mm: (IGNORE_WARNINGS_BEGIN): Deleted. * UIProcess/API/Cocoa/WKPreviewElementInfo.mm: * UIProcess/API/Cocoa/WKProcessGroup.mm: (IGNORE_WARNINGS_BEGIN): Deleted. * UIProcess/API/Cocoa/WKTypeRefWrapper.mm: * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WKWebView draggedImage:endedAt:operation:]): (-[WKWebView accessibilityAttributeValue:]): (-[WKWebView accessibilityAttributeValue:forParameter:]): (-[WKWebView namesOfPromisedFilesDroppedAtDestination:]): (-[WKWebView IGNORE_WARNINGS_END]): Deleted. * UIProcess/API/Cocoa/WKWebViewConfiguration.mm: (-[WKWebViewConfiguration ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WKWebViewConfiguration _setWebsiteDataStore:]): (-[WKWebViewConfiguration IGNORE_WARNINGS_END]): Deleted. * UIProcess/API/Cocoa/_WKWebsiteDataStore.mm: * UIProcess/API/mac/WKView.mm: (-[WKView ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WKView draggedImage:endedAt:operation:]): (-[WKView accessibilityAttributeValue:]): (-[WKView accessibilityAttributeValue:forParameter:]): (-[WKView namesOfPromisedFilesDroppedAtDestination:]): (-[WKView IGNORE_WARNINGS_END]): Deleted. * UIProcess/WKImagePreviewViewController.mm: (-[WKImagePreviewViewController ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WKImagePreviewViewController IGNORE_WARNINGS_END]): Deleted. * UIProcess/ios/forms/WKAirPlayRoutePicker.mm: (-[WKAirPlayRoutePicker popoverControllerDidDismissPopover:]): * UIProcess/ios/forms/WKFileUploadPanel.mm: (-[WKFileUploadPanel popoverControllerDidDismissPopover:]): * UIProcess/ios/forms/WKFormPopover.mm: (-[WKRotatingPopover popoverControllerDidDismissPopover:]): * WebProcess/Plugins/PDF/PDFPlugin.mm: (-[WKPDFPluginAccessibilityObject ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WKPDFPluginAccessibilityObject accessibilityAttributeValue:]): (-[WKPDFPluginAccessibilityObject accessibilityAttributeValue:forParameter:]): (-[WKPDFPluginAccessibilityObject accessibilityPerformAction:]): (-[WKPDFPluginAccessibilityObject accessibilityIsAttributeSettable:]): (-[WKPDFPluginAccessibilityObject accessibilitySetValue:forAttribute:]): (-[WKPDFPluginAccessibilityObject IGNORE_WARNINGS_END]): Deleted. * WebProcess/WebPage/mac/WKAccessibilityWebPageObjectMac.mm: (-[WKAccessibilityWebPageObject ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WKAccessibilityWebPageObject accessibilityIsAttributeSettable:]): (-[WKAccessibilityWebPageObject accessibilitySetValue:forAttribute:]): (-[WKAccessibilityWebPageObject accessibilityAttributeValue:]): (-[WKAccessibilityWebPageObject accessibilityAttributeValue:forParameter:]): (-[WKAccessibilityWebPageObject IGNORE_WARNINGS_END]): Deleted. Source/WebKitLegacy/mac: * Misc/WebDownload.mm: (-[WebDownload initWithRequest:delegate:]): * Misc/WebIconDatabase.mm: * Plugins/WebBaseNetscapePluginView.mm: (-[WebBaseNetscapePluginView ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WebBaseNetscapePluginView IGNORE_WARNINGS_END]): Deleted. * WebView/WebDynamicScrollBarsView.mm: (-[WebDynamicScrollBarsView ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WebDynamicScrollBarsView IGNORE_WARNINGS_END]): Deleted. * WebView/WebHTMLView.mm: (-[WebHTMLView draggingSourceOperationMaskForLocal:]): (-[WebHTMLView draggedImage:endedAt:operation:]): (-[WebHTMLView namesOfPromisedFilesDroppedAtDestination:]): (-[WebHTMLView accessibilityAttributeValue:]): (-[WebHTMLView ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WebHTMLView characterIndexForPoint:]): (-[WebHTMLView firstRectForCharacterRange:]): (-[WebHTMLView attributedSubstringFromRange:]): (-[WebHTMLView setMarkedText:selectedRange:]): (-[WebHTMLView doCommandBySelector:]): (-[WebHTMLView insertText:]): (-[WebHTMLView IGNORE_WARNINGS_END]): Deleted. Source/WTF: * wtf/Compiler.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247837 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-25 Dean Jackson <dino@apple.com> Add helper for ignoring deprecated implementation warnings https://bugs.webkit.org/show_bug.cgi?id=200135 Reviewed by Wenson Hsieh. Add ALLOW_DEPRECATED_IMPLEMENTATIONS_BEGIN/END macro which is IGNORE_WARNINGS_BEGIN("deprecated-implementations") * UIProcess/API/Cocoa/LegacyBundleForClass.mm: * UIProcess/API/Cocoa/WKBrowsingContextController.mm: (IGNORE_WARNINGS_BEGIN): Deleted. * UIProcess/API/Cocoa/WKBrowsingContextGroup.mm: (IGNORE_WARNINGS_BEGIN): Deleted. * UIProcess/API/Cocoa/WKConnection.mm: (IGNORE_WARNINGS_BEGIN): Deleted. * UIProcess/API/Cocoa/WKPreviewElementInfo.mm: * UIProcess/API/Cocoa/WKProcessGroup.mm: (IGNORE_WARNINGS_BEGIN): Deleted. * UIProcess/API/Cocoa/WKTypeRefWrapper.mm: * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WKWebView draggedImage:endedAt:operation:]): (-[WKWebView accessibilityAttributeValue:]): (-[WKWebView accessibilityAttributeValue:forParameter:]): (-[WKWebView namesOfPromisedFilesDroppedAtDestination:]): (-[WKWebView IGNORE_WARNINGS_END]): Deleted. * UIProcess/API/Cocoa/WKWebViewConfiguration.mm: (-[WKWebViewConfiguration ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WKWebViewConfiguration _setWebsiteDataStore:]): (-[WKWebViewConfiguration IGNORE_WARNINGS_END]): Deleted. * UIProcess/API/Cocoa/_WKWebsiteDataStore.mm: * UIProcess/API/mac/WKView.mm: (-[WKView ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WKView draggedImage:endedAt:operation:]): (-[WKView accessibilityAttributeValue:]): (-[WKView accessibilityAttributeValue:forParameter:]): (-[WKView namesOfPromisedFilesDroppedAtDestination:]): (-[WKView IGNORE_WARNINGS_END]): Deleted. * UIProcess/WKImagePreviewViewController.mm: (-[WKImagePreviewViewController ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WKImagePreviewViewController IGNORE_WARNINGS_END]): Deleted. * UIProcess/ios/forms/WKAirPlayRoutePicker.mm: (-[WKAirPlayRoutePicker popoverControllerDidDismissPopover:]): * UIProcess/ios/forms/WKFileUploadPanel.mm: (-[WKFileUploadPanel popoverControllerDidDismissPopover:]): * UIProcess/ios/forms/WKFormPopover.mm: (-[WKRotatingPopover popoverControllerDidDismissPopover:]): * WebProcess/Plugins/PDF/PDFPlugin.mm: (-[WKPDFPluginAccessibilityObject ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WKPDFPluginAccessibilityObject accessibilityAttributeValue:]): (-[WKPDFPluginAccessibilityObject accessibilityAttributeValue:forParameter:]): (-[WKPDFPluginAccessibilityObject accessibilityPerformAction:]): (-[WKPDFPluginAccessibilityObject accessibilityIsAttributeSettable:]): (-[WKPDFPluginAccessibilityObject accessibilitySetValue:forAttribute:]): (-[WKPDFPluginAccessibilityObject IGNORE_WARNINGS_END]): Deleted. * WebProcess/WebPage/mac/WKAccessibilityWebPageObjectMac.mm: (-[WKAccessibilityWebPageObject ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WKAccessibilityWebPageObject accessibilityIsAttributeSettable:]): (-[WKAccessibilityWebPageObject accessibilitySetValue:forAttribute:]): (-[WKAccessibilityWebPageObject accessibilityAttributeValue:]): (-[WKAccessibilityWebPageObject accessibilityAttributeValue:forParameter:]): (-[WKAccessibilityWebPageObject IGNORE_WARNINGS_END]): Deleted. 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247822. rdar://problem/53648211 Avoid UI Process hangs when the WebContent process is showing JS prompts / alerts https://bugs.webkit.org/show_bug.cgi?id=200107 <rdar://problem/53034592> Reviewed by Geoffrey Garen. Source/WebCore: Add testing infrastructure for SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply. Test: fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply.html * page/ChromeClient.h: * testing/Internals.cpp: (WebCore::Internals::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * testing/Internals.h: * testing/Internals.idl: Source/WebKit: * Platform/IPC/Connection.cpp: (IPC::Connection::SyncMessageState::incrementProcessIncomingSyncMessagesWhenWaitingForSyncReplyCount): (IPC::Connection::SyncMessageState::decrementProcessIncomingSyncMessagesWhenWaitingForSyncReplyCount): (IPC::Connection::SyncMessageState::processIncomingMessage): (IPC::Connection::sendSyncMessage): * Platform/IPC/Connection.h: Add support for new SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply flag to allow processing incoming sync messages while sending a particular sync IPC. This is the default behavior in all processes except in the WebContent process, where we try to avoid re-entering to prevent bugs. This flag allows the WebContent process to change its default behavior for some specific IPCs, where we know it is safe to re-enter and where it benefits performance to re-renter. * NetworkProcess/NetworkConnectionToWebProcess.cpp: (WebKit::NetworkConnectionToWebProcess::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * NetworkProcess/NetworkConnectionToWebProcess.h: * NetworkProcess/NetworkConnectionToWebProcess.messages.in: * UIProcess/Network/NetworkProcessProxy.cpp: (WebKit::NetworkProcessProxy::didReceiveSyncMessage): (WebKit::NetworkProcessProxy::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * UIProcess/Network/NetworkProcessProxy.h: * UIProcess/Network/NetworkProcessProxy.messages.in: * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * WebProcess/WebCoreSupport/WebChromeClient.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * WebProcess/WebPage/WebPage.h: (WebKit::WebPage::sendSyncWithDelayedReply): * WebProcess/WebPage/WebPage.messages.in: SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply Add testing infrastructure for SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply flag. * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::runJavaScriptAlert): (WebKit::WebChromeClient::runJavaScriptConfirm): (WebKit::WebChromeClient::runJavaScriptPrompt): Use new SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply flag when sending the synchronous IPC for JS alerts / prompt / confirm. This allows the WebProcess to process incoming synchronous IPC for other processes (in particular the UIProcess) while it is blocked on those synchronous IPCs. It is safe to re-enter the WebContent process on these sync IPCs since they are triggered by JS and we return to JS right after. This should avoid UIProcess hangs when the UIProcess is sending a sync IPC to the WebContent process, which is itself stuck on the sync IPC to show a JS alert. LayoutTests: Add layout test coverage for SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply. Without the flag on the sendSync from the WebContent process of the NetworkConnectionToWebProcess::TestProcessIncomingSyncMessagesWhenWaitingForSyncReply IPC, the test would hang. This is because the WebContent process sends a sync IPC to the network process, which in turns sends one to the UIProcess, which itself sends one back to the WebContent process. This would attempt to re-enter the WebContent process which is currently sending a sync IPC, which is not allowed by default. * fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply-expected.txt: Added. * fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247822 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-25 Chris Dumez <cdumez@apple.com> Avoid UI Process hangs when the WebContent process is showing JS prompts / alerts https://bugs.webkit.org/show_bug.cgi?id=200107 <rdar://problem/53034592> Reviewed by Geoffrey Garen. * Platform/IPC/Connection.cpp: (IPC::Connection::SyncMessageState::incrementProcessIncomingSyncMessagesWhenWaitingForSyncReplyCount): (IPC::Connection::SyncMessageState::decrementProcessIncomingSyncMessagesWhenWaitingForSyncReplyCount): (IPC::Connection::SyncMessageState::processIncomingMessage): (IPC::Connection::sendSyncMessage): * Platform/IPC/Connection.h: Add support for new SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply flag to allow processing incoming sync messages while sending a particular sync IPC. This is the default behavior in all processes except in the WebContent process, where we try to avoid re-entering to prevent bugs. This flag allows the WebContent process to change its default behavior for some specific IPCs, where we know it is safe to re-enter and where it benefits performance to re-renter. * NetworkProcess/NetworkConnectionToWebProcess.cpp: (WebKit::NetworkConnectionToWebProcess::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * NetworkProcess/NetworkConnectionToWebProcess.h: * NetworkProcess/NetworkConnectionToWebProcess.messages.in: * UIProcess/Network/NetworkProcessProxy.cpp: (WebKit::NetworkProcessProxy::didReceiveSyncMessage): (WebKit::NetworkProcessProxy::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * UIProcess/Network/NetworkProcessProxy.h: * UIProcess/Network/NetworkProcessProxy.messages.in: * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * WebProcess/WebCoreSupport/WebChromeClient.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): * WebProcess/WebPage/WebPage.h: (WebKit::WebPage::sendSyncWithDelayedReply): * WebProcess/WebPage/WebPage.messages.in: SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply Add testing infrastructure for SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply flag. * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::runJavaScriptAlert): (WebKit::WebChromeClient::runJavaScriptConfirm): (WebKit::WebChromeClient::runJavaScriptPrompt): Use new SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply flag when sending the synchronous IPC for JS alerts / prompt / confirm. This allows the WebProcess to process incoming synchronous IPC for other processes (in particular the UIProcess) while it is blocked on those synchronous IPCs. It is safe to re-enter the WebContent process on these sync IPCs since they are triggered by JS and we return to JS right after. This should avoid UIProcess hangs when the UIProcess is sending a sync IPC to the WebContent process, which is itself stuck on the sync IPC to show a JS alert. 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247817. rdar://problem/53648067 Unable to tap/double tap to open files/folders in Google Drive in Safari https://bugs.webkit.org/show_bug.cgi?id=200096 <rdar://problem/52748552> Reviewed by Wenson Hsieh. Source/WebKit: This patch reverts to the original double-tap-for-double-click implementation (see r244775 and r246347 for more information). * Shared/WebPageCreationParameters.cpp: (WebKit::WebPageCreationParameters::encode const): (WebKit::WebPageCreationParameters::decode): * Shared/WebPageCreationParameters.h: * UIProcess/PageClient.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::creationParameters): * UIProcess/WebPageProxy.h: * UIProcess/ios/PageClientImplIOS.h: * UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::doubleTapForDoubleClickDelay): Deleted. (WebKit::PageClientImpl::doubleTapForDoubleClickRadius): Deleted. * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView setupInteraction]): (-[WKContentView cleanupInteraction]): (-[WKContentView _removeDefaultGestureRecognizers]): (-[WKContentView _addDefaultGestureRecognizers]): (-[WKContentView gestureRecognizer:shouldRecognizeSimultaneouslyWithGestureRecognizer:]): Do not recognize the single and double gestures the same time. (-[WKContentView gestureRecognizerShouldBegin:]): (-[WKContentView _doubleTapRecognizedForDoubleClick:]): (-[WKContentView _didStartProvisionalLoadForMainFrame]): (-[WKContentView _ensureNonBlockingDoubleTapGestureRecognizer]): Deleted. (-[WKContentView _doubleTapForDoubleClickDelay]): Deleted. (-[WKContentView _doubleTapForDoubleClickRadius]): Deleted. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::handleDoubleTapForDoubleClickAtPoint): * WebProcess/WebPage/WebPage.cpp: * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::handleDoubleTapForDoubleClickAtPoint): (WebKit::WebPage::commitPotentialTap): (WebKit::WebPage::handlePotentialDoubleTapForDoubleClickAtPoint): Deleted. LayoutTests: Rebaseline. * fast/events/touch/ios/double-tap-for-double-click3-expected.txt: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247817 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-24 Zalan Bujtas <zalan@apple.com> Unable to tap/double tap to open files/folders in Google Drive in Safari https://bugs.webkit.org/show_bug.cgi?id=200096 <rdar://problem/52748552> Reviewed by Wenson Hsieh. This patch reverts to the original double-tap-for-double-click implementation (see r244775 and r246347 for more information). * Shared/WebPageCreationParameters.cpp: (WebKit::WebPageCreationParameters::encode const): (WebKit::WebPageCreationParameters::decode): * Shared/WebPageCreationParameters.h: * UIProcess/PageClient.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::creationParameters): * UIProcess/WebPageProxy.h: * UIProcess/ios/PageClientImplIOS.h: * UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::doubleTapForDoubleClickDelay): Deleted. (WebKit::PageClientImpl::doubleTapForDoubleClickRadius): Deleted. * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView setupInteraction]): (-[WKContentView cleanupInteraction]): (-[WKContentView _removeDefaultGestureRecognizers]): (-[WKContentView _addDefaultGestureRecognizers]): (-[WKContentView gestureRecognizer:shouldRecognizeSimultaneouslyWithGestureRecognizer:]): Do not recognize the single and double gestures the same time. (-[WKContentView gestureRecognizerShouldBegin:]): (-[WKContentView _doubleTapRecognizedForDoubleClick:]): (-[WKContentView _didStartProvisionalLoadForMainFrame]): (-[WKContentView _ensureNonBlockingDoubleTapGestureRecognizer]): Deleted. (-[WKContentView _doubleTapForDoubleClickDelay]): Deleted. (-[WKContentView _doubleTapForDoubleClickRadius]): Deleted. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::handleDoubleTapForDoubleClickAtPoint): * WebProcess/WebPage/WebPage.cpp: * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::handleDoubleTapForDoubleClickAtPoint): (WebKit::WebPage::commitPotentialTap): (WebKit::WebPage::handlePotentialDoubleTapForDoubleClickAtPoint): Deleted. 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247793. rdar://problem/53648076 Regression(r247400): Unable to log into AIB Mobile Banking App https://bugs.webkit.org/show_bug.cgi?id=200094 <rdar://problem/52519818> Reviewed by Brent Fulgham. In r247400, a change was made to only set the 'app has universal sandbox access' flag only when issueing the sandbox extension for / actually succeeded (it usually fails in practice). Previously, AIB Mobile Banking app was relying on this behavior to trigger a load for file:///login which is outside their container. However, now that the 'app has universal sandbox access' flag is no longer set, it trips our security checks and the load gets ignored. To address the issue, apply only the 'app has universal sandbox access' flag fix with a linked-on-after check. * UIProcess/Cocoa/VersionChecks.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247793 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-24 Chris Dumez <cdumez@apple.com> Regression(r247400): Unable to log into AIB Mobile Banking App https://bugs.webkit.org/show_bug.cgi?id=200094 <rdar://problem/52519818> Reviewed by Brent Fulgham. In r247400, a change was made to only set the 'app has universal sandbox access' flag only when issueing the sandbox extension for / actually succeeded (it usually fails in practice). Previously, AIB Mobile Banking app was relying on this behavior to trigger a load for file:///login which is outside their container. However, now that the 'app has universal sandbox access' flag is no longer set, it trips our security checks and the load gets ignored. To address the issue, apply only the 'app has universal sandbox access' flag fix with a linked-on-after check. * UIProcess/Cocoa/VersionChecks.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle): 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247791. rdar://problem/53647631 Module-enabled users of WKWebProcessPlugInFrame.h fail to build; duplicate declaration https://bugs.webkit.org/show_bug.cgi?id=200095 <rdar://problem/53512407> Reviewed by Wenson Hsieh. * WebProcess/InjectedBundle/API/Cocoa/WKWebProcessPlugInFrame.h: Import <JavaScriptCore/JavaScriptCore.h> (the module header) instead of <JavaScriptCore/JSContext.h> directly, otherwise we can end up getting JSContext.h included twice, to the compiler's chagrin. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247791 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-24 Tim Horton <timothy_horton@apple.com> Module-enabled users of WKWebProcessPlugInFrame.h fail to build; duplicate declaration https://bugs.webkit.org/show_bug.cgi?id=200095 <rdar://problem/53512407> Reviewed by Wenson Hsieh. * WebProcess/InjectedBundle/API/Cocoa/WKWebProcessPlugInFrame.h: Import <JavaScriptCore/JavaScriptCore.h> (the module header) instead of <JavaScriptCore/JSContext.h> directly, otherwise we can end up getting JSContext.h included twice, to the compiler's chagrin. 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247787. rdar://problem/53647890 Crash in WebContent process with custom schemes. <rdar://problem/52968793> and https://bugs.webkit.org/show_bug.cgi?id=200062 Reviewed by Andy Estes. Almost everywhere in WebURLSchemeTaskProxy where we call processNextPendingTask() we first protect the task with a ref. But not in didReceiveData. So lets do that. * WebProcess/WebPage/WebURLSchemeTaskProxy.cpp: (WebKit::WebURLSchemeTaskProxy::didReceiveData): Protect this. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247787 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-24 Brady Eidson <beidson@apple.com> Crash in WebContent process with custom schemes. <rdar://problem/52968793> and https://bugs.webkit.org/show_bug.cgi?id=200062 Reviewed by Andy Estes. Almost everywhere in WebURLSchemeTaskProxy where we call processNextPendingTask() we first protect the task with a ref. But not in didReceiveData. So lets do that. * WebProcess/WebPage/WebURLSchemeTaskProxy.cpp: (WebKit::WebURLSchemeTaskProxy::didReceiveData): Protect this. 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247786. rdar://problem/53647457 Null check CompletionHandler in WebPreviewLoaderClient::didReceivePassword https://bugs.webkit.org/show_bug.cgi?id=200080 <rdar://problem/37275772> Patch by Alex Christensen <achristensen@webkit.org> on 2019-07-24 Reviewed by Chris Dumez. * WebProcess/WebCoreSupport/ios/WebPreviewLoaderClient.cpp: (WebKit::WebPreviewLoaderClient::didReceivePassword): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247786 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-24 Alex Christensen <achristensen@webkit.org> Null check CompletionHandler in WebPreviewLoaderClient::didReceivePassword https://bugs.webkit.org/show_bug.cgi?id=200080 <rdar://problem/37275772> Reviewed by Chris Dumez. * WebProcess/WebCoreSupport/ios/WebPreviewLoaderClient.cpp: (WebKit::WebPreviewLoaderClient::didReceivePassword): 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247784. rdar://problem/53647468 Crash under WebKit:WTF::Detail::CallableWrapper<WebKit::ResourceLoadStatisticsMemoryStore::updateCookieBlocking(WTF::CompletionHandler<void ()>&&)::$_32::operator()()::'lambda'(), void>::call https://bugs.webkit.org/show_bug.cgi?id=200071 <rdar://problem/53335583> Reviewed by Brent Fulgham and Youenn Fablet. The WebResourceLoadStatisticsStore is a main thread object. In its destructor, it was dispatching to the background queue to destroy the m_statisticsStore / m_persistentStorage data members, which live on the background queue. It would then synchronously wait for the background queue to finish destroying them. The idea was to guarantee that the ResourceLoadStatisticsMemoryStore and the ResourceLoadStatisticsPersistentStorage would never outlive the WebResourceLoadStatisticsStore, given that they keep a raw pointer back to the WebResourceLoadStatisticsStore (via m_store data member). The issue is that *while* the WebResourceLoadStatisticsStore destructor is running on the main thread, the background queue may be running code in ResourceLoadStatisticsMemoryStore or ResourceLoadStatisticsPersistentStorage which refs the WebResourceLoadStatisticsStore, even though its ref count has already reached 0. It is actually a common pattern in ResourceLoadStatisticsMemoryStore to call RunLoop::main().dispatch() and ref their m_store in the lambda, so that they can interact with the WebResourceLoadStatisticsStore. To address the issue, we now destroy m_statisticsStore / m_persistentStorage *before* the WebResourceLoadStatisticsStore destructor runs. The NetworkSession destructor now calls WebResourceLoadStatisticsStore::didDestroyNetworkSession() which takes care of destroying m_statisticsStore / m_persistentStorage on the background queue, synchronously. The WebResourceLoadStatisticsStore destructor will only run later, once all remaining references to it are gone. * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp: (WebKit::WebResourceLoadStatisticsStore::~WebResourceLoadStatisticsStore): (WebKit::WebResourceLoadStatisticsStore::didDestroyNetworkSession): * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.h: * NetworkProcess/NetworkSession.cpp: (WebKit::NetworkSession::~NetworkSession): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247784 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-24 Chris Dumez <cdumez@apple.com> Crash under WebKit:WTF::Detail::CallableWrapper<WebKit::ResourceLoadStatisticsMemoryStore::updateCookieBlocking(WTF::CompletionHandler<void ()>&&)::$_32::operator()()::'lambda'(), void>::call https://bugs.webkit.org/show_bug.cgi?id=200071 <rdar://problem/53335583> Reviewed by Brent Fulgham and Youenn Fablet. The WebResourceLoadStatisticsStore is a main thread object. In its destructor, it was dispatching to the background queue to destroy the m_statisticsStore / m_persistentStorage data members, which live on the background queue. It would then synchronously wait for the background queue to finish destroying them. The idea was to guarantee that the ResourceLoadStatisticsMemoryStore and the ResourceLoadStatisticsPersistentStorage would never outlive the WebResourceLoadStatisticsStore, given that they keep a raw pointer back to the WebResourceLoadStatisticsStore (via m_store data member). The issue is that *while* the WebResourceLoadStatisticsStore destructor is running on the main thread, the background queue may be running code in ResourceLoadStatisticsMemoryStore or ResourceLoadStatisticsPersistentStorage which refs the WebResourceLoadStatisticsStore, even though its ref count has already reached 0. It is actually a common pattern in ResourceLoadStatisticsMemoryStore to call RunLoop::main().dispatch() and ref their m_store in the lambda, so that they can interact with the WebResourceLoadStatisticsStore. 2019-07-24 Simon Fraser <simon.fraser@apple.com> [iOS WK2] A top fixed bar can flicker when scrolling with the keyboard up https://bugs.webkit.org/show_bug.cgi?id=200105 rdar://problem/52871975 Reviewed by Wenson Hsieh. ScrollingTreeFrameScrollingNode::layoutViewportForScrollPosition() computes a visual viewport from the current scroll position and scrollableAreaSize(). This doesn't know anything about the impact of keyboards on the visual viewport, so it computes a too-large visual viewport when the keyboard is up, triggering incorrect manipulations of the layout viewport. This leads to the top bar flashing to position 0 when it should be hidden off the top. Fix by feeding into the scrolling tree the height of the visual viewport which takes FrameView::visualViewportOverrideRect() into account. This is stored on ScrollingStateFrameScrollingNode/ ScrollingTreeFrameScrollingNode. * Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.cpp: (ArgumentCoder<ScrollingStateFrameScrollingNode>::encode): (ArgumentCoder<ScrollingStateFrameScrollingNode>::decode): To address the issue, we now destroy m_statisticsStore / m_persistentStorage *before* the WebResourceLoadStatisticsStore destructor runs. The NetworkSession destructor now calls WebResourceLoadStatisticsStore::didDestroyNetworkSession() which takes care of destroying m_statisticsStore / m_persistentStorage on the background queue, synchronously. The WebResourceLoadStatisticsStore destructor will only run later, once all remaining references to it are gone. * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp: (WebKit::WebResourceLoadStatisticsStore::~WebResourceLoadStatisticsStore): (WebKit::WebResourceLoadStatisticsStore::didDestroyNetworkSession): * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.h: * NetworkProcess/NetworkSession.cpp: (WebKit::NetworkSession::~NetworkSession): 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247782. rdar://problem/53647473 SYS___pthread_markcancel is sometimes used by libwebrtc https://bugs.webkit.org/show_bug.cgi?id=200087 <rdar://problem/53408606> Reviewed by Brent Fulgham. * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb: Whitelist this unix-call within WebProcess as libwebrtc uses it. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247782 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-24 Youenn Fablet <youenn@apple.com> SYS___pthread_markcancel is sometimes used by libwebrtc https://bugs.webkit.org/show_bug.cgi?id=200087 <rdar://problem/53408606> Reviewed by Brent Fulgham. * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb: Whitelist this unix-call within WebProcess as libwebrtc uses it. 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247780. rdar://problem/53647618 ASSERTION FAILED: settings().textAutosizingEnabled() && settings().textAutosizingUsesIdempotentMode() in WebCore::Page::recomputeTextAutoSizingInAllFrames() https://bugs.webkit.org/show_bug.cgi?id=200079 <rdar://problem/53474325> Reviewed by Wenson Hsieh. Source/WebKit: Do not reset idempotent values when the text autosizing is off. * UIProcess/API/C/WKPreferences.cpp: (WKPreferencesSetTextAutosizingUsesIdempotentMode): (WKPreferencesGetTextAutosizingUsesIdempotentMode): * UIProcess/API/C/WKPreferencesRef.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::resetIdempotentTextAutosizingIfNeeded): Tools: Reset textAutosizingUsesIdempotentMode when transitioning to a new test. * WebKitTestRunner/ios/TestControllerIOS.mm: (WTR::TestController::platformResetPreferencesToConsistentValues): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247780 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-24 Zalan Bujtas <zalan@apple.com> ASSERTION FAILED: settings().textAutosizingEnabled() && settings().textAutosizingUsesIdempotentMode() in WebCore::Page::recomputeTextAutoSizingInAllFrames() https://bugs.webkit.org/show_bug.cgi?id=200079 <rdar://problem/53474325> Reviewed by Wenson Hsieh. Do not reset idempotent values when the text autosizing is off. * UIProcess/API/C/WKPreferences.cpp: (WKPreferencesSetTextAutosizingUsesIdempotentMode): (WKPreferencesGetTextAutosizingUsesIdempotentMode): * UIProcess/API/C/WKPreferencesRef.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::resetIdempotentTextAutosizingIfNeeded): 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247755. rdar://problem/53575423 AX: CrashTracer: com.apple.WebKit.WebContent at WebKit: WebKit::WebSpeechSynthesisClient::speak https://bugs.webkit.org/show_bug.cgi?id=199988 Reviewed by Per Arne Vollan. Source/WebCore: Implement the reset state to cancel current speech jobs. * Modules/speech/SpeechSynthesis.cpp: (WebCore::SpeechSynthesis::startSpeakingImmediately): (WebCore::SpeechSynthesis::cancel): * platform/PlatformSpeechSynthesizer.h: * platform/ios/PlatformSpeechSynthesizerIOS.mm: (WebCore::PlatformSpeechSynthesizer::resetState): * platform/mac/PlatformSpeechSynthesizerMac.mm: (WebCore::PlatformSpeechSynthesizer::resetState): Source/WebKit: Improvements to WebSpeechSynthesis to avoid crashing and improve correctness. - Reset and cancel speech jobs on page close or reload (otherwise the synthesizer keeps talking after your page is gone) - Have a separate speech finish callback mechanism, use the start speaking callback when the synthesizer tells us. - Move an assert on utterance state to only apply when we use the in process synthesizer. * UIProcess/Cocoa/WebPageProxyCocoa.mm: (WebKit::WebPageProxy::didStartSpeaking): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::reload): (WebKit::WebPageProxy::resetState): (WebKit::WebPageProxy::resetSpeechSynthesizer): (WebKit::WebPageProxy::speechSynthesisSetFinishedCallback): (WebKit::WebPageProxy::speechSynthesisSpeak): * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * WebProcess/WebCoreSupport/WebSpeechSynthesisClient.cpp: (WebKit::WebSpeechSynthesisClient::speak): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247755 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-23 Chris Fleizach <cfleizach@apple.com> AX: CrashTracer: com.apple.WebKit.WebContent at WebKit: WebKit::WebSpeechSynthesisClient::speak https://bugs.webkit.org/show_bug.cgi?id=199988 Reviewed by Per Arne Vollan. Improvements to WebSpeechSynthesis to avoid crashing and improve correctness. - Reset and cancel speech jobs on page close or reload (otherwise the synthesizer keeps talking after your page is gone) - Have a separate speech finish callback mechanism, use the start speaking callback when the synthesizer tells us. - Move an assert on utterance state to only apply when we use the in process synthesizer. * UIProcess/Cocoa/WebPageProxyCocoa.mm: (WebKit::WebPageProxy::didStartSpeaking): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::reload): (WebKit::WebPageProxy::resetState): (WebKit::WebPageProxy::resetSpeechSynthesizer): (WebKit::WebPageProxy::speechSynthesisSetFinishedCallback): (WebKit::WebPageProxy::speechSynthesisSpeak): * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * WebProcess/WebCoreSupport/WebSpeechSynthesisClient.cpp: (WebKit::WebSpeechSynthesisClient::speak): 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247722. rdar://problem/53647293 [macOS 10.15] Web process crashes when attempting to show the font panel via Font > Show Fonts https://bugs.webkit.org/show_bug.cgi?id=200021 <rdar://problem/53301325> Reviewed by Ryosuke Niwa. Source/WebCore: In macOS 10.15, attempting to access ~/Library/FontCollections/ from the web process causes a Sandbox violation and a subsequent crash. This can be triggered by trying to show the font panel via Font > Show Fonts in the context menu after right clicking. In the (near) future, we should fix this by moving logic to show the font panel, color panel and styles panel from the Editor in the web process to the UI process in WebKit2. However, for the time being, we can just work around this by adding a new EditorClient hook to determine whether to allow the font panel to show; this returns true in the legacy macOS WebKit port, and false everywhere else. Test: editing/mac/style/do-not-crash-when-showing-font-panel.html * editing/mac/EditorMac.mm: (WebCore::Editor::showFontPanel): * loader/EmptyClients.cpp: * page/EditorClient.h: Source/WebKit: Always return false from canShowFontPanel in WebKit2. * WebProcess/WebCoreSupport/WebEditorClient.h: Source/WebKitLegacy/mac: Implement a new editing client hook. In WebKit1, this always returns true on macOS and false on iOS. * WebCoreSupport/WebEditorClient.h: Source/WebKitLegacy/win: Implement a new editing client hook. * WebCoreSupport/WebEditorClient.h: Tools: Add support for grabbing the child menu items of a context menu item. * WebKitTestRunner/InjectedBundle/EventSendingController.cpp: (WTR::getMenuItemChildrenCallback): LayoutTests: Add a new layout test to verify that attempting to show the font panel doesn't crash the web process in WebKit2. This test is skipped in WebKit1, since EventSender::contextClick() in WebKit1 only returns an array of strings corresponding to the titles of each menu item. * editing/mac/style/do-not-crash-when-showing-font-panel-expected.txt: Added. * editing/mac/style/do-not-crash-when-showing-font-panel.html: Added. * platform/mac-wk1/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247722 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-23 Wenson Hsieh <wenson_hsieh@apple.com> [macOS 10.15] Web process crashes when attempting to show the font panel via Font > Show Fonts https://bugs.webkit.org/show_bug.cgi?id=200021 <rdar://problem/53301325> Reviewed by Ryosuke Niwa. Always return false from canShowFontPanel in WebKit2. * WebProcess/WebCoreSupport/WebEditorClient.h: 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247695. rdar://problem/53648210 REGRESSION(rUnknown): YouTube playback pauses when switching to a new tab https://bugs.webkit.org/show_bug.cgi?id=199971 <rdar://problem/51951218> Reviewed by Alex Christensen. Source/WebKit: When we get a message notifying us that the view has been removed from the window, we unconditionally ask the fullscreen manager to exit fullscreen, which has the side effect (on iOS) of pausing the video unconditionally. Only ask the fullscreen manager to exit fullscreen if there is actually a video in fullscreen mode. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::viewDidLeaveWindow): Tools: * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKitCocoa/NoPauseWhenSwitchingTabs.mm: Added. (TestWebKitAPI::TEST): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247695 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-22 Jer Noble <jer.noble@apple.com> REGRESSION(rUnknown): YouTube playback pauses when switching to a new tab https://bugs.webkit.org/show_bug.cgi?id=199971 <rdar://problem/51951218> Reviewed by Alex Christensen. When we get a message notifying us that the view has been removed from the window, we unconditionally ask the fullscreen manager to exit fullscreen, which has the side effect (on iOS) of pausing the video unconditionally. Only ask the fullscreen manager to exit fullscreen if there is actually a video in fullscreen mode. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::viewDidLeaveWindow): 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247687. rdar://problem/53648060 [iOS] REGRESSION (r241734): Autocorrection highlight should hide when field becomes defocused https://bugs.webkit.org/show_bug.cgi?id=199807 <rdar://problem/52760259> Fix a bad merge of r247653. svn-apply was way too forgiving. The original patch touched the non-existent function, -_didCommitLoadForMainFrame in WKContentViewInteraction.mm. Because that didn't exist, svn-apply patched up -clearSelection. * UIProcess/ios/WKContentView.h: * UIProcess/ios/WKContentView.mm: (-[WKContentView _didCommitLoadForMainFrame]): Deleted; moved to WKContentViewInteraction.mm * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView clearSelection]): Remove code that should be in -_didCommitLoadForMainFrame. (-[WKContentView _didCommitLoadForMainFrame]): Moved from WKContentView.mm git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247687 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-22 Daniel Bates <dabates@apple.com> [iOS] REGRESSION (r241734): Autocorrection highlight should hide when field becomes defocused https://bugs.webkit.org/show_bug.cgi?id=199807 <rdar://problem/52760259> Fix a bad merge of r247653. svn-apply was way too forgiving. The original patch touched the non-existent function, -_didCommitLoadForMainFrame in WKContentViewInteraction.mm. Because that didn't exist, svn-apply patched up -clearSelection. * UIProcess/ios/WKContentView.h: * UIProcess/ios/WKContentView.mm: (-[WKContentView _didCommitLoadForMainFrame]): Deleted; moved to WKContentViewInteraction.mm * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView clearSelection]): Remove code that should be in -_didCommitLoadForMainFrame. (-[WKContentView _didCommitLoadForMainFrame]): Moved from WKContentView.mm 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247679. rdar://problem/53648080 [iOS] [WebKit2] Add limited support for -isPosition:atBoundary:inDirection: in WKContentView https://bugs.webkit.org/show_bug.cgi?id=199993 <rdar://problem/49523528> Reviewed by Beth Dakin. Source/WebKit: Add support for -isPosition:atBoundary:inDirection:, only in the cases where the given position is the start or and position and the given granularity is UITextGranularityParagraph. Test: EditorStateTests.ParagraphBoundary * Shared/EditorState.cpp: (WebKit::EditorState::PostLayoutData::encode const): (WebKit::EditorState::PostLayoutData::decode): * Shared/EditorState.h: Add a couple of bits to indicate whether the selection start or end positions are at paragraph boundaries. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView isPosition:atBoundary:inDirection:]): Implement this to return selectionStartIsAtParagraphBoundary or selectionEndIsAtParagraphBoundary. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::platformEditorState const): Tools: Add a new API test to verify the behavior of -isPosition:atBoundary:inDirection:. * TestWebKitAPI/Tests/WebKitCocoa/EditorStateTests.mm: (TestWebKitAPI::TEST): * TestWebKitAPI/cocoa/TestWKWebView.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247679 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-21 Wenson Hsieh <wenson_hsieh@apple.com> [iOS] [WebKit2] Add limited support for -isPosition:atBoundary:inDirection: in WKContentView https://bugs.webkit.org/show_bug.cgi?id=199993 <rdar://problem/49523528> Reviewed by Beth Dakin. Add support for -isPosition:atBoundary:inDirection:, only in the cases where the given position is the start or and position and the given granularity is UITextGranularityParagraph. Test: EditorStateTests.ParagraphBoundary * Shared/EditorState.cpp: (WebKit::EditorState::PostLayoutData::encode const): (WebKit::EditorState::PostLayoutData::decode): * Shared/EditorState.h: Add a couple of bits to indicate whether the selection start or end positions are at paragraph boundaries. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView isPosition:atBoundary:inDirection:]): Implement this to return selectionStartIsAtParagraphBoundary or selectionEndIsAtParagraphBoundary. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::platformEditorState const): 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247667. rdar://problem/53647463 [Text autosizing] Do not nuke the style on dynamicViewportSizeUpdate https://bugs.webkit.org/show_bug.cgi?id=199718 <rdar://problem/53344961> Reviewed by Simon Fraser. Source/WebCore: When the page scale changes (e.g. as the result of shink to fit mode) we need to visit all the text content on the page and check whether they need to be boosted. Currently we call setNeedsRecalcStyleInAllFrames() to accomplish it. Unfortunatelly setNeedsRecalcStyleInAllFrames destroys all the style information which means that the subsequent styleResolve() needs to start from scratch. This patch addresses this issue by directly adjusting the computed style information when text boosting is required and schedules layout accordingly. We also trigger this style adjusting on a timer so that rapid dynamicViewportSizeUpdate() calls won't trigger redundant layouts. * css/StyleResolver.cpp: (WebCore::hasTextChild): (WebCore::StyleResolver::adjustRenderStyleForTextAutosizing): (WebCore::hasTextChildren): Deleted. * css/StyleResolver.h: * page/FrameView.h: * page/Page.cpp: (WebCore::Page::invalidateTextAutoSizeInAllFrames): * page/Page.h: Source/WebKit: * WebProcess/WebPage/WebPage.cpp: (WebKit::m_textAutoSizingAdjustmentTimer): (WebKit::WebPage::close): (WebKit::WebPage::didCommitLoad): (WebKit::WebPage::textAutoSizingAdjustmentTimerFired): (WebKit::m_shrinkToFitContentTimer): Deleted. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::dynamicViewportSizeUpdate): (WebKit::WebPage::resetIdempotentTextAutosizingIfNeeded): (WebKit::WebPage::resetTextAutosizing): (WebKit::WebPage::viewportConfigurationChanged): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247667 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-20 Zalan Bujtas <zalan@apple.com> [Text autosizing] Do not nuke the style on dynamicViewportSizeUpdate https://bugs.webkit.org/show_bug.cgi?id=199718 <rdar://problem/53344961> Reviewed by Simon Fraser. * WebProcess/WebPage/WebPage.cpp: (WebKit::m_textAutoSizingAdjustmentTimer): (WebKit::WebPage::close): (WebKit::WebPage::didCommitLoad): (WebKit::WebPage::textAutoSizingAdjustmentTimerFired): (WebKit::m_shrinkToFitContentTimer): Deleted. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::dynamicViewportSizeUpdate): (WebKit::WebPage::resetIdempotentTextAutosizingIfNeeded): (WebKit::WebPage::resetTextAutosizing): (WebKit::WebPage::viewportConfigurationChanged): 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247662. rdar://problem/53648208 Remote WebInspector should enable mock capture devices in UIProcess if doing it in WebProcess https://bugs.webkit.org/show_bug.cgi?id=199924 <rdar://problem/50552067> Reviewed by Devin Rousso. Source/WebCore: Add necessary API to set mock capture devices override. In case of desynchronization between webprocess and uiprocess, make sure to return early and fail capture instead of crashing. * inspector/InspectorClient.h: (WebCore::InspectorClient::setMockCaptureDevicesEnabled): * inspector/agents/InspectorPageAgent.cpp: (WebCore::InspectorPageAgent::disable): (WebCore::InspectorPageAgent::overrideSetting): * platform/mock/MockRealtimeMediaSourceCenter.cpp: Source/WebKit: Add IPC plumbery to pass inspector override value for mock capture devices. Add an override in UserMediaPermissionRequestManagerProxy so that the value stays in sync with web inspector. The override will be removed when web inspector goes away. * UIProcess/UserMediaPermissionRequestManagerProxy.cpp: (WebKit::UserMediaPermissionRequestManagerProxy::syncWithWebCorePrefs const): * UIProcess/UserMediaPermissionRequestManagerProxy.h: (WebKit::UserMediaPermissionRequestManagerProxy::setMockCaptureDevicesEnabledOverride): * UIProcess/WebInspectorProxy.cpp: (WebKit::WebInspectorProxy::setMockCaptureDevicesEnabled): * UIProcess/WebInspectorProxy.h: * UIProcess/WebInspectorProxy.messages.in: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::setMockCaptureDevicesEnabledOverride): * UIProcess/WebPageProxy.h: * WebProcess/WebCoreSupport/WebInspectorClient.cpp: (WebKit::WebInspectorClient::setMockCaptureDevicesEnabled): * WebProcess/WebCoreSupport/WebInspectorClient.h: * WebProcess/WebPage/WebInspector.cpp: (WebKit::WebInspector::setMockCaptureDevicesEnabled): * WebProcess/WebPage/WebInspector.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247662 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-19 Youenn Fablet <youenn@apple.com> Remote WebInspector should enable mock capture devices in UIProcess if doing it in WebProcess https://bugs.webkit.org/show_bug.cgi?id=199924 <rdar://problem/50552067> Reviewed by Devin Rousso. Add IPC plumbery to pass inspector override value for mock capture devices. Add an override in UserMediaPermissionRequestManagerProxy so that the value stays in sync with web inspector. The override will be removed when web inspector goes away. * UIProcess/UserMediaPermissionRequestManagerProxy.cpp: (WebKit::UserMediaPermissionRequestManagerProxy::syncWithWebCorePrefs const): * UIProcess/UserMediaPermissionRequestManagerProxy.h: (WebKit::UserMediaPermissionRequestManagerProxy::setMockCaptureDevicesEnabledOverride): * UIProcess/WebInspectorProxy.cpp: (WebKit::WebInspectorProxy::setMockCaptureDevicesEnabled): * UIProcess/WebInspectorProxy.h: * UIProcess/WebInspectorProxy.messages.in: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::setMockCaptureDevicesEnabledOverride): * UIProcess/WebPageProxy.h: * WebProcess/WebCoreSupport/WebInspectorClient.cpp: (WebKit::WebInspectorClient::setMockCaptureDevicesEnabled): * WebProcess/WebCoreSupport/WebInspectorClient.h: * WebProcess/WebPage/WebInspector.cpp: (WebKit::WebInspector::setMockCaptureDevicesEnabled): * WebProcess/WebPage/WebInspector.h: 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247657. rdar://problem/53648058 Provide correct names for UIContextMenuInteraction API replacements https://bugs.webkit.org/show_bug.cgi?id=199966 Reviewed by Tim Horton. We had some old incorrect names for replacements to SPI. While here, I reordered and expanded the documentation for the new API. * UIProcess/API/Cocoa/WKUIDelegate.h: * UIProcess/API/Cocoa/WKUIDelegatePrivate.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247657 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-19 Dean Jackson <dino@apple.com> Provide correct names for UIContextMenuInteraction API replacements https://bugs.webkit.org/show_bug.cgi?id=199966 Reviewed by Tim Horton. We had some old incorrect names for replacements to SPI. While here, I reordered and expanded the documentation for the new API. * UIProcess/API/Cocoa/WKUIDelegate.h: * UIProcess/API/Cocoa/WKUIDelegatePrivate.h: 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247656. rdar://problem/53648229 [iOS WK2] Allow scrolling interaction on frames and oveflow scroll even when the main frame is rubber-banding https://bugs.webkit.org/show_bug.cgi?id=199963 rdar://problem/52897797 Reviewed by Tim Horton. Adopt UIKit SPI to allow for scrolling of inner UIScrollViews when the outer one is still rubber-banding. * Platform/spi/ios/UIKitSPI.h: * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _initializeWithConfiguration:]): * UIProcess/RemoteLayerTree/ios/ScrollingTreeScrollingNodeDelegateIOS.mm: (WebKit::ScrollingTreeScrollingNodeDelegateIOS::commitStateAfterChildren): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247656 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247653. rdar://problem/53648060 [iOS] REGRESSION (r241734): Autocorrection highlight should hide when field becomes defocused https://bugs.webkit.org/show_bug.cgi?id=199807 <rdar://problem/52760259> Reviewed by Wenson Hsieh. Sometimes the correction highlight may not hide when defocusing an editable field. This occurs only when a person pressed a key in a non-editable element beforehand. We need to reset some state to force a re-computation of whether a keyboard is still needed whenever an element is defocused (blurred in web paralance). Following r241734 both editable and non-editable key events are handled using the same code path. This is accomplished by having WKContentView's -_requiresKeyboardWhenFirstResponder return YES to tell UIKit it needs a keyboard even when there is no editable element focused. As a result UIKit retains all the keyboard state, including keeping the correction highlight visible. Prior to r241734 WKContentView's -_requiresKeyboardWhenFirstResponder would not return YES when a non-editable element was focused and hence UIKit would tear down the keyboard and its state, including the correction highlight. In r245154, we made keyboard instantiate for a focused non-editable element lazy as a performance optimization. Although r245154 kept the r241734 behavior (just made it lazy) it re-wrote the code in such a way that we can utilize it as a hook to fix this bug. In particular, we now clear the bit about a seen keydown in a non-editable element whenever we are defocusing an editable element before we reload the input views, as part of hiding the keyboard. On the reload, UIKit will call -_requiresKeyboardWhenFirstResponder, WebKit will respond with NO now that a non-editable element is focused and hence UIKit will do what it did pre r241734: tear down the keyboard. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _didCommitLoadForMainFrame]): Clear the bit about a seen keydown here so that we don't keep the keyboard around on a new page commit. This includes the case when the same page is reloaded. There is not much advantage to keeping the keyboard around across reloads and not doing so will reduce our memory footprint. (-[WKContentView _elementDidBlur]): Clear the same bit as well when defocusing an editable element. This will cause UIKit to tear down the keyboard on reload removing the correction highlight. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247653 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-19 Daniel Bates <dabates@apple.com> [iOS] REGRESSION (r241734): Autocorrection highlight should hide when field becomes defocused https://bugs.webkit.org/show_bug.cgi?id=199807 <rdar://problem/52760259> Reviewed by Wenson Hsieh. Sometimes the correction highlight may not hide when defocusing an editable field. This occurs only when a person pressed a key in a non-editable element beforehand. We need to reset some state to force a re-computation of whether a keyboard is still needed whenever an element is defocused (blurred in web paralance). Following r241734 both editable and non-editable key events are handled using the same code path. This is accomplished by having WKContentView's -_requiresKeyboardWhenFirstResponder return YES to tell UIKit it needs a keyboard even when there is no editable element focused. As a result UIKit retains all the keyboard state, including keeping the correction highlight visible. Prior to r241734 WKContentView's -_requiresKeyboardWhenFirstResponder would not return YES when a non-editable element was focused and hence UIKit would tear down the keyboard and its state, including the correction highlight. In r245154, we made keyboard instantiate for a focused non-editable element lazy as a performance optimization. Although r245154 kept the r241734 behavior (just made it lazy) it re-wrote the code in such a way that we can utilize it as a hook to fix this bug. In particular, we now clear the bit about a seen keydown in a non-editable element whenever we are defocusing an editable element before we reload the input views, as part of hiding the keyboard. On the reload, UIKit will call -_requiresKeyboardWhenFirstResponder, WebKit will respond with NO now that a non-editable element is focused and hence UIKit will do what it did pre r241734: tear down the keyboard. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _didCommitLoadForMainFrame]): Clear the bit about a seen keydown here so that we don't keep the keyboard around on a new page commit. This includes the case when the same page is reloaded. There is not much advantage to keeping the keyboard around across reloads and not doing so will reduce our memory footprint. (-[WKContentView _elementDidBlur]): Clear the same bit as well when defocusing an editable element. This will cause UIKit to tear down the keyboard on reload removing the correction highlight. 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247651. rdar://problem/53648007 [iOS] Entering 2FA code on idmsa.apple.com causes unexpected scrolling https://bugs.webkit.org/show_bug.cgi?id=199949 <rdar://problem/49944428> Reviewed by Tim Horton and Megan Gardner. Source/WebKit: Since at least iOS 11, -[UIScrollView _adjustForAutomaticKeyboardInfo:animated:lastAdjustment:] adjusts the scroll view's content offset to account for updated keyboard bottom insets. In WebKit, we call this method whenever keyboard geometry changes (based on system notifications, such as UIKeyboardWillHideNotification). When switching between focused form fields, we hide the keyboard for the previous focused element prior to showing the keyboard for the newly focused element. This means that we will actually dismiss the keyboard in the process of changing the focused element, which posts keyboard geometry notifications, which causes us to scroll WKScrollView. On iOS 12, this would be immediately followed by re-presenting the keyboard for the new focused element, which causes us to adjust the scroll view back to its original position right away; this means that the scrolling that happens as a result of adjusting for the keyboard insets after dismissal doesn't result in any visible change. However, on iOS 13, after r239441 and r244546, we now defer scrolling and zooming to reveal the focused element until later; this means the scrolling that happens as a result of initially dismissing the keyboard now causes a consistent jump in the scroll view's scroll position (whereas on iOS 12, this only happens rarely, and the jump is also less noticeable). To mitigate this, we detect the case where we're moving focus from one element to another; if we're about to show a keyboard for the newly focused element, then we should avoid scrolling as a result of the impending "keyboard will hide" notification. Test: fast/forms/ios/no-scrolling-when-moving-focus-between-adjacent-fields.html * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _keyboardChangedWithInfo:adjustScrollView:]): (-[WKWebView _keyboardWillHide:]): * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (shouldShowKeyboardForElement): Add a helper to determine whether we're focusing an element which presents a "keyboard" (i.e. a UIKit input view, as opposed to modal select pickers, modal date pickers, or fields with inputmode="none", for which we don't show an input view). (-[WKContentView _elementDidFocus:userIsInteracting:blurPreviousNode:activityStateChanges:userObject:]): (-[WKContentView shouldIgnoreKeyboardWillHideNotification]): LayoutTests: Add a new layout test to verify that moving focus between horizontally adjacent form controls doesn't induce vertical scrolling. * fast/forms/ios/no-scrolling-when-moving-focus-between-adjacent-fields-expected.txt: Added. * fast/forms/ios/no-scrolling-when-moving-focus-between-adjacent-fields.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247651 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-19 Wenson Hsieh <wenson_hsieh@apple.com> [iOS] Entering 2FA code on idmsa.apple.com causes unexpected scrolling https://bugs.webkit.org/show_bug.cgi?id=199949 <rdar://problem/49944428> Reviewed by Tim Horton and Megan Gardner. Since at least iOS 11, -[UIScrollView _adjustForAutomaticKeyboardInfo:animated:lastAdjustment:] adjusts the scroll view's content offset to account for updated keyboard bottom insets. In WebKit, we call this method whenever keyboard geometry changes (based on system notifications, such as UIKeyboardWillHideNotification). When switching between focused form fields, we hide the keyboard for the previous focused element prior to showing the keyboard for the newly focused element. This means that we will actually dismiss the keyboard in the process of changing the focused element, which posts keyboard geometry notifications, which causes us to scroll WKScrollView. On iOS 12, this would be immediately followed by re-presenting the keyboard for the new focused element, which causes us to adjust the scroll view back to its original position right away; this means that the scrolling that happens as a result of adjusting for the keyboard insets after dismissal doesn't result in any visible change. However, on iOS 13, after r239441 and r244546, we now defer scrolling and zooming to reveal the focused element until later; this means the scrolling that happens as a result of initially dismissing the keyboard now causes a consistent jump in the scroll view's scroll position (whereas on iOS 12, this only happens rarely, and the jump is also less noticeable). To mitigate this, we detect the case where we're moving focus from one element to another; if we're about to show a keyboard for the newly focused element, then we should avoid scrolling as a result of the impending "keyboard will hide" notification. Test: fast/forms/ios/no-scrolling-when-moving-focus-between-adjacent-fields.html * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _keyboardChangedWithInfo:adjustScrollView:]): (-[WKWebView _keyboardWillHide:]): * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (shouldShowKeyboardForElement): Add a helper to determine whether we're focusing an element which presents a "keyboard" (i.e. a UIKit input view, as opposed to modal select pickers, modal date pickers, or fields with inputmode="none", for which we don't show an input view). (-[WKContentView _elementDidFocus:userIsInteracting:blurPreviousNode:activityStateChanges:userObject:]): (-[WKContentView shouldIgnoreKeyboardWillHideNotification]): 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247635. rdar://problem/53647467 Fix warning when importing WebKit in Swift https://bugs.webkit.org/show_bug.cgi?id=199914 <rdar://problem/52854930> Patch by Alex Christensen <achristensen@webkit.org> on 2019-07-18 Reviewed by Wenson Hsieh. * UIProcess/API/Cocoa/NSAttributedString.h: Declare NSAttributedString and update a swift name. This fix was proposed by Argyrios Kyrtzidis. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247635 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-18 Alex Christensen <achristensen@webkit.org> Fix warning when importing WebKit in Swift https://bugs.webkit.org/show_bug.cgi?id=199914 <rdar://problem/52854930> Reviewed by Wenson Hsieh. * UIProcess/API/Cocoa/NSAttributedString.h: Declare NSAttributedString and update a swift name. This fix was proposed by Argyrios Kyrtzidis. 2019-07-24 Alan Coon <alancoon@apple.com> Apply patch. rdar://problem/53483188 Disable ENABLE_LAYOUT_FORMATTING_CONTEXT https://bugs.webkit.org/show_bug.cgi?id=200038 <rdar://problem/53457282> Reviewed by Zalan Bujtas. This feature is not complete. It is enabled for the trunk, but needs to be disabled in branches for shipping products. Source/JavaScriptCore: * Configurations/FeatureDefines.xcconfig: Source/WebCore: No new tests -- this change does not add any new functionality. * Configurations/FeatureDefines.xcconfig: Source/WebCore/PAL: * Configurations/FeatureDefines.xcconfig: Source/WebKit: * Configurations/FeatureDefines.xcconfig: Source/WebKitLegacy/mac: * Configurations/FeatureDefines.xcconfig: Tools: * TestWebKitAPI/Configurations/FeatureDefines.xcconfig: 2019-07-23 Keith Rollin <krollin@apple.com> Disable ENABLE_LAYOUT_FORMATTING_CONTEXT https://bugs.webkit.org/show_bug.cgi?id=200038 <rdar://problem/53457282> Reviewed by Zalan Bujtas. This feature is not complete. It is enabled for the trunk, but needs to be disabled in branches for shipping products. * Configurations/FeatureDefines.xcconfig: 2019-07-24 Alan Coon <alancoon@apple.com> Cherry-pick r247746. rdar://problem/53483297 [iOS] Tapping the search field on a search results page on zillow.com shows and immediately dismisses the keyboard https://bugs.webkit.org/show_bug.cgi?id=200044 <rdar://problem/53103732> Reviewed by Wenson Hsieh. Source/WebCore: 1. The keyboard gets dismissed as the result of scroll event. 2. The (horizontal)scroll event is initiated by WebKit as we try to re-center the content. 3. The content gets off-centered as the result of the newly constructed drop-down menu which slightly sticks out of the document to the right (layout overflows). It works with shipping version of iOS because _zoomToFocusRect operates on stale viewport information (see r244494 for the progression). This patch applies a site specific quirk to restore shipping behavior. * page/Quirks.cpp: (WebCore::Quirks::shouldAvoidScrollingWhenFocusedContentIsVisible const): * page/Quirks.h: Source/WebKit: * Shared/FocusedElementInformation.cpp: (WebKit::FocusedElementInformation::encode const): (WebKit::FocusedElementInformation::decode): * Shared/FocusedElementInformation.h: * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _zoomToFocusRect:selectionRect:insideFixed:fontSize:minimumScale:maximumScale:allowScaling:forceScroll:]): * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _elementDidBlur]): (-[WKContentView _shouldAvoidScrollingWhenFocusedContentIsVisible]): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::getFocusedElementInformation): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247746 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-23 Zalan Bujtas <zalan@apple.com> [iOS] Tapping the search field on a search results page on zillow.com shows and immediately dismisses the keyboard https://bugs.webkit.org/show_bug.cgi?id=200044 <rdar://problem/53103732> Reviewed by Wenson Hsieh. * Shared/FocusedElementInformation.cpp: (WebKit::FocusedElementInformation::encode const): (WebKit::FocusedElementInformation::decode): * Shared/FocusedElementInformation.h: * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _zoomToFocusRect:selectionRect:insideFixed:fontSize:minimumScale:maximumScale:allowScaling:forceScroll:]): * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _elementDidBlur]): (-[WKContentView _shouldAvoidScrollingWhenFocusedContentIsVisible]): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::getFocusedElementInformation): 2019-07-24 Alan Coon <alancoon@apple.com> Revert r247700. rdar://problem/53456070 2019-07-19 Simon Fraser <simon.fraser@apple.com> [iOS WK2] Allow scrolling interaction on frames and oveflow scroll even when the main frame is rubber-banding https://bugs.webkit.org/show_bug.cgi?id=199963 rdar://problem/52897797 Reviewed by Tim Horton. Adopt UIKit SPI to allow for scrolling of inner UIScrollViews when the outer one is still rubber-banding. * Platform/spi/ios/UIKitSPI.h: * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _initializeWithConfiguration:]): * UIProcess/RemoteLayerTree/ios/ScrollingTreeScrollingNodeDelegateIOS.mm: (WebKit::ScrollingTreeScrollingNodeDelegateIOS::commitStateAfterChildren): 2019-07-23 Alan Coon <alancoon@apple.com> Revert r247672. rdar://problem/53449739 2019-07-23 Alan Coon <alancoon@apple.com> Revert r247673. rdar://problem/53449723 2019-07-23 Alan Coon <alancoon@apple.com> Cherry-pick r247701. rdar://problem/53449745 Correct web audio-related crash in seed reports https://bugs.webkit.org/show_bug.cgi?id=200009 <rdar://problem/51565203> Reviewed by Per Arne Vollan. Source/WebCore: Update the 'createMix' method to do proper return value checking so that we can clear the result of MTAudioProcessingTapCreate if the create operation failed. * platform/graphics/avfoundation/AudioSourceProviderAVFObjC.mm: (WebCore::AudioSourceProviderAVFObjC::createMix): Source/WebKit: Revise the iOS sandbox to allow the WebContent process to communicate with the 'com.apple.coremedia.audioprocessingtap.xpc' service, which is needed by some types of WebAudio. * WebProcess/com.apple.WebKit.WebContent.sb.in: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247701 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-22 Brent Fulgham <bfulgham@apple.com> Correct web audio-related crash in seed reports https://bugs.webkit.org/show_bug.cgi?id=200009 <rdar://problem/51565203> Reviewed by Per Arne Vollan. Revise the iOS sandbox to allow the WebContent process to communicate with the 'com.apple.coremedia.audioprocessingtap.xpc' service, which is needed by some types of WebAudio. * WebProcess/com.apple.WebKit.WebContent.sb.in: 2019-07-23 Alan Coon <alancoon@apple.com> Cherry-pick r247700. rdar://problem/53456055 WebKit SPI fix for [ClickyOrb] Audio continues playing after dismissing a video preview in Safari https://bugs.webkit.org/show_bug.cgi?id=200011 <rdar://problem/53409457> Reviewed by Tim Horton. Don't check for the SPI @selector(_webView:contextMenuDidEndForElement:) on the WKUIDelegate so that clients that got caught implementing the SPI before moving to the real API can still clean-up state. In other words, don't force a client that only implements that method to move completely to the new API. * UIProcess/ios/WKContentViewInteraction.mm: (needsDeprecatedPreviewAPI): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247700 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-22 Dean Jackson <dino@apple.com> WebKit SPI fix for [ClickyOrb] Audio continues playing after dismissing a video preview in Safari https://bugs.webkit.org/show_bug.cgi?id=200011 <rdar://problem/53409457> Reviewed by Tim Horton. Don't check for the SPI @selector(_webView:contextMenuDidEndForElement:) on the WKUIDelegate so that clients that got caught implementing the SPI before moving to the real API can still clean-up state. In other words, don't force a client that only implements that method to move completely to the new API. * UIProcess/ios/WKContentViewInteraction.mm: (needsDeprecatedPreviewAPI): 2019-07-23 Alan Coon <alancoon@apple.com> Cherry-pick r247673. rdar://problem/53449723 Speed up HashTable decoding by reserving capacity and avoiding rehashing https://bugs.webkit.org/show_bug.cgi?id=199982 Reviewed by Saam Barati. Source/WebKit: Use HashMap::reserveInitialCapacity() in the HashMap IPC decoder for performance. I measured a ~35% improvement when decoding a very large HashMap of Strings (~160k entries) in the context of the StorageManager::GetValues IPC. * Platform/IPC/ArgumentCoders.h: * Shared/API/c/WKDictionary.cpp: (WKDictionaryCreate): Source/WTF: Introduce reserveInitialCapacity() on HashMap to reserve capacity on a HashMap and cut down on rehashing cost when possible. * wtf/HashMap.h: * wtf/HashTable.h: (WTF::HashTable::reserveInitialCapacity): * wtf/persistence/PersistentCoders.h: Use HashMap::reserveInitialCapacity() in the HashMap persistent decoder for performance. Tools: Add API test coverage. * TestWebKitAPI/Tests/WTF/HashMap.cpp: (TestWebKitAPI::TEST): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247673 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-20 Chris Dumez <cdumez@apple.com> Speed up HashTable decoding by reserving capacity and avoiding rehashing https://bugs.webkit.org/show_bug.cgi?id=199982 Reviewed by Saam Barati. Use HashMap::reserveInitialCapacity() in the HashMap IPC decoder for performance. I measured a ~35% improvement when decoding a very large HashMap of Strings (~160k entries) in the context of the StorageManager::GetValues IPC. * Platform/IPC/ArgumentCoders.h: * Shared/API/c/WKDictionary.cpp: (WKDictionaryCreate): 2019-07-23 Alan Coon <alancoon@apple.com> Cherry-pick r247672. rdar://problem/53449739 Micro-optimize HashMap & String IPC decoding https://bugs.webkit.org/show_bug.cgi?id=199967 Reviewed by Geoffrey Garen. The legacy HashMap decoder (returning a boolean) was failing to WTFMove() the key & value when calling HashMap::add(). The modern decoder (returning an Optional) was properly using WTFMove(). Rewrite the legacy HashMap decoder to call the modern one to reduce code duplication and to get this optimization. Also, encode HashMap::size() as a uint32_t instead of a uint64_t since HashMap::size() returns an 'unsigned int' type. Finally, update the modern decoder to WTFMove(hashMap) when returning. Because the function returns an Optional<HashMap> and not a HashMap, I do not believe we get return value optimization (RVO). Do similar changes to String IPC coders. * Platform/IPC/ArgumentCoders.cpp: (IPC::decodeStringText): (IPC::ArgumentCoder<String>::decode): * Platform/IPC/ArgumentCoders.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247672 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-20 Chris Dumez <cdumez@apple.com> Micro-optimize HashMap & String IPC decoding https://bugs.webkit.org/show_bug.cgi?id=199967 Reviewed by Geoffrey Garen. The legacy HashMap decoder (returning a boolean) was failing to WTFMove() the key & value when calling HashMap::add(). The modern decoder (returning an Optional) was properly using WTFMove(). Rewrite the legacy HashMap decoder to call the modern one to reduce code duplication and to get this optimization. Also, encode HashMap::size() as a uint32_t instead of a uint64_t since HashMap::size() returns an 'unsigned int' type. Finally, update the modern decoder to WTFMove(hashMap) when returning. Because the function returns an Optional<HashMap> and not a HashMap, I do not believe we get return value optimization (RVO). Do similar changes to String IPC coders. * Platform/IPC/ArgumentCoders.cpp: (IPC::decodeStringText): (IPC::ArgumentCoder<String>::decode): * Platform/IPC/ArgumentCoders.h: 2019-07-23 Alan Coon <alancoon@apple.com> Cherry-pick r247658. rdar://problem/53449709 Web Content process gets stuck suspended after navigating away from a system preview https://bugs.webkit.org/show_bug.cgi?id=199965 <rdar://problem/53109004> Reviewed by Dean Jackson. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _isBackground]): * UIProcess/ios/WKSystemPreviewView.h: * UIProcess/ios/WKSystemPreviewView.mm: (-[WKSystemPreviewView web_initWithFrame:webView:mimeType:]): (-[WKSystemPreviewView web_isBackground]): Apply the fix from r193481 to WKSystemPreviewView as well, having it become a WKApplicationStateTrackingView and plumbing that through to our is-background machinery. We really, really should instead have WKWebView itself be the application state tracking view, but that is a bigger change (and has some implications for full-screen video and whatnot). git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247658 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-19 Tim Horton <timothy_horton@apple.com> Web Content process gets stuck suspended after navigating away from a system preview https://bugs.webkit.org/show_bug.cgi?id=199965 <rdar://problem/53109004> Reviewed by Dean Jackson. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _isBackground]): * UIProcess/ios/WKSystemPreviewView.h: * UIProcess/ios/WKSystemPreviewView.mm: (-[WKSystemPreviewView web_initWithFrame:webView:mimeType:]): (-[WKSystemPreviewView web_isBackground]): Apply the fix from r193481 to WKSystemPreviewView as well, having it become a WKApplicationStateTrackingView and plumbing that through to our is-background machinery. We really, really should instead have WKWebView itself be the application state tracking view, but that is a bigger change (and has some implications for full-screen video and whatnot). 2019-07-23 Alan Coon <alancoon@apple.com> Cherry-pick r247652. rdar://problem/53423997 Add a menu item to toggle between showing and hiding link previews https://bugs.webkit.org/show_bug.cgi?id=199940 <rdar://problem/53032288> Reviewed by Beth Dakin. Source/WebCore: New strings for Show/Hide Link Previews. * en.lproj/Localizable.strings: Source/WebKit: Add a new _WKElementAction that toggles the display of link previews in context menus, and add it to the default set of actions we provide for links. When a UIAction is created from this new _WKElementAction type, it can be identified by WKElementActionTypeToggleShowLinkPreviewsIdentifier. This allows us to check a UIMenu provided by a delegate to make sure that they have provided the toggle menu item. If they haven't, we add it back. The preference for showing links is moved from kCFPreferencesAnyApplication to standard user defaults, so that it can be set no matter what the hosting application is. * UIProcess/API/Cocoa/_WKElementAction.h: New action type. * UIProcess/API/Cocoa/_WKElementAction.mm: (+[_WKElementAction _elementActionWithType:customTitle:assistant:]): (+[_WKElementAction imageForElementActionType:]): Use eye.fill for now. I'll need to check with HI to see if there is a more appropriate glyph. (elementActionTypeToUIActionIdentifier): (uiActionIdentifierToElementActionType): * UIProcess/ios/WKActionSheetAssistant.mm: Add the toggle action to the default set. (-[WKActionSheetAssistant defaultActionsForLinkSheet:]): * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _registerPreview]): No need to listen for CFPreferences notifications any more. (-[WKContentView _unregisterPreview]): (menuWithShowLinkPreviewAction): New method that adds the UIAction for toggling previews to a UIMenu if necessary. (-[WKContentView assignLegacyDataForContextMenuInteraction]): (-[WKContentView _contextMenuInteraction:configurationForMenuAtLocation:completion:]): (-[WKContentView _showLinkPreviewsPreferenceChanged:]): Deleted. (titleForMenu): Deleted. URL text previews will be provided separately. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247652 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-19 Dean Jackson <dino@apple.com> Add a menu item to toggle between showing and hiding link previews https://bugs.webkit.org/show_bug.cgi?id=199940 <rdar://problem/53032288> Reviewed by Beth Dakin. Add a new _WKElementAction that toggles the display of link previews in context menus, and add it to the default set of actions we provide for links. When a UIAction is created from this new _WKElementAction type, it can be identified by WKElementActionTypeToggleShowLinkPreviewsIdentifier. This allows us to check a UIMenu provided by a delegate to make sure that they have provided the toggle menu item. If they haven't, we add it back. The preference for showing links is moved from kCFPreferencesAnyApplication to standard user defaults, so that it can be set no matter what the hosting application is. * UIProcess/API/Cocoa/_WKElementAction.h: New action type. * UIProcess/API/Cocoa/_WKElementAction.mm: (+[_WKElementAction _elementActionWithType:customTitle:assistant:]): (+[_WKElementAction imageForElementActionType:]): Use eye.fill for now. I'll need to check with HI to see if there is a more appropriate glyph. (elementActionTypeToUIActionIdentifier): (uiActionIdentifierToElementActionType): * UIProcess/ios/WKActionSheetAssistant.mm: Add the toggle action to the default set. (-[WKActionSheetAssistant defaultActionsForLinkSheet:]): * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _registerPreview]): No need to listen for CFPreferences notifications any more. (-[WKContentView _unregisterPreview]): (menuWithShowLinkPreviewAction): New method that adds the UIAction for toggling previews to a UIMenu if necessary. (-[WKContentView assignLegacyDataForContextMenuInteraction]): (-[WKContentView _contextMenuInteraction:configurationForMenuAtLocation:completion:]): (-[WKContentView _showLinkPreviewsPreferenceChanged:]): Deleted. (titleForMenu): Deleted. URL text previews will be provided separately. 2019-07-18 Alan Coon <alancoon@apple.com> Cherry-pick r247565. rdar://problem/53279116 Regression(r247486) Multiple Layout Tests in http/tests/cache/* are crashing on iOS Debug WK2 https://bugs.webkit.org/show_bug.cgi?id=199892 <rdar://problem/53230217> Reviewed by Geoffrey Garen. The StorageManager was unregistering itself as a WorkQueueMessageReceiver on a given IPC connection too early. As a result, we would sometimes receive a 'StorageManager:DestroyStorageMap' IPC in NetworkConnectionToWebProcess::didReceiveMessage() with nobody to process it, which would trigger an assertion. To address the issue, we stop unregistering the StorageManager as a WorkQueueMessageReceiver inside removeAllowedSessionStorageNamespaceConnection(). Instead, we let the logic inside processDidCloseConnection() take care of it once the connection closes. * NetworkProcess/WebStorage/StorageManager.cpp: (WebKit::StorageManager::removeAllowedSessionStorageNamespaceConnection): (WebKit::StorageManager::processDidCloseConnection): * NetworkProcess/WebStorage/StorageManager.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247565 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-18 Chris Dumez <cdumez@apple.com> Regression(r247486) Multiple Layout Tests in http/tests/cache/* are crashing on iOS Debug WK2 https://bugs.webkit.org/show_bug.cgi?id=199892 <rdar://problem/53230217> Reviewed by Geoffrey Garen. The StorageManager was unregistering itself as a WorkQueueMessageReceiver on a given IPC connection too early. As a result, we would sometimes receive a 'StorageManager:DestroyStorageMap' IPC in NetworkConnectionToWebProcess::didReceiveMessage() with nobody to process it, which would trigger an assertion. To address the issue, we stop unregistering the StorageManager as a WorkQueueMessageReceiver inside removeAllowedSessionStorageNamespaceConnection(). Instead, we let the logic inside processDidCloseConnection() take care of it once the connection closes. * NetworkProcess/WebStorage/StorageManager.cpp: (WebKit::StorageManager::removeAllowedSessionStorageNamespaceConnection): (WebKit::StorageManager::processDidCloseConnection): * NetworkProcess/WebStorage/StorageManager.h: 2019-07-18 Alan Coon <alancoon@apple.com> Cherry-pick r247552. rdar://problem/53279120 Set WordIsNearTap flag, was not being set at all before https://bugs.webkit.org/show_bug.cgi?id=199880 Reviewed by Wenson Hsieh. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::selectWithGesture): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247552 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-17 Megan Gardner <megan_gardner@apple.com> Set WordIsNearTap flag, was not being set at all before https://bugs.webkit.org/show_bug.cgi?id=199880 Reviewed by Wenson Hsieh. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::selectWithGesture): 2019-07-18 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r247557. rdar://problem/53254407 [macCatalyst] Unable to interact with YouTube video while it's playing https://bugs.webkit.org/show_bug.cgi?id=199893 <rdar://problem/51871151> Reviewed by Simon Fraser. * Platform/spi/ios/UIKitSPI.h: * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm: (-[WKRemoteView initWithFrame:contextID:]): (-[WKUIRemoteView initWithFrame:pid:contextID:]): Disable remote context hit-testing for WKUIRemoteView just like we already do for WKRemoteView. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247557 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-17 Tim Horton <timothy_horton@apple.com> [macCatalyst] Unable to interact with YouTube video while it's playing https://bugs.webkit.org/show_bug.cgi?id=199893 <rdar://problem/51871151> Reviewed by Simon Fraser. * Platform/spi/ios/UIKitSPI.h: * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm: (-[WKRemoteView initWithFrame:contextID:]): (-[WKUIRemoteView initWithFrame:pid:contextID:]): Disable remote context hit-testing for WKUIRemoteView just like we already do for WKRemoteView. 2019-07-18 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r247555. rdar://problem/53254411 Prewarm local storage in the NetworkProcess to reduce WebContent process hangs https://bugs.webkit.org/show_bug.cgi?id=199879 <rdar://problem/53217757> Reviewed by Ryosuke Niwa. Source/WebCore: When JS accesses window.localStorage for the first time, we end up doing a synchronous IPC to the network process to pull in all items in the local storage for the origin. If the network process does not have this data in memory, it has to read it from a database on disk, which may take a significant amount of time and hang the WebContent process during this time. To alleviate this problem, this patch introduces prewarming on the local storage in the network process when loading a given origin in the WebContent process. This way, in most cases, when the JS accesses window.localStorage for the first time, the synchronous IPC to the network process returns much faster (measured 50-100ms for a very large database, down from 250-300ms), as it only needs to IPC the data over, without the need to fetch it from disk. As a safety net to avoid excessive prewarming, we currently prewarm at most 5 security origins per page load. * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::commitData): * page/DOMWindow.cpp: (WebCore::DOMWindow::prewarmLocalStorageIfNecessary): * page/DOMWindow.h: * page/Frame.cpp: (WebCore::Frame::didPrewarmLocalStorage): (WebCore::Frame::mayPrewarmLocalStorage const): * page/Frame.h: * storage/Storage.cpp: (WebCore::Storage::prewarm): * storage/Storage.h: * storage/StorageArea.h: (WebCore::StorageArea::prewarm): Source/WebKit: * NetworkProcess/WebStorage/StorageManager.cpp: (WebKit::StorageManager::prewarm): (WebKit::StorageManager::getValues): * NetworkProcess/WebStorage/StorageManager.h: * NetworkProcess/WebStorage/StorageManager.messages.in: * WebProcess/WebStorage/StorageAreaImpl.cpp: (WebKit::StorageAreaImpl::prewarm): * WebProcess/WebStorage/StorageAreaImpl.h: * WebProcess/WebStorage/StorageAreaMap.cpp: (WebKit::StorageAreaMap::loadValuesIfNeeded): (WebKit::StorageAreaMap::prewarm): * WebProcess/WebStorage/StorageAreaMap.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247555 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-17 Chris Dumez <cdumez@apple.com> Prewarm local storage in the NetworkProcess to reduce WebContent process hangs https://bugs.webkit.org/show_bug.cgi?id=199879 <rdar://problem/53217757> Reviewed by Ryosuke Niwa. * NetworkProcess/WebStorage/StorageManager.cpp: (WebKit::StorageManager::prewarm): (WebKit::StorageManager::getValues): * NetworkProcess/WebStorage/StorageManager.h: * NetworkProcess/WebStorage/StorageManager.messages.in: * WebProcess/WebStorage/StorageAreaImpl.cpp: (WebKit::StorageAreaImpl::prewarm): * WebProcess/WebStorage/StorageAreaImpl.h: * WebProcess/WebStorage/StorageAreaMap.cpp: (WebKit::StorageAreaMap::loadValuesIfNeeded): (WebKit::StorageAreaMap::prewarm): * WebProcess/WebStorage/StorageAreaMap.h: 2019-07-17 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r247559. rdar://problem/53230035 Early Out of positionInfomation check if possible https://bugs.webkit.org/show_bug.cgi?id=199885 <rdar://problem/53229413> This is an early-out check that happens after most of the work is done. Move it to happen before we make all these calls, if in the end, we will not use the information. Reviewed by Tim Horton. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView textInteractionGesture:shouldBeginAtPoint:]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247559 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-17 Megan Gardner <megan_gardner@apple.com> Early Out of positionInfomation check if possible https://bugs.webkit.org/show_bug.cgi?id=199885 <rdar://problem/53229413> This is an early-out check that happens after most of the work is done. Move it to happen before we make all these calls, if in the end, we will not use the information. Reviewed by Tim Horton. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView textInteractionGesture:shouldBeginAtPoint:]): 2019-07-17 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r247547. rdar://problem/53230043 Provide a NSURL cateogry to tell AppSSO Kerberos URLs https://bugs.webkit.org/show_bug.cgi?id=199887 <rdar://problem/52323161> Reviewed by Brent Fulgham. * UIProcess/Cocoa/SOAuthorization/SOAuthorizationNSURLExtras.h: * UIProcess/Cocoa/SOAuthorization/SOAuthorizationNSURLExtras.mm: (+[NSURL _web_willPerformSOKerberosAuthorizationWithURL:]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247547 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-17 Jiewen Tan <jiewen_tan@apple.com> Provide a NSURL cateogry to tell AppSSO Kerberos URLs https://bugs.webkit.org/show_bug.cgi?id=199887 <rdar://problem/52323161> Reviewed by Brent Fulgham. * UIProcess/Cocoa/SOAuthorization/SOAuthorizationNSURLExtras.h: * UIProcess/Cocoa/SOAuthorization/SOAuthorizationNSURLExtras.mm: (+[NSURL _web_willPerformSOKerberosAuthorizationWithURL:]): 2019-07-17 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r247530. rdar://problem/53229569 Typing into a cell in a Google Sheet lags behind by one character https://bugs.webkit.org/show_bug.cgi?id=199587 <rdar://problem/51616845> Reviewed by Brent Fulgham. Source/WebCore: Add a Google Sheets quirk. Put all DOM timers scheduled from keydown and keypress event listeners into a holding tank. The timers continue to tick, but are barred from executing their action until the next text insertion or deletion or 32 ms (on device) have elapsed, whichever is sooner. We only allocate a holding tank once per document, only if the quirk is active, and this allocation is done when the document schedules a timer on keydown or keypress. The holding tank lives for the lifetime of the document. The story behind the quirk: On keypress Google Sheets schedules timers and expects that a DOM update will occur (i.e. text will be inserted or deleted) within the same event loop iteration as the dispatched keypress. The UI Events spec. [1] makes no such guarantee of when a DOM update must occur in relation to the keypress event. It could happen in the same event loop iteration as the key press (as Google expects), the next iteration, 500ms later, 2 minutes later, etc. What the spec does guarantee is that by the time a DOM input event is dispatched that the DOM will be updated. And this is the solution to the problem Google Sheets is trying to solve, but is doing so using pre-IE 9 technology (though similar functionality was available via onpropertychange in IE < 9). See also <https://github.com/w3c/uievents/issues/238>, which is tracking a spec. text update for this quirk. Test: fast/events/ios/dom-update-on-keydown-quirk.html [1] <https://w3c.github.io/uievents/> (Editor's Draft, 14 October 2018) * SourcesCocoa.txt: * WebCore.xcodeproj/project.pbxproj: Add some files to the project. * dom/Document.cpp: (WebCore::Document::domTimerHoldingTank): Added. * dom/Document.h: (WebCore::Document::domTimerHoldingTankIfExists): Added. * page/DOMTimer.cpp: (WebCore::DOMTimer::install): Put the newly instantiated timer into the holding tank. (WebCore::DOMTimer::removeById): Remove the timer from the holding tank. (WebCore::DOMTimer::fired): Check if the timer is in the holding tank. If it is and it is a one- shot timer then schedule it for the next event loop iteration. If it's a repeating timer just let it continue ticking. Otherwise, do what we no now and execute the timer's action. The reason we do not suspend timers in the holding tank is because: 1. Far out timers (Google Sheets registers timers as far out as 5 minutes!) are not penalized. Though smart supension logic could avoid this. See (3). 2. Empirical observations indicate that the keyboard will perform the insertion or deletion reasonably quickly (not the same event loop iteration as the keydown, but within two iterations out). So, the timers in the holding tank are short-lived. 3. Simplifies the code. There is no need to keep additional bookkeeping to track multiple timer suspension reasons (timers currently can only have one suspension reason) or alternatively defer scheduling a timer until a later time and computing a new "fair" firing time when scheduled. * page/EventHandler.cpp: (WebCore::EventHandler::internalKeyEvent): Place a token on the stack to put all DOM timers scheduled on keydown and keypress into the holding tank if the quirk is enabled. * page/Quirks.cpp: (WebCore::Quirks::needsDeferKeyDownAndKeyPressTimersUntilNextEditingCommand const): Added. * page/Quirks.h: * page/Settings.yaml: Added setting so that this quirk can be enabled from a layout test. This setting also lets us enable the quirk for all sites or for certain third-party apps if desired. * page/ios/DOMTimerHoldingTank.cpp: Added. (WebCore::DOMTimerHoldingTank::DOMTimerHoldingTank): (WebCore::DOMTimerHoldingTank::add): (WebCore::DOMTimerHoldingTank::remove): (WebCore::DOMTimerHoldingTank::contains): (WebCore::DOMTimerHoldingTank::removeAll): (WebCore::DOMTimerHoldingTank::stopExceededMaximumHoldTimer): * page/ios/DOMTimerHoldingTank.h: Added. (WebCore::DeferDOMTimersForScope::DeferDOMTimersForScope): (WebCore::DeferDOMTimersForScope::~DeferDOMTimersForScope): (WebCore::DeferDOMTimersForScope::isDeferring): Source/WebKit: Remove all timers from the holding tank on text insertion or deletion (represented as an editing command). Timers that were in the holding tank never stopped ticking and will now be able to execute their action. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::executeEditingCommand): (WebKit::WebPage::insertTextAsync): (WebKit::WebPage::setCompositionAsync): (WebKit::WebPage::confirmCompositionAsync): Call platformWillPerformEditingCommand(). * WebProcess/WebPage/WebPage.h: (WebKit::WebPage::platformWillPerformEditingCommand): Added. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::platformWillPerformEditingCommand): Remove all the timers from the holding tank if we have a holding tank. LayoutTests: Add a test that enables the quirk and ensures that the DOM is up-to-date on expiration of a zero timer scheduled from keydown, keypress, keyup, and input. * fast/events/ios/dom-update-on-keydown-quirk-expected.txt: Added. * fast/events/ios/dom-update-on-keydown-quirk.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247530 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-17 Daniel Bates <dabates@apple.com> Typing into a cell in a Google Sheet lags behind by one character https://bugs.webkit.org/show_bug.cgi?id=199587 <rdar://problem/51616845> Reviewed by Brent Fulgham. Remove all timers from the holding tank on text insertion or deletion (represented as an editing command). Timers that were in the holding tank never stopped ticking and will now be able to execute their action. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::executeEditingCommand): (WebKit::WebPage::insertTextAsync): (WebKit::WebPage::setCompositionAsync): (WebKit::WebPage::confirmCompositionAsync): Call platformWillPerformEditingCommand(). * WebProcess/WebPage/WebPage.h: (WebKit::WebPage::platformWillPerformEditingCommand): Added. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::platformWillPerformEditingCommand): Remove all the timers from the holding tank if we have a holding tank. 2019-07-17 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r247524. rdar://problem/53229635 [iOS] Option + Up or Down Arrow key doesn’t move cursor past paragraph boundaries in WebKit2 https://bugs.webkit.org/show_bug.cgi?id=199851 Reviewed by Wenson Hsieh. Source/WebKit: The bug was caused by the difference in the way AppKit and UIKit responds to Option + Up / Down. On macOS, AppKit sends moveForward before sending moveToStartOfParagraph and moveBackward before sending moveToEndOfParagraph. As a result, when Option + Down is pressed when we are at the end of a line, we would first move to the beginning of the next line (i.e. after the line break) before moving or extending selection with the paragraph boundary granurality. On iOS, UIKit only calls _moveToStartOfParagraph without moving forward by a character. As a result, moving forward by the paragraph boundary granurality immediately stops when we're starting at the end of a line when Option + Down is pressed. Option + Up case is similar. Fix the bug on iOS by emulating what happens on macOS. Namely, move the selection forward or backward by the character granurality before moving by the paragraph boundary granurality. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _moveToStartOfParagraph:withHistory:]): (-[WKContentView _moveToEndOfParagraph:withHistory:]): Tools: Added a regression test for iOS. Unfortunately, event sender, etc... doesn't work because this code is getting directly triggered from UIKeyboard's code. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/ios/SelectionModifyByParagraphBoundary.h: Added. * TestWebKitAPI/Tests/ios/SelectionModifyByParagraphBoundary.mm: Added. * TestWebKitAPI/ios/UIKitSPI.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247524 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-17 Ryosuke Niwa <rniwa@webkit.org> [iOS] Option + Up or Down Arrow key doesn’t move cursor past paragraph boundaries in WebKit2 https://bugs.webkit.org/show_bug.cgi?id=199851 Reviewed by Wenson Hsieh. The bug was caused by the difference in the way AppKit and UIKit responds to Option + Up / Down. On macOS, AppKit sends moveForward before sending moveToStartOfParagraph and moveBackward before sending moveToEndOfParagraph. As a result, when Option + Down is pressed when we are at the end of a line, we would first move to the beginning of the next line (i.e. after the line break) before moving or extending selection with the paragraph boundary granurality. On iOS, UIKit only calls _moveToStartOfParagraph without moving forward by a character. As a result, moving forward by the paragraph boundary granurality immediately stops when we're starting at the end of a line when Option + Down is pressed. Option + Up case is similar. Fix the bug on iOS by emulating what happens on macOS. Namely, move the selection forward or backward by the character granurality before moving by the paragraph boundary granurality. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _moveToStartOfParagraph:withHistory:]): (-[WKContentView _moveToEndOfParagraph:withHistory:]): 2019-07-17 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r247502. rdar://problem/53229564 REGRESSION: fast/events/watchos/double-tap-to-zoom* tests crashing in com.apple.WebKit: -[WKContentView(WKInteraction) _singleTapDidReset:] https://bugs.webkit.org/show_bug.cgi?id=199840 <rdar://problem/52856531> Patch by Antoine Quint <graouts@apple.com> on 2019-07-16 Reviewed by Wenson Hsieh. Source/WebCore: Fix a build error that occured when building for the watchOS Simulator in the debug configuration. * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::updateScrollingNodeForScrollingProxyRole): Source/WebKit: We need to ensure the NSNumber used for -[WKSyntheticTapGestureRecognizer lastActiveTouchIdentifier] is retained. This innocent change required the use of RetainPtr<>, which required the move to an Objective-C++ file, which lead to a change in the order files are unified, which lead to build errors, which leads to a much bigger patch than just the source change necessary to fix the crash. * SourcesCocoa.txt: * UIProcess/ios/WKSyntheticTapGestureRecognizer.mm: Renamed from Source/WebKit/UIProcess/ios/WKSyntheticTapGestureRecognizer.m. * UIProcess/ios/forms/WKFormPeripheralBase.h: * UIProcess/ios/forms/WKFormPeripheralBase.mm: * WebKit.xcodeproj/project.pbxproj: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247502 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-16 Antoine Quint <graouts@apple.com> REGRESSION: fast/events/watchos/double-tap-to-zoom* tests crashing in com.apple.WebKit: -[WKContentView(WKInteraction) _singleTapDidReset:] https://bugs.webkit.org/show_bug.cgi?id=199840 <rdar://problem/52856531> Reviewed by Wenson Hsieh. We need to ensure the NSNumber used for -[WKSyntheticTapGestureRecognizer lastActiveTouchIdentifier] is retained. This innocent change required the use of RetainPtr<>, which required the move to an Objective-C++ file, which lead to a change in the order files are unified, which lead to build errors, which leads to a much bigger patch than just the source change necessary to fix the crash. * SourcesCocoa.txt: * UIProcess/ios/WKSyntheticTapGestureRecognizer.mm: Renamed from Source/WebKit/UIProcess/ios/WKSyntheticTapGestureRecognizer.m. * UIProcess/ios/forms/WKFormPeripheralBase.h: * UIProcess/ios/forms/WKFormPeripheralBase.mm: * WebKit.xcodeproj/project.pbxproj: 2019-07-17 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r247494. rdar://problem/53229554 [macCatalyst] Do not include WebKitLegacy.h in WebKit.h https://bugs.webkit.org/show_bug.cgi?id=199833 <rdar://problem/53036744> Reviewed by Tim Horton. * Shared/API/Cocoa/WebKit.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247494 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-16 Andy Estes <aestes@apple.com> [macCatalyst] Do not include WebKitLegacy.h in WebKit.h https://bugs.webkit.org/show_bug.cgi?id=199833 <rdar://problem/53036744> Reviewed by Tim Horton. * Shared/API/Cocoa/WebKit.h: 2019-07-17 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r247490. rdar://problem/53229559 NSTextFinder holes don't scroll with the page https://bugs.webkit.org/show_bug.cgi?id=199815 <rdar://problem/52280514> Reviewed by Simon Fraser. Source/WebCore: * rendering/ScrollAlignment.h: Source/WebKit: * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _usePlatformFindUI]): (-[WKWebView _setUsePlatformFindUI:]): (-[WKWebView _ensureTextFinderClient]): Add a bit so that clients can choose whether they want our find UI, which respects scrolling, or the system find UI, which works when doing multi-document searches. Right now you can't have both. (-[WKWebView scrollFindMatchToVisible:]): Implement and plumb scrollFindMatchToVisible. * UIProcess/API/Cocoa/WKWebViewPrivate.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::indicateFindMatch): * UIProcess/WebPageProxy.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::indicateFindMatch): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: Plumb indicateFindMatch to FindController. * UIProcess/mac/WKTextFinderClient.h: * UIProcess/mac/WKTextFinderClient.mm: (-[WKTextFinderClient initWithPage:view:usePlatformFindUI:]): Store whether or not we are using the platform find UI. (-[WKTextFinderClient findMatchesForString:relativeToMatch:findOptions:maxResults:resultCollector:]): If using WebKit find UI, turn on our UI in the options passed to findString[Matches]. (-[WKTextFinderClient scrollFindMatchToVisible:]): If using WebKit find UI, when the platform tells us to reveal a find match, indicate it. (-[WKTextFinderClient didFindStringMatchesWithRects:didWrapAround:]): If using WebKit find UI, lie to the platform and return no rects so that it doesn't paint a yellow rectangle. (-[WKTextFinderClient getImageForMatchResult:completionHandler:]): If using WebKit find UI, lie to the platform and return no image so that it doesn't paint a yellow rectangle. (-[WKTextFinderClient initWithPage:view:]): Deleted. * WebProcess/WebPage/FindController.cpp: (WebKit::FindController::updateFindUIAfterPageScroll): Make it possible to use our find UI with 'findStringMatches'; since the platform find infrastrucutre depends on knowing about all matches up front, we need to use 'findStringMatches' instead of 'findString', but we had never combined that with our UI. Don't throw away the other matches when we indicate one, and don't send DidFindString in the case we are coming from 'findStringMatches'. This all needs a bit of cleanup in the future. (WebKit::FindController::findString): Tell updateFindUIAfterPageScroll that we are 'findString' so that it uses its normal behavior. (WebKit::FindController::findStringMatches): Tell updateFindUIAfterPageScroll that we are 'findStringMatches' so that it uses the adjusted behavior. (WebKit::FindController::indicateFindMatch): Add 'indicateFindMatch', which both selects the match and moves the indicator there. * WebProcess/WebPage/FindController.h: Tools: * MiniBrowser/mac/WK2BrowserWindowController.m: (-[MiniBrowserNSTextFinder performAction:]): (-[WK2BrowserWindowController awakeFromNib]): Adopt the WebKit UI in MiniBrowser. Also, override NSTextFinder's -performAction: so that we can intercept the close action and hide our own find UI, since there is no delegate for that action yet. * TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm: (TEST): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247490 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-16 Tim Horton <timothy_horton@apple.com> NSTextFinder holes don't scroll with the page https://bugs.webkit.org/show_bug.cgi?id=199815 <rdar://problem/52280514> Reviewed by Simon Fraser. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _usePlatformFindUI]): (-[WKWebView _setUsePlatformFindUI:]): (-[WKWebView _ensureTextFinderClient]): Add a bit so that clients can choose whether they want our find UI, which respects scrolling, or the system find UI, which works when doing multi-document searches. Right now you can't have both. (-[WKWebView scrollFindMatchToVisible:]): Implement and plumb scrollFindMatchToVisible. * UIProcess/API/Cocoa/WKWebViewPrivate.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::indicateFindMatch): * UIProcess/WebPageProxy.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::indicateFindMatch): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: Plumb indicateFindMatch to FindController. * UIProcess/mac/WKTextFinderClient.h: * UIProcess/mac/WKTextFinderClient.mm: (-[WKTextFinderClient initWithPage:view:usePlatformFindUI:]): Store whether or not we are using the platform find UI. (-[WKTextFinderClient findMatchesForString:relativeToMatch:findOptions:maxResults:resultCollector:]): If using WebKit find UI, turn on our UI in the options passed to findString[Matches]. (-[WKTextFinderClient scrollFindMatchToVisible:]): If using WebKit find UI, when the platform tells us to reveal a find match, indicate it. (-[WKTextFinderClient didFindStringMatchesWithRects:didWrapAround:]): If using WebKit find UI, lie to the platform and return no rects so that it doesn't paint a yellow rectangle. (-[WKTextFinderClient getImageForMatchResult:completionHandler:]): If using WebKit find UI, lie to the platform and return no image so that it doesn't paint a yellow rectangle. (-[WKTextFinderClient initWithPage:view:]): Deleted. * WebProcess/WebPage/FindController.cpp: (WebKit::FindController::updateFindUIAfterPageScroll): Make it possible to use our find UI with 'findStringMatches'; since the platform find infrastrucutre depends on knowing about all matches up front, we need to use 'findStringMatches' instead of 'findString', but we had never combined that with our UI. Don't throw away the other matches when we indicate one, and don't send DidFindString in the case we are coming from 'findStringMatches'. This all needs a bit of cleanup in the future. (WebKit::FindController::findString): Tell updateFindUIAfterPageScroll that we are 'findString' so that it uses its normal behavior. (WebKit::FindController::findStringMatches): Tell updateFindUIAfterPageScroll that we are 'findStringMatches' so that it uses the adjusted behavior. (WebKit::FindController::indicateFindMatch): Add 'indicateFindMatch', which both selects the match and moves the indicator there. * WebProcess/WebPage/FindController.h: 2019-07-17 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r247486. rdar://problem/53229738 Speed up StorageManager::getValues() https://bugs.webkit.org/show_bug.cgi?id=199812 Reviewed by Alex Christensen. Source/WebCore: * storage/StorageMap.cpp: (WebCore::StorageMap::importItems): * storage/StorageMap.h: Source/WebKit: Made the following performance improvements: - Made StorageManager a WorkQueueMessageReceiver again (like it was before it got moved from the UIProcess to the Network process). This avoids a lot of thread hopping (IPC thread -> Main thread -> StorageManagerThread -> Main Thread) and a lot of isolatedCopying of the strings. - Move values around when possible to avoid copying. - Add fast path to StorageMap::importItems() for when the StorageMap is empty when importing (15ms -> 2.5ms). * NetworkProcess/NetworkConnectionToWebProcess.cpp: (WebKit::NetworkConnectionToWebProcess::didReceiveMessage): (WebKit::NetworkConnectionToWebProcess::didReceiveSyncMessage): * NetworkProcess/WebStorage/LocalStorageDatabase.cpp: (WebKit::LocalStorageDatabase::importItems): * NetworkProcess/WebStorage/StorageManager.cpp: (WebKit::StorageManager::addAllowedSessionStorageNamespaceConnection): (WebKit::StorageManager::removeAllowedSessionStorageNamespaceConnection): (WebKit::StorageManager::processDidCloseConnection): (WebKit::StorageManager::createLocalStorageMap): (WebKit::StorageManager::createTransientLocalStorageMap): (WebKit::StorageManager::createSessionStorageMap): (WebKit::StorageManager::destroyStorageMap): (WebKit::StorageManager::getValues): (WebKit::StorageManager::setItem): (WebKit::StorageManager::setItems): (WebKit::StorageManager::removeItem): (WebKit::StorageManager::clear): * NetworkProcess/WebStorage/StorageManager.h: * Platform/IPC/Connection.cpp: (IPC::Connection::addWorkQueueMessageReceiver): (IPC::Connection::removeWorkQueueMessageReceiver): (IPC::Connection::processIncomingMessage): (IPC::Connection::dispatchMessage): (IPC::Connection::dispatchMessageToWorkQueueReceiver): * Platform/IPC/Connection.h: * WebProcess/WebStorage/StorageAreaMap.cpp: (WebKit::StorageAreaMap::loadValuesIfNeeded): Messages to WorkQueueMessageReceivers are normally dispatched from the IPC WorkQueue. However, there is a race if a client (here StorageManager) adds itself as a WorkQueueMessageReceiver as a result of receiving an IPC message on the main thread (here NetworkConnectionToWebProcess::WebPageWasAdded). The message might have already been dispatched from the IPC WorkQueue to the main thread by the time the client registers itself as a WorkQueueMessageReceiver. To address this, we check again for messages receivers once the message arrives on the main thread. Source/WebKitLegacy: * Storage/StorageAreaImpl.cpp: (WebKit::StorageAreaImpl::importItems): * Storage/StorageAreaImpl.h: * Storage/StorageAreaSync.cpp: (WebKit::StorageAreaSync::performImport): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247486 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-16 Chris Dumez <cdumez@apple.com> Speed up StorageManager::getValues() https://bugs.webkit.org/show_bug.cgi?id=199812 Reviewed by Alex Christensen. Made the following performance improvements: - Made StorageManager a WorkQueueMessageReceiver again (like it was before it got moved from the UIProcess to the Network process). This avoids a lot of thread hopping (IPC thread -> Main thread -> StorageManagerThread -> Main Thread) and a lot of isolatedCopying of the strings. - Move values around when possible to avoid copying. - Add fast path to StorageMap::importItems() for when the StorageMap is empty when importing (15ms -> 2.5ms). * NetworkProcess/NetworkConnectionToWebProcess.cpp: (WebKit::NetworkConnectionToWebProcess::didReceiveMessage): (WebKit::NetworkConnectionToWebProcess::didReceiveSyncMessage): * NetworkProcess/WebStorage/LocalStorageDatabase.cpp: (WebKit::LocalStorageDatabase::importItems): * NetworkProcess/WebStorage/StorageManager.cpp: (WebKit::StorageManager::addAllowedSessionStorageNamespaceConnection): (WebKit::StorageManager::removeAllowedSessionStorageNamespaceConnection): (WebKit::StorageManager::processDidCloseConnection): (WebKit::StorageManager::createLocalStorageMap): (WebKit::StorageManager::createTransientLocalStorageMap): (WebKit::StorageManager::createSessionStorageMap): (WebKit::StorageManager::destroyStorageMap): (WebKit::StorageManager::getValues): (WebKit::StorageManager::setItem): (WebKit::StorageManager::setItems): (WebKit::StorageManager::removeItem): (WebKit::StorageManager::clear): * NetworkProcess/WebStorage/StorageManager.h: * Platform/IPC/Connection.cpp: (IPC::Connection::addWorkQueueMessageReceiver): (IPC::Connection::removeWorkQueueMessageReceiver): (IPC::Connection::processIncomingMessage): (IPC::Connection::dispatchMessage): (IPC::Connection::dispatchMessageToWorkQueueReceiver): * Platform/IPC/Connection.h: * WebProcess/WebStorage/StorageAreaMap.cpp: (WebKit::StorageAreaMap::loadValuesIfNeeded): Messages to WorkQueueMessageReceivers are normally dispatched from the IPC WorkQueue. However, there is a race if a client (here StorageManager) adds itself as a WorkQueueMessageReceiver as a result of receiving an IPC message on the main thread (here NetworkConnectionToWebProcess::WebPageWasAdded). The message might have already been dispatched from the IPC WorkQueue to the main thread by the time the client registers itself as a WorkQueueMessageReceiver. To address this, we check again for messages receivers once the message arrives on the main thread. 2019-07-17 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r247483. rdar://problem/53229618 [ContentChangeObserver] Cancel ongoing content observation when tap is failed/cancelled https://bugs.webkit.org/show_bug.cgi?id=199828 <rdar://problem/53152696> Reviewed by Wenson Hsieh. Source/WebCore: This patch ensures that we stop the content observation (initiated by touch start) when the tap is cancelled/failed. Not testable. * page/ios/ContentChangeObserver.cpp: (WebCore::ContentChangeObserver::didCancelPotentialTap): * page/ios/ContentChangeObserver.h: Source/WebKit: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::commitPotentialTapFailed): (WebKit::WebPage::cancelPotentialTap): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247483 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-16 Zalan Bujtas <zalan@apple.com> [ContentChangeObserver] Cancel ongoing content observation when tap is failed/cancelled https://bugs.webkit.org/show_bug.cgi?id=199828 <rdar://problem/53152696> Reviewed by Wenson Hsieh. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::commitPotentialTapFailed): (WebKit::WebPage::cancelPotentialTap): 2019-07-17 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r247470. rdar://problem/53229634 outlook.live.com has odd viewport with edge gap https://bugs.webkit.org/show_bug.cgi?id=199822 <rdar://problem/53029072> Reviewed by Wenson Hsieh. Source/WebCore: r244944 introduced a viewport width quirk because at certain screen size outlook.live.com's flex setup produced a slighly broken layout. We don't seem to need this quirk anymore (composed column's min-width is removed.) * page/Quirks.cpp: (WebCore::Quirks::shouldIgnoreShrinkToFitContent const): Deleted. (WebCore::Quirks::overriddenViewLayoutWidth const): Deleted. * page/Quirks.h: Source/WebKit: * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::setViewportConfigurationViewLayoutSize): (WebKit::WebPage::dynamicViewportSizeUpdate): (WebKit::WebPage::resetViewportDefaultConfiguration): (WebKit::WebPage::immediatelyShrinkToFitContent): (WebKit::WebPage::viewLayoutSizeAdjustedForQuirks): Deleted. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247470 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-15 Zalan Bujtas <zalan@apple.com> outlook.live.com has odd viewport with edge gap https://bugs.webkit.org/show_bug.cgi?id=199822 <rdar://problem/53029072> Reviewed by Wenson Hsieh. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::setViewportConfigurationViewLayoutSize): (WebKit::WebPage::dynamicViewportSizeUpdate): (WebKit::WebPage::resetViewportDefaultConfiguration): (WebKit::WebPage::immediatelyShrinkToFitContent): (WebKit::WebPage::viewLayoutSizeAdjustedForQuirks): Deleted. 2019-07-17 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r247461. rdar://problem/53229637 Make WKURLSchemeTask thread safe. <rdar://problem/50471863> and https://bugs.webkit.org/show_bug.cgi?id=199764 Reviewed by Alex Christensen. Source/WebKit: Punt most of the WKURLSchemeTask operations back to the main thread. Make accessing the NSURLRequest be thread safe with lock protection. * UIProcess/API/Cocoa/WKURLSchemeTask.mm: (getExceptionTypeFromMainRunLoop): (-[WKURLSchemeTaskImpl dealloc]): (-[WKURLSchemeTaskImpl request]): (-[WKURLSchemeTaskImpl _requestOnlyIfCached]): (-[WKURLSchemeTaskImpl didReceiveResponse:]): (-[WKURLSchemeTaskImpl didReceiveData:]): (-[WKURLSchemeTaskImpl didFinish]): (-[WKURLSchemeTaskImpl didFailWithError:]): (-[WKURLSchemeTaskImpl _didPerformRedirection:newRequest:]): * UIProcess/WebURLSchemeTask.cpp: (WebKit::WebURLSchemeTask::WebURLSchemeTask): (WebKit::WebURLSchemeTask::~WebURLSchemeTask): (WebKit::WebURLSchemeTask::didPerformRedirection): (WebKit::WebURLSchemeTask::didReceiveResponse): (WebKit::WebURLSchemeTask::didReceiveData): (WebKit::WebURLSchemeTask::didComplete): (WebKit::WebURLSchemeTask::pageDestroyed): (WebKit::WebURLSchemeTask::stop): (WebKit::WebURLSchemeTask::nsRequest const): * UIProcess/WebURLSchemeTask.h: (WebKit::WebURLSchemeTask::identifier const): (WebKit::WebURLSchemeTask::pageID const): (WebKit::WebURLSchemeTask::process): (WebKit::WebURLSchemeTask::process const): Deleted. (WebKit::WebURLSchemeTask::request const): Deleted. Source/WTF: * wtf/MainThread.cpp: (WTF::callOnMainAndWait): (WTF::callOnMainRunLoopAndWait): (WTF::callOnMainThreadAndWait): * wtf/MainThread.h: Tools: * TestWebKitAPI/Tests/WebKitCocoa/WKURLSchemeHandler-1.mm: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247461 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-15 Brady Eidson <beidson@apple.com> Make WKURLSchemeTask thread safe. <rdar://problem/50471863> and https://bugs.webkit.org/show_bug.cgi?id=199764 Reviewed by Alex Christensen. Punt most of the WKURLSchemeTask operations back to the main thread. Make accessing the NSURLRequest be thread safe with lock protection. * UIProcess/API/Cocoa/WKURLSchemeTask.mm: (getExceptionTypeFromMainRunLoop): (-[WKURLSchemeTaskImpl dealloc]): (-[WKURLSchemeTaskImpl request]): (-[WKURLSchemeTaskImpl _requestOnlyIfCached]): (-[WKURLSchemeTaskImpl didReceiveResponse:]): (-[WKURLSchemeTaskImpl didReceiveData:]): (-[WKURLSchemeTaskImpl didFinish]): (-[WKURLSchemeTaskImpl didFailWithError:]): (-[WKURLSchemeTaskImpl _didPerformRedirection:newRequest:]): * UIProcess/WebURLSchemeTask.cpp: (WebKit::WebURLSchemeTask::WebURLSchemeTask): (WebKit::WebURLSchemeTask::~WebURLSchemeTask): (WebKit::WebURLSchemeTask::didPerformRedirection): (WebKit::WebURLSchemeTask::didReceiveResponse): (WebKit::WebURLSchemeTask::didReceiveData): (WebKit::WebURLSchemeTask::didComplete): (WebKit::WebURLSchemeTask::pageDestroyed): (WebKit::WebURLSchemeTask::stop): (WebKit::WebURLSchemeTask::nsRequest const): * UIProcess/WebURLSchemeTask.h: (WebKit::WebURLSchemeTask::identifier const): (WebKit::WebURLSchemeTask::pageID const): (WebKit::WebURLSchemeTask::process): (WebKit::WebURLSchemeTask::process const): Deleted. (WebKit::WebURLSchemeTask::request const): Deleted. 2019-07-17 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r247460. rdar://problem/53229628 Followup to r247439 https://bugs.webkit.org/show_bug.cgi?id=199788 <rdar://problem/52142570> Reviewed by Tim Horton. As it turns out, sending modern async completion-handler based IPC messages while processing incoming sync messages results in a debug assertion. Instead of migrating FontAtSelection to the new async IPC mechanism, restore the older CallbackID-based async IPC. * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/mac/WebPageProxyMac.mm: (WebKit::WebPageProxy::fontAtSelection): (WebKit::WebPageProxy::fontAtSelectionCallback): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/mac/WebPageMac.mm: (WebKit::WebPage::fontAtSelection): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247460 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-15 Wenson Hsieh <wenson_hsieh@apple.com> Followup to r247439 https://bugs.webkit.org/show_bug.cgi?id=199788 <rdar://problem/52142570> Reviewed by Tim Horton. As it turns out, sending modern async completion-handler based IPC messages while processing incoming sync messages results in a debug assertion. Instead of migrating FontAtSelection to the new async IPC mechanism, restore the older CallbackID-based async IPC. * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/mac/WebPageProxyMac.mm: (WebKit::WebPageProxy::fontAtSelection): (WebKit::WebPageProxy::fontAtSelectionCallback): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/mac/WebPageMac.mm: (WebKit::WebPage::fontAtSelection): 2019-07-17 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r247439. rdar://problem/53229628 [macOS 10.15] Cannot unbold selected text when the system font is used https://bugs.webkit.org/show_bug.cgi?id=199788 <rdar://problem/52142570> Reviewed by Tim Horton. Source/WebKit: In macOS 10.15, +[NSFont fontWithName:size:] no longer recognizes system fonts (of name ".SFNS-*") and returns nil instead. However, our existing implementation of WebPageProxy::fontAtSelection works by grabbing the font name in the web process, and sending it over to the UI process, where it is mapped to an NSFont. As a result, this always results in a nil font in macOS 10.15, which causes us to never update NSFontManager's selected font. In turn, this means that once selected text is bolded, it can't be unbolded via NSFontManager, since NSFontManager thinks that the text is still not bold. To fix this, we simply encode and send a platform FontInfo instead of sending the font name. This allows the UI process to reconstruct NSFonts from font attribute dictionaries instead, and update the font manager. * UIProcess/Cocoa/WebViewImpl.mm: (WebKit::WebViewImpl::updateFontManagerIfNeeded): * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/mac/WebPageProxyMac.mm: (WebKit::WebPageProxy::fontAtSelection): Refactor this to send a FontInfo (containing a font attribute dictionary) instead of a font name. (WebKit::WebPageProxy::fontAtSelectionCallback): Deleted. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: Change FontAtSelection to use sendWithAsyncReply instead of sending a callback ID. This also allows us to remove FontAtSelectionCallback. * WebProcess/WebPage/mac/WebPageMac.mm: (WebKit::WebPage::fontAtSelection): Tools: Add a new API test to verify that bolding and unbolding updates the shared font manager's selected font. * TestWebKitAPI/Tests/mac/FontManagerTests.mm: (TestWebKitAPI::TEST): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247439 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-15 Wenson Hsieh <wenson_hsieh@apple.com> [macOS 10.15] Cannot unbold selected text when the system font is used https://bugs.webkit.org/show_bug.cgi?id=199788 <rdar://problem/52142570> Reviewed by Tim Horton. In macOS 10.15, +[NSFont fontWithName:size:] no longer recognizes system fonts (of name ".SFNS-*") and returns nil instead. However, our existing implementation of WebPageProxy::fontAtSelection works by grabbing the font name in the web process, and sending it over to the UI process, where it is mapped to an NSFont. As a result, this always results in a nil font in macOS 10.15, which causes us to never update NSFontManager's selected font. In turn, this means that once selected text is bolded, it can't be unbolded via NSFontManager, since NSFontManager thinks that the text is still not bold. To fix this, we simply encode and send a platform FontInfo instead of sending the font name. This allows the UI process to reconstruct NSFonts from font attribute dictionaries instead, and update the font manager. * UIProcess/Cocoa/WebViewImpl.mm: (WebKit::WebViewImpl::updateFontManagerIfNeeded): * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/mac/WebPageProxyMac.mm: (WebKit::WebPageProxy::fontAtSelection): Refactor this to send a FontInfo (containing a font attribute dictionary) instead of a font name. (WebKit::WebPageProxy::fontAtSelectionCallback): Deleted. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: Change FontAtSelection to use sendWithAsyncReply instead of sending a callback ID. This also allows us to remove FontAtSelectionCallback. * WebProcess/WebPage/mac/WebPageMac.mm: (WebKit::WebPage::fontAtSelection): 2019-07-17 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r247437. rdar://problem/53229545 [iOS] SOAuthorizationSession should tell AppSSO whether the UIClient is capable of showing the extension UI https://bugs.webkit.org/show_bug.cgi?id=199790 <rdar://problem/52790112> Reviewed by Brent Fulgham. Source/WebKit: On iOS, WebKit relies on a SPI -[WKUIDelegatePrivate _presentingViewControllerForWebView:] to present the extension UI. However, third party clients often don't implement this SPI. Therefore, WebKit will not be able to present the extension UI for them. To be able to show the extension UI for third party WebKit clients, WebKit should unset SOAuthorization.enableEmbeddedAuthorizationViewController whenever clients don't implement the above SPI such that AppSSO could show the UI in their UI process. * UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.mm: (WebKit::SOAuthorizationSession::start): Tools: Add tests to check SOAuthorization.enableEmbeddedAuthorizationViewController accordingly. * TestWebKitAPI/Tests/WebKitCocoa/TestSOAuthorization.mm: (-[TestSOAuthorizationDelegate _presentingViewControllerForWebView:]): (configureSOAuthorizationWebView): (TestWebKitAPI::TEST): (-[TestSOAuthorizationNavigationDelegate init]): Deleted. (-[TestSOAuthorizationNavigationDelegate webView:didFinishNavigation:]): Deleted. (-[TestSOAuthorizationNavigationDelegate webView:decidePolicyForNavigationAction:decisionHandler:]): Deleted. (-[TestSOAuthorizationNavigationDelegate webView:createWebViewWithConfiguration:forNavigationAction:windowFeatures:]): Deleted. (-[TestSOAuthorizationNavigationDelegate _webView:decidePolicyForSOAuthorizationLoadWithCurrentPolicy:forExtension:completionHandler:]): Deleted. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247437 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-15 Jiewen Tan <jiewen_tan@apple.com> [iOS] SOAuthorizationSession should tell AppSSO whether the UIClient is capable of showing the extension UI https://bugs.webkit.org/show_bug.cgi?id=199790 <rdar://problem/52790112> Reviewed by Brent Fulgham. On iOS, WebKit relies on a SPI -[WKUIDelegatePrivate _presentingViewControllerForWebView:] to present the extension UI. However, third party clients often don't implement this SPI. Therefore, WebKit will not be able to present the extension UI for them. To be able to show the extension UI for third party WebKit clients, WebKit should unset SOAuthorization.enableEmbeddedAuthorizationViewController whenever clients don't implement the above SPI such that AppSSO could show the UI in their UI process. * UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.mm: (WebKit::SOAuthorizationSession::start): 2019-07-17 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r247377. rdar://problem/53229731 New York font erroneously gets synthetic bold https://bugs.webkit.org/show_bug.cgi?id=199653 <rdar://problem/51692592> Reviewed by Simon Fraser. Source/WebCore: This patch adds support for -apple-system-ui-serif, -apple-system-ui-monospaced, and -apple-system-ui-rounded, behind an SPI that is off-by-default. We don't want to expose these fonts to the web because we don't a standardization story for them yet, but we do want some apps to be able to use them. WebKit clients who want to use these fonts can set -[WKPreferences _shouldAllowDesignSystemUIFonts] = YES. The patch generalizes our existing system-ui infrastructure to handle these three additional fonts. It also explicitly disables the unsupported dot-prefixed names so they don't leak out into Web content. Tests: fast/text/design-system-ui-10.html fast/text/design-system-ui-11.html fast/text/design-system-ui-12.html fast/text/design-system-ui-13.html fast/text/design-system-ui-14.html fast/text/design-system-ui-15.html fast/text/design-system-ui-16.html fast/text/design-system-ui-2.html fast/text/design-system-ui-3.html fast/text/design-system-ui-4.html fast/text/design-system-ui-5.html fast/text/design-system-ui-6.html fast/text/design-system-ui-7.html fast/text/design-system-ui-8.html fast/text/design-system-ui-9.html fast/text/design-system-ui.html * css/CSSFontFace.cpp: (WebCore::CSSFontFace::shouldAllowDesignSystemUIFonts const): * css/CSSFontFace.h: * css/CSSFontFaceSource.cpp: (WebCore::CSSFontFaceSource::load): * css/StyleResolver.cpp: (WebCore::StyleResolver::initializeFontStyle): * page/Settings.yaml: * platform/graphics/FontDescription.cpp: (WebCore::m_shouldAllowDesignSystemUIFonts): (WebCore::m_shouldAllowUserInstalledFonts): Deleted. * platform/graphics/FontDescription.h: (WebCore::FontDescription::shouldAllowDesignSystemUIFonts const): (WebCore::FontDescription::setShouldAllowDesignSystemUIFonts): (WebCore::FontDescription::operator== const): * platform/graphics/cocoa/FontCacheCoreText.cpp: (WebCore::platformFontLookupWithFamily): (WebCore::fontWithFamily): * platform/graphics/cocoa/FontCacheCoreText.h: * platform/graphics/cocoa/FontDescriptionCocoa.cpp: (WebCore::systemFontUse): (WebCore::systemFontCascadeList): (WebCore::FontCascadeDescription::effectiveFamilyCount const): (WebCore::FontCascadeDescription::effectiveFamilyAt const): (WebCore::isSystemFontString): Deleted. (WebCore::isUIFontTextStyle): Deleted. * platform/graphics/cocoa/FontPlatformDataCocoa.mm: (WebCore::FontPlatformData::ctFont const): * platform/graphics/cocoa/SystemFontDatabaseCoreText.cpp: (WebCore::SystemFontDatabaseCoreText::createSystemUI): (WebCore::SystemFontDatabaseCoreText::createDesignSystemUI): (WebCore::SystemFontDatabaseCoreText::createTextStyle): (WebCore::SystemFontDatabaseCoreText::cascadeList): (WebCore::SystemFontDatabaseCoreText::applyWeightItalicsAndFallbackBehavior): (WebCore::SystemFontDatabaseCoreText::systemFontParameters): * platform/graphics/cocoa/SystemFontDatabaseCoreText.h: * platform/graphics/ios/FontCacheIOS.mm: (WebCore::platformFontWithFamilySpecialCase): * platform/graphics/mac/FontCacheMac.mm: (WebCore::platformFontWithFamilySpecialCase): * style/StyleResolveForDocument.cpp: (WebCore::Style::resolveForDocument): * svg/graphics/SVGImage.cpp: (WebCore::SVGImage::dataChanged): * testing/InternalSettings.cpp: (WebCore::InternalSettings::Backup::Backup): (WebCore::InternalSettings::Backup::restoreTo): (WebCore::InternalSettings::setShouldAllowDesignSystemUIFonts): * testing/InternalSettings.h: * testing/InternalSettings.idl: Source/WebCore/PAL: * pal/spi/cocoa/CoreTextSPI.h: Source/WebKit: Add the SPI to enable the new fonts. * Shared/WebPreferences.yaml: * UIProcess/API/C/WKPreferences.cpp: (WKPreferencesSetShouldAllowDesignSystemUIFonts): (WKPreferencesGetShouldAllowDesignSystemUIFonts): * UIProcess/API/C/WKPreferencesRefPrivate.h: * UIProcess/API/Cocoa/WKPreferences.mm: (-[WKPreferences _shouldAllowDesignSystemUIFonts]): (-[WKPreferences _setShouldAllowDesignSystemUIFonts:]): * UIProcess/API/Cocoa/WKPreferencesPrivate.h: Source/WTF: * wtf/Platform.h: LayoutTests: * TestExpectations: * fast/text/design-system-ui-10-expected-mismatch.html: Added. * fast/text/design-system-ui-10.html: Added. * fast/text/design-system-ui-11-expected-mismatch.html: Added. * fast/text/design-system-ui-11.html: Added. * fast/text/design-system-ui-12-expected-mismatch.html: Added. * fast/text/design-system-ui-12.html: Added. * fast/text/design-system-ui-13-expected-mismatch.html: Added. * fast/text/design-system-ui-13.html: Added. * fast/text/design-system-ui-14-expected-mismatch.html: Added. * fast/text/design-system-ui-14.html: Added. * fast/text/design-system-ui-15-expected-mismatch.html: Added. * fast/text/design-system-ui-15.html: Added. * fast/text/design-system-ui-16-expected-mismatch.html: Added. * fast/text/design-system-ui-16.html: Added. * fast/text/design-system-ui-2-expected.html: Added. * fast/text/design-system-ui-2.html: Added. * fast/text/design-system-ui-3-expected-mismatch.html: Added. * fast/text/design-system-ui-3.html: Added. * fast/text/design-system-ui-4-expected-mismatch.html: Added. * fast/text/design-system-ui-4.html: Added. * fast/text/design-system-ui-5-expected-mismatch.html: Added. * fast/text/design-system-ui-5.html: Added. * fast/text/design-system-ui-6-expected.html: Added. * fast/text/design-system-ui-6.html: Added. * fast/text/design-system-ui-7-expected.html: Added. * fast/text/design-system-ui-7.html: Added. * fast/text/design-system-ui-8-expected-mismatch.html: Added. * fast/text/design-system-ui-8.html: Added. * fast/text/design-system-ui-9-expected-mismatch.html: Added. * fast/text/design-system-ui-9.html: Added. * fast/text/design-system-ui-expected.html: Added. * fast/text/design-system-ui.html: Added. * platform/mac/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247377 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-11 Myles C. Maxfield <mmaxfield@apple.com> New York font erroneously gets synthetic bold https://bugs.webkit.org/show_bug.cgi?id=199653 <rdar://problem/51692592> Reviewed by Simon Fraser. Add the SPI to enable the new fonts. * Shared/WebPreferences.yaml: * UIProcess/API/C/WKPreferences.cpp: (WKPreferencesSetShouldAllowDesignSystemUIFonts): (WKPreferencesGetShouldAllowDesignSystemUIFonts): * UIProcess/API/C/WKPreferencesRefPrivate.h: * UIProcess/API/Cocoa/WKPreferences.mm: (-[WKPreferences _shouldAllowDesignSystemUIFonts]): (-[WKPreferences _setShouldAllowDesignSystemUIFonts:]): * UIProcess/API/Cocoa/WKPreferencesPrivate.h: 2019-07-15 Alan Coon <alancoon@apple.com> Revert r247377. rdar://problem/53125241 2019-07-15 Alan Coon <alancoon@apple.com> Cherry-pick r247436. rdar://problem/53106179 REGRESSION: Chase app crashes immediately after authentication https://bugs.webkit.org/show_bug.cgi?id=199798 <rdar://problem/53106179> Reviewed by Alex Christensen. After r247411, we sometimes try to consult `_page` from WKWebView, before WKWebView's `_page` has been set. This happens under a check for -[WKWebView _isEditable], from within -[WKContentView setupInteraction], which happens if the host app is not linked on the iOS 12 SDK or earlier. To mitigate this, simply add a null check in -_isEditable. There's currently no great way to test this, since we don't have a mechanism for simulating linked-on checks. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _isEditable]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247436 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-15 Wenson Hsieh <wenson_hsieh@apple.com> REGRESSION: Chase app crashes immediately after authentication https://bugs.webkit.org/show_bug.cgi?id=199798 <rdar://problem/53106179> Reviewed by Alex Christensen. After r247411, we sometimes try to consult `_page` from WKWebView, before WKWebView's `_page` has been set. This happens under a check for -[WKWebView _isEditable], from within -[WKContentView setupInteraction], which happens if the host app is not linked on the iOS 12 SDK or earlier. To mitigate this, simply add a null check in -_isEditable. There's currently no great way to test this, since we don't have a mechanism for simulating linked-on checks. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _isEditable]): 2019-07-13 Andres Gonzalez <andresg_22@apple.com> Add accessibility support to WKDataListSuggestionsView. https://bugs.webkit.org/show_bug.cgi?id=199772 <rdar://problem/47095851> Reviewed by Chris Fleizach. Added accessibility announcement notifications to show, dismiss and selection change for the datalist suggestions view. * UIProcess/mac/WebDataListSuggestionsDropdownMac.mm: (-[WKDataListSuggestionsView notifyAccessibilityClients:]): (-[WKDataListSuggestionsView moveSelectionByDirection:]): (-[WKDataListSuggestionsView invalidate]): (-[WKDataListSuggestionsView showSuggestionsDropdown:]): 2019-07-13 Zalan Bujtas <zalan@apple.com> Cannot bring up custom media controls at all on v.youku.com https://bugs.webkit.org/show_bug.cgi?id=199699 <rdar://problem/51835327> Reviewed by Simon Fraser. * WebProcess/InjectedBundle/InjectedBundleNavigationAction.cpp: (WebKit::InjectedBundleNavigationAction::InjectedBundleNavigationAction): * WebProcess/WebPage/Cocoa/WebPageCocoa.mm: (WebKit::WebPage::performDictionaryLookupAtLocation): * WebProcess/WebPage/WebFrame.cpp: (WebKit::WebFrame::hitTest const): * WebProcess/WebPage/WebPage.cpp: (WebKit::handleContextMenuEvent): (WebKit::WebPage::characterIndexForPointAsync): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::handleStylusSingleTapAtPoint): (WebKit::textInteractionPositionInformation): * WebProcess/WebPage/mac/WebPageMac.mm: (WebKit::WebPage::shouldDelayWindowOrderingEvent): (WebKit::WebPage::acceptsFirstMouse): (WebKit::WebPage::performImmediateActionHitTestAtLocation): 2019-07-12 Andy Estes <aestes@apple.com> [Cocoa] -loadFileURL:allowingReadAccessToURL: should fully resolve file URLs https://bugs.webkit.org/show_bug.cgi?id=199768 <rdar://problem/52002206> Reviewed by Geoffrey Garen. -loadFileURL:allowingReadAccessToURL: used -_web_originalDataAsWTFString from WKNSURLExtras to convert the file and read access NSURLs to strings, which under the hood calls CFURLGetBytes(). CFURLGetBytes() gets the URL's string without considering the base URL, so if the client creates a URL like this: NSURL *url = [NSURL fileURLWithPath:@"tmpfile.txt" relativeToURL:[NSURL fileURLWithPath:@"/tmp"]] ... then -_web_originalDataAsWTFString will merely return the string "tmpfile.txt". When that is later converted back to a URL in WebPageProxy::loadFile(), we lose track of the base component and refuse to load something that no longer looks like a file: URL. Fixed this by fully resolving the URLs passed to -loadFileURL:allowingReadAccessToURL: when converting to strings by using -[NSURL absoluteString] instead of -_web_originalDataAsWTFString. * Shared/Cocoa/WKNSURLExtras.mm: (-[NSURL _web_originalDataAsWTFString]): * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView loadFileURL:allowingReadAccessToURL:]): 2019-07-12 Megan Gardner <megan_gardner@apple.com> Turn off two finger gestures for editable non-scaled content https://bugs.webkit.org/show_bug.cgi?id=199739 <rdar://problem/52107190> Reviewed by Tim Horton. This gesture is blocking a selection gesture. Turn it off as it is not even being used in editable content. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView setupInteraction]): (-[WKContentView _didChangeWebViewEditability]): 2019-07-12 Jiewen Tan <jiewen_tan@apple.com> SOAuthorizationSession::presentViewController should check WebPageProxy::isClosed() https://bugs.webkit.org/show_bug.cgi?id=199755 <rdar://problem/52323585> Reviewed by Chris Dumez. WebPageProxy::pageClient() is not guaranteed to be non null all the time. Therefore, we should check WebPageProxy::isClosed() before using it. * UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.mm: (WebKit::SOAuthorizationSession::presentViewController): 2019-07-12 Chris Dumez <cdumez@apple.com> Regression(macOS Catalina): Cannot quick look html documents in Mail https://bugs.webkit.org/show_bug.cgi?id=199754 <rdar://problem/51304961> Reviewed by Geoff Garen. If the client asks us to load a file URL but does not provide a resource path, WebKit would fallback to issuing a sandbox extension for /. This no longer works on mac OS Catalina and it would thus fail to load the file. To address the issue, if the attempt to create a sandbox extension for / fails, we now fall back to issuing one for the file's baseURL (path of containing folder). * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle): 2019-07-12 Michael Catanzaro <mcatanzaro@igalia.com> WebBackForwardListItem::setPageState should receive pageState by rvalue reference https://bugs.webkit.org/show_bug.cgi?id=199535 Reviewed by Alex Christensen Coverity is complaining here about copying PageState by value in the parameter list. It's sort of a false positive, in that the PageState really does need to be copied here, so this is the best we can do. But pass by value and then WTFMove() is a pretty strange way to write it. Passing by rvalue reference would be better. This makes the copy more clear. * Shared/WebBackForwardListItem.h: (WebKit::WebBackForwardListItem::setPageState): * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::updateBackForwardItem): 2019-07-12 Youenn Fablet <youenn@apple.com> Add release logging for quota checks https://bugs.webkit.org/show_bug.cgi?id=199697 Reviewed by Alex Christensen. Log requests made to the page and the result from the application. * Platform/Logging.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::requestStorageSpace): 2019-07-12 Youenn Fablet <youenn@apple.com> Remove unneeded variable in LocalStorageNamespace::getOrCreateStorageArea https://bugs.webkit.org/show_bug.cgi?id=199477 Reviewed by Alex Christensen. * NetworkProcess/WebStorage/StorageManager.cpp: (WebKit::StorageManager::LocalStorageNamespace::getOrCreateStorageArea): 2019-07-12 Pawel Stanek <p.stanek@metrological.com> Connection::waitForSyncReply() uses wall time clock for timeout https://bugs.webkit.org/show_bug.cgi?id=198712 Due to a nature of the system time (it might not be set, jump, be off by a lot) it is better to use monotonically increasing time which is exactly what's used in a similar place i.e. Connection::waitForMessage() Reviewed by Alex Christensen. * Platform/IPC/Connection.cpp: (IPC::Connection::waitForSyncReply): 2019-07-12 Timothy Hatcher <timothy@apple.com> Drop DarkModeCSSEnabled as an experimental feature and always enable it. https://bugs.webkit.org/show_bug.cgi?id=199725 rdar://problem/52970972 Reviewed by Megan Gardner. * Shared/WebPreferences.yaml: Removed DarkModeCSSEnabled. 2019-07-11 Myles C. Maxfield <mmaxfield@apple.com> New York font erroneously gets synthetic bold https://bugs.webkit.org/show_bug.cgi?id=199653 <rdar://problem/51692592> Reviewed by Simon Fraser. Add the SPI to enable the new fonts. * Shared/WebPreferences.yaml: * UIProcess/API/C/WKPreferences.cpp: (WKPreferencesSetShouldAllowDesignSystemUIFonts): (WKPreferencesGetShouldAllowDesignSystemUIFonts): * UIProcess/API/C/WKPreferencesRefPrivate.h: * UIProcess/API/Cocoa/WKPreferences.mm: (-[WKPreferences _shouldAllowDesignSystemUIFonts]): (-[WKPreferences _setShouldAllowDesignSystemUIFonts:]): * UIProcess/API/Cocoa/WKPreferencesPrivate.h: 2019-07-11 Chris Dumez <cdumez@apple.com> ASSERTION FAILED: RunLoop::isMain() under IPC::Connection::sendWithAsyncReply() https://bugs.webkit.org/show_bug.cgi?id=199734 <rdar://problem/52977439> Reviewed by Geoffrey Garen. It appears WKProcessTaskStateObserverDelegate's taskStateDidChange handler can get called on a background thread so we need to make sure we go back to the main thread before we go into WebKit and do IPC. * Shared/Cocoa/ProcessTaskStateObserver.mm: (-[WKProcessTaskStateObserverDelegate process:taskStateDidChange:]): 2019-07-11 Sihui Liu <sihui_liu@apple.com> StorageArea should not be destructed on the main thread https://bugs.webkit.org/show_bug.cgi?id=199713 <rdar://problem/52911900> Reviewed by Alex Christensen. After r246079, LocalStorageNameSpace could be destructed on the main thread and it may hold the last reference to StorageArea. Then we saw the crashes that StorageArea was wrongly destructed on the main thread. * NetworkProcess/NetworkSession.cpp: (WebKit::NetworkSession::~NetworkSession): * NetworkProcess/WebStorage/StorageManager.cpp: (WebKit::StorageManager::waitUntilTasksFinished): (WebKit::StorageManager::waitUntilWritesFinished): Deleted. * NetworkProcess/WebStorage/StorageManager.h: 2019-07-11 Tim Horton <timothy_horton@apple.com> Null deref of Range under WebPage::startAutoscrollAtPosition https://bugs.webkit.org/show_bug.cgi?id=199724 <rdar://problem/41127089> Reviewed by Dean Jackson. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::startAutoscrollAtPosition): Refactor this function to be early-return-y, and add one more early return if the Range is null. 2019-07-11 Pablo Saavedra <psaavedra@igalia.com> [WPE][GTK] Build failure with ENABLE_ACCESSIBILITY=OFF https://bugs.webkit.org/show_bug.cgi?id=199625 Added ENABLE(ACCESSIBILITY) and replaced HAVE(ACCESSIBILITY) with ENABLE(ACCESSIBILITY) in the code. Additionally, the TestRunner code generator now honors the Conditional IDL format. Reviewed by Konstantin Tokarev. * UIProcess/API/glib/WebKitWebViewAccessible.cpp: * UIProcess/API/glib/WebKitWebViewAccessible.h: * UIProcess/API/wpe/PageClientImpl.cpp: * UIProcess/API/wpe/PageClientImpl.h: * UIProcess/API/wpe/WPEView.cpp: (WKWPE::m_backend): (WKWPE::View::~View): * UIProcess/API/wpe/WPEView.h: * WebProcess/InjectedBundle/API/c/WKBundlePage.cpp: (WKAccessibilityRootObject): (WKAccessibilityFocusedObject): (WKAccessibilityEnableEnhancedAccessibility): (WKAccessibilityEnhancedAccessibilityEnabled): * WebProcess/WebPage/WebPage.cpp: * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/atk/WebKitWebPageAccessibilityObject.cpp: * WebProcess/WebPage/atk/WebKitWebPageAccessibilityObject.h: * WebProcess/WebPage/gtk/WebPageGtk.cpp: (WebKit::WebPage::platformInitialize): * WebProcess/WebPage/wpe/WebPageWPE.cpp: (WebKit::WebPage::platformInitialize): * WebProcess/wpe/WebProcessMainWPE.cpp: 2019-07-11 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r247314. https://bugs.webkit.org/show_bug.cgi?id=199721 Caused performance regression. (Requested by deanj on #webkit). Reverted changeset: "Disable speculative loading if cache is not to be used for the load" https://bugs.webkit.org/show_bug.cgi?id=199644 https://trac.webkit.org/changeset/247314 2019-07-11 Dean Jackson <dino@apple.com> CrashTracer: Regression : MobileSafari at UIKit: -[CALayerAccessibility__UIKit__QuartzCore setBounds:] https://bugs.webkit.org/show_bug.cgi?id=199720 <rdar://problem/51470469> Reviewed by Tim Horton. Speculative fix after confirming that this crash can occur when a zero width/height view is used for a UITargetedPreview. We already guarded against this in the default flow, but not in the fallback path where we take a view snapshot. * UIProcess/ios/WKContentViewInteraction.mm: (createFallbackTargetedPreview): Return early if rectangles are empty. 2019-07-11 Alex Christensen <achristensen@webkit.org> Use mobile UA on jsfiddle.net https://bugs.webkit.org/show_bug.cgi?id=199687 <rdar://problem/50839844> Reviewed by Maciej Stachowiak. Text selection does not work on iPads using desktop UA. This isn't the best solution, but it's certainly *a* solution. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::desktopClassBrowsingRecommendedForRequest): 2019-07-11 Simon Fraser <simon.fraser@apple.com> [iOS WK2] Can't place caret or select in content that overflows a contenteditable element https://bugs.webkit.org/show_bug.cgi?id=199741 rdar://problem/50545233 Reviewed by Wenson Hsieh. Various code paths for editing used renderer->absoluteBoundingBoxRect(), which is the border box of the element (or a set of line boxes for inline elements) converted to absolute coordinates. This excludes overflow content, but contenteditable needs to be able to place the caret in overflow content, and allow selection rects to be in the overflow area (if the element has visible overflow). Try to clean this up by adding some static helpers on WebPage for accessing the relevant rects, and use them in code call from visiblePositionInFocusedNodeForPoint(), and code that is input to selectionClipRect. This changes selectionClipRect to use the padding box (excluding borders), which is a progression. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::platformEditorState const): (WebKit::elementBoundsInFrame): (WebKit::constrainPoint): (WebKit::WebPage::rootViewBoundsForElement): (WebKit::WebPage::absoluteInteractionBoundsForElement): (WebKit::WebPage::rootViewInteractionBoundsForElement): (WebKit::WebPage::dispatchSyntheticMouseEventsForSelectionGesture): (WebKit::WebPage::getFocusedElementInformation): (WebKit::innerFrameQuad): Deleted. (WebKit::elementRectInRootViewCoordinates): Deleted. 2019-07-11 Jonathan Bedard <jbedard@apple.com> [iOS 13] Enable WebKit build https://bugs.webkit.org/show_bug.cgi?id=199481 <rdar://problem/52619048> Reviewed by Tim Horton. * Platform/spi/ios/UIKitSPI.h: Add UITextEffectsWindow.sharedTextEffectsWindowForWindowScene SPI. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView showGlobalMenuControllerInRect:]): setTargetRect, setMenuVisible marked depreciated in iOS 13. (-[WKContentView hideGlobalMenuController]): Ditto. 2019-07-11 Wenson Hsieh <wenson_hsieh@apple.com> MobileSafari may crash under -[UIKeyboardTaskExecutionContext transferExecutionToMainThreadWithTask:] https://bugs.webkit.org/show_bug.cgi?id=199701 <rdar://problem/52590170> Reviewed by Tim Horton. Mitigates a crash wherein we end up calling the completion handler of -requestAutocorrectionContextWithCompletionHandler: within a nested call to -requestAutocorrectionContextWithCompletionHandler:. In this particular case, a sync `window.open` from the web process to the UI process happens while the UI process is already handling a sync autocorrection context request. This causes the UI process to try and immediately dispatch the incoming sync message to avoid deadlock. However, Safari's logic to create and set up a new web view when opening a new window makes the new view the first responder, which then prompts UIKit logic to request an autocorrection context for the new web view. To avoid the issue for now, simply use -resignFirstResponder as a cue to invoke pending autocorrection context handlers in the original web view before UIKit tries to request autocorrection context in the newly created view. I attempted to write a test for this, but realized that we only end up hitting the debug assertion pointed out in <https://webkit.org/b/199680>; we should be able to write a test for this in the future, if we teach Connection to handle multiple outgoing sync messages. For the time being, I've attached a manual test case to the bug. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView resignFirstResponderForWebView]): (-[WKContentView _cancelPendingAutocorrectionContextHandler]): Add a new helper to signify that a pending autocorrection context handler should be cancelled (invoked immediately with empty data). Use this in a few places where we currently explicitly pass -[WKAutocorrectionContext emptyAutocorrectionContext]. (-[WKContentView requestAutocorrectionContextWithCompletionHandler:]): 2019-07-10 Simon Fraser <simon.fraser@apple.com> [iOS WK2] With modal overlay and body overflow:hidden, can't access all the content https://bugs.webkit.org/show_bug.cgi?id=199693 rdar://problem/51930364 Reviewed by Tim Horton. A page with overflow:hidden on the root needs to be scrollable if: * it's zoomed * the visual viewport is smaller than the layout viewport (including visible keyboard) * scrolling is required to hide MobileSafari's squishy bars This patch does the last two, plumbing a "visual viewport is smaller than layout viewport" bit up from WebCore via the scrolling tree (that way, when it changes we automatically trigger a commit), and checking for squished bars in WKWebView. * Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.cpp: (ArgumentCoder<ScrollingStateFrameScrollingNode>::encode): (ArgumentCoder<ScrollingStateFrameScrollingNode>::decode): * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _didCommitLayerTree:]): (-[WKWebView _overrideLayoutParametersWithMinimumLayoutSize:maximumUnobscuredSizeOverride:]): * UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.cpp: (WebKit::RemoteScrollingCoordinatorProxy::hasScrollableMainFrame const): * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::maximumUnobscuredSize const): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::dynamicViewportSizeUpdate): (WebKit::WebPage::updateVisibleContentRects): 2019-07-10 Tim Horton <timothy_horton@apple.com> Long pressing on attachments will crash the WebContent process https://bugs.webkit.org/show_bug.cgi?id=199696 <rdar://problem/52920241> Reviewed by Dean Jackson. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::linkIndicatorPositionInformation): (WebKit::elementPositionInformation): (WebKit::selectionPositionInformation): (WebKit::WebPage::positionInformation): Instead of one-off creating a node snapshot for <attachment>, just use TextIndicator. This way, we get an estimated background color, paint at the right resolution, etc. Also, hitNode was often null where we were previously calling shareableBitmapSnapshotForNode, because it depends on the element having click event handlers. selectionPositionInformation() re-hit-tests more permissively to find the <attachment>, so moving this code inside that function ensures that we don't try to snapshot a null node. 2019-07-10 Dean Jackson <dino@apple.com> Safari’s context menu actions are missing options https://bugs.webkit.org/show_bug.cgi?id=199694 <rdar://problem/52726822> Reviewed by Tim Horton. One of the most embarrassing errors I've ever made. I was returning early when something existed, instead of when it didn't exist. (*cough* tests *cough*) * UIProcess/ios/WKContentViewInteraction.mm: 2019-07-10 Jon Lee <jonlee@apple.com> Opt trello.com to mobile UA https://bugs.webkit.org/show_bug.cgi?id=199686 rdar://problem/51708119 Reviewed by Wenson Hsieh. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::desktopClassBrowsingRecommendedForRequest): Currently the desktop version of the site prevents users from tapping cards to edit them. Opt trello into the mobile UA for now. 2019-07-10 Daniel Bates <dabates@apple.com> [iOS] Selection handles "Lollipops" can become gray and stay gray https://bugs.webkit.org/show_bug.cgi?id=198852 <rdar://problem/51736130> Reviewed by Wenson Hsieh. Tell the text interaction assistant to update the selection UI when the tint color changes. We do this by way of deactivating and activating selection. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView tintColorDidChange]): 2019-07-10 Dean Jackson <dino@apple.com> Share or Copy image from context menu does not share the correct data https://bugs.webkit.org/show_bug.cgi?id=199681 <rdar://problem/50538771> Reviewed by Tim Horton. The UIContextMenuInteraction calls didEndInteraction before executing the actions of a selected menu item. This means we were assuming the interaction had finished before performing the action triggered in the interaction, ending up in the state where we had forgotten which element we were working with. Rather than ask for UIKit to change, I'm just starting the interaction again as the action is run. Thankfully we already had the location of the interaction. There is a small risk that the page has changed in the meantime, but I'm not sure what to do about that. While here, I moved a method only used by us into _WKElementActionInternal, and changed the location stored by _WKActivatedElementInfo from a CGPoint to an WebCore::IntPoint (since it doesn't escape WebKit). * UIProcess/API/Cocoa/_WKActivatedElementInfo.mm: Use a WebCore::IntPoint rather than a CGPoint. (-[_WKActivatedElementInfo _initWithType:URL:imageURL:location:title:ID:rect:image:]): (-[_WKActivatedElementInfo _initWithType:URL:imageURL:location:title:ID:rect:image:userInfo:]): (-[_WKActivatedElementInfo _interactionLocation]): * UIProcess/API/Cocoa/_WKActivatedElementInfoInternal.h: * UIProcess/API/Cocoa/_WKElementAction.h: Move uiActionForElementInfo to Internal. * UIProcess/API/Cocoa/_WKElementActionInternal.h: * UIProcess/API/Cocoa/_WKElementAction.mm: When executing the handlers, restart the interaction using the location in _WKActivatedElementInfo. (+[_WKElementAction _elementActionWithType:customTitle:assistant:]): * UIProcess/ios/WKContentViewInteraction.mm: Explicitly start and stop interactions at the appropriate points in the UIContextMenu flow. This isn't really needed since we're doing it in the handlers, but it will be correct if the UIKit delegate order changes. (-[WKContentView continueContextMenuInteraction:]): (-[WKContentView contextMenuInteractionDidEnd:]): 2019-07-10 Chris Dumez <cdumez@apple.com> Crash under IPC::Connection::waitForMessage() https://bugs.webkit.org/show_bug.cgi?id=199680 <rdar://problem/52500561> Reviewed by Tim Horton. IPC::Connection::waitForMessage() is crashing due to a null defererence of m_waitingForMessage. Since m_waitingForMessage is only ever set to null in waitForMessage(), this seems to imply we've re-entered waitForMessage(). This is in theory possible since the loop inside waitForMessage() calls SyncMessageState::singleton().dispatchMessages() on every iteration to process incoming synchronous IPC messages. In theory, one of these sync IPC messages could run code which ends up calling waitForAndDispatchImmediately() (and thus waitForMessage()). We had a debug assertion to try and catch re-entrancy with a comment stating "We don't support having multiple clients waiting for messages." but we would not see those in release and we would crash with a null dereference instead. To address the crashes in release, return early in case of re-entrancy (we would still hit an assertion in debug). * Platform/IPC/Connection.cpp: (IPC::Connection::Connection): (IPC::Connection::waitForMessage): * Platform/IPC/Connection.h: 2019-07-10 Tim Horton <timothy_horton@apple.com> Context menus are not presented for WKWebViews that don't have UIDelegates https://bugs.webkit.org/show_bug.cgi?id=199678 Reviewed by Dean Jackson. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView continueContextMenuInteraction:]): Remove this unnecessary early-return if we don't have a UIDelegate. We have a default behavior that we totally want to happen. Also, rename completion() to continueWithContextMenuConfiguration() to reduce confusion between completion() and completionBlock() in this method. 2019-07-10 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r247223. https://bugs.webkit.org/show_bug.cgi?id=199679 Caused perf regression. (Requested by deanj on #webkit). Reverted changeset: "[iPadOS] Viewport pops while loading sohu.com, xinhuanet.com, and various other websites" https://bugs.webkit.org/show_bug.cgi?id=199575 https://trac.webkit.org/changeset/247223 2019-07-10 Youenn Fablet <youenn@apple.com> Disable speculative loading if cache is not to be used for the load https://bugs.webkit.org/show_bug.cgi?id=199644 Reviewed by Chris Dumez. When the page is reloaded, loads are instructed to not use the cache. It is therefore unneeded to do speculative revalidation. Allow speculative revalidation if the cache policy is either the default HTTP policy or if policy is to refresh all cache data. Covered by added test. * NetworkProcess/cache/NetworkCache.cpp: (WebKit::NetworkCache::cachePolicyValidForSpeculativeRevalidation): (WebKit::NetworkCache::canRequestUseSpeculativeRevalidation): 2019-07-10 Alex Christensen <achristensen@webkit.org> Fix build after Foundation changes UIEdgeInsets definition https://bugs.webkit.org/show_bug.cgi?id=199660 <rdar://problem/52390453> Reviewed by Tim Horton. * UIProcess/API/Cocoa/WKUIDelegatePrivate.h: * UIProcess/Cocoa/WKWebViewContentProvider.h: 2019-07-10 Antti Koivisto <antti@apple.com> Remove TouchActionData https://bugs.webkit.org/show_bug.cgi?id=199668 Reviewed by Simon Fraser. * Shared/WebCoreArgumentCoders.cpp: (IPC::ArgumentCoder<EventTrackingRegions>::encode): (IPC::ArgumentCoder<EventTrackingRegions>::decode): (IPC::ArgumentCoder<TouchActionData>::encode): Deleted. (IPC::ArgumentCoder<TouchActionData>::decode): Deleted. 2019-07-09 Michael Catanzaro <mcatanzaro@igalia.com> [WPE][GTK] GUniqueOutPtr::release should return a raw pointer https://bugs.webkit.org/show_bug.cgi?id=199579 Reviewed by Carlos Garcia Campos. * NetworkProcess/glib/WebKitCachedResolver.cpp: (webkitCachedResolverLookupByNameAsync): (webkitCachedResolverLookupByNameWithFlagsAsync): * UIProcess/API/glib/WebKitFaviconDatabase.cpp: (processPendingIconsForPageURL): (webkit_favicon_database_get_favicon): * UIProcess/API/glib/WebKitUserContentFilterStore.cpp: (webkit_user_content_filter_store_save_from_file): 2019-07-09 Tim Horton <timothy_horton@apple.com> Fixed elements appear in the middle of full page screenshots taken when scrolled https://bugs.webkit.org/show_bug.cgi?id=199649 <rdar://problem/52476226> Reviewed by Simon Fraser. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::computePagesForPrintingAndDrawToPDF): Temporarily expand the layout viewport to the size of the snapshotting page, so that fixed elements sit against the bounds of the page instead of wherever you're currently scrolled to. 2019-07-09 Simon Fraser <simon.fraser@apple.com> [iOS WK2] Use Optional<> for two data members of WKWebView https://bugs.webkit.org/show_bug.cgi?id=199637 Reviewed by Tim Horton. Use Optional<CGSize> to replace _overridesViewLayoutSize/_viewLayoutSizeOverride and _overridesMaximumUnobscuredSize/_maximumUnobscuredSizeOverride. No behavior change. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView activeViewLayoutSize:]): (-[WKWebView _frameOrBoundsChanged]): (activeMaximumUnobscuredSize): (-[WKWebView _minimumLayoutSizeOverride]): (-[WKWebView _setViewLayoutSizeOverride:]): (-[WKWebView _maximumUnobscuredSizeOverride]): (-[WKWebView _setMaximumUnobscuredSizeOverride:]): (-[WKWebView _beginAnimatedResizeWithUpdates:]): (-[WKWebView _clearOverrideLayoutParameters]): 2019-07-09 Chris Dumez <cdumez@apple.com> Fix integer type encoding / decoding in WKRemoteObjectCoder https://bugs.webkit.org/show_bug.cgi?id=199643 <rdar://problem/52732342> Reviewed by Anders Carlsson. As per [1], q / Q match to long long / unsigned long long, not long / unsigned long. [1] https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtTypeEncodings.html#//apple_ref/doc/uid/TP40008048-CH100 * Shared/API/Cocoa/WKRemoteObjectCoder.mm: (encodeInvocationArguments): (decodeInvocationArguments): 2019-07-09 Chris Dumez <cdumez@apple.com> Cleanup uses of NetworkProcess::m_sessionByConnection https://bugs.webkit.org/show_bug.cgi?id=199586 Reviewed by Alex Christensen. Avoid double HashMap lookups and call add() instead of ensure() when appropriate. * NetworkProcess/NetworkProcess.cpp: (WebKit::NetworkProcess::networkSessionByConnection const): (WebKit::NetworkProcess::webPageWasAdded): (WebKit::NetworkProcess::webProcessWasDisconnected): 2019-07-09 Saagar Jha <saagarjha@apple.com> WKObject's minimum object alignment needs to be larger https://bugs.webkit.org/show_bug.cgi?id=199523 Reviewed by Alex Christensen. WKObject's wrapped objects are currently constructed at addresses aligned to 8-byte boundaries, but some classes have more stringent requirements. By querying std::aligned_storage for the alignment of an object larger than anything we can construct, we should be able to satisfy alignment for any of WebKit's types. * Shared/Cocoa/APIObject.mm: Use std::aligned_storage in conjunction with alignof to determine minimumObjectAlignment, instead of hardcoding 8. 2019-07-09 Megan Gardner <megan_gardner@apple.com> Don't strip out spaces for personalized Autocorrections https://bugs.webkit.org/show_bug.cgi?id=199476 <rdar://problem/50782015> Reviewed by Dean Jackson. When inserting 'autocorrections' that are really predictive text suggestions based on personal data, we would remove the space before the suggestion, resulting in incorrect input. To fix, do not remove a space when the autocorrected text and the text it is replacing do not have any length. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::applyAutocorrectionInternal): 2019-07-09 Truitt Savell <tsavell@apple.com> Unreviewed, rolling out r247230. Caused storage/domstorage/localstorage/private-browsing- affects-storage.html to crash with an assertion. Reverted changeset: "Cleanup uses of NetworkProcess::m_sessionByConnection" https://bugs.webkit.org/show_bug.cgi?id=199586 https://trac.webkit.org/changeset/247230 2019-07-09 Youenn Fablet <youenn@apple.com> XHR CORS requests logged twice in the server https://bugs.webkit.org/show_bug.cgi?id=199492 <rdar://problem/52757558> Reviewed by Chris Dumez. Disable speculative loading for XHR and fetch. These speculative requests might have specific headers that are no longer relevant when reloading the page. This might then confuse servers. * NetworkProcess/cache/NetworkCache.cpp: (WebKit::NetworkCache::makeStoreDecision): (WebKit::NetworkCache::canRequestUseSpeculativeRevalidation): (WebKit::NetworkCache::Cache::retrieve): 2019-07-09 Chris Dumez <cdumez@apple.com> Fix validation of method signature in decodeInvocation() https://bugs.webkit.org/show_bug.cgi?id=199629 <rdar://problem/52731659> Reviewed by Dan Bernstein. The decoder was mistakenly assigning remoteMethodSignature to localMethodSignature before comparing remoteMethodSignature and localMethodSignature, thus making the check useless. * Shared/API/Cocoa/WKRemoteObjectCoder.mm: (decodeInvocation): 2019-07-09 Youenn Fablet <youenn@apple.com> Revert conditional WebPageProxy check to grant universal file read sandbox upon correct sandbox creation https://bugs.webkit.org/show_bug.cgi?id=199622 <rdar://problem/52357508> Reviewed by Alex Christensen. On iOS, the sandbox extension to '/' will usually fail, thus the universal file read sandbox is not granted. This makes WebPageProxy cancel some file:// loads to the application own container. As a short term fix, go back to previous behavior. Covered by testing broken app identified in rdar://problem/52357508. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle): 2019-07-09 Sihui Liu <sihui_liu@apple.com> Only allow fetching and removing session credentials from WebsiteDataStore https://bugs.webkit.org/show_bug.cgi?id=199385 <rdar://problem/52622080> Reviewed by Alex Christensen. Stop sending an extra message to network process for fetching or removing persistent credentials. Also introduce a new SPI for clearing persistent credentials created in test. * NetworkProcess/NetworkProcess.cpp: (WebKit::NetworkProcess::clearPermanentCredentialsForProtectionSpace): (WebKit::NetworkProcess::fetchWebsiteData): (WebKit::NetworkProcess::deleteWebsiteData): (WebKit::NetworkProcess::deleteWebsiteDataForOrigins): (WebKit::NetworkProcess::deleteWebsiteDataForRegistrableDomains): (WebKit::NetworkProcess::originsWithPersistentCredentials): Deleted. (WebKit::NetworkProcess::removeCredentialsWithOrigins): Deleted. * NetworkProcess/NetworkProcess.h: * NetworkProcess/NetworkProcess.messages.in: * NetworkProcess/cocoa/NetworkProcessCocoa.mm: (WebKit::NetworkProcess::originsWithPersistentCredentials): Deleted. (WebKit::NetworkProcess::removeCredentialsWithOrigins): Deleted. * UIProcess/API/Cocoa/WKProcessPool.mm: (-[WKProcessPool _clearPermanentCredentialsForProtectionSpace:completionHandler:]): * UIProcess/API/Cocoa/WKProcessPoolPrivate.h: * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::clearPermanentCredentialsForProtectionSpace): * UIProcess/WebProcessPool.h: * UIProcess/WebsiteData/WebsiteDataStore.cpp: (WebKit::WebsiteDataStore::fetchDataAndApply): (WebKit::computeWebProcessAccessTypeForDataRemoval): (WebKit::WebsiteDataStore::removeData): 2019-07-09 Antoine Quint <graouts@apple.com> [Pointer Events] Scroll indicators should not show for scrollable content with touch-action: none https://bugs.webkit.org/show_bug.cgi?id=199618 Reviewed by Simon Fraser. Even though we correctly didn't scroll when "touch-action: none" was specified on an element, we would only apply scrolling constraints after the panning gesture was recognized and the backing UIScrollView would show its scroll indicators. While this is correct when only "pan-x" or "pan-y" is specified, we should not show the scroll indicators at all for "touch-action: none" since no scrolling should happen. To do this, we add a new method to the WKTouchActionGestureRecognizerDelegate protocol to indicate whether a given gesture recognizer may pan content in the WKWebView. If the gesture recognizer is the top-level scroll view or one created within the page to back "overflow: scroll" content or an iframe, we correctly make that gesture recognizer fail to recognize if neither "pan-x" nor "pan-y" is specified for this touch identifier. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView gestureRecognizerMayPanWebView:]): * UIProcess/ios/WKTouchActionGestureRecognizer.h: * UIProcess/ios/WKTouchActionGestureRecognizer.mm: (-[WKTouchActionGestureRecognizer canPreventGestureRecognizer:]): 2019-07-09 Chris Dumez <cdumez@apple.com> Validate reply block signature in [WKRemoteObjectRegistry _invokeMethod] https://bugs.webkit.org/show_bug.cgi?id=199584 <rdar://problem/46268249> Reviewed by Geoffrey Garen. Validate reply block signature in [WKRemoteObjectRegistry _invokeMethod] for robustness. * Shared/API/Cocoa/_WKRemoteObjectRegistry.mm: (validateReplyBlockSignature): (-[_WKRemoteObjectRegistry _invokeMethod:]): 2019-07-09 Alex Christensen <achristensen@webkit.org> UserData::decode should return false when decoding an unrecognized type https://bugs.webkit.org/show_bug.cgi?id=199598 <rdar://52735138> Reviewed by Ryosuke Niwa. * Shared/UserData.cpp: (WebKit::UserData::decode): 2019-07-08 Chris Dumez <cdumez@apple.com> Speculative fix for crashes under LocalStorageDatabaseTracker::databasePath() https://bugs.webkit.org/show_bug.cgi?id=199599 <rdar://problem/31169686> Reviewed by Ryosuke Niwa. Speculative fix for crashes under LocalStorageDatabaseTracker::databasePath(): - Add new localStorageDirectory() getter to LocalStorageDatabaseTracker which calls isolatedCopy() on m_localStorageDirectory before returning it. Use it everywhere instead of m_localStorageDirectory since it is not safe to use the same String from various threads like it was done. - Move localStorageDirectory when constructing the LocalStorageDatabaseTracker instead of copying it. - Make sure that LocalStorageDatabaseTracker and StorageManager are both constructed and destroyed on the main thread. * NetworkProcess/NetworkSession.cpp: (WebKit::NetworkSession::NetworkSession): * NetworkProcess/NetworkSession.h: * NetworkProcess/WebStorage/LocalStorageDatabaseTracker.cpp: (WebKit::LocalStorageDatabaseTracker::create): (WebKit::LocalStorageDatabaseTracker::LocalStorageDatabaseTracker): (WebKit::LocalStorageDatabaseTracker::localStorageDirectory const): (WebKit::LocalStorageDatabaseTracker::~LocalStorageDatabaseTracker): (WebKit::LocalStorageDatabaseTracker::deleteAllDatabases): (WebKit::LocalStorageDatabaseTracker::origins const): (WebKit::LocalStorageDatabaseTracker::databasePath const): * NetworkProcess/WebStorage/LocalStorageDatabaseTracker.h: * NetworkProcess/WebStorage/StorageManager.cpp: (WebKit::StorageManager::create): (WebKit::StorageManager::StorageManager): (WebKit::StorageManager::~StorageManager): * NetworkProcess/WebStorage/StorageManager.h: * NetworkProcess/WebStorage/ios/LocalStorageDatabaseTrackerIOS.mm: (WebKit::LocalStorageDatabaseTracker::platformMaybeExcludeFromBackup const): * NetworkProcess/cocoa/NetworkSessionCocoa.mm: (WebKit::NetworkSessionCocoa::NetworkSessionCocoa): * NetworkProcess/curl/NetworkSessionCurl.cpp: (WebKit::NetworkSessionCurl::NetworkSessionCurl): * NetworkProcess/soup/NetworkSessionSoup.cpp: (WebKit::NetworkSessionSoup::NetworkSessionSoup): 2019-07-08 Chris Dumez <cdumez@apple.com> Use WeakHashSet for WebUserContentControllerProxy::m_processes https://bugs.webkit.org/show_bug.cgi?id=199591 <rdar://problem/52798721> Reviewed by Youenn Fablet. Use WeakHashSet for WebUserContentControllerProxy::m_processses for safety. In theory, a WebProcessProxy could stay in the map if we failed to call WebProcessProxy::shutDown() before destroying it. * UIProcess/UserContent/WebUserContentControllerProxy.cpp: (WebKit::WebUserContentControllerProxy::~WebUserContentControllerProxy): (WebKit::WebUserContentControllerProxy::addProcess): (WebKit::WebUserContentControllerProxy::removeProcess): (WebKit::WebUserContentControllerProxy::addUserContentWorldUse): (WebKit::WebUserContentControllerProxy::removeUserContentWorldUses): (WebKit::WebUserContentControllerProxy::addUserScript): (WebKit::WebUserContentControllerProxy::removeUserScript): (WebKit::WebUserContentControllerProxy::removeAllUserScripts): (WebKit::WebUserContentControllerProxy::addUserStyleSheet): (WebKit::WebUserContentControllerProxy::removeUserStyleSheet): (WebKit::WebUserContentControllerProxy::removeAllUserStyleSheets): (WebKit::WebUserContentControllerProxy::addUserScriptMessageHandler): (WebKit::WebUserContentControllerProxy::removeUserMessageHandlerForName): (WebKit::WebUserContentControllerProxy::removeAllUserMessageHandlers): (WebKit::WebUserContentControllerProxy::addContentRuleList): (WebKit::WebUserContentControllerProxy::removeContentRuleList): (WebKit::WebUserContentControllerProxy::removeAllContentRuleLists): * UIProcess/UserContent/WebUserContentControllerProxy.h: (WebKit::WebUserContentControllerProxy::addNetworkProcess): (WebKit::WebUserContentControllerProxy::removeNetworkProcess): 2019-07-08 Daniel Bates <dabates@apple.com> [iOS] Support select all in non-editable element https://bugs.webkit.org/show_bug.cgi?id=199257 <rdar://problem/52553667> Reviewed by Wenson Hsieh. Unless we are populating the callout bar always advertise that WebKit can perform Select All when building with USE(UIKIT_KEYBOARD_ADDITIONS). This way you can press Command + A to select all text even in a non-editable element just like you can on Mac. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView canPerformActionForWebView:withSender:]): 2019-07-08 Chris Dumez <cdumez@apple.com> Cleanup uses of NetworkProcess::m_sessionByConnection https://bugs.webkit.org/show_bug.cgi?id=199586 Reviewed by Alex Christensen. Avoid double HashMap lookups and call add() instead of ensure() when appropriate. * NetworkProcess/NetworkProcess.cpp: (WebKit::NetworkProcess::networkSessionByConnection const): (WebKit::NetworkProcess::webPageWasAdded): (WebKit::NetworkProcess::webProcessWasDisconnected): 2019-07-08 Tim Horton <timothy_horton@apple.com> WKWebView fails to render when another view uses CoreImage filters https://bugs.webkit.org/show_bug.cgi?id=199488 <rdar://problem/52695825> Reviewed by Dean Jackson. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::layerHostingModeDidChange): Update m_layerHostingMode when it changes, even if we can't message the Web Content process. This ensures that the next time we launch a Web Content process, WebPageCreationParameters will have the correct layer hosting mode, and is the usual pattern for such things. 2019-07-08 Wenson Hsieh <wenson_hsieh@apple.com> [iPadOS] Viewport pops while loading sohu.com, xinhuanet.com, and various other websites https://bugs.webkit.org/show_bug.cgi?id=199575 <rdar://problem/51842220> Reviewed by Simon Fraser. Currently, the shrink-to-fit-content heuristic added to scale desktop sites fit within the viewport on iPadOS only runs during two intervals: after document load, and after page load. On very script-heavy websites, this may cause a visible jump, as rendering may commence well before the document is finished parsing. To mitigate this, we move the first opportunity for the shrink-to-fit heuristic from after document, to right after the page transition has completed (before we unfreeze the layer tree). * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::dispatchDidFinishDocumentLoad): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::didCompletePageTransition): (WebKit::WebPage::didFinishDocumentLoad): Deleted. Remove this didFinishDocumentLoad hook, which was only used to schedule the shrink-to-fit timer. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::immediatelyShrinkToFitContent): m_mainFrame might be null after page transition completes, so we need to ensure immediatelyShrinkToFitContent is robust in this scenario. 2019-07-08 Chris Dumez <cdumez@apple.com> Add threading assertion to WTF::CompletionHandler https://bugs.webkit.org/show_bug.cgi?id=199516 Reviewed by Alex Christensen. Update some MessagePort-related code to use WTF::Function instead of WTF::CompletionHandler since the callback is always called on the main thread, even when it was created on a worker thread. Ideally, this code would be refactored so that the callback gets called on the worker thread directly. * UIProcess/UIMessagePortChannelProvider.cpp: (WebKit::UIMessagePortChannelProvider::checkRemotePortForActivity): * UIProcess/UIMessagePortChannelProvider.h: * WebProcess/WebCoreSupport/WebMessagePortChannelProvider.cpp: (WebKit::WebMessagePortChannelProvider::checkRemotePortForActivity): * WebProcess/WebCoreSupport/WebMessagePortChannelProvider.h: 2019-07-08 Antoine Quint <graouts@apple.com> [Pointer Events] "touch-action: none" does not prevent double-tap-to-zoom https://bugs.webkit.org/show_bug.cgi?id=199571 <rdar://problem/51715002> Reviewed by Wenson Hsieh. We add a new WKTouchActionGestureRecognizerDelegate method to check whether a gesture recognizer may lead to zooming the page as a result of double-tapping, which can be caused by two different gesture recognizers managed by WKContentViewInteraction. If that delegate method returns true and we have "touch-action: none" set for this touch, we cause those gesture recognizers to fail and prevent double-tap-to-zoom behavior. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView gestureRecognizerMayDoubleTapToZoomWebView:]): * UIProcess/ios/WKTouchActionGestureRecognizer.h: * UIProcess/ios/WKTouchActionGestureRecognizer.mm: (-[WKTouchActionGestureRecognizer canPreventGestureRecognizer:]): 2019-07-08 Per Arne Vollan <pvollan@apple.com> [iOS] WebContent processes should not globally allow mach lookup to the AX server. https://bugs.webkit.org/show_bug.cgi?id=199386 <rdar://problem/52487468> Reviewed by Chris Fleizach. Instead, a mach extension for this service should be issued to the WebContent process. This has already been implemented. * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb: 2019-07-08 Claudio Saavedra <csaavedra@igalia.com> REGRESSION(r246671): [WPE][GTK] Crash in NetworkProcess since the DNS cache landed https://bugs.webkit.org/show_bug.cgi?id=199572 Reviewed by Michael Catanzaro. The GError coming from the wrapped resolver shouldn't be freed, but passed onto the caller. * NetworkProcess/glib/WebKitCachedResolver.cpp: (webkitCachedResolverLookupByNameAsync): (webkitCachedResolverLookupByNameWithFlagsAsync): 2019-07-07 Antoine Quint <graouts@apple.com> [Pointer Events] touch-action should affect the behavior of pinch-to-zoom to show tabs in Safari https://bugs.webkit.org/show_bug.cgi?id=199560 <rdar://problem/52742265> Reviewed by Dean Jackson. There are other UIPinchGestureRecognizer objects that may lead to pinch-to-zoom behavior, for instance pinching out to show open tabs in Safari on iOS. We add a new WKUIDelegatePrivate method that will allow Safari to indicate that a UIPinchGestureRecognizer considered for prevention would lead to pinch-to-zoom behavior. * UIProcess/API/Cocoa/WKUIDelegatePrivate.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView gestureRecognizerMayPinchToZoomWebView:]): 2019-07-08 Antoine Quint <graouts@apple.com> [Pointer Events] Enable only on the most recent version of the supported iOS family https://bugs.webkit.org/show_bug.cgi?id=199562 <rdar://problem/52766511> Reviewed by Dean Jackson. * Configurations/FeatureDefines.xcconfig: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView cancelPointersForGestureRecognizer:]): (-[WKContentView activeTouchIdentifierForGestureRecognizer:]): (-[WKContentView touchActionActiveTouches]): * UIProcess/ios/WKSyntheticTapGestureRecognizer.m: (-[WKSyntheticTapGestureRecognizer touchesEnded:withEvent:]): * UIProcess/ios/WKTouchActionGestureRecognizer.h: * UIProcess/ios/WKTouchActionGestureRecognizer.mm: (-[WKTouchActionGestureRecognizer canPreventGestureRecognizer:]): 2019-07-08 Michael Catanzaro <mcatanzaro@igalia.com> [GTK] ViewGestureController constructor leaves m_direction uninitialized https://bugs.webkit.org/show_bug.cgi?id=199532 Reviewed by Carlos Garcia Campos. This is harmless because it should never be read until after it's initialized, but still not robust. Fix it by assuming Back as the default value until the first swipe begins. * UIProcess/ViewGestureController.h: 2019-07-07 Zalan Bujtas <zalan@apple.com> [ContentChangeObserver] Difficult to control videos on iqiyi.com as the actions are mouse hover https://bugs.webkit.org/show_bug.cgi?id=199542 <rdar://problem/51886813> Reviewed by Simon Fraser. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::handleSyntheticClick): 2019-07-06 Antoine Quint <graouts@apple.com> [Pointer Events] Use a gesture recognizer to prevent pinch-to-zoom behavior https://bugs.webkit.org/show_bug.cgi?id=199543 Reviewed by Dean Jackson. We used to set the "enabled" property on the main UIScrollView's UIPinchGestureRecognizer to disable pinch-to-zoom behavior based on the "touch-action" CSS property. This was sub-optimal since this gesture recognizer can be publicly accessible by third-party developers, but also because it set state instead of a run-time solution. We now introduce a new WKTouchActionGestureRecognizer dedicated to preventing clearly identified gesture recognizers from being recognized to disable some built-in behavior. As a new touch starts, we record the computed touch-action property for the given touch identifier on the WKTouchActionGestureRecognizer, then WKTouchActionGestureRecognizer determines, by implementing -[canPreventGestureRecognizer:], whether the possibly-prevented gesture recognizer is known to lead to a pinch-to-zoom behavior and whether it contains a touch that should prevent it. To support the WKTouchActionGestureRecognizer, WKContentViewInteraction implements the new WKTouchActionGestureRecognizerDelegate protocol to indicate whether the possibly-prevented gesture recognizer is the main UIScrollView's UIPinchGestureRecognizer. No new test since this changes the implementation of existing behavior. * SourcesCocoa.txt: * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView setupInteraction]): (-[WKContentView cleanupInteraction]): (-[WKContentView _removeDefaultGestureRecognizers]): (-[WKContentView _addDefaultGestureRecognizers]): (-[WKContentView _handleTouchActionsForTouchEvent:]): (-[WKContentView gestureRecognizerMayPinchToZoomWebView:]): (-[WKContentView touchActionActiveTouches]): * UIProcess/ios/WKTouchActionGestureRecognizer.h: Added. * UIProcess/ios/WKTouchActionGestureRecognizer.mm: Added. (-[WKTouchActionGestureRecognizer initWithTouchActionDelegate:]): (-[WKTouchActionGestureRecognizer setTouchActions:forTouchIdentifier:]): (-[WKTouchActionGestureRecognizer clearTouchActionsForTouchIdentifier:]): (-[WKTouchActionGestureRecognizer touchesBegan:withEvent:]): (-[WKTouchActionGestureRecognizer touchesMoved:withEvent:]): (-[WKTouchActionGestureRecognizer touchesEnded:withEvent:]): (-[WKTouchActionGestureRecognizer touchesCancelled:withEvent:]): (-[WKTouchActionGestureRecognizer _updateState]): (-[WKTouchActionGestureRecognizer canBePreventedByGestureRecognizer:]): (-[WKTouchActionGestureRecognizer canPreventGestureRecognizer:]): * WebKit.xcodeproj/project.pbxproj: 2019-07-06 Chris Fleizach <cfleizach@apple.com> AX: CrashTracer: com.apple.WebKit.WebContent at WebKit: WebKit::WebSpeechSynthesisClient::speak https://bugs.webkit.org/show_bug.cgi?id=199435 Reviewed by Ryosuke Niwa. Ensure we don't access null observers in speech callbacks. * WebProcess/WebCoreSupport/WebSpeechSynthesisClient.cpp: (WebKit::WebSpeechSynthesisClient::voiceList): (WebKit::WebSpeechSynthesisClient::speak): (WebKit::WebSpeechSynthesisClient::pause): (WebKit::WebSpeechSynthesisClient::resume): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::speakingErrorOccurred): (WebKit::WebPage::boundaryEventOccurred): (WebKit::WebPage::voicesDidChange): 2019-07-05 Chris Dumez <cdumez@apple.com> Fix thread safety bug in WebResourceLoadStatisticsTelemetry::calculateAndSubmit() https://bugs.webkit.org/show_bug.cgi?id=199536 Reviewed by Youenn Fablet. The resourceLoadStatisticsStore is an object that is created / used / destroyed on the background queue. It is therefore not safe to create a WeakPtr for it and use that WeakPtr on the main thread. * NetworkProcess/Classifier/WebResourceLoadStatisticsTelemetry.cpp: (WebKit::WebResourceLoadStatisticsTelemetry::calculateAndSubmit): 2019-07-05 Michael Catanzaro <mcatanzaro@igalia.com> Unreviewed, fix -Wswitch warning We don't support HTTPCookieAcceptPolicy::ExclusivelyFromMainDocumentDomain. Fun fact, soup's OnlyFromMainDocumentDomain functions the same as Apple's ExclusivelyFromMainDocumentDomain. These should be renamed.... * NetworkProcess/Cookies/soup/WebCookieManagerSoup.cpp: (WebKit::WebCookieManager::platformSetHTTPCookieAcceptPolicy): 2019-07-05 Dean Jackson <dino@apple.com> [iOS] Context Menu - Add to Reading List does nothing https://bugs.webkit.org/show_bug.cgi?id=199504 <rdar://problem/52554137> Reviewed by Anders Carlsson. We were holding weak references to the _WKElementAction in the handler provided to UIAction. By the time the handler was called, the object had been deallocated. * UIProcess/API/Cocoa/_WKElementAction.mm: (-[_WKElementAction uiActionForElementInfo:]): Use strong references in handler. 2019-07-05 Ryosuke Niwa <rniwa@webkit.org> [iOS] Crash in WebKit::WebPage::positionInformation via Range::startPosition https://bugs.webkit.org/show_bug.cgi?id=199503 Reviewed by Wenson Hsieh. The crash was caused because focusedElementPositionInformation asssumes Editor::compositionRange is not null whenever Editor::hasComposition returns true, which is not necessary the case when Editor::m_compositionNode contains no text (data is of length 0). Fixed the crash by adding an early return for when Editor::compositionRange returns nullptr. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::focusedElementPositionInformation): 2019-07-05 Zalan Bujtas <zalan@apple.com> [ContentChangeObserver] REGRESSION (r247015): facebook photo/video upload button is unresponsive to user interaction. https://bugs.webkit.org/show_bug.cgi?id=199502 <rdar://problem/52547473> Reviewed by Simon Fraser. Apparently it's a common practice to put transparent elements over visible click targets (button like divs) and use the invisible elements to catch the user input (e.g. Facebook's Photo/Video button). This patch modifies the original "do not trigger click on invisible targets" heuristic to a more restrictive "do not trigger click if the click target was previously hidden and became visible through touch start". If this still breaks some use cases, we could turn it into YouTube quirk. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::handleSyntheticClick): 2019-07-05 Ryan Haddad <ryanhaddad@apple.com> Unreviewed, rolling out r247123. Caused TestWebKitAPI.Challenge.BasicProposedCredential to fail. Reverted changeset: "Only allow fetching and removing session credentials from WebsiteDataStore" https://bugs.webkit.org/show_bug.cgi?id=199385 https://trac.webkit.org/changeset/247123 2019-07-05 Wenson Hsieh <wenson_hsieh@apple.com> Click events on outer page are not being dispatched correctly after touch-zooming within an iframe https://bugs.webkit.org/show_bug.cgi?id=185001 <rdar://problem/40569615> Reviewed by Simon Fraser. Mitigations introduced in r227759 prevent a touch inside a document of origin A to result in a click event being dispatched on an element inside a document of origin B. It accomplishes this by keeping track of the security origin of the last touch via m_potentialTapSecurityOrigin on WebPage. However, there exists a corner case in which m_potentialTapSecurityOrigin, set after touching a document in a subframe, may persist even after the user has finished interacting, causing taps in subsequent documents to not result in synthetic click events due to mismatched potential tap origins. This may happen if the first user gesture happens inside an element in a subframe with touch event handlers, but no click event handler (and the touch is additionally not over some clickable element). In this case, m_potentialTapNode is set to null in WebPage::potentialTapAtPosition, and when we consult it in WebPage::commitPotentialTap, we just end up calling commitPotentialTapFailed(); and return early. This means that m_potentialTapNode, m_potentialTapLocation, and (importantly) m_potentialTapSecurityOrigin are not reset. This causes subsequent taps in the top-level document to never dispatch click events, if the security origin does not match with that of the subframe. To fix this, we add a new async IPC message from the UI process to the web process to ensure that our current security origin is reset before attempting to handle a tap. Test: http/tests/events/touch/ios/click-after-handling-touch-in-cross-origin-frame.https.html * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::resetPotentialTapSecurityOrigin): Reset any stale potential tap security origin if needed. * UIProcess/WebPageProxy.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _webTouchEventsRecognized:]): Send the new IPC message when starting a touch. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::resetPotentialTapSecurityOrigin): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: 2019-07-05 Wenson Hsieh <wenson_hsieh@apple.com> Touching media controls sometimes shows software keyboard https://bugs.webkit.org/show_bug.cgi?id=199490 <rdar://problem/52076270> Reviewed by Eric Carlson. In r243044, we added a compatibility hack for Google Slides (and other G-suite properties) to allow the on- screen keyboard to show up after a prevented touch event in the case where an element was already focused, even if the touch event handler doesn't explicitly refocus the element. However, this means that if a regular text field (or other form control) has been programmatically focused, then interacting with any other element that prevents default on touchstart will cause us to show the keyboard for that focused element. To mitigate this, only fall down this refocusing codepath in the case where the focused element is a hidden editable element (in the style of many Google productivity web apps). For non-hidden editable elements that are already focused, this refocusing logic is not necessary, since the user should be able to interact with the control to show the keyboard anyways; for hidden editable areas, this compatibility hack is actually needed, since there is typically no other way for a user to focus these elements and show an on-screen keyboard. Tests: fast/events/touch/ios/show-keyboard-after-preventing-touchstart.html fast/events/touch/ios/do-not-show-keyboard-after-preventing-touchstart.html * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::dispatchTouchEvent): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::isTransparentOrFullyClipped const): Renamed from enclosingLayerIsTransparentOrFullyClipped, and pulled out into a private helper method. (WebKit::WebPage::platformEditorState const): (WebKit::WebPage::requestEvasionRectsAboveSelection): (WebKit::WebPage::getFocusedElementInformation): (WebKit::enclosingLayerIsTransparentOrFullyClipped): Deleted. 2019-07-04 Chris Dumez <cdumez@apple.com> Simplify logic that handles registering WebProcessProxy objects with their WebsiteDataStore https://bugs.webkit.org/show_bug.cgi?id=199412 <rdar://problem/51899751> Reviewed by Ryosuke Niwa. Simplify logic that handles registering WebProcessProxy objects with their WebsiteDataStore to make it more maintainable and less error-prone (avoid bugs like <rdar://problem/51899751>). The following changes were made: 1. The WebProcess now registers / unregisters itself directly with its WebsiteDataStore when needed, instead of having the WebPageProxy/ProvisionalPageProxy be in charge of calling the right WebProcessLifetimeTracker / WebProcessLifetimeObserver abstractions. 2. The WebProcessLifetimeTracker / WebProcessLifetimeObserver abstractions were dropped. The WebsiteDataStore was the only observer. 3. The WebProcessProxy is now registered with its WebsiteDataStore as soon as it has a page (provisional or not) instead of waiting until the process has finished launching. This simplifies the logic a lot and waiting until the process has launched is not needed by the WebsiteDataStore. * Sources.txt: * UIProcess/ProvisionalPageProxy.cpp: (WebKit::ProvisionalPageProxy::ProvisionalPageProxy): (WebKit::ProvisionalPageProxy::~ProvisionalPageProxy): * UIProcess/ProvisionalPageProxy.h: * UIProcess/WebPageProxy.cpp: (WebKit::m_resetRecentCrashCountTimer): (WebKit::WebPageProxy::finishAttachingToWebProcess): (WebKit::WebPageProxy::close): (WebKit::WebPageProxy::processDidTerminate): * UIProcess/WebPageProxy.h: * UIProcess/WebProcessCache.cpp: (WebKit::WebProcessCache::CachedProcess::CachedProcess): * UIProcess/WebProcessLifetimeObserver.cpp: Removed. * UIProcess/WebProcessLifetimeObserver.h: Removed. * UIProcess/WebProcessLifetimeTracker.cpp: Removed. * UIProcess/WebProcessLifetimeTracker.h: Removed. * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::setWebsiteDataStore): (WebKit::WebProcessProxy::updateRegistrationWithDataStore): (WebKit::WebProcessProxy::addProvisionalPageProxy): (WebKit::WebProcessProxy::removeProvisionalPageProxy): (WebKit::WebProcessProxy::connectionWillOpen): (WebKit::WebProcessProxy::processWillShutDown): (WebKit::WebProcessProxy::addExistingWebPage): (WebKit::WebProcessProxy::removeWebPage): * UIProcess/WebProcessProxy.h: * UIProcess/WebsiteData/WebsiteDataStore.cpp: (WebKit::WebsiteDataStore::registerProcess): (WebKit::WebsiteDataStore::unregisterProcess): (WebKit::WebsiteDataStore::processPoolForCookieStorageOperations): Drop change that was added in r246097 to work around the fact that WebProcessProxy objects were only registering themselves with their data store after their process had finished launching. (WebKit::WebsiteDataStore::fetchDataAndApply): (WebKit::WebsiteDataStore::removeData): (WebKit::WebsiteDataStore::processPools const): * UIProcess/WebsiteData/WebsiteDataStore.h: (WebKit::WebsiteDataStore::processes const): * WebKit.xcodeproj/project.pbxproj: 2019-07-04 Zalan Bujtas <zalan@apple.com> [ContentChangeObserver] Limit mouseOut dispatching after synthetic click to YouTube.com https://bugs.webkit.org/show_bug.cgi?id=199497 <rdar://problem/52361019> Reviewed by Wenson Hsieh. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::completeSyntheticClick): 2019-07-03 Ryosuke Niwa <rniwa@webkit.org> Crash in WebDragClient::startDrag because GraphicsContext is nullptr https://bugs.webkit.org/show_bug.cgi?id=199491 Reviewed by Wenson Hsieh. Added a nullptr check. Unfortunately no new tests since we don't have a reproducible test case. * WebProcess/WebCoreSupport/mac/WebDragClientMac.mm: (WebKit::convertImageToBitmap): 2019-07-03 Tim Horton <timothy_horton@apple.com> Data Detectors are not working for context menus in clients that use the legacy preview API https://bugs.webkit.org/show_bug.cgi?id=199486 <rdar://problem/52117322> Reviewed by Dean Jackson. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView assignLegacyDataForContextMenuInteraction]): The Data Detectors code in the legacy preview path is guarded by a #define that did not survive upstreaming. Remove it. 2019-07-03 Chris Dumez <cdumez@apple.com> StorageManager::suspend() sometimes fails to call its completion handler https://bugs.webkit.org/show_bug.cgi?id=199482 Reviewed by Youenn Fablet. Make sure the completion handler gets called in the early return cases. * NetworkProcess/WebStorage/StorageManager.cpp: (WebKit::StorageManager::suspend): 2019-07-03 Youenn Fablet <youenn@apple.com> Make CacheStorage::Engine directory listing operations in a background thread https://bugs.webkit.org/show_bug.cgi?id=199470 Reviewed by Chris Dumez. Use the io work queue to get the list of directories. Then go back to main thread and trigger clear/fetch operation as currently done. * NetworkProcess/cache/CacheStorageEngine.cpp: (WebKit::CacheStorage::ReadOriginsTaskCounter::create): (WebKit::CacheStorage::ReadOriginsTaskCounter::ReadOriginsTaskCounter): (WebKit::CacheStorage::Engine::getDirectories): (WebKit::CacheStorage::Engine::fetchEntries): (WebKit::CacheStorage::Engine::fetchDirectoryEntries): (WebKit::CacheStorage::Engine::clearCachesForOriginFromDisk): (WebKit::CacheStorage::Engine::clearCachesForOriginFromDirectories): * NetworkProcess/cache/CacheStorageEngine.h: 2019-07-03 Sihui Liu <sihui_liu@apple.com> Only allow fetching and removing session credentials from WebsiteDataStore https://bugs.webkit.org/show_bug.cgi?id=199385 Reviewed by Alex Christensen. Stop sending an extra message to network process for fetching or removing persistent credentials. * NetworkProcess/NetworkProcess.cpp: (WebKit::NetworkProcess::fetchWebsiteData): (WebKit::NetworkProcess::deleteWebsiteData): (WebKit::NetworkProcess::deleteWebsiteDataForOrigins): (WebKit::NetworkProcess::deleteWebsiteDataForRegistrableDomains): (WebKit::NetworkProcess::originsWithPersistentCredentials): Deleted. (WebKit::NetworkProcess::removeCredentialsWithOrigins): Deleted. * NetworkProcess/NetworkProcess.h: * NetworkProcess/NetworkProcess.messages.in: * NetworkProcess/cocoa/NetworkProcessCocoa.mm: (WebKit::NetworkProcess::originsWithPersistentCredentials): Deleted. (WebKit::NetworkProcess::removeCredentialsWithOrigins): Deleted. * UIProcess/WebsiteData/WebsiteDataStore.cpp: (WebKit::WebsiteDataStore::fetchDataAndApply): (WebKit::computeWebProcessAccessTypeForDataRemoval): (WebKit::WebsiteDataStore::removeData): 2019-07-03 Tim Horton <timothy_horton@apple.com> UI process exception when dragging an <attachment> with no content type https://bugs.webkit.org/show_bug.cgi?id=199480 <rdar://problem/44351353> Reviewed by Wenson Hsieh. * UIProcess/API/Cocoa/APIAttachmentCocoa.mm: (API::Attachment::mimeType const): (API::Attachment::utiType const): * UIProcess/Cocoa/WebViewImpl.mm: (WebKit::WebViewImpl::startDrag): Make null or empty contentType fail the drag, instead of crashing. 2019-07-03 Chris Dumez <cdumez@apple.com> Clarify threading model for WebResourceLoadStatisticsStore::dumpResourceLoadStatistics() https://bugs.webkit.org/show_bug.cgi?id=199468 Reviewed by Youenn Fablet. Our convention is that the WebResourceLoadStatisticsStore is always created, used and destroyed on the main thread, while the ResourceLoadStatisticsStore is always created, used and destroyed on the background queue. r245517 broke this convention by introducing a tryDumpResourceLoadStatistics() method to WebResourceLoadStatisticsStore which gets called on the background queue. This patch fixes this since this has been a huge source of thread-safety bugs in the past. * NetworkProcess/Classifier/ResourceLoadStatisticsDatabaseStore.cpp: (WebKit::ResourceLoadStatisticsDatabaseStore::dumpResourceLoadStatistics): * NetworkProcess/Classifier/ResourceLoadStatisticsDatabaseStore.h: * NetworkProcess/Classifier/ResourceLoadStatisticsMemoryStore.cpp: (WebKit::ResourceLoadStatisticsMemoryStore::dumpResourceLoadStatistics): * NetworkProcess/Classifier/ResourceLoadStatisticsMemoryStore.h: * NetworkProcess/Classifier/ResourceLoadStatisticsStore.cpp: (WebKit::ResourceLoadStatisticsStore::removeDataRecords): * NetworkProcess/Classifier/ResourceLoadStatisticsStore.h: (WebKit::ResourceLoadStatisticsStore::dataRecordsBeingRemoved const): * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp: (WebKit::WebResourceLoadStatisticsStore::dumpResourceLoadStatistics): * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.h: 2019-07-03 Jonathan Bedard <jbedard@apple.com> [Catalina] Enable WebKit build https://bugs.webkit.org/show_bug.cgi?id=199209 Reviewed by Darin Adler. * UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.h: AppSSO is SPI. * WebKit2Prefix.h: SecTask.h declares SecTaskGetCodeSignStatus(...) unavailable on Mac, exclude this header. 2019-07-03 Daniel Bates <dabates@apple.com> REGRESSION (r246817): fast/events/ios/key-events-comprehensive/key-events-{control, control-shift}.html are failing https://bugs.webkit.org/show_bug.cgi?id=199465 <rdar://problem/52613496> Reviewed by Wenson Hsieh. Don't advertise that WebKit can perform cursor movements when there isn't some kind of selection. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView canPerformAction:withSender:]): 2019-07-03 Chris Dumez <cdumez@apple.com> Fix a couple of thread safety issues in ResourceLoadStatisticsStore https://bugs.webkit.org/show_bug.cgi?id=199463 Reviewed by Alex Christensen. The ResourceLoadStatisticsStore object is constructed / used / destroyed on a background queue. It is therefore not safe to use a WeakPtr to the ResourceLoadStatisticsStore on the main thread. The safe pattern is to have the ResourceLoadStatisticsStore capture a Ref<> of its m_store before dispatching to the main thread and use this store on the main thread instead of weakThis->m_store. ResourceLoadStatisticsStore's m_store is constructed / used / destroyed on the main thread. * NetworkProcess/Classifier/ResourceLoadStatisticsStore.cpp: (WebKit::ResourceLoadStatisticsStore::removeDataRecords): (WebKit::ResourceLoadStatisticsStore::processStatisticsAndDataRecords): 2019-07-03 Youenn Fablet <youenn@apple.com> Isolate CacheStorage::Engine path when hopping to a background thread https://bugs.webkit.org/show_bug.cgi?id=199461 Reviewed by Chris Dumez. * NetworkProcess/cache/CacheStorageEngine.cpp: (WebKit::CacheStorage::Engine::initialize): 2019-07-03 Jer Noble <jer.noble@apple.com> Unreviewed, rolling out r246053. This changeset caused media playback to break when the hosting app was backgrounded. * UIProcess/ApplicationStateTracker.mm: * UIProcess/ios/ProcessAssertionIOS.mm: (-[WKProcessAssertionBackgroundTaskManager init]): (-[WKProcessAssertionBackgroundTaskManager _scheduleReleaseTask]): (-[WKProcessAssertionBackgroundTaskManager _cancelPendingReleaseTask]): (-[WKProcessAssertionBackgroundTaskManager _updateBackgroundTask]): (-[WKProcessAssertionBackgroundTaskManager _releaseBackgroundTask]): 2019-07-03 Alex Christensen <achristensen@webkit.org> Use smarter pointers in WKDownloadProgress https://bugs.webkit.org/show_bug.cgi?id=199456 <rdar://problem/51392926> Reviewed by Chris Dumez. There's still a problem related to our use of raw pointers. Let's just not use raw pointers. * NetworkProcess/Downloads/Download.h: * NetworkProcess/Downloads/cocoa/DownloadCocoa.mm: (WebKit::Download::publishProgress): * NetworkProcess/Downloads/cocoa/WKDownloadProgress.h: * NetworkProcess/Downloads/cocoa/WKDownloadProgress.mm: (-[WKDownloadProgress performCancel]): (-[WKDownloadProgress initWithDownloadTask:download:URL:sandboxExtension:]): (-[WKDownloadProgress progressCancelled]): Deleted. 2019-07-03 Sam Weinig <weinig@apple.com> Adopt simple structured bindings in more places https://bugs.webkit.org/show_bug.cgi?id=199247 Reviewed by Alex Christensen. Replaces simple uses of std::tie() with structured bindings. Does not touch uses of std::tie() that are not initial declarations, use std::ignore or in case where the binding is captured by a lambda, as structured bindings don't work for those cases yet. * NetworkProcess/cache/NetworkCacheSpeculativeLoadManager.cpp: (WebKit::NetworkCache::printSpeculativeLoadingDiagnosticMessageCounts): * NetworkProcess/cache/PrefetchCache.cpp: (WebKit::PrefetchCache::clearExpiredEntries): * Platform/IPC/MessageReceiverMap.cpp: (IPC::MessageReceiverMap::removeMessageReceiver): * UIProcess/Cocoa/PlaybackSessionManagerProxy.mm: (WebKit::PlaybackSessionManagerProxy::invalidate): * UIProcess/Cocoa/VideoFullscreenManagerProxy.mm: (WebKit::VideoFullscreenManagerProxy::invalidate): (WebKit::VideoFullscreenManagerProxy::requestHideAndExitFullscreen): (WebKit::VideoFullscreenManagerProxy::hasMode const): (WebKit::VideoFullscreenManagerProxy::mayAutomaticallyShowVideoPictureInPicture const): (WebKit::VideoFullscreenManagerProxy::isPlayingVideoInEnhancedFullscreen const): (WebKit::VideoFullscreenManagerProxy::applicationDidBecomeActive): (WebKit::VideoFullscreenManagerProxy::setupFullscreenWithID): (WebKit::VideoFullscreenManagerProxy::didCleanupFullscreen): * UIProcess/ios/SmartMagnificationController.mm: (WebKit::SmartMagnificationController::zoomFactorForTargetRect): (WebKit::SmartMagnificationController::didCollectGeometryForSmartMagnificationGesture): (WebKit::SmartMagnificationController::magnify): * WebProcess/Plugins/PDF/PDFPlugin.mm: (WebKit:: const): * WebProcess/WebPage/Cocoa/WebPageCocoa.mm: (WebKit::WebPage::performDictionaryLookupAtLocation): (WebKit::WebPage::performDictionaryLookupForSelection): * WebProcess/cocoa/PlaybackSessionManager.mm: (WebKit::PlaybackSessionManager::~PlaybackSessionManager): (WebKit::PlaybackSessionManager::removeContext): * WebProcess/cocoa/VideoFullscreenManager.mm: (WebKit::VideoFullscreenManager::~VideoFullscreenManager): (WebKit::VideoFullscreenManager::removeContext): (WebKit::VideoFullscreenManager::enterVideoFullscreenForVideoElement): (WebKit::VideoFullscreenManager::requestVideoContentLayer): (WebKit::VideoFullscreenManager::didSetupFullscreen): (WebKit::VideoFullscreenManager::willExitFullscreen): (WebKit::VideoFullscreenManager::didEnterFullscreen): (WebKit::VideoFullscreenManager::didCleanupFullscreen): (WebKit::VideoFullscreenManager::setVideoLayerFrameFenced): 2019-07-03 Zalan Bujtas <zalan@apple.com> [ContentChangeObserver] REGRESSION (r244356): Drop down menus collapse without user input - Ebay.com https://bugs.webkit.org/show_bug.cgi?id=199457 <rdar://problem/52386563> Reviewed by Simon Fraser. There's a fixed, 32ms window for observing content changes after the tap is committed. r244356 introduced the fast-click behavior on form elements by omitting this fixed window and dispatch the synthetic click on the target node. This patch preserves the fast-click behavior, but now we stay at hover if the mouseMove event triggers a synchronous actionable visiblity change (as opposed to always proceed with click). * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::handleSyntheticClick): 2019-07-03 Patrick Griffis <pgriffis@igalia.com> [GTK][WPE] Remove Flatpak sandbox https://bugs.webkit.org/show_bug.cgi?id=199416 Reviewed by Michael Catanzaro. The flatpak-spawn based sandbox was only a proof of concept and lacks flexibility for our needs so we ended up using it with very permissive permissions and it still imposed limitations that our main bubblewrap sandbox didn't have. So in order to get as many applications using the sandbox as possible we will just remove this for now and focus on bubblewrap. At some point it may be possible to improve flatpak-spawn to fit our needs. * SourcesGTK.txt: * SourcesWPE.txt: * UIProcess/Launcher/glib/FlatpakLauncher.cpp: Removed. * UIProcess/Launcher/glib/FlatpakLauncher.h: Removed. * UIProcess/Launcher/glib/ProcessLauncherGLib.cpp: (WebKit::ProcessLauncher::launchProcess): 2019-07-03 Ryan Haddad <ryanhaddad@apple.com> Unreviewed, rolling out r246616. Caused http/tests/inspector/network/har/har-page.html to fail on Catalina. Reverted changeset: "Web Inspector: Network: replace CFNetwork SPI with new API where able" https://bugs.webkit.org/show_bug.cgi?id=198762 https://trac.webkit.org/changeset/246616 2019-07-03 Chris Dumez <cdumez@apple.com> Crash under WTF::RefCounted<WebKit::TaskCounter>::deref() https://bugs.webkit.org/show_bug.cgi?id=199453 <rdar://problem/51991477> Reviewed by Youenn Fablet. The crash was caused by StorageManager::suspend() getting called on the main thread but calling its completion handler on a background queue. The completion handler was capturing a TaskCounter object which is RefCounted (not ThreadSafeRefCounted). Address the issue by making sure StorageManager::suspend() calls its completion handler on the main thread. Also get rid of TaskCounter and use a WTF::CallbackAggregator instead. * NetworkProcess/NetworkProcess.cpp: (WebKit::NetworkProcess::actualPrepareToSuspend): (WebKit::TaskCounter::TaskCounter): Deleted. (WebKit::TaskCounter::~TaskCounter): Deleted. * NetworkProcess/WebStorage/StorageManager.cpp: (WebKit::StorageManager::suspend): 2019-07-03 Youenn Fablet <youenn@apple.com> Make sure to cross-thread copy in StorageManager when hopping back to the main thread https://bugs.webkit.org/show_bug.cgi?id=199423 Reviewed by Chris Dumez. Make sure to isolate copy some strings that may not be isolated in case of ephemeral sessions. Small refactoring to use crossThreadCopy instead of doing vector copy ourselves. * NetworkProcess/WebStorage/LocalStorageDatabaseTracker.h: (WebKit::LocalStorageDatabaseTracker::OriginDetails::isolatedCopy const): * NetworkProcess/WebStorage/StorageManager.cpp: (WebKit::StorageManager::deleteSessionStorageEntriesForOrigins): (WebKit::StorageManager::getLocalStorageOrigins): (WebKit::StorageManager::getLocalStorageOriginDetails): (WebKit::StorageManager::deleteLocalStorageEntriesForOrigins): 2019-07-02 Joonghun Park <jh718.park@samsung.com> Unreviewed. Fix build break introduced in r247058. * UIProcess/API/gtk/WebKitRemoteInspectorProtocolHandler.cpp: 2019-07-02 Youenn Fablet <youenn@apple.com> StorageManager does not need to be a WorkQueueMessageReceiver anymore https://bugs.webkit.org/show_bug.cgi?id=199421 Reviewed by Chris Dumez. * NetworkProcess/WebStorage/StorageManager.h: 2019-07-02 Chris Dumez <cdumez@apple.com> ThreadSafeRefCounted<DestructionThread::Main> is not safe to use in the UIProcess https://bugs.webkit.org/show_bug.cgi?id=199420 <rdar://problem/52289717> Reviewed by Ryosuke Niwa. Update IPC::Connection and DeviceIdHashSaltStorage to use DestructionThread::MainRunLoop instead of DestructionThread::Main, since both classes are used in the UIProcess. Using DestructionThread::Main is not safe in the UIProcess because its implementation relies on isMainThread() / callOnMainThread(). Those get confused about which thread is the main thread when an application uses both WK1 and WK2. * Platform/IPC/Connection.h: * UIProcess/DeviceIdHashSaltStorage.h: 2019-07-02 Patrick Griffis <pgriffis@igalia.com> [GTK][WPE] Explicitly blacklist problematic directories for sandbox https://bugs.webkit.org/show_bug.cgi?id=199367 Reviewed by Michael Catanzaro. There are some directories that simply do not make sense to bind into the sandbox and will only cause issues such as `/proc` so lets just block them. * UIProcess/API/glib/WebKitWebContext.cpp: (path_is_not_blacklisted): (webkit_web_context_add_path_to_sandbox): 2019-07-02 Tim Horton <timothy_horton@apple.com> REGRESSION (r243240): Unable to swipe back in Safari https://bugs.webkit.org/show_bug.cgi?id=199394 <rdar://problem/51137447> Reviewed by Wenson Hsieh. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _processDidExit]): r243240 started nilling out the ViewGestureController, but we don't actually expect that; the only time WKWebView's ViewGestureController goes away is if the client turns off the gestures... and so nothing ever puts it back. Instead, just always disconnect, don't nil it out. 2019-07-02 Chris Dumez <cdumez@apple.com> Protect NetworkProcess::m_networkSessions against corruption https://bugs.webkit.org/show_bug.cgi?id=199418 <rdar://problem/50614019> Reviewed by Youenn Fablet. I believe the most likely reason for the crash at <rdar://problem/50614019> is that NetworkProcess::m_networkSessions is getting corrupted and is returning us a bad pointer. To harden our code, I added debug assertions to make sure that this HashMap is only used on the main thread and to make sure that the sessionID used as key is always valid. I have also added if checks to avoid crashing in release whenever possible. Note that we came to a similar conclusion for NetworkProcess::m_swServers when investigating rdar://problem/51859081, so the two radars are potentially related. Both HashMaps are owned by the NetworkProcess and use a SessionID as key. * NetworkProcess/NetworkConnectionToWebProcess.cpp: (WebKit::NetworkConnectionToWebProcess::cookiesForDOM): (WebKit::NetworkConnectionToWebProcess::setCookiesFromDOM): (WebKit::NetworkConnectionToWebProcess::logUserInteraction): (WebKit::NetworkConnectionToWebProcess::logWebSocketLoading): (WebKit::NetworkConnectionToWebProcess::logSubresourceLoading): (WebKit::NetworkConnectionToWebProcess::logSubresourceRedirect): (WebKit::NetworkConnectionToWebProcess::hasStorageAccess): (WebKit::NetworkConnectionToWebProcess::requestStorageAccess): (WebKit::NetworkConnectionToWebProcess::requestStorageAccessUnderOpener): * NetworkProcess/NetworkProcess.cpp: (WebKit::NetworkProcess::networkSession const): (WebKit::NetworkProcess::setSession): (WebKit::NetworkProcess::destroySession): (WebKit::NetworkProcess::addKeptAliveLoad): (WebKit::NetworkProcess::removeKeptAliveLoad): (WebKit::NetworkProcess::webProcessWasDisconnected): * NetworkProcess/NetworkProcess.h: * NetworkProcess/NetworkResourceLoader.cpp: (WebKit::NetworkResourceLoader::retrieveCacheEntry): (WebKit::NetworkResourceLoader::didFinishWithRedirectResponse): (WebKit::NetworkResourceLoader::tryStoreAsCacheEntry): (WebKit::NetworkResourceLoader::shouldLogCookieInformation): * NetworkProcess/ios/NetworkConnectionToWebProcessIOS.mm: (WebKit::NetworkConnectionToWebProcess::paymentCoordinatorBoundInterfaceIdentifier): (WebKit::NetworkConnectionToWebProcess::paymentCoordinatorCTDataConnectionServiceType): (WebKit::NetworkConnectionToWebProcess::paymentCoordinatorSourceApplicationBundleIdentifier): (WebKit::NetworkConnectionToWebProcess::paymentCoordinatorSourceApplicationSecondaryIdentifier): 2019-07-02 Chris Dumez <cdumez@apple.com> VisitedLinkStore does not need to subclass WebProcessLifetimeObserver https://bugs.webkit.org/show_bug.cgi?id=199407 Reviewed by Sam Weinig. VisitedLinkStore does not need to subclass WebProcessLifetimeObserver, it overrides only 2 of WebProcessLifetimeObserver's functions and the implementation of those overrides is empty. It also does not use WebProcessLifetimeObserver::processes() since the VisitedLinkStore maintains its own list of processes. * UIProcess/API/mac/WKView.mm: * UIProcess/Automation/WebAutomationSession.cpp: * UIProcess/VisitedLinkStore.cpp: * UIProcess/VisitedLinkStore.h: * UIProcess/WebPageProxy.cpp: (WebKit::m_resetRecentCrashCountTimer): * UIProcess/WebProcessPool.h: * UIProcess/WebsiteData/WebsiteDataStore.cpp: 2019-07-02 Chris Dumez <cdumez@apple.com> Null dereference under StorageManager::destroySessionStorageNamespace() https://bugs.webkit.org/show_bug.cgi?id=199388 <rdar://problem/52030641> Reviewed by Youenn Fablet. * NetworkProcess/WebStorage/StorageManager.cpp: (WebKit::StorageManager::createSessionStorageNamespace): Call HashMap::ensure() instead of contains() + set() to avoid double hash lookup. (WebKit::StorageManager::destroySessionStorageNamespace): Add null check to address top crasher, similarly to what was done in r246552. I am keeping the debug assertion since this is not supposed to happen. 2019-07-02 Daniel Bates <dabates@apple.com> [iOS] Cannot tab cycle through credit card fields on antonsvpatisserie.com checkout page https://bugs.webkit.org/show_bug.cgi?id=196053 <rdar://problem/49093034> Reviewed by Wenson Hsieh. Allow iframes to be keyboard focusable when pressing the Tab key on the keyboard. This also allow the that the focus controller to search their content document for other editable elements. This makes iOS match the behavior on Mac. Although iframes can be focused by pressing the Tab key we maintain the current UI restriction on iOS of not allowing iframes themselves to be focusable via the next and previous accessory bar buttons. We do this because it's unclear what value supporting such focusing brings, but it's clear that doing so makes tab cycling more confusing since the default focus appearance for an iframe is indistinguishable from its non- focused appearance. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::isAssistableElement): Do not consider an iframe as assistable. 2019-07-02 Alexander Mikhaylenko <exalm7659@gmail.com> [GTK] Support cancelling touchscreen back/forward gesture https://bugs.webkit.org/show_bug.cgi?id=199401 Reviewed by Michael Catanzaro. It should be possible to cancel the gesture when performing it on touchscreen, for example, by moving pen too far from the screen. Handle this case properly. Only DragGesture in GestureController needs to handle this, SwipeGesture simply won't emit the relevant event in this case. * UIProcess/API/gtk/WebKitWebViewBase.cpp: * UIProcess/ViewGestureController.h: * UIProcess/gtk/GestureController.cpp: (WebKit::GestureController::DragGesture::cancelDrag): (WebKit::GestureController::DragGesture::cancel): (WebKit::GestureController::DragGesture::DragGesture): * UIProcess/gtk/GestureController.h: * UIProcess/gtk/ViewGestureControllerGtk.cpp: (WebKit::ViewGestureController::platformTeardown): (WebKit::ViewGestureController::cancelSwipe): 2019-07-02 Devin Rousso <drousso@apple.com> Web Inspector: Debug: "Reset Web Inspector" should also clear the saved window size and attachment side https://bugs.webkit.org/show_bug.cgi?id=198956 Reviewed by Matt Baker. * UIProcess/WebPreferences.h: * UIProcess/WebPreferences.cpp: (WebKit::WebPreferences::deleteKey): Added. * UIProcess/gtk/WebPreferencesGtk.cpp: (WebKit::WebPreferences::platformDeleteKey): Added. * UIProcess/mac/WebPreferencesMac.mm: (WebKit::WebPreferences::platformDeleteKey): Added. * UIProcess/wpe/WebPreferencesWPE.cpp: (WebKit::WebPreferences::platformDeleteKey): Added. * UIProcess/win/WebPreferencesWin.cpp: (WebKit::WebPreferences::platformDeleteKey): Added. * Shared/WebPreferencesStore.h: * Shared/WebPreferencesStore.cpp: (WebKit::WebPreferencesStore::deleteKey): Added. * UIProcess/WebInspectorProxy.messages.in: * UIProcess/WebInspectorProxy.h: * UIProcess/WebInspectorProxy.cpp: (WebKit::WebInspectorProxy::resetWindowState): Added. (WebKit::WebInspectorProxy::platformResetWindowState): Added. * UIProcess/gtk/WebInspectorProxyGtk.cpp: (WebKit::WebInspectorProxy::platformResetWindowState): Added. * UIProcess/mac/WebInspectorProxyMac.mm: (WebKit::WebInspectorProxy::platformResetWindowState): Added. * UIProcess/wpe/WebInspectorProxyWPE.cpp: (WebKit::WebInspectorProxy::platformResetWindowState): Added. * UIProcess/win/WebInspectorProxyWin.cpp: (WebKit::WebInspectorProxy::platformResetWindowState): Added. * WebProcess/WebPage/WebInspectorUI.h: * WebProcess/WebPage/WebInspectorUI.cpp: (WebKit::WebInspectorUI::resetWindowState): Added. * UIProcess/RemoteWebInspectorProxy.messages.in: * UIProcess/RemoteWebInspectorProxy.h: * UIProcess/RemoteWebInspectorProxy.cpp: (WebKit::RemoteWebInspectorProxy::resetWindowState): Added. (WebKit::RemoteWebInspectorProxy::platformResetWindowState): Added. * UIProcess/gtk/RemoteWebInspectorProxyGtk.cpp: (WebKit::RemoteWebInspectorProxy::platformResetWindowState): Added. * UIProcess/mac/RemoteWebInspectorProxyMac.mm: (WebKit::RemoteWebInspectorProxy::platformResetWindowState): Added. * UIProcess/win/RemoteWebInspectorProxyWin.cpp: (WebKit::RemoteWebInspectorProxy::platformResetWindowState): Added. * WebProcess/WebPage/RemoteWebInspectorUI.h: * WebProcess/WebPage/RemoteWebInspectorUI.cpp: (WebKit::RemoteWebInspectorUI::resetWindowState): Added. 2019-07-01 Chris Dumez <cdumez@apple.com> Remove virtual functions on WebProcessLifetimeObserver that are unused after r245540 https://bugs.webkit.org/show_bug.cgi?id=199383 Reviewed by Alex Christensen. * UIProcess/WebProcessLifetimeObserver.h: (WebKit::WebProcessLifetimeObserver::webProcessDidCloseConnection): * UIProcess/WebProcessLifetimeTracker.cpp: (WebKit::WebProcessLifetimeTracker::addObserver): (WebKit::WebProcessLifetimeTracker::pageWasInvalidated): 2019-07-01 Chris Dumez <cdumez@apple.com> StorageManager::SessionStorageNamespace::allowedConnections() should not copy the HashSet https://bugs.webkit.org/show_bug.cgi?id=199379 Reviewed by Alex Christensen. This was pretty inefficient. * NetworkProcess/WebStorage/StorageManager.cpp: (WebKit::StorageManager::SessionStorageNamespace::allowedConnections const): 2019-07-01 Wenson Hsieh <wenson_hsieh@apple.com> [iOS] REGRESSION (r246757): Unable to select non-editable text in subframes https://bugs.webkit.org/show_bug.cgi?id=199366 <rdar://problem/52460509> Reviewed by Tim Horton. r246757 removed logic in selectionPositionInformation responsible for setting the focused frame when handling a position information request. As the FIXME formerly in InteractionInformationRequest.h alluded to, text selection gestures on iOS were dependent on this behavior when selecting text in subframes, since text selection helpers in WebPageIOS.mm assume that the focused frame already contains the selection being set. Rather than calling setFocusedFrame when requesting position information, we can fix this by making WebPage::selectWithGesture and WebPage::selectTextWithGranularityAtPoint both set the focused frame if needed before extending or moving text selections. Covered by layout tests that began to fail after r246757: - editing/selection/ios/selection-handles-in-iframe.html - editing/selection/ios/selection-handle-clamping-in-iframe.html * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::selectWithGesture): Only call the new helper method, setFocusedFrameBeforeSelectingTextAtLocation, at the start of the gesture. (WebKit::WebPage::setFocusedFrameBeforeSelectingTextAtLocation): (WebKit::WebPage::selectTextWithGranularityAtPoint): 2019-07-01 Alex Christensen <achristensen@webkit.org> Add new decidePolicyForNavigationAction SPI with preferences and userInfo https://bugs.webkit.org/show_bug.cgi?id=199371 <rdar://problem/52352905> Reviewed by Tim Horton. Also deprecate some older SPI so we may someday clean up this mess. * UIProcess/API/Cocoa/WKNavigationDelegatePrivate.h: * UIProcess/Cocoa/NavigationState.h: * UIProcess/Cocoa/NavigationState.mm: (WebKit::NavigationState::setNavigationDelegate): (WebKit::NavigationState::NavigationClient::decidePolicyForNavigationAction): (WebKit::NavigationState::NavigationClient::shouldBypassContentModeSafeguards const): 2019-07-01 Alex Christensen <achristensen@webkit.org> Deprecate but still call _webView:showCustomSheetForElement: after transition to UIContextMenuInteraction https://bugs.webkit.org/show_bug.cgi?id=199296 <rdar://problem/51041960> Reviewed by Darin Adler. * UIProcess/API/Cocoa/WKUIDelegatePrivate.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _showAttachmentSheet]): (-[WKContentView actionSheetAssistant:showCustomSheetForElement:]): (-[WKContentView continueContextMenuInteraction:]): 2019-07-01 Alex Christensen <achristensen@webkit.org> Add main thread assertions in sendWithAsyncReply code https://bugs.webkit.org/show_bug.cgi?id=199324 Reviewed by Sam Weinig. sendWithAsyncReply can only be used on the main thread because the CompletionHandler will be called on the main thread, and if it's called from a background thread, then HashMap corruption will likely happen. Add assertions to alert developers that they should only call sendWithAsyncReply from the main thread. This is responding to good feedback from r237294 * Platform/IPC/Connection.cpp: (IPC::asyncReplyHandlerMap): (IPC::nextAsyncReplyHandlerID): (IPC::addAsyncReplyHandler): (IPC::clearAsyncReplyHandlers): (IPC::CompletionHandler<void): 2019-07-01 Eric Carlson <eric.carlson@apple.com> [iOS] Exiting from fullscreen scrolls to top of page https://bugs.webkit.org/show_bug.cgi?id=199338 <rdar://problem/51273017> Reviewed by Jer Noble. * UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm: (-[WKFullScreenWindowController _completedExitFullScreen]): Restore scroll position. Hide window after restoring scroll position. (-[WKFullScreenWindowController _exitFullscreenImmediately]): Drive-by fix: remove code already also done in _completedExitFullScreen. 2019-07-01 Zalan Bujtas <zalan@apple.com> Tapping on the bottom part of youtube video behaves as if controls were visible https://bugs.webkit.org/show_bug.cgi?id=199349 <rdar://problem/51955744> Reviewed by Simon Fraser. * WebProcess/WebPage/WebPage.cpp: (WebKit::handleTouchEvent): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::handleSyntheticClick): (WebKit::WebPage::completePendingSyntheticClickForContentChangeObserver): (WebKit::WebPage::completeSyntheticClick): (WebKit::WebPage::potentialTapAtPosition): 2019-07-01 Wenson Hsieh <wenson_hsieh@apple.com> iOS: REGRESSION(async scroll): Caret doesn't scroll when scrolling textarea https://bugs.webkit.org/show_bug.cgi?id=198217 <rdar://problem/51097296> Reviewed by Simon Fraser. In iOS 12, when scrolling a text selection in an fast-scrolling container, editor state updates are scheduled under AsyncScrollingCoordinator::updateScrollPositionAfterAsyncScroll after the end of the scrolling gesture, when the scrolling layer action is ScrollingLayerPositionAction::Set. This is no longer the case in iOS 13, because we now bail in ScrollingTreeScrollingNode::wasScrolledByDelegatedScrolling after scroll deceleration finishes since the scroll position didn't end up changing. Additionally, we no longer use ScrollingLayerPositionAction::Set in the case where scrolling finished decelerating, since ScrollingTreeScrollingNodeDelegateIOS::scrollViewDidScroll no longer uses to value of inUserInteraction to determine whether to Set or Sync scrolling layer positions. To restore iOS 12 behavior, ensure that we send a scrolling tree update using ScrollingLayerPositionAction::Set after scrolling ends. * UIProcess/RemoteLayerTree/ios/ScrollingTreeScrollingNodeDelegateIOS.mm: (WebKit::ScrollingTreeScrollingNodeDelegateIOS::scrollViewDidScroll): 2019-07-01 Per Arne Vollan <pvollan@apple.com> Perform less work when a pre-warmed WebProcess is suspended or resumed. https://bugs.webkit.org/show_bug.cgi?id=199195 Reviewed by Darin Adler. Return early from WebProcess::actualPrepareToSuspend and WebProcess::processDidResume if this is a pre-warmed process. This is a confirmed improvement in page load time. * WebProcess/WebProcess.cpp: (WebKit::WebProcess::actualPrepareToSuspend): (WebKit::WebProcess::cancelPrepareToSuspend): (WebKit::WebProcess::processDidResume): 2019-07-01 Carlos Garcia Campos <cgarcia@igalia.com> WebSockets: add support for sending blob messages when using web sockets platform APIs https://bugs.webkit.org/show_bug.cgi?id=199189 Reviewed by Youenn Fablet. Add helper private class BlobLoader that uses FileReaderLoader to load the blobs. Since blob loads are asynchronous, the messages are queued using another helper internal class PendingMessage. * WebProcess/Network/WebSocketChannel.cpp: (WebKit::WebSocketChannel::increaseBufferedAmount): Increase the buffered amount checking we don't overlofw. (WebKit::WebSocketChannel::decreaseBufferedAmount): Decrease the buffered amount. (WebKit::WebSocketChannel::sendMessage): Helper class to send message to the network process and decrease the buffered amount when done. (WebKit::WebSocketChannel::send): Queue the message in pending queue if there are pending messages in the queue for text and binary messages. For blobs, always queue the message unless it's an empty blob that we can handle as empty binary data directly. (WebKit::PendingMessage::PendingMessage): Helper class to queue message requests. (WebKit::PendingMessage::type const): Type of message: Text, Binary, Blob. (WebKit::PendingMessage::textMessage const): The text message. (WebKit::PendingMessage::binaryData const): The binary data. (WebKit::PendingMessage::blobLoader const): The blob loader. (WebKit::WebSocketChannel::fail): Notify the client about the error to ensure onclose is emitted. (WebKit::WebSocketChannel::disconnect): Clear the pending messages queue. * WebProcess/Network/WebSocketChannel.h: 2019-07-01 Miguel Gomez <magomez@igalia.com> [WPE][GTK] Content disappearing when using CSS transforms https://bugs.webkit.org/show_bug.cgi?id=181757 Reviewed by Žan Doberšek. Set the appropriate AnimatedBackingStoreClient to the TextureMapperLayers when required. * Shared/CoordinatedGraphics/CoordinatedGraphicsScene.cpp: (WebKit::CoordinatedGraphicsScene::updateSceneState): 2019-06-30 Antti Koivisto <antti@apple.com> Use separate variables for moving and stationary scrolling relationships in RemoteLayerTreeNode https://bugs.webkit.org/show_bug.cgi?id=199348 Reviewed by Darin Adler. A layer can have only one acting scroll parent. Not using a vector for that case makes the code clearer. * UIProcess/RemoteLayerTree/RemoteLayerTreeNode.h: (WebKit::RemoteLayerTreeNode::actingScrollContainerID const): (WebKit::RemoteLayerTreeNode::stationaryScrollContainerIDs const): Separate fields for the acting container and stationary containers. (WebKit::RemoteLayerTreeNode::setActingScrollContainerID): (WebKit::RemoteLayerTreeNode::setStationaryScrollContainerIDs): (WebKit::RemoteLayerTreeNode::relatedScrollContainerIDs const): Deleted. (WebKit::RemoteLayerTreeNode::relatedScrollContainerPositioningBehavior const): Deleted. * UIProcess/RemoteLayerTree/RemoteLayerTreeNode.mm: (WebKit::RemoteLayerTreeNode::setRelatedScrollContainerBehaviorAndIDs): Deleted. * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm: (WebKit::isScrolledBy): (WebKit::findActingScrollParent): * UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.mm: (WebKit::RemoteScrollingCoordinatorProxy::establishLayerTreeScrollingRelations): 2019-06-30 Fujii Hironori <Hironori.Fujii@sony.com> [Win] Multiline mode of tooltip control does word-wrapping very slowly https://bugs.webkit.org/show_bug.cgi?id=198989 Reviewed by Ross Kirsling. * UIProcess/win/WebView.cpp: (WebKit::truncatedString): Added. (WebKit::WebView::setToolTip): Use truncatedString. 2019-06-30 Basuke Suzuki <Basuke.Suzuki@sony.com> Pass WebProcess information to platformInitializeWebProcess(). https://bugs.webkit.org/show_bug.cgi?id=199345 Reviewed by Darin Adler. Add const reference to WebProcessProxy for first argument of WebProcessPool::platformInitializeWebProcess(). * UIProcess/Cocoa/WebProcessPoolCocoa.mm: (WebKit::WebProcessPool::platformInitializeWebProcess): * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::initializeNewWebProcess): * UIProcess/WebProcessPool.h: * UIProcess/glib/WebProcessPoolGLib.cpp: (WebKit::WebProcessPool::platformInitializeWebProcess): * UIProcess/win/WebProcessPoolWin.cpp: (WebKit::WebProcessPool::platformInitializeWebProcess): 2019-06-28 Brent Fulgham <bfulgham@apple.com> Revise WebContent sandbox based on seed feedback https://bugs.webkit.org/show_bug.cgi?id=199339 <rdar://problem/49609201> Reviewed by Alexey Proskuryakov. Unblock syscall needed by CoreText. * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb: * WebProcess/com.apple.WebProcess.sb.in: 2019-06-28 Tim Horton <timothy_horton@apple.com> iOS WebKit2 find-in-page indicator doesn't move with 'overflow: scroll' https://bugs.webkit.org/show_bug.cgi?id=175032 <rdar://problem/29346482> Reviewed by Wenson Hsieh. * WebProcess/WebPage/FindController.cpp: (WebKit::FindController::drawRect): (WebKit::FindController::didScrollAffectingFindIndicatorPosition): Adopt the macOS code that notices that the find highlight doesn't match its original position, but instead of hiding the highlight like we do on macOS, update it. We do this asynchronously to avoid mutating the layer tree in the middle of painting, which is not /truly/ unsafe, but definitely non-ideal and causes fun flashes. * WebProcess/WebPage/FindController.h: * WebProcess/WebPage/ios/FindControllerIOS.mm: (WebKit::FindController::updateFindIndicator): Store m_findIndicatorRect when updating the indicator, just like we do on macOS. 2019-06-28 Ryan Haddad <ryanhaddad@apple.com> Unreviewed build fix attempt after r246928. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _closeAllMediaPresentations]): 2019-06-28 Youenn Fablet <youenn@apple.com> Protect NetworkProcess::m_swServers from bad session IDs https://bugs.webkit.org/show_bug.cgi?id=199298 <rdar://problem/51859081> Reviewed by Chris Dumez. Protect NetworkProcess from receiving bad session IDs in service worker code path by checking for session ID validity whenever interacting with the map. One of the check is done in WebProcess in which case, if the session ID is bad, the SW connection to NetworkProcess will not be made. For bad session IDs, this will in that case trigger timing out of service worker operations. For get/clear data, exit early in case of bad session ID. Made some refactoring to remove swOriginStoreForSession method. In the one call site where it is used, the store should already be created so we reuse existingSWOriginStoreForSession. Added a bunch of additional ASSERTs. * NetworkProcess/NetworkProcess.cpp: (WebKit::NetworkProcess::destroySession): (WebKit::NetworkProcess::fetchWebsiteData): (WebKit::NetworkProcess::deleteWebsiteData): (WebKit::NetworkProcess::deleteWebsiteDataForRegistrableDomains): (WebKit::NetworkProcess::registrableDomainsWithWebsiteData): (WebKit::NetworkProcess::actualPrepareToSuspend): (WebKit::NetworkProcess::swServerForSession): (WebKit::NetworkProcess::existingSWOriginStoreForSession const): (WebKit::NetworkProcess::registerSWServerConnection): * NetworkProcess/NetworkProcess.h: * WebProcess/Network/NetworkProcessConnection.cpp: (WebKit::NetworkProcessConnection::initializeSWClientConnection): * WebProcess/Storage/WebSWClientConnection.cpp: (WebKit::WebSWClientConnection::WebSWClientConnection): (WebKit::WebSWClientConnection::initializeConnectionIfNeeded): (WebKit::WebSWClientConnection::ensureConnectionAndSend): 2019-06-28 Timothy Hatcher <timothy@apple.com> Rename effectiveAppearanceIsInactive and useInactiveAppearance to better match UIUserInterfaceLevel. https://bugs.webkit.org/show_bug.cgi?id=199336 rdar://problem/52348938 Reviewed by Tim Horton. * Shared/WebPageCreationParameters.cpp: (WebKit::WebPageCreationParameters::encode const): (WebKit::WebPageCreationParameters::decode): * Shared/WebPageCreationParameters.h: * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _effectiveUserInterfaceLevelIsElevated]): (-[WKWebView _effectiveAppearanceIsInactive]): Deleted. * UIProcess/API/Cocoa/WKWebViewInternal.h: * UIProcess/Cocoa/WebViewImpl.h: * UIProcess/Cocoa/WebViewImpl.mm: (WebKit::WebViewImpl::effectiveUserInterfaceLevelIsElevated): (WebKit::WebViewImpl::effectiveAppearanceIsInactive): Deleted. * UIProcess/PageClient.h: (WebKit::PageClient::effectiveUserInterfaceLevelIsElevated const): (WebKit::PageClient::effectiveAppearanceIsInactive const): Deleted. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::creationParameters): (WebKit::WebPageProxy::useElevatedUserInterfaceLevel const): (WebKit::WebPageProxy::effectiveAppearanceDidChange): (WebKit::WebPageProxy::useInactiveAppearance const): Deleted. * UIProcess/WebPageProxy.h: * UIProcess/ios/PageClientImplIOS.h: * UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::effectiveUserInterfaceLevelIsElevated const): (WebKit::PageClientImpl::effectiveAppearanceIsInactive const): Deleted. * UIProcess/mac/PageClientImplMac.h: * UIProcess/mac/PageClientImplMac.mm: (WebKit::PageClientImpl::effectiveUserInterfaceLevelIsElevated const): (WebKit::PageClientImpl::effectiveAppearanceIsInactive const): Deleted. * WebProcess/InjectedBundle/API/c/WKBundlePage.cpp: (WKBundlePageSetUseDarkAppearance): * WebProcess/WebPage/WebPage.cpp: (WebKit::m_shrinkToFitContentTimer): (WebKit::WebPage::effectiveAppearanceDidChange): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: 2019-06-28 Jer Noble <jer.noble@apple.com> Unreviewed maccatalyst build fix; add ENABLE(FULLSCREEN) checks around calls to fullScreenManager(). * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _closeAllMediaPresentations]): 2019-06-28 Tim Horton <timothy_horton@apple.com> macCatalyst: Selected range sometimes wrong after autocorrection https://bugs.webkit.org/show_bug.cgi?id=199299 <rdar://problem/49717224> Reviewed by Wenson Hsieh. * UIProcess/Cocoa/TextCheckingController.h: * UIProcess/Cocoa/TextCheckingController.mm: (WebKit::TextCheckingController::replaceRelativeToSelection): * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView replaceSelectionOffset:length:withAnnotatedString:relativeReplacementRange:]): Plumb the whole relative replacement range through to the Web Content process. * WebProcess/WebPage/Cocoa/TextCheckingControllerProxy.h: * WebProcess/WebPage/Cocoa/TextCheckingControllerProxy.messages.in: * WebProcess/WebPage/Cocoa/TextCheckingControllerProxy.mm: (WebKit::TextCheckingControllerProxy::replaceRelativeToSelection): Only replace the text of the substring that changed (the replacement range), and fix up the selection offset math (it was really just wrong before). 2019-06-28 Wenson Hsieh <wenson_hsieh@apple.com> Need a way for SPI clients to know when to avoid resizing to accommodate for the input view bounds https://bugs.webkit.org/show_bug.cgi?id=199331 <rdar://problem/52116170> Reviewed by Tim Horton. Expose new SPI, such that clients may check whether to avoid resizing the web view when changing input view bounds. In particular, resizing the web view in this case causes toolbar menus in Microsoft Word online to dismiss immediately after opening them, due to resize events fired as a result of the input view dismissing. * Shared/FocusedElementInformation.cpp: (WebKit::FocusedElementInformation::encode const): (WebKit::FocusedElementInformation::decode): * Shared/FocusedElementInformation.h: Add a new flag to FocusedElementInformation to indicate whether we should avoid resizing the web view when an input view is presented. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _shouldAvoidResizingWhenInputViewBoundsChange]): * UIProcess/API/Cocoa/WKWebViewPrivate.h: * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _elementDidBlur]): Reset the value of the flag. (-[WKContentView _shouldAvoidResizingWhenInputViewBoundsChange]): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::getFocusedElementInformation): 2019-06-28 Jer Noble <jer.noble@apple.com> Add new -[WKWebView _closeAllMediaPresentations] SPI https://bugs.webkit.org/show_bug.cgi?id=199294 <rdar://problem/51965958> Reviewed by Alex Christensen. Add a new SPI that will close all out-of-window media presentations, including picture-in-picture, video fullscreen, and element fullscreen. Drive-by fixes: + -[WKApplicationStateTrackingView didMoveToWindow] incorrectly assumes that a WKWebView will never be moved frome one window to another, and asserts. + -[WKFullScreenWindowController close] doesn't fire the correct 'webkitfullscreenchange' event when called in the middle of animating into fullscreen. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _closeAllMediaPresentations]): * UIProcess/API/Cocoa/WKWebViewPrivate.h: * UIProcess/Cocoa/VideoFullscreenManagerProxy.h: * UIProcess/Cocoa/VideoFullscreenManagerProxy.mm: (WebKit::VideoFullscreenManagerProxy::forEachSession): * UIProcess/ios/WKApplicationStateTrackingView.mm: (-[WKApplicationStateTrackingView didMoveToWindow]): * UIProcess/mac/WKFullScreenWindowController.h: * UIProcess/mac/WKFullScreenWindowController.mm: (-[WKFullScreenWindowController exitFullScreenImmediately]): (-[WKFullScreenWindowController close]): 2019-06-28 Antti Koivisto <antti@apple.com> [iOS Scrolling] Propagate scrolls to non-nested UIScrollViews https://bugs.webkit.org/show_bug.cgi?id=199222 Reviewed by Simon Fraser. We may generate scrolling hierarchies where the scrolling ancestor of a layer is not an ancestor in the layer tree. We handle this in most situations but there is still a problem where a scroller fails to propage scroll to the ancestor when it reaches the edge. This patch hooks up a new SPI that allows us to tell UIKit about non-ancestor scrolling relations and solve this problem. * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.h: * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm: (WebKit::findActingScrollParent): * UIProcess/RemoteLayerTree/ios/ScrollingTreeScrollingNodeDelegateIOS.h: * UIProcess/RemoteLayerTree/ios/ScrollingTreeScrollingNodeDelegateIOS.mm: (-[WKScrollingNodeScrollViewDelegate _actingParentScrollViewForScrollView:]): Hook into UIKit SPI. (WebKit::ScrollingTreeScrollingNodeDelegateIOS::findActingScrollParent): 2019-06-28 Konstantin Tokarev <annulen@yandex.ru> Remove traces of ENABLE_ICONDATABASE remaining after its removal in 219733 https://bugs.webkit.org/show_bug.cgi?id=199317 Reviewed by Michael Catanzaro. While IconDatabase and all code using it was removed, ENABLE_ICONDATABASE still exists as build option and C++ macro. * Configurations/FeatureDefines.xcconfig: * PlatformGTK.cmake: Remove reference to unused urlIcon.png file. 2019-06-28 Wenson Hsieh <wenson_hsieh@apple.com> -[WKContentView _selectionClipRects] returns a bogus value in -reloadInputViews when focusing an element https://bugs.webkit.org/show_bug.cgi?id=199310 <rdar://problem/52292137> Reviewed by Megan Gardner. When reloading input views under -_elementDidFocus:, -_selectionClipRect returns the value of the previously focused element; this is because _selectionClipRect depends on EditorState's post layout data, which is only guaranteed to arrive during the next remote layer tree commit after the element is focused. However, some clients need to inspect this value under the call to -reloadInputViews when an element is focused; to make this work, simply check whether we are currently waiting for post-layout EditorState data to arrive following element focus; if so, return the FocusedElementInformation's elementRect, which represents the initial state of the focused element. Otherwise, use the EditorState's post layout data, which is guaranteed to be more up-to-date than the FocusedElementInformation's element rect. Test: KeyboardInputTests.SelectionClipRectsWhenPresentingInputView * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::waitingForPostLayoutEditorStateUpdateAfterFocusingElement const): * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _selectionClipRect]): 2019-06-28 Carlos Garcia Campos <cgarcia@igalia.com> [SOUP] WebSockets: runtime critical warning when closing the connection in some cases https://bugs.webkit.org/show_bug.cgi?id=199265 Reviewed by Michael Catanzaro. Ensure the connection is still open before calling soup_websocket_connection_close(). * NetworkProcess/soup/WebSocketTaskSoup.cpp: (WebKit::WebSocketTask::close): 2019-06-27 Zan Dobersek <zdobersek@igalia.com> Unreviewed WPE build fix. * SourcesWPE.txt: Add WebSocketTaskSoup.cpp to the build. 2019-06-27 Dean Jackson <dino@apple.com> Provide overrides for UIKit's suggested actions in UIContextMenuInteraction https://bugs.webkit.org/show_bug.cgi?id=199301 <rdar://problem/52297380> Reviewed by Tim Horton. We were previously wrapping the actionMenuProvider with our own block in order to ensure the correct suggestedActions were passed to the provider. UIKit added API for us to override the actions separately. Unfortunately we can't quite yet get rid of our access into the UIContextMenuConfiguration, because we still need to override the preview handler in the case where the user does not want link previews. * Platform/spi/ios/UIKitSPI.h: * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView continueContextMenuInteraction:]): (-[WKContentView _contextMenuInteraction:overrideSuggestedActionsForConfiguration:]): Implement the new delegate SPI to provide our own actions. 2019-06-27 Daniel Bates <dabates@apple.com> [iOS] Select all with existing range selection replaces range instead of selecting all text https://bugs.webkit.org/show_bug.cgi?id=197950 <rdar://problem/50245131> Reviewed by Wenson Hsieh. Following <rdar://problem/47333786>, UIKit now asks WebKit whether it can handle Command + A as "select all" instead of just demanding that we handle it. So, WebKit needs to be able to correctly tell UIKit in advance whether it can handle it. Currenlty WebKit tells UIKit it cannot handle a "select all" whenever there is an existing range selection. So, UIKit does not tell WebKit to perform the "select all". Moreover, since UIKit has no other means to handle this key command itself it tells WebKit the key command was not handled. So, WebKit tells the keyboard to insert the "a". Instead, WebKit should tell UIKit it can handle a "select all" even when this is an existing range selection. However we need to keep the current logic just for when UIKit is asking us with respect to populating the callout menu to not regress platform behavior. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView canPerformActionForWebView:withSender:]): Do what we do now if we are called when populating the callout menu and action is Select All. Otherwise, return YES for the Select All action if we have a non-empty selection. 2019-06-27 Andy Estes <aestes@apple.com> [iOS] Stop using cached UITargetedPreviews from previous interactions when starting a new context menu interaction https://bugs.webkit.org/show_bug.cgi?id=199285 <rdar://problem/52074916> Reviewed by Tim Horton. WKContentView was caching the UITargetedPreview created in -contextMenuInteraction:previewForHighlightingMenuWithConfiguration: for later reuse by -contextMenuInteraction:previewForDismissingMenuWithConfiguration:. The cached value was then cleared in -contextMenuInteractionDidEnd:. This was wrong, because -contextMenuInteractionDidEnd: can be called before -contextMenuInteraction:previewForDismissingMenuWithConfiguration:, so we would clear the cache then create and cache a new UITargetedPreview during dismissal. Then when a new context menu interaction started, we'd reuse the targeted preview created for the previous dismissal (which has the wrong geometry). Stop assuming an ordering between -contextMenuInteraction:previewForDismissingMenuWithConfiguration: and -contextMenuInteractionDidEnd:. Instead, always create and cache a new UITargetedPreview in -contextMenuInteraction:previewForHighlightingMenuWithConfiguration:, then reuse it and clear the cache in -contextMenuInteraction:previewForDismissingMenuWithConfiguration:. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _createTargetedPreviewIfPossible]): (-[WKContentView contextMenuInteraction:previewForDismissingMenuWithConfiguration:]): (-[WKContentView contextMenuInteractionDidEnd:]): 2019-06-27 Sihui Liu <sihui_liu@apple.com> Regression(r246526): StorageManager thread hangs https://bugs.webkit.org/show_bug.cgi?id=199278 <rdar://problem/52202948> Reviewed by Geoffrey Garen. r246526 adds a lock m_localStorageNamespacesMutex to protect m_localStorageNamespaces, because m_localStorageNamespaces is destroyed at main thread while accesses to m_localStorageNamespaces happen in the background thread. After r246526, getOrCreateLocalStorageNamespace acquires lock m_localStorageNamespacesMutex when m_localStorageNamespacesMutex is already acquired in cloneSessionStorageNamespace, so the StorageManager thread hangs. To solve this issue, we can remove the lock in getOrCreateLocalStorageNamespace, or we can remove the m_localStorageNamespacesMutex. waitUntilWritesFinished() before ~StorageManager() already guarantees nothing will be running in the background thread, so it is unlikely we the access to m_localStorageNamespaces in the background thread would collide with the destruction of m_localStorageNamespaces. Also, we don't need didDestroyStorageArea as LocalStorageNamespace can hold the last reference of StorageArea after r245881. * NetworkProcess/WebStorage/StorageManager.cpp: (WebKit::StorageManager::StorageArea::StorageArea): (WebKit::StorageManager::StorageArea::~StorageArea): (WebKit::StorageManager::LocalStorageNamespace::LocalStorageNamespace): (WebKit::StorageManager::cloneSessionStorageNamespace): (WebKit::StorageManager::getLocalStorageOrigins): (WebKit::StorageManager::deleteLocalStorageEntriesForOrigin): (WebKit::StorageManager::deleteLocalStorageOriginsModifiedSince): (WebKit::StorageManager::deleteLocalStorageEntriesForOrigins): (WebKit::StorageManager::getOrCreateLocalStorageNamespace): (WebKit::StorageManager::LocalStorageNamespace::didDestroyStorageArea): Deleted. * NetworkProcess/WebStorage/StorageManager.h: 2019-06-27 Carlos Garcia Campos <cgarcia@igalia.com> WebSockets: avoid data copies when queuing tasks in WebSocketChannel https://bugs.webkit.org/show_bug.cgi?id=199262 Reviewed by Alex Christensen. For IPC message handler arguments we can receive rvalue references instead of const references. * WebProcess/Network/WebSocketChannel.cpp: (WebKit::WebSocketChannel::didConnect): (WebKit::WebSocketChannel::didReceiveText): (WebKit::WebSocketChannel::didReceiveBinaryData): (WebKit::WebSocketChannel::didClose): (WebKit::WebSocketChannel::didReceiveMessageError): * WebProcess/Network/WebSocketChannel.h: 2019-06-27 Youenn Fablet <youenn@apple.com> Fix build after revision 246877 https://bugs.webkit.org/show_bug.cgi?id=199276 Unreviewed. Pass protocol parameter to NetworkSocketChannel. * NetworkProcess/cocoa/NetworkSessionCocoa.mm: (-[WKNetworkSessionDelegate URLSession:webSocketTask:didOpenWithProtocol:]): * NetworkProcess/cocoa/WebSocketTaskCocoa.h: * NetworkProcess/cocoa/WebSocketTaskCocoa.mm: (WebKit::WebSocketTask::didConnect): 2019-06-27 Beth Dakin <bdakin@apple.com> Upstream use of MACCATALYST https://bugs.webkit.org/show_bug.cgi?id=199245 rdar://problem/51687723 Reviewed by Tim Horton. * Configurations/Base.xcconfig: * Configurations/FeatureDefines.xcconfig: * Configurations/Network-iOSMac.entitlements: Removed. * Configurations/Network-macCatalyst.entitlements: Copied from Source/WebKit/Configurations/Network-iOSMac.entitlements. * Configurations/NetworkService.xcconfig: * Configurations/SDKVariant.xcconfig: * Configurations/WebContent-iOSMac.entitlements: Removed. * Configurations/WebContent-macCatalyst.entitlements: Copied from Source/WebKit/Configurations/WebContent-iOSMac.entitlements. * Configurations/WebContentService.xcconfig: * Configurations/WebKit.xcconfig: * NetworkProcess/ios/NetworkProcessIOS.mm: * NetworkProcess/mac/NetworkProcessMac.mm: (WebKit::NetworkProcess::initializeProcess): (WebKit::NetworkProcess::initializeProcessName): * Platform/mac/LayerHostingContext.mm: (WebKit::LayerHostingContext::createForExternalHostingProcess): * Platform/spi/ios/ManagedConfigurationSPI.h: * Platform/spi/ios/UIKitSPI.h: * Shared/WebPreferencesDefaultValues.cpp: (WebKit::defaultCustomPasteboardDataEnabled): * Shared/ios/AuxiliaryProcessIOS.mm: (WebKit::AuxiliaryProcess::initializeSandbox): * Shared/ios/InteractionInformationAtPosition.h: * Shared/ios/InteractionInformationAtPosition.mm: (WebKit::InteractionInformationAtPosition::encode const): (WebKit::InteractionInformationAtPosition::decode): * Shared/mac/AuxiliaryProcessMac.mm: (WebKit::enableSandboxStyleFileQuarantine): * Shared/mac/CodeSigning.mm: * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _webViewPrintFormatter]): * UIProcess/API/Cocoa/WKWebViewInternal.h: * UIProcess/API/Cocoa/WKWebViewPrivate.h: * UIProcess/RemoteLayerTree/RemoteLayerTreeHost.mm: (WebKit::RemoteLayerTreeHost::updateLayerTree): * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm: (-[WKRemoteView initWithFrame:contextID:]): * UIProcess/_WKWebViewPrintFormatter.mm: * UIProcess/_WKWebViewPrintFormatterInternal.h: * UIProcess/ios/WKActionSheetAssistant.mm: (-[WKActionSheetAssistant _elementActionForDDAction:]): * UIProcess/ios/WKContentView.mm: (-[WKContentView _commonInitializationWithProcessPool:configuration:]): * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView setupInteraction]): (-[WKContentView cleanupInteraction]): (-[WKContentView _removeDefaultGestureRecognizers]): (-[WKContentView _addDefaultGestureRecognizers]): (-[WKContentView _showTapHighlight]): (-[WKContentView gestureRecognizer:canBePreventedByGestureRecognizer:]): (-[WKContentView gestureRecognizer:shouldRecognizeSimultaneouslyWithGestureRecognizer:]): (-[WKContentView canPerformActionForWebView:withSender:]): (-[WKContentView _defineForWebView:]): (-[WKContentView setSelectedTextRange:]): (-[WKContentView closestPositionToPoint:]): (-[WKContentView _showShareSheet:inRect:completionHandler:]): * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::desktopClassBrowsingSupported): (WebKit::desktopClassBrowsingRecommended): * UIProcess/ios/forms/WKFileUploadPanel.mm: (-[WKFileUploadPanel _showDocumentPickerMenu]): * WebKit.xcodeproj/project.pbxproj: * WebProcess/WebPage/Cocoa/TextCheckingControllerProxy.mm: * WebProcess/WebPage/Cocoa/WebPageCocoa.mm: (WebKit::WebPage::dictionaryPopupInfoForRange): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::platformEditorState const): (WebKit::WebPage::selectWithGesture): (WebKit::selectionPositionInformation): * WebProcess/cocoa/WebProcessCocoa.mm: (WebKit::WebProcess::initializeSandbox): * WebProcess/com.apple.WebProcess.sb.in: 2019-06-27 Saam Barati <sbarati@apple.com> Make WEBGPU enabled only on Mojave and later. Rubber-stamped by Myles C. Maxfield. * Configurations/FeatureDefines.xcconfig: 2019-06-27 Adrian Perez de Castro <aperez@igalia.com> [GTK][WPE] Fix build non-unified builds after r246856 https://bugs.webkit.org/show_bug.cgi?id=199263 Reviewed by Michael Catanzaro. * UIProcess/API/C/WKMessageListener.cpp: Added missing inclusion of WKAPICast.h and usage of WebKit namespace. 2019-06-27 Carlos Garcia Campos <cgarcia@igalia.com> [SOUP] WebSockets: handle TLS certificate and errors https://bugs.webkit.org/show_bug.cgi?id=199223 Reviewed by Michael Catanzaro. Connect to accept-certificate signal on the WebSocket message connection to decide what to do in case of TLS errors. * NetworkProcess/soup/NetworkSessionSoup.cpp: (WebKit::webSocketAcceptCertificateCallback): (WebKit::webSocketMessageNetworkEventCallback): (WebKit::NetworkSessionSoup::createWebSocketTask): 2019-06-27 Carlos Garcia Campos <cgarcia@igalia.com> [SOUP] Use libsoup WebSockets API https://bugs.webkit.org/show_bug.cgi?id=199151 Reviewed by Michael Catanzaro. Use the new WebSockets code path that depends on platform specific WebSockets implementation using the libsoup API. This is an initial implementation manually tested using the layout tests, which most of them fail due to missing console messages, missing features in the new code path or differences in the platform implementation. It will be disabled by default until it's feature complete compared to the internal WebKit implementation. * NetworkProcess/NetworkSocketChannel.cpp: (WebKit::NetworkSocketChannel::NetworkSocketChannel): Null check m_socket before using it, because createWebSocketTask() can return nullptr; (WebKit::NetworkSocketChannel::didConnect): Receive the protocol accepted by the server. (WebKit::NetworkSocketChannel::didReceiveMessageError): Something failed in the server side. * NetworkProcess/NetworkSocketChannel.h: * NetworkProcess/WebSocketTask.h: * NetworkProcess/soup/NetworkSessionSoup.cpp: (WebKit::NetworkSessionSoup::createWebSocketTask): Create a WebSocketTask. * NetworkProcess/soup/NetworkSessionSoup.h: * NetworkProcess/soup/WebSocketTaskSoup.cpp: Added. (WebKit::WebSocketTask::WebSocketTask): (WebKit::WebSocketTask::~WebSocketTask): (WebKit::WebSocketTask::didConnect): (WebKit::WebSocketTask::didReceiveMessageCallback): (WebKit::WebSocketTask::didReceiveErrorCallback): (WebKit::WebSocketTask::didFail): (WebKit::WebSocketTask::didCloseCallback): (WebKit::WebSocketTask::didClose): (WebKit::WebSocketTask::sendString): (WebKit::WebSocketTask::sendData): (WebKit::WebSocketTask::close): (WebKit::WebSocketTask::cancel): (WebKit::WebSocketTask::resume): * NetworkProcess/soup/WebSocketTaskSoup.h: Copied from Source/WebKit/NetworkProcess/WebSocketTask.h. * SourcesGTK.txt: * WebProcess/Network/WebSocketChannel.cpp: (WebKit::WebSocketChannel::subprotocol): Return the protocol accepted by the server. (WebKit::WebSocketChannel::didConnect): Set the protocol accepted by the server. (WebKit::WebSocketChannel::didReceiveMessageError): It's now an IPC message handler and receives the reason as parameter. (WebKit::WebSocketChannel::networkProcessCrashed): Pass empty reason. * WebProcess/Network/WebSocketChannel.h: * WebProcess/Network/WebSocketChannel.messages.in: 2019-06-21 Konstantin Tokarev <annulen@yandex.ru> [cmake] Switch to built-in handling of C++ standard instead of hardcoding -std=c++17 https://bugs.webkit.org/show_bug.cgi?id=199108 Reviewed by Don Olmstead. Rationale: 1. It provides an abstraction over exact flags of particular compilers - we just specify required version of C++ standard 2. External libraries (like Qt used in WPEQt) may require particular C++ standard or even particular C++ features to be availabe (e.g. Qt requires INTERFACE_COMPILE_FEATURES cxx_decltype, which causes cmake to add -std=gnu++11 unless proper CXX_STANDARD is defined) * PlatformWPE.cmake: Use project-level default for CXX_STANDARD property. 2019-06-26 Jiewen Tan <jiewen_tan@apple.com> SubFrameSOAuthorizationSession should preserve the referrer header when fall back to web path https://bugs.webkit.org/show_bug.cgi?id=199232 <rdar://problem/51718328> Reviewed by Youenn Fablet. The fall back to web path mechanism in SubFrameSOAuthorizationSession doesn't actually resume the previous navigation. Instead it starts a new one. The current implementation doesn't carry any information from the previous navigation. It is problematic when it comes to http referrer as the server might use that to determine what kind of responses to send back. Therefore, we add that information now. To accomplish the above, the patch teaches WebFrameProxy::loadURL to carry referrer information when it is available. Then SubFrameSOAuthorizationSession can reuses the referrer from the original request. * UIProcess/Cocoa/SOAuthorization/SubFrameSOAuthorizationSession.mm: (WebKit::SubFrameSOAuthorizationSession::fallBackToWebPathInternal): * UIProcess/WebFrameProxy.cpp: (WebKit::WebFrameProxy::loadURL): * UIProcess/WebFrameProxy.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::loadURLInFrame): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: 2019-06-26 Fujii Hironori <Hironori.Fujii@sony.com> testRunner.setAlwaysAcceptCookies should wait for cookie accept policy to be set https://bugs.webkit.org/show_bug.cgi?id=199230 <rdar://problem/52217933> Unreviewed build fix for WinCairo WK2 since r246856. * PlatformWin.cmake: Added WKMessageListener.h to WebKit_PUBLIC_FRAMEWORK_HEADERS. 2019-06-26 Dean Jackson <dino@apple.com> Add type to UIImage symbol mapping for _WKElementAction https://bugs.webkit.org/show_bug.cgi?id=199255 Reviewed by Sam Weinig. Moving some code in from WebKitAdditions now that the API is public. * UIProcess/API/Cocoa/_WKElementAction.mm: (+[_WKElementAction imageForElementActionType:]): (elementActionTypeToUIActionIdentifier): (uiActionIdentifierToElementActionType): 2019-06-26 Dean Jackson <dino@apple.com> Expose UIAction identifiers for _WKElementActions https://bugs.webkit.org/show_bug.cgi?id=199246 <rdar://problem/52218950> Reviewed by Tim Horton. In order for clients to create a contextual menu, they are given a set of suggested UIActions, created from _WKElementActions. By associating identifiers (strings) with the UIActions, clients can inspect the suggestions and make a decision on whether or not to include them in the final menu. * UIProcess/API/Cocoa/_WKElementAction.h: Typedef UIActionIdentifier, add a method to create a UIAction from an _WKElementAction, and a helper to map between identifiers and types. * UIProcess/API/Cocoa/_WKElementAction.mm: (elementActionTypeToUIActionIdentifier): Helper to convert between the two types. (uiActionIdentifierToElementActionType): The inverse of above. (+[_WKElementAction elementActionTypeForUIActionIdentifier:]): A client given a UIAction object can use this helper method to see what _WKElementActionType it corresponds to. (-[_WKElementAction uiActionForElementInfo:]): Used by WKContentViewInteraction to create a UIAction from this _WKElementAction. * UIProcess/ios/WKContentViewInteraction.mm: (uiActionForLegacyPreviewAction): Renamed to make it clear this is a legacy approach. (menuFromLegacyPreviewOrDefaultActions): Split these functions to separate the legacy and non-legacy approach. (-[WKContentView assignLegacyDataForContextMenuInteraction]): (-[WKContentView continueContextMenuInteraction:]): (uiActionForPreviewAction): Deleted. (menuFromPreviewOrDefaults): Deleted. 2019-06-26 Wenson Hsieh <wenson_hsieh@apple.com> [iPadOS] Fix another crash in -[UIPreviewTarget initWithContainer:center:transform:] when generating a fallback targeted preview https://bugs.webkit.org/show_bug.cgi?id=199243 <rdar://problem/51554509> Reviewed by Tim Horton. Additionally make createFallbackTargetedPreview robust in the case where the content view is unparented, and rename _ensureTargetedPreview to _createTargetedPreviewIfPossible, to reflect the fact that it may now return nil. * UIProcess/ios/WKContentViewInteraction.mm: (createTargetedPreview): (createFallbackTargetedPreview): (-[WKContentView _createTargetedPreviewIfPossible]): (-[WKContentView contextMenuInteraction:previewForHighlightingMenuWithConfiguration:]): (-[WKContentView contextMenuInteraction:previewForDismissingMenuWithConfiguration:]): (-[WKContentView _ensureTargetedPreview]): Deleted. 2019-06-26 Alex Christensen <achristensen@webkit.org> testRunner.setAlwaysAcceptCookies should wait for cookie accept policy to be set https://bugs.webkit.org/show_bug.cgi?id=199230 <rdar://51757107> Reviewed by Andy Estes. This patch adds an optional callback to WKCookieManagerSetHTTPCookieAcceptPolicy which is luckily only used for testing. It also adds listener-based asynchronous versions of didReceiveSynchronousMessageFromInjectedBundle. WebKitTestRunner uses these new abilities to wait for the cookie accept policy to be set in the network process while the web process is hung. This removes the race condition that was causing some flakiness in tests that use testRunner.setAlwaysAcceptCookies * Shared/API/APIObject.h: * Shared/API/c/WKBase.h: * Sources.txt: * UIProcess/API/APIInjectedBundleClient.h: (API::InjectedBundleClient::didReceiveSynchronousMessageFromInjectedBundle): * UIProcess/API/APIMessageListener.h: Copied from Source/WebKit/UIProcess/API/APIInjectedBundleClient.h. (API::MessageListener::create): (API::MessageListener::sendReply): (API::MessageListener::MessageListener): * UIProcess/API/C/WKAPICast.h: * UIProcess/API/C/WKContextInjectedBundleClient.h: * UIProcess/API/C/WKCookieManager.cpp: (WKCookieManagerSetHTTPCookieAcceptPolicy): * UIProcess/API/C/WKCookieManager.h: * UIProcess/API/C/WKMessageListener.cpp: Copied from Source/WebKit/UIProcess/API/APIInjectedBundleClient.h. (WKMessageListenerGetTypeID): (WKMessageListenerSendReply): * UIProcess/API/C/WKMessageListener.h: Copied from Source/WebKit/UIProcess/API/APIInjectedBundleClient.h. * UIProcess/API/C/WKPageInjectedBundleClient.h: * UIProcess/WebContextInjectedBundleClient.cpp: (WebKit::WebContextInjectedBundleClient::didReceiveSynchronousMessageFromInjectedBundle): * UIProcess/WebContextInjectedBundleClient.h: * UIProcess/WebPageInjectedBundleClient.cpp: (WebKit::WebPageInjectedBundleClient::didReceiveSynchronousMessageFromInjectedBundle): * UIProcess/WebPageInjectedBundleClient.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::handleSynchronousMessage): * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::injectedBundleClient): Deleted. * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::handleSynchronousMessage): * WebKit.xcodeproj/project.pbxproj: 2019-06-26 Wenson Hsieh <wenson_hsieh@apple.com> [iPadOS] eddm.usps.com scrolls horizontally due to explicit width set in viewport meta tag https://bugs.webkit.org/show_bug.cgi?id=199219 <rdar://problem/50425765> Reviewed by Tim Horton. Currently, the heuristic to determine whether the page should be shrunk to fit the content width after loading works by checking whether the page's content is wider than the layout width we've provided for the page. However, in the case where an explicit width larger than the true view width is specified by the page's meta viewport, we'll end up believing that the page's content is not wider than the layout width, which is dictated by the fixed meta viewport width. Instead, we can shrink the page down in this scenario by comparing the content width against the scaled size of the view when computing the amount of horizontal overflow. Test: fast/viewport/ios/shrink-to-fit-content-large-constant-width.html * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::immediatelyShrinkToFitContent): 2019-06-26 Zalan Bujtas <zalan@apple.com> [ContentChangeObserver] Dispatch synthetic mouse event asynchronously in completePendingSyntheticClickForContentChangeObserver https://bugs.webkit.org/show_bug.cgi?id=199220 <rdar://problem/51787961> Reviewed by Simon Fraser. WebPage::completePendingSyntheticClickForContentChangeObserver should not dispatch mouse events synchronously. Mouse events, through style updates could destroy the element that initiated this change. WebPage::handleSyntheticClick() already implements this pattern. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::completePendingSyntheticClickForContentChangeObserver): 2019-06-25 Jiewen Tan <jiewen_tan@apple.com> Implement a new SPI to inform clients about AppSSO https://bugs.webkit.org/show_bug.cgi?id=199085 <rdar://problem/50028246> Reviewed by Geoffrey Garen. This patch implements a new SPI to inform clients about incoming AppSSO interceptions during navigations. Therefore, clients can make an informed decision about whether this is the right moment to do the interception as interceptions often show native UI. Also, the SPI is designed to pass along a human readable name for the extension such that clients can do whatever they want to inform users about what's going on. Here is the new SPI: - (void)_webView:(WKWebView *)webView decidePolicyForSOAuthorizationLoadWithCurrentPolicy:(_WKSOAuthorizationLoadPolicy)policy forExtension:(NSString *)extension completionHandler:(void (^)(_WKSOAuthorizationLoadPolicy policy))completionHandler; * UIProcess/API/APINavigationClient.h: (API::NavigationClient::decidePolicyForSOAuthorizationLoad): * UIProcess/API/Cocoa/WKNavigationDelegatePrivate.h: * UIProcess/Cocoa/NavigationState.h: * UIProcess/Cocoa/NavigationState.mm: (WebKit::NavigationState::setNavigationDelegate): (WebKit::soAuthorizationLoadPolicy): (WebKit::wkSOAuthorizationLoadPolicy): (WebKit::NavigationState::NavigationClient::decidePolicyForSOAuthorizationLoad): * UIProcess/Cocoa/SOAuthorization/SOAuthorizationLoadPolicy.h: Added. * UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.mm: (WebKit::SOAuthorizationSession::start): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::decidePolicyForSOAuthorizationLoad): * UIProcess/WebPageProxy.h: * WebKit.xcodeproj/project.pbxproj: 2019-06-25 Simon Fraser <simon.fraser@apple.com> [iOS WK2 Debug] scrollingcoordinator/scrolling-tree/scroller-with-negative-z-child.html asserts https://bugs.webkit.org/show_bug.cgi?id=199218 Reviewed by Zalan Bujtas. Followup to r246766; don't assert in the UI process if a ScrollingTreeOverflowScrollProxyNode doesn't have a related overflow node; this is currently expected behavior with negative z-order children of a scroller. * UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.mm: (WebKit::RemoteScrollingCoordinatorProxy::establishLayerTreeScrollingRelations): 2019-06-25 Daniel Bates <dabates@apple.com> Non-editable text selections should be modifiable with hardware keyboard https://bugs.webkit.org/show_bug.cgi?id=199204 <rdar://problem/51651496> Reviewed by Wenson Hsieh. UIKit changes are need for this to work, including <rdar://problem/48322899>. Note that without these changes, -canPerformAction is never called for _move* selectors. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView canPerformAction:withSender:]): 2019-06-25 Daniel Bates <dabates@apple.com> [iOS] Should not process key events in non-editable elements using IME https://bugs.webkit.org/show_bug.cgi?id=199122 <rdar://problem/52006654> Reviewed by Brent Fulgham. Use the non-Input Method code path (the one we use for US keyboard input) for all key events targeting a non-editable element. Such key events will never require Input Method support (i.e. show candidate suggestions). Moreover, this behavior matches the behavior on Mac. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView handleKeyWebEvent:withCompletionHandler:]): 2019-06-25 Alex Christensen <achristensen@webkit.org> Make HTTPCookieAcceptPolicy an enum class https://bugs.webkit.org/show_bug.cgi?id=199081 Reviewed by Michael Catanzaro. Doing so reveals some interesting bugs in the C API that are also fixed: WKPreferencesGetIncrementalRenderingSuppressionTimeout was using its toAPI function to convert a double to a double because HTTPCookieAcceptPolicy used to be an unsigned integer. toAPI(WebCore::MouseButton) was also using the toAPI(HTTPCookieAcceptPolicy) because HTTPCookieAcceptPolicy used to be an unsigned integer. Yikes! Type safety is our friend. * NetworkProcess/Cookies/WebCookieManager.messages.in: * NetworkProcess/Cookies/mac/WebCookieManagerMac.mm: (WebKit::toCFHTTPCookieStorageAcceptPolicy): (WebKit::WebCookieManager::platformSetHTTPCookieAcceptPolicy): (WebKit::WebCookieManager::platformGetHTTPCookieAcceptPolicy): * Shared/API/c/WKSharedAPICast.h: (WebKit::toAPI): * Shared/HTTPCookieAcceptPolicy.h: (): Deleted. * UIProcess/API/C/WKAPICast.h: (WebKit::toHTTPCookieAcceptPolicy): (WebKit::toAPI): * UIProcess/API/C/WKPreferences.cpp: (WKPreferencesGetIncrementalRenderingSuppressionTimeout): * UIProcess/API/Cocoa/WKProcessPool.mm: (toHTTPCookieAcceptPolicy): * UIProcess/WebCookieManagerProxy.cpp: (WebKit::WebCookieManagerProxy::didGetHTTPCookieAcceptPolicy): * UIProcess/WebCookieManagerProxy.h: * UIProcess/WebCookieManagerProxy.messages.in: 2019-06-25 Tim Horton <timothy_horton@apple.com> Wrong title for Data Detectors tap action menu https://bugs.webkit.org/show_bug.cgi?id=199198 <rdar://problem/51957842> Reviewed by Wenson Hsieh. * UIProcess/ios/WKActionSheetAssistant.mm: (-[WKActionSheetAssistant showDataDetectorsSheet]): Always pass the results array through to DataDetectors; they need it to figure out the title too! 2019-06-25 Wenson Hsieh <wenson_hsieh@apple.com> [iOS] Occasional crash under -[UIPreviewTarget initWithContainer:center:transform:] when generating a drag preview https://bugs.webkit.org/show_bug.cgi?id=199192 <rdar://problem/51554509> Reviewed by Tim Horton. Tweak our preview generation code (for both the context menu and dragging) to be robust in the case where the content view's unscaled view is nil; this may happen in the case after the web content process is terminated and -cleanupInteraction is called, but before -setupInteraction is subsequently called. Additionally, make our logic for creating targeted previews robust in the case where the view is removed from the view hierarchy right before the platform asks for a targeted preview. Test: DragAndDropTests.WebProcessTerminationDuringDrag DragAndDropTests.WebViewRemovedFromViewHierarchyDuringDrag * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView containerViewForTargetedPreviews]): (-[WKContentView _deliverDelayedDropPreviewIfPossible:]): (-[WKContentView dragInteraction:previewForLiftingItem:session:]): (-[WKContentView _ensureTargetedPreview]): 2019-06-25 Youenn Fablet <youenn@apple.com> Close sockets with too high file descriptor https://bugs.webkit.org/show_bug.cgi?id=199116 Reviewed by Eric Carlson. Log the case of failing to open a socket. * NetworkProcess/webrtc/NetworkRTCProvider.cpp: (WebKit::NetworkRTCProvider::createSocket): 2019-06-25 Tim Horton <timothy_horton@apple.com> When Caps Lock is enabled on the Smart Keyboard, can't scroll with space or arrow keys https://bugs.webkit.org/show_bug.cgi?id=199187 <rdar://problem/51521709> Reviewed by Anders Carlsson. * UIProcess/ios/WKKeyboardScrollingAnimator.mm: (-[WKKeyboardScrollingAnimator keyboardScrollForEvent:]): When deciding whether a key event should start a scroll, ignore all modifiers other than the ones we actually care about (including Caps Lock). 2019-06-25 Michael Catanzaro <mcatanzaro@igalia.com> Fully rename WebKitGTK+ -> WebKitGTK everywhere https://bugs.webkit.org/show_bug.cgi?id=199159 Reviewed by Carlos Garcia Campos. * UIProcess/API/glib/APIWebsiteDataStoreGLib.cpp: 2019-06-24 Brady Eidson <beidson@apple.com> Null deref in WebFrameLoaderClient::dispatchDidReceiveServerRedirectForProvisionalLoad. <rdar://problem/51535942> and https://bugs.webkit.org/show_bug.cgi?id=199123 Reviewed by Andy Estes. * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::dispatchDidReceiveServerRedirectForProvisionalLoad): Properly detect this null DocumentLoader and try to learn more about the state of things. 2019-06-24 Chris Dumez <cdumez@apple.com> Pages using Google's anti-flicker optimization may take ~5 seconds to do initial paint https://bugs.webkit.org/show_bug.cgi?id=199173 <rdar://problem/45968770> Reviewed by Geoffrey Garen. Add experimental feature for the quirk. * Shared/WebPreferences.yaml: 2019-06-24 John Wilander <wilander@apple.com> Remove IsITPFirstPartyWebsiteDataRemovalEnabled as runtime check https://bugs.webkit.org/show_bug.cgi?id=199164 <rdar://problem/52061147> Reviewed by Brent Fulgham. We've had this toggle as a safety thing since mid-March. No need for it any longer. * NetworkProcess/Classifier/ResourceLoadStatisticsMemoryStore.cpp: (WebKit::ResourceLoadStatisticsMemoryStore::shouldRemoveAllButCookiesFor const): * NetworkProcess/NetworkProcess.cpp: (WebKit::NetworkProcess::initializeNetworkProcess): * NetworkProcess/NetworkProcessCreationParameters.cpp: (WebKit::NetworkProcessCreationParameters::encode const): (WebKit::NetworkProcessCreationParameters::decode): * NetworkProcess/NetworkProcessCreationParameters.h: * Shared/WebPreferences.yaml: * UIProcess/Cocoa/WebProcessPoolCocoa.mm: (WebKit::WebProcessPool::platformInitializeNetworkProcess): 2019-06-24 Daniel Bates <dabates@apple.com> m_focusedElement != &element in WebPage::elementDidBlur() sometimes https://bugs.webkit.org/show_bug.cgi?id=198928 <rdar://problem/51814327> Reviewed by Brent Fulgham. This can happen when the focused editable element is inside a nested frame and a person taps outside that frame. For reasons that seem lost to time, WebKit2 on iOS would mutate the focused frame whenever computing selection positioning information (say, for a tap). This "quirk" was added in r163476, but that code has go through multiple iterations and is no longer comparable to the current code. Yet, the original mutation of the focused frame remained. As a result the UI process and Web process go out of sync with respect to what each thinks is the focused element and this visually manifest itself in at least two ways: 1. A non-sensical DOM focus event would be dispatched at the frame tapped, but we would keep the focused element focused. 2. Because we would keep the focused element focused in (1), even though its frame is not focused, the keyboard would be active (software keyboard on screen or candidate bar on screen if a hardware keyboard is attached), but appear unresponsive: any keys pressed would not cause text to be typed into the editable field. Because of (1) it was possible for m_focusedElement != &element in WebPage::elementDidBlur(). When this happens the UI process would never receive an ElementDidBlur message and hence would not clear out the focused element state and hide the keyboard. We neither do this frame focus mutation in Legacy WebKit on iOS nor Mac. Let's remove this quirk. If it turns out that it causes a compatibility issue then we will be in a better position to understand its purpose and consider bringing this quirk back, if needed. * Shared/ios/InteractionInformationRequest.cpp: (WebKit::InteractionInformationRequest::encode const): (WebKit::InteractionInformationRequest::decode): (WebKit::InteractionInformationRequest::isValidForRequest): (WebKit::InteractionInformationRequest::isApproximatelyValidForRequest): * Shared/ios/InteractionInformationRequest.h: * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _requestActivatedElementAtPosition:completionBlock:]): * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _webTouchEventsRecognized:]): Remove the readOnly field. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::selectionPositionInformation): Remove code to mutate the focused frame. 2019-06-24 Per Arne Vollan <pvollan@apple.com> [Cocoa] Avoid creating a PlatformMediaSessionManager when the WebProcess is suspended or resumed https://bugs.webkit.org/show_bug.cgi?id=199160 Reviewed by Brent Fulgham. When the WebProcess suspends or resumes, the PlatformMediaSessionManager is notified about this. Avoid creating a new PlatformMediaSessionManager if it does not already exist. * WebProcess/WebProcess.cpp: (WebKit::WebProcess::actualPrepareToSuspend): (WebKit::WebProcess::cancelPrepareToSuspend): (WebKit::WebProcess::processDidResume): 2019-06-24 Adrian Perez de Castro <aperez@igalia.com> [WPE][GTK] Fixes for compilation with unified builds disabled https://bugs.webkit.org/show_bug.cgi?id=199155 Reviewed by Michael Catanzaro. * NetworkProcess/glib/DNSCache.cpp: Add missing inclusion of wtf/glib/RunLoopSourcePriority.h * NetworkProcess/glib/DNSCache.h: Add missing forward declaration for GInetAddress 2019-06-24 Alexander Mikhaylenko <exalm7659@gmail.com> [GTK] Navigation gesture should use dark fallback bg color on dark themes https://bugs.webkit.org/show_bug.cgi?id=199104 Reviewed by Michael Catanzaro. Use theme_base_color instead of white background for swipe gesture fallback if no snapshot is found and the page did not specify a color. This allows it to use dark colors for dark themes. If the color was not found, still fall back to white. * UIProcess/gtk/ViewGestureControllerGtk.cpp: (WebKit::ViewGestureController::beginSwipeGesture): 2019-06-23 Dan Bernstein <mitz@apple.com> Platform font class gets needlessly initialized in the Networking process https://bugs.webkit.org/show_bug.cgi?id=199140 Reviewed by Tim Horton. * NetworkProcess/mac/com.apple.WebKit.NetworkProcess.sb.in: Revert a change that was made in r246702, which is not needed anymore. * Resources/SandboxProfiles/ios/com.apple.WebKit.Networking.sb: Ditto. * Shared/Cocoa/ArgumentCodersCocoa.mm: (IPC::platformColorClass): Added getter that uses NSClassFromString, thereby avoiding initializing the class. (IPC::platformFontClass): Ditto. (IPC::typeFromObject): Changed to use the above getters instead of +class. 2019-06-23 Simon Fraser <simon.fraser@apple.com> [Async overflow scroll] Clipped composited layers inside overflow scroll jitter and get incorrectly clipped https://bugs.webkit.org/show_bug.cgi?id=199133 rdar://problem/43614439 Reviewed by Antti Koivisto. LayoutConstraints -> AbsolutePositionConstraints rename. * Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.cpp: (ArgumentCoder<ScrollingStatePositionedNode>::decode): * Shared/WebCoreArgumentCoders.cpp: (IPC::ArgumentCoder<AbsolutePositionConstraints>::encode): (IPC::ArgumentCoder<AbsolutePositionConstraints>::decode): (IPC::ArgumentCoder<LayoutConstraints>::encode): Deleted. (IPC::ArgumentCoder<LayoutConstraints>::decode): Deleted. * Shared/WebCoreArgumentCoders.h: * Shared/WebRenderLayer.cpp: (WebKit::WebRenderLayer::WebRenderLayer): * UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.mm: (WebKit::RemoteScrollingCoordinatorProxy::establishLayerTreeScrollingRelations): ScrollingTreeOverflowScrollProxyNode have overflow scroll relations now too. 2019-06-23 Simon Fraser <simon.fraser@apple.com> Add OverflowScrollProxyNodes to the scrolling tree https://bugs.webkit.org/show_bug.cgi?id=199132 Reviewed by Antti Koivisto. Add ScrollingStateOverflowScrollProxyNode and ScrollingTreeOverflowScrollProxyNode. These nodes represent clip and scroll position for an overflow:scroll in the containing block chain, but not the paint ancestor chain of a layer. They will be used to correctly manipulate clip rects for composited layers in non-stacking-context scrollers, and in a future patch will replace the functionality of "Moves" positioned nodes. An OverflowScrollProxyNode has the ScrollingNodeID of the scrolling node that it relates to, and we use the existing "related overflow nodes" to create the back references in the scrolling tree. These nodes are not instantiated yet; a future patch will hook them up. * Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.cpp: (ArgumentCoder<ScrollingStateOverflowScrollProxyNode>::encode): (ArgumentCoder<ScrollingStateOverflowScrollProxyNode>::decode): (WebKit::encodeNodeAndDescendants): (WebKit::RemoteScrollingCoordinatorTransaction::decode): (WebKit::dump): * UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.cpp: (WebKit::RemoteScrollingCoordinatorProxy::connectStateNodeLayers): * UIProcess/RemoteLayerTree/RemoteScrollingTree.cpp: (WebKit::RemoteScrollingTree::createScrollingTreeNode): * UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.mm: (WebKit::RemoteScrollingCoordinatorProxy::connectStateNodeLayers): * UIProcess/RemoteLayerTree/ios/ScrollingTreeScrollingNodeDelegateIOS.mm: (WebKit::ScrollingTreeScrollingNodeDelegateIOS::repositionScrollingLayers): 2019-06-21 Jiewen Tan <jiewen_tan@apple.com> Unreviewed, a build fix after r246701 * Shared/LoadParameters.h: Add a default value for shouldOpenExternalURLsPolicy. 2019-06-21 Brent Fulgham <bfulgham@apple.com> Adjust sandboxes based on seed feedback https://bugs.webkit.org/show_bug.cgi?id=199119 <rdar://problem/50164879> Reviewed by Geoffrey Garen. Update our sandboxes to address test failures and bugs encountered during initial iOS 13 and macOS Catalina testing. * NetworkProcess/mac/com.apple.WebKit.NetworkProcess.sb.in: * Resources/SandboxProfiles/ios/com.apple.WebKit.Networking.sb: * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb: * WebProcess/com.apple.WebProcess.sb.in: 2019-06-21 Jiewen Tan <jiewen_tan@apple.com> WebPageProxy::loadData should accept ShouldOpenExternalURLsPolicy https://bugs.webkit.org/show_bug.cgi?id=199114 <rdar://problem/51671674> Reviewed by Youenn Fablet. This patch teaches WebPageProxy::loadData to accept ShouldOpenExternalURLsPolicy policy, and then utilize it in RedirectSOAuthorizationSession. Therefore, the response loaded after successful interceptions will be able to propagate the same policy from the last navigation as it were continuous loading. Besides the above, this patch also fixes some minor issues. * Shared/LoadParameters.h: * UIProcess/Cocoa/SOAuthorization/NavigationSOAuthorizationSession.mm: (WebKit::NavigationSOAuthorizationSession::shouldStartInternal): (WebKit::NavigationSOAuthorizationSession::webViewDidMoveToWindow): * UIProcess/Cocoa/SOAuthorization/PopUpSOAuthorizationSession.h: * UIProcess/Cocoa/SOAuthorization/PopUpSOAuthorizationSession.mm: (WebKit::PopUpSOAuthorizationSession::completeInternal): * UIProcess/Cocoa/SOAuthorization/RedirectSOAuthorizationSession.h: * UIProcess/Cocoa/SOAuthorization/RedirectSOAuthorizationSession.mm: (WebKit::shouldOpenExternalURLsPolicy): (WebKit::RedirectSOAuthorizationSession::completeInternal): * UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.h: * UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.mm: (WebKit::SOAuthorizationSession::complete): * UIProcess/Cocoa/SOAuthorization/SubFrameSOAuthorizationSession.h: * UIProcess/Cocoa/SOAuthorization/SubFrameSOAuthorizationSession.mm: (WebKit::SubFrameSOAuthorizationSession::fallBackToWebPathInternal): (WebKit::SubFrameSOAuthorizationSession::completeInternal): (WebKit::SubFrameSOAuthorizationSession::loadDataToFrame): (WebKit::SubFrameSOAuthorizationSession::postDidCancelMessageToParent): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::loadRequestWithNavigationShared): (WebKit::WebPageProxy::loadFile): (WebKit::WebPageProxy::loadData): (WebKit::WebPageProxy::loadDataWithNavigationShared): * UIProcess/WebPageProxy.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::loadDataImpl): (WebKit::WebPage::loadData): * WebProcess/WebPage/WebPage.h: 2019-06-21 Tim Horton <timothy_horton@apple.com> WebKit context menu highlights include extra padding https://bugs.webkit.org/show_bug.cgi?id=199080 <rdar://problem/51140126> Reviewed by Dean Jackson. * Shared/ios/InteractionInformationRequest.cpp: (WebKit::InteractionInformationRequest::encode const): (WebKit::InteractionInformationRequest::decode): (WebKit::InteractionInformationRequest::isValidForRequest): (WebKit::InteractionInformationRequest::isApproximatelyValidForRequest): * Shared/ios/InteractionInformationRequest.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView gestureRecognizerShouldBegin:]): (-[WKContentView positionInformationForActionSheetAssistant:]): (-[WKContentView updatePositionInformationForActionSheetAssistant:]): (-[WKContentView _contextMenuInteraction:configurationForMenuAtLocation:completion:]): (-[WKContentView _interactionShouldBeginFromPreviewItemController:forPosition:]): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::linkIndicatorPositionInformation): Disable the margin going forward, but leave it if we're using the legacy API, because there is no way to add margin at the platform level with the legacy API. In the future we should always have no margin in our indicator, and just apply it in whatever consumes the indicator, so that there is no disagreement between clients about the size of the margin. 2019-06-21 Youenn Fablet <youenn@apple.com> WebPageProxy should use the right path for sandbox extension https://bugs.webkit.org/show_bug.cgi?id=198902 <rdar://problem/50772810> Reviewed by Geoffrey Garen. Store the sandbox path, if any, in UIProcess for each page in its PageLoadState. This allows proper sandbox handling for reload after crash and process swap cases. Store the sandbox path, if any, in the b/w list so that the sandbox path can be properly computed during b/f navigation works. Add SPI for test purposes to check what is the current sandbox path. * Shared/WebBackForwardListItem.h: (WebKit::WebBackForwardListItem::resourceDirectoryURL const): (WebKit::WebBackForwardListItem::setResourceDirectoryURL): * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _resourceDirectoryURL]): * UIProcess/API/Cocoa/WKWebViewPrivate.h: * UIProcess/PageLoadState.cpp: (WebKit::PageLoadState::resourceDirectoryURL const): (WebKit::PageLoadState::setPendingAPIRequestURL): * UIProcess/PageLoadState.h: (WebKit::PageLoadState::setPendingAPIRequestURL): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle): (WebKit::WebPageProxy::loadRequestWithNavigationShared): (WebKit::WebPageProxy::loadFile): (WebKit::WebPageProxy::reload): (WebKit::WebPageProxy::backForwardAddItem): (WebKit::WebPageProxy::backForwardGoToItemShared): (WebKit::WebPageProxy::currentResourceDirectoryURL const): * UIProcess/WebPageProxy.h: 2019-06-21 Antoine Quint <graouts@apple.com> [iOS] Compatibility mouse events aren't prevented by calling preventDefault() on pointerdown https://bugs.webkit.org/show_bug.cgi?id=198124 <rdar://problem/50410863> Reviewed by Dean Jackson. Ensure we wait until completion of a tap before removing the pointer ID and the preventDefault() state along with it. * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _singleTapDidReset:]): (-[WKContentView _commitPotentialTapFailed]): (-[WKContentView _didCompleteSyntheticClick]): (-[WKContentView _singleTapRecognized:]): 2019-06-21 Keith Rollin <krollin@apple.com> Address reference to UIColor.groupTableViewBackgroundColor in WKPasswordView.mm https://bugs.webkit.org/show_bug.cgi?id=199111 <rdar://problem/51992107> Reviewed by Timothy Hatcher. WKPasswordView.mm is used on iOS-family devices. However, it doesn't build on tvOS or watchOS when "treat deprecation warnings as errors" is enabled. This build failure is due to a reference to UIColor.groupTableViewBackgroundColor in a branch of non-dark-mode code. Address this by surrounding the reference with ALLOW_DEPRECATED_DECLARATIONS_* macros. Attempting to address the build failure by unconditionally enabling the dark-mode code works for tvOS, but fails for watchOS due to lack of dark-mode support on that platform. * UIProcess/ios/WKPasswordView.mm: (-[WKPasswordView showInScrollView:]): 2019-06-21 Michael Catanzaro <mcatanzaro@igalia.com> [WPE][GTK] Bump minimum versions of GLib, GTK, libsoup, ATK, GStreamer, and Cairo https://bugs.webkit.org/show_bug.cgi?id=199094 Reviewed by Carlos Garcia Campos. * NetworkProcess/soup/NetworkDataTaskSoup.cpp: (WebKit::NetworkDataTaskSoup::createRequest): (WebKit::NetworkDataTaskSoup::writeDownloadCallback): (WebKit::NetworkDataTaskSoup::writeDownload): (WebKit::NetworkDataTaskSoup::startingCallback): (WebKit::NetworkDataTaskSoup::requestStartedCallback): Deleted. * Shared/gtk/WebEventFactory.cpp: (WebKit::buttonForEvent): (WebKit::WebEventFactory::createWebMouseEvent): (WebKit::WebEventFactory::createWebWheelEvent): (WebKit::WebEventFactory::createWebKeyboardEvent): (WebKit::WebEventFactory::createWebTouchEvent): * UIProcess/API/gtk/PageClientImpl.cpp: (WebKit::PageClientImpl::doneWithTouchEvent): * UIProcess/API/gtk/WebKitWebViewBase.cpp: (ClickCounter::currentClickCountForGdkButtonEvent): (webkitWebViewBaseRealize): (webkitWebViewBaseHandleMouseEvent): (webkitWebViewBaseGetTouchPointsForEvent): (webkitWebViewBaseTouchEvent): (webkitWebViewBaseGestureController): (webkitWebViewBaseEvent): (deviceScaleFactorChanged): (webkitWebViewBaseCreateWebPage): (webkitWebViewBaseTakeViewSnapshot): * UIProcess/API/gtk/WebKitWebViewBasePrivate.h: * UIProcess/API/gtk/WebKitWebViewDialog.cpp: (webkitWebViewDialogDraw): (webkitWebViewDialogConstructed): (webkit_web_view_dialog_class_init): * UIProcess/API/gtk/WebKitWebViewGtk.cpp: (fileChooserDialogResponseCallback): (webkitWebViewRunFileChooser): * UIProcess/Automation/gtk/WebAutomationSessionGtk.cpp: (WebKit::doMouseEvent): (WebKit::doMotionEvent): (WebKit::doKeyStrokeEvent): * UIProcess/WebPageProxy.h: * UIProcess/gtk/AcceleratedBackingStoreWayland.cpp: (WebKit::AcceleratedBackingStoreWayland::~AcceleratedBackingStoreWayland): (WebKit::AcceleratedBackingStoreWayland::tryEnsureGLContext): (WebKit::AcceleratedBackingStoreWayland::makeContextCurrent): (WebKit::AcceleratedBackingStoreWayland::paint): * UIProcess/gtk/AcceleratedBackingStoreWayland.h: * UIProcess/gtk/DragAndDropHandler.cpp: (WebKit::DragAndDropHandler::startDrag): (WebKit::DragAndDropHandler::fillDragData): (WebKit::DragAndDropHandler::finishDrag): * UIProcess/gtk/DragAndDropHandler.h: * UIProcess/gtk/GestureController.cpp: (WebKit::GestureController::handleEvent): * UIProcess/gtk/GestureController.h: * UIProcess/gtk/InputMethodFilter.cpp: (WebKit::InputMethodFilter::filterKeyEvent): (WebKit::InputMethodFilter::logHandleKeyboardEventForTesting): (WebKit::InputMethodFilter::logHandleKeyboardEventWithCompositionResultsForTesting): * UIProcess/gtk/ViewGestureControllerGtk.cpp: (WebKit::isEventStop): (WebKit::createScrollEvent): * UIProcess/gtk/WebContextMenuProxyGtk.cpp: (WebKit::WebContextMenuProxyGtk::append): (WebKit::WebContextMenuProxyGtk::WebContextMenuProxyGtk): (WebKit::WebContextMenuProxyGtk::~WebContextMenuProxyGtk): * UIProcess/gtk/WebKitInspectorWindow.cpp: (webkit_inspector_window_init): (webkitInspectorWindowSetSubtitle): * UIProcess/gtk/WebPageProxyGtk.cpp: (WebKit::WebPageProxy::getCenterForZoomGesture): * UIProcess/gtk/WebPopupMenuProxyGtk.cpp: (WebKit::WebPopupMenuProxyGtk::showPopupMenu): (WebKit::WebPopupMenuProxyGtk::hidePopupMenu): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/gtk/WebPageGtk.cpp: (WebKit::WebPage::getCenterForZoomGesture): 2019-06-20 Patrick Griffis <pgriffis@igalia.com> and Carlos Garcia Campos <cgarcia@igalia.com> [GTK][WPE] Implement a basic DNS cache https://bugs.webkit.org/show_bug.cgi?id=196094 Reviewed by Michael Catanzaro. This adds a simple cache to all DNS operations in the network process. * NetworkProcess/glib/DNSCache.cpp: Added. (WebKit::DNSCache::DNSCache): (WebKit::DNSCache::mapForType): (WebKit::DNSCache::lookup): (WebKit::DNSCache::update): (WebKit::DNSCache::removeExpiredResponsesInMap): (WebKit::DNSCache::pruneResponsesInMap): (WebKit::DNSCache::removeExpiredResponsesFired): (WebKit::DNSCache::clear): * NetworkProcess/glib/DNSCache.h: Added. * NetworkProcess/glib/WebKitCachedResolver.cpp: Added. (addressListVectorToGList): (addressListGListToVector): (webkitCachedResolverLookupByName): (webkitCachedResolverLookupByNameAsync): (webkitCachedResolverLookupByNameFinish): (dnsCacheType): (webkitCachedResolverLookupByNameWithFlags): (webkitCachedResolverLookupByNameWithFlagsAsync): (webkitCachedResolverLookupByNameWithFlagsFinish): (webkitCachedResolverLookupByAddress): (webkitCachedResolverLookupByAddressAsync): (webkitCachedResolverLookupByAddressFinish): (webkitCachedResolverLookupRecords): (webkitCachedResolverLookupRecordsAsync): (webkitCachedResolverLookupRecordsFinish): (webkitCachedResolverReload): (webkit_cached_resolver_class_init): (webkitCachedResolverNew): * NetworkProcess/glib/WebKitCachedResolver.h: Added. * NetworkProcess/soup/NetworkProcessSoup.cpp: (WebKit::NetworkProcess::platformInitializeNetworkProcess): * PlatformGTK.cmake: * PlatformWPE.cmake: * SourcesGTK.txt: * SourcesWPE.txt: 2019-06-20 Carlos Garcia Campos <cgarcia@igalia.com> [GTK] Stop pretending WebCore::Widget can have a platform widget https://bugs.webkit.org/show_bug.cgi?id=199066 Reviewed by Michael Catanzaro. Rename PlatformWidget as PlatformViewWidget to avoid conflict with PlatformWidget defined in WebCore. * UIProcess/WebPageProxy.h: * UIProcess/win/WebPageProxyWin.cpp: (WebKit::WebPageProxy::viewWidget): 2019-06-20 Megan Gardner <megan_gardner@apple.com> Remove change that was causing hangs https://bugs.webkit.org/show_bug.cgi?id=199055 <rdar://problem/51820516> Reviewed by Darin Adler. This fix can sometimes cause deadlocks in the UIProcess. We have a different fix that will go into UIKit <rdar://problem/51927701>. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _selectionChanged]): 2019-06-20 Daniel Bates <dabates@apple.com> [iOS] Evernote crashes when creating a note https://bugs.webkit.org/show_bug.cgi?id=199083 <rdar://problem/51759247> Reviewed by Brent Fulgham. Add a hack just for Evernote linked before iOS 13 that dynamically adds a placeholder -[WKContentView keyCommands] method (it just calls super). Evernote swizzles the IPI -[WKContentView keyCommands], but this method may not always be present in the WebKit binary following r240514. So, Evernote may end up swizzling -[UIResponder keyCommands], but their implementation doesn't account for this scenario and they end up crashing because they call an unrecognized selector. * UIProcess/Cocoa/VersionChecks.h: Add version check. * UIProcess/ios/WKContentView.mm: (keyCommandsPlaceholderHackForEvernote): Added. (-[WKContentView _commonInitializationWithProcessPool:configuration:]): Install the hack. 2019-06-20 Brady Eidson <beidson@apple.com> WebURLSchemeHandlerProxy::loadSynchronously crash with sync request. <rdar://problem/51862206> and https://bugs.webkit.org/show_bug.cgi?id=199063 Reviewed by Geoffrey Garen. Don't use a DataReference for the sync reply type. * UIProcess/WebPageProxy.messages.in: * UIProcess/WebURLSchemeHandler.h: * UIProcess/WebURLSchemeTask.cpp: (WebKit::WebURLSchemeTask::didComplete): * UIProcess/WebURLSchemeTask.h: * WebProcess/WebPage/WebURLSchemeHandlerProxy.cpp: (WebKit::WebURLSchemeHandlerProxy::loadSynchronously): 2019-06-20 Alex Christensen <achristensen@webkit.org> Add unit test for UIContextMenuConfiguration API https://bugs.webkit.org/show_bug.cgi?id=199043 Reviewed by Wenson Hsieh. * UIProcess/API/APIPageConfiguration.cpp: (API::PageConfiguration::copy const): * UIProcess/API/APIPageConfiguration.h: (API::PageConfiguration::clickInteractionDriverForTesting const): (API::PageConfiguration::setClickInteractionDriverForTesting): * UIProcess/API/Cocoa/WKWebViewConfiguration.mm: (-[WKWebViewConfiguration _setClickInteractionDriverForTesting:]): (-[WKWebViewConfiguration _clickInteractionDriverForTesting]): * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _registerPreview]): 2019-06-20 Alexander Mikhaylenko <exalm7659@gmail.com> [GTK] Enable navigation swipe layout tests https://bugs.webkit.org/show_bug.cgi?id=198995 Reviewed by Michael Catanzaro. Implement API for enabling and controlling swipes from WebKitTestRunner. Implement beginSimulatedSwipeInDirectionForTesting() and completeSimulatedSwipeInDirectionForTesting() in ViewGestureController for controlling the test swipes. Add functions in WebKitWebViewBase for calling them. Simulate the gesture by generating two scroll events: one to begin the gesture and one to complete it. Since there's no reliable way to set source device type of the generated events to touchpad, don't check source device type for simulated swipes. * UIProcess/API/C/gtk/WKView.cpp: (WKViewSetEnableBackForwardNavigationGesture): Added. (WKViewBeginBackSwipeForTesting): Added. (WKViewCompleteBackSwipeForTesting): Added. * UIProcess/API/C/gtk/WKViewPrivate.h: * UIProcess/API/gtk/WebKitWebViewBase.cpp: (webkitWebViewBaseBeginBackSwipeForTesting): Added. (webkitWebViewBaseCompleteBackSwipeForTesting): Added. * UIProcess/API/gtk/WebKitWebViewBasePrivate.h: * UIProcess/ViewGestureController.h: * UIProcess/gtk/ViewGestureControllerGtk.cpp: (WebKit::ViewGestureController::PendingSwipeTracker::scrollEventCanInfluenceSwipe): Skip source device type check for simulated swipes. Also, remove an incorrect FIXME. (WebKit::createScrollEvent): Added. (WebKit::ViewGestureController::beginSimulatedSwipeInDirectionForTesting): Implemented. (WebKit::ViewGestureController::completeSimulatedSwipeInDirectionForTesting): Implemented. 2019-06-20 Charlie Turner <cturner@igalia.com> [GTK] Make startup pause available in DEVELOPER_MODE rather than DEBUG. https://bugs.webkit.org/show_bug.cgi?id=199069 Reviewed by Michael Catanzaro. * WebProcess/gtk/WebProcessMainGtk.cpp: Allow developers to pause the web process in DEVELOPER_MODE rather than only DEBUG, matching the WPE behaviour and also the purpose of DEVELOPER_MODE. 2019-06-20 Alexander Mikhaylenko <exalm7659@gmail.com> [GTK] The Previous/Next gesture should handle RTL https://bugs.webkit.org/show_bug.cgi?id=198707 Reviewed by Michael Catanzaro. The gesture uses PageClientImpl::userInterfaceLayoutDirection() to determine the text direction. Implement that method, then adjust drawing so that the pages move from/to the left instead of right side for RTL locales. * UIProcess/API/gtk/PageClientImpl.cpp: (WebKit::): Implemented. * UIProcess/API/gtk/PageClientImpl.h: * UIProcess/gtk/ViewGestureControllerGtk.cpp: (WebKit::ViewGestureController::draw): 2019-06-20 Carlos Garcia Campos <cgarcia@igalia.com> [GTK] Remove support for GTK2 plugins https://bugs.webkit.org/show_bug.cgi?id=199065 Reviewed by Sergio Villar Senin. * PlatformGTK.cmake: * Shared/Plugins/Netscape/NetscapePluginModule.cpp: (WebKit::moduleMixesGtkSymbols): * Shared/Plugins/Netscape/unix/NetscapePluginModuleUnix.cpp: (WebKit::NetscapePluginModule::getPluginInfo): * Shared/Plugins/PluginModuleInfo.h: * Shared/gtk/WebEventFactory.cpp: (WebKit::isGdkKeyCodeFromKeyPad): (WebKit::buttonForEvent): (WebKit::WebEventFactory::createWebMouseEvent): (WebKit::WebEventFactory::createWebWheelEvent): (WebKit::WebEventFactory::createWebKeyboardEvent): (WebKit::WebEventFactory::createWebTouchEvent): * SourcesGTK.txt: * UIProcess/API/gtk/WebKitWebViewBase.cpp: * UIProcess/Launcher/glib/ProcessLauncherGLib.cpp: (WebKit::ProcessLauncher::launchProcess): * UIProcess/Plugins/PluginProcessProxy.h: * UIProcess/Plugins/gtk/PluginInfoCache.cpp: (WebKit::PluginInfoCache::getPluginInfo): (WebKit::PluginInfoCache::updatePluginInfo): * UIProcess/Plugins/unix/PluginInfoStoreUnix.cpp: (WebKit::PluginInfoStore::getPluginInfo): * UIProcess/Plugins/unix/PluginProcessProxyUnix.cpp: (WebKit::PluginProcessProxy::platformGetLaunchOptionsWithAttributes): (WebKit::PluginProcessProxy::scanPlugin): * WebProcess/Plugins/Netscape/x11/NetscapePluginX11.cpp: 2019-06-19 Dean Jackson <dino@apple.com> No menu pop-up when long pressing on a link in Firefox app https://bugs.webkit.org/show_bug.cgi?id=199045 <rdar://problem/51422407> Reviewed by Tim Horton. Add a version check for linking on-or-after iOS 13. When that isn't true, we don't use UIContextMenuInteraction and instead fall back on the legacy UIPreviewItem API. * UIProcess/Cocoa/VersionChecks.h: Add FirstThatHasUIContextMenuInteraction. * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _shouldUseContextMenus]): New method to decide if we should use context menus or preview items. (-[WKContentView setupInteraction]): Make the decision at runtime rather than compile time. (-[WKContentView _contentsOfUserInterfaceItem:]): Ditto. (-[WKContentView _registerPreview]): Ditto. (-[WKContentView _unregisterPreview]): Ditto. 2019-06-19 Andy Estes <aestes@apple.com> [iOS] Fall back to taking a UIView snapshohot for UITargetedPreviews if InteractionInformationAtPosition does not have an image https://bugs.webkit.org/show_bug.cgi?id=199038 <rdar://problem/50555810> Reviewed by Tim Horton. In -contextMenuInteraction:previewForHighlightingMenuWithConfiguration: and friend, we should always return a non-nil UITargetedPreview. When we do return nil, UIKit uses the web view itself as the snapshot view, creating an unsightly animation. For cases where we fail to create a UITargetedPreview from the information in InteractionInformationAtPosition, this patch falls back to creating a UITargetedPreview with a snapshot view obtained from -[UIView resizableSnapshotViewFromRect:afterScreenUpdates:withCapInsets:]. Also renamed -targetedPreview to -_ensureTargetedPreview and cached the UITargetedPreview for reuse in -contextMenuInteraction:previewForDismissingMenuWithConfiguration:. * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (createFallbackTargetedPreview): (-[WKContentView _ensureTargetedPreview]): (-[WKContentView contextMenuInteraction:previewForHighlightingMenuWithConfiguration:]): (-[WKContentView contextMenuInteraction:previewForDismissingMenuWithConfiguration:]): (-[WKContentView contextMenuInteractionDidEnd:]): (-[WKContentView _targetedPreview]): Renamed to _ensureTargetedPreview. 2019-06-19 Devin Rousso <drousso@apple.com> Web Inspector: Network: replace CFNetwork SPI with new API where able https://bugs.webkit.org/show_bug.cgi?id=198762 Reviewed by Timothy Hatcher. * NetworkProcess/cocoa/NetworkSessionCocoa.mm: (-[WKNetworkSessionDelegate URLSession:task:didFinishCollectingMetrics:]): 2019-06-19 Alex Christensen <achristensen@webkit.org> DownloadMonitor::measuredThroughputRate should approach zero with no throughput https://bugs.webkit.org/show_bug.cgi?id=198981 <rdar://problem/51456914> Reviewed by Geoffrey Garen. When the timer fires to approximate the download rate, add a new timestamp with 0 bytes received since the last time we received bytes. Then, if there's only one timestamp, assume the throughput rate is 0 instead of infinite. This will prevent false positives estimating large download rates based on old data when the throughput drops to 0. * NetworkProcess/Downloads/DownloadMonitor.cpp: (WebKit::DownloadMonitor::measuredThroughputRate const): (WebKit::DownloadMonitor::timerFired): 2019-06-19 Sihui Liu <sihui_liu@apple.com> Remove unused originsWithCredentials from WebsiteData https://bugs.webkit.org/show_bug.cgi?id=199020 Reviewed by Geoffrey Garen. * Shared/WebsiteData/WebsiteData.cpp: (WebKit::WebsiteData::encode const): (WebKit::WebsiteData::decode): * Shared/WebsiteData/WebsiteData.h: 2019-06-19 Sihui Liu <sihui_liu@apple.com> Crash at com.apple.WebKit: WebKit::WebsiteDataStore::processPools const https://bugs.webkit.org/show_bug.cgi?id=198935 <rdar://problem/51549308> Reviewed by Geoffrey Garen. When WebProcessProxy is in WebProcessCache or is pre-warmed, it does not hold a strong reference of WebProcessPool. In this case, we should not store the raw pointer of WebProcessPool and perform websiteDataStore operations with it. This patch should fix the crash at dereferencing null pointer of WebProcessPool in WebsiteDataStore::processPools, but it is unclear why websiteDataStore comes to observe cached or prewarmed web process that should not have web page. The release log may help us find the cause. * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::processPoolIfExists const): * UIProcess/WebProcessProxy.h: * UIProcess/WebsiteData/WebsiteDataStore.cpp: (WebKit::WebsiteDataStore::processPools const): 2019-06-19 Alex Christensen <achristensen@webkit.org> Add a unit test for client certificate authentication https://bugs.webkit.org/show_bug.cgi?id=197800 Reviewed by Youenn Fablet. * Shared/cf/ArgumentCodersCF.cpp: Move SPI declarations to SecuritySPI.h. 2019-06-19 Alex Christensen <achristensen@webkit.org> Update preview API deprecation message. https://bugs.webkit.org/show_bug.cgi?id=198974 * UIProcess/API/Cocoa/WKUIDelegate.h: 2019-06-19 Adrian Perez de Castro <aperez@igalia.com> [GTK] Fix compilation errors for the GTK2 plugin process https://bugs.webkit.org/show_bug.cgi?id=199000 Reviewed by Michael Catanzaro. * Shared/gtk/WebEventFactory.cpp: Use the GdkEvent union fields when directly accessing event struct fields. (WebKit::buttonForEvent): (WebKit::WebEventFactory::createWebMouseEvent): (WebKit::WebEventFactory::createWebKeyboardEvent): 2019-06-19 Adrian Perez de Castro <aperez@igalia.com> [WPE][GTK] Fix build with unified sources disabled https://bugs.webkit.org/show_bug.cgi?id=198752 Reviewed by Michael Catanzaro. * NetworkProcess/NetworkHTTPSUpgradeChecker.cpp: (WebKit::NetworkHTTPSUpgradeChecker::NetworkHTTPSUpgradeChecker): Qualify SQLiteDatabase with its namespace. * UIProcess/WebFrameProxy.h: Replace forward declaration of WebPageProxy with inclusion of WebPageProxy.h to avoid build error due to usage of undefined class. Moved DataCallback definition from WebPageProxy.h to avoid code using the type before its declaration. * UIProcess/WebPageProxy.h: Remove definition of DataCallback. * UIProcess/wpe/WebInspectorProxyWPE.cpp: Add missing forward declaration of WebCore::FloatRect. (WebKit::WebInspectorProxy::platformSetSheetRect): Qualify FloatRect with its namespace. * WebProcess/Automation/WebAutomationSessionProxy.cpp: Qualify all occurrences of PageIdentifier with its namespace. (WebKit::WebAutomationSessionProxy::evaluateJavaScriptFunction): (WebKit::WebAutomationSessionProxy::resolveChildFrameWithOrdinal): (WebKit::WebAutomationSessionProxy::resolveChildFrameWithNodeHandle): (WebKit::WebAutomationSessionProxy::resolveChildFrameWithName): (WebKit::WebAutomationSessionProxy::resolveParentFrame): (WebKit::WebAutomationSessionProxy::focusFrame): (WebKit::WebAutomationSessionProxy::computeElementLayout): (WebKit::WebAutomationSessionProxy::selectOptionElement): (WebKit::WebAutomationSessionProxy::takeScreenshot): (WebKit::WebAutomationSessionProxy::getCookiesForFrame): (WebKit::WebAutomationSessionProxy::deleteCookie): * WebProcess/Cache/WebCacheStorageConnection.cpp: Ditto. (WebKit::WebCacheStorageConnection::open): (WebKit::WebCacheStorageConnection::remove): (WebKit::WebCacheStorageConnection::retrieveCaches): (WebKit::WebCacheStorageConnection::retrieveRecords): (WebKit::WebCacheStorageConnection::batchDeleteOperation): (WebKit::WebCacheStorageConnection::batchPutOperation): * WebProcess/WebCoreSupport/gtk/WebEditorClientGtk.cpp: Add missing inclusion of WebPage.h * WebProcess/WebPage/gtk/WebPageGtk.cpp: Add missing inclusion of gtk/gtk.h * WebProcess/WebPage/wpe/WebPageWPE.cpp: Add missing inclusion of WebPageProxy.h 2019-06-19 Alexander Mikhaylenko <exalm7659@gmail.com> [GTK] Page blinks after navigation swipe if it triggered PSON https://bugs.webkit.org/show_bug.cgi?id=198996 Reviewed by Michael Catanzaro. Disconnect and then reconnect ViewGestureController during process swap instead of destroying and re-creating it. * UIProcess/API/gtk/PageClientImpl.cpp: (WebKit::PageClientImpl::PageClientImpl::processWillSwap): Added. (WebKit::PageClientImpl::PageClientImpl::processDidExit): Implemented. * UIProcess/API/gtk/PageClientImpl.h: * UIProcess/API/gtk/WebKitWebViewBase.cpp: (webkitWebViewBaseWillSwapWebProcess): Added. Disconnect ViewGestureController if it exists. (webkitWebViewBaseDidExitWebProcess): Added. Destroy ViewGestureController. (webkitWebViewBaseDidRelaunchWebProcess): Reconnect the ViewGestureController if it exists. * UIProcess/API/gtk/WebKitWebViewBasePrivate.h: 2019-06-19 Takashi Komori <Takashi.Komori@sony.com> [Curl] CurlRequestScheduler doesn't terminate worker thread in a certain situation. https://bugs.webkit.org/show_bug.cgi?id=198993 Cancel CurlRequest before invalidation to remove tasks from CurlRequestScheduler certainly in ~NetworkDataTaskCurl. Reviewed by Fujii Hironori. * NetworkProcess/curl/NetworkDataTaskCurl.cpp: (WebKit::NetworkDataTaskCurl::~NetworkDataTaskCurl): 2019-06-19 Zan Dobersek <zdobersek@igalia.com> [Nicosia] Invalidate SceneIntegration in LayerTreeHost::invalidate() https://bugs.webkit.org/show_bug.cgi?id=198992 Reviewed by Carlos Garcia Campos. * WebProcess/WebPage/CoordinatedGraphics/LayerTreeHost.cpp: (WebKit::LayerTreeHost::invalidate): Invalidate the Nicosia::SceneIntegration object. This should properly disassociate the now-invalited LayerTreeHost (a SceneIntegration client) from the SceneIntegration object that can still be shared with platform layers originating from this LayerTreeHost. 2019-06-18 Dean Jackson <dino@apple.com> UIContextMenuInteraction implementation for WKContentView https://bugs.webkit.org/show_bug.cgi?id=198986 <rdar://problem/51875189> Reviewed by Andy Estes. Implement UIContextMenuInteraction and its delegate as a replacement for UIPreviewItemController in iOS 13. In order to preserve existing behaviour as much as possible, we check for the implementation of new WebKit API to configure the menu. If that is not present, we attempt to convert the results of the existing WebKit WKPreviewAction delegates into something that works with UIContextMenus. * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView setupInteraction]): (-[WKContentView _contentsOfUserInterfaceItem:]): (-[WKContentView _registerPreview]): (-[WKContentView _unregisterPreview]): (-[WKContentView _showLinkPreviewsPreferenceChanged:]): (needsDeprecatedPreviewAPI): (uiActionForPreviewAction): (menuFromPreviewOrDefaults): (titleForMenu): (-[WKContentView assignLegacyDataForContextMenuInteraction]): (-[WKContentView contextMenuInteraction:configurationForMenuAtLocation:]): (-[WKContentView _contextMenuInteraction:configurationForMenuAtLocation:completion:]): (-[WKContentView continueContextMenuInteraction:]): (uiImageForImage): (createTargetedPreview): (-[WKContentView _targetedPreview]): (-[WKContentView contextMenuInteraction:previewForHighlightingMenuWithConfiguration:]): (-[WKContentView contextMenuInteractionWillPresent:]): (-[WKContentView contextMenuInteraction:previewForDismissingMenuWithConfiguration:]): (-[WKContentView contextMenuInteraction:willCommitWithAnimator:]): (-[WKContentView contextMenuInteractionDidEnd:]): (-[WKContentView shouldUsePreviewForLongPress]): Deleted. 2019-06-18 Ryan Haddad <ryanhaddad@apple.com> Unreviewed, rolling out r246575. Breaks internal builds. Reverted changeset: "Update WebKit API to separately retrieve actions and use context menus" https://bugs.webkit.org/show_bug.cgi?id=198974 https://trac.webkit.org/changeset/246575 2019-06-18 Alex Christensen <achristensen@webkit.org> Update WebKit API to separately retrieve actions and use context menus https://bugs.webkit.org/show_bug.cgi?id=198974 <rdar://problem/50735687> Reviewed by Tim Horton. Update API and SPI, and add infrastructure for asynchronously requesting interaction information. * UIProcess/API/Cocoa/WKUIDelegate.h: * UIProcess/API/Cocoa/WKUIDelegatePrivate.h: 2019-06-18 Daniel Bates <dabates@apple.com> REGRESSION (r240757): Cannot dismiss the keyboard on http://apple.com/apple-tv-plus https://bugs.webkit.org/show_bug.cgi?id=198922 <rdar://problem/50300056> Reviewed by Wenson Hsieh. Actually dismiss the keyboard as intended in r240757. Do not wait for the round-trip to the WebProcess to run through the -elementDidBlur steps in the UIProcess and hide the keyboard when a person explicitly dismisses the keyboard via the Done button (iPhone) or hide keyboard button (iPad). Note that r240757 revealed another bug in this code, <https://bugs.webkit.org/show_bug.cgi?id=198928>. I am unclear of the implications of that bug, but it is clear for this bug that it never makes sense to round-trip to the WebProcess when the keyboard is dismissed by a user gesture. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView endEditingAndUpdateFocusAppearanceWithReason:]): Invoke -_elementDidBlur to blur the element in the UIProcess and hide the keyboard. (-[WKContentView _elementDidBlur]): Prevent duplicate invocations of -didEndFormControlInteraction and setIsShowingInputViewForFocusedElement messages by only doing these actions when editablity changes. This covers the case where -_elementDidBlur may be invoked a second time (the reply in the round-trip). In that case we don't need to do these actions. 2019-06-18 Alex Christensen <achristensen@webkit.org> NetworkSession::networkStorageSession can return null https://bugs.webkit.org/show_bug.cgi?id=198947 <rdar://problem/51394449> Reviewed by Youenn Fablet. We are seeing evidence of crashes from the map owning NetworkSessions and the map owning NetworkStorageSessions becoming out of sync because NetworkSession is refcounted but NetworkStorageSession is not. I started the complete fix in https://bugs.webkit.org/show_bug.cgi?id=194926 but for now let's add less risky null checks to prevent fallout. * NetworkProcess/Classifier/ResourceLoadStatisticsStore.cpp: (WebKit::ResourceLoadStatisticsStore::updateClientSideCookiesAgeCap): * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp: (WebKit::WebResourceLoadStatisticsStore::hasStorageAccessForFrame): (WebKit::WebResourceLoadStatisticsStore::callHasStorageAccessForFrameHandler): (WebKit::WebResourceLoadStatisticsStore::grantStorageAccess): (WebKit::WebResourceLoadStatisticsStore::removeAllStorageAccess): (WebKit::WebResourceLoadStatisticsStore::setCacheMaxAgeCap): (WebKit::WebResourceLoadStatisticsStore::callUpdatePrevalentDomainsToBlockCookiesForHandler): (WebKit::WebResourceLoadStatisticsStore::removePrevalentDomains): * NetworkProcess/NetworkProcess.cpp: (WebKit::NetworkProcess::initializeNetworkProcess): * NetworkProcess/NetworkSession.cpp: (WebKit::NetworkSession::networkStorageSession const): * NetworkProcess/NetworkSession.h: * NetworkProcess/cocoa/NetworkDataTaskCocoa.mm: (WebKit::NetworkDataTaskCocoa::applyCookieBlockingPolicy): (WebKit::NetworkDataTaskCocoa::NetworkDataTaskCocoa): (WebKit::NetworkDataTaskCocoa::willPerformHTTPRedirection): (WebKit::NetworkDataTaskCocoa::tryPasswordBasedAuthentication): 2019-06-18 Brady Eidson <beidson@apple.com> Handle NSProgress calling our cancellation handler on background threads (and calling it more than once). <rdar://problem/51392926> and https://bugs.webkit.org/show_bug.cgi?id=198945 Reviewed by Alex Christensen. If you have a download in progress and quickly tap the button to cancel it multiple times, then: - NSProgress calls our cancellation handler on a non-main thread, which we can't handle. - They do it more than once, which is also bad. - They might even do it multiple times concurrently (on different background dispatch queues) Let's work around these. * NetworkProcess/Downloads/Download.cpp: (WebKit::Download::cancel): Double check we're on the main thread, and handle being called twice. * NetworkProcess/Downloads/cocoa/WKDownloadProgress.mm: (-[WKDownloadProgress performCancel]): Actually cancel the WebKit::Download if we still have one. (-[WKDownloadProgress progressCancelled]): Called when NSProgress calls the cancellation handler, no matter which thread it does it on. By leveraging std::call_once we handle multiple calls as well as being called concurrently from different threads. call_once punts the *actual* cancel operation off to the main thread. (-[WKDownloadProgress initWithDownloadTask:download:URL:sandboxExtension:]): The cancellation handler is now simply calling 'progressCancelled' on self, assuming the weak pointer for self is still valid. 2019-06-18 Daniel Bates <dabates@apple.com> [iOS] Pressing key while holding Command should not insert character https://bugs.webkit.org/show_bug.cgi?id=198925 <rdar://problem/51778811> Reviewed by Brent Fulgham. Do not insert a character for an unhandled key command that has a Command modifier. For example, pressing Command + Shift + v, which is an unhandled key command (at the time of writing) should not insert v. This matches iOS and Mac platform conventions. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _interpretKeyEvent:isCharEvent:]): 2019-06-18 John Wilander <wilander@apple.com> Change log channel name from ResourceLoadStatisticsDebug to ITPDebug and remove unnecessary #if !RELEASE_LOG_DISABLED https://bugs.webkit.org/show_bug.cgi?id=198970 <rdar://problem/51855836> Reviewed by Brent Fulgham. * NetworkProcess/Classifier/ResourceLoadStatisticsDatabaseStore.cpp: (WebKit::ResourceLoadStatisticsDatabaseStore::requestStorageAccess): (WebKit::ResourceLoadStatisticsDatabaseStore::requestStorageAccessUnderOpener): (WebKit::ResourceLoadStatisticsDatabaseStore::ensurePrevalentResourcesForDebugMode): (WebKit::ResourceLoadStatisticsDatabaseStore::updateCookieBlocking): * NetworkProcess/Classifier/ResourceLoadStatisticsMemoryStore.cpp: (WebKit::ResourceLoadStatisticsMemoryStore::requestStorageAccess): (WebKit::ResourceLoadStatisticsMemoryStore::requestStorageAccessUnderOpener): (WebKit::ResourceLoadStatisticsMemoryStore::ensurePrevalentResourcesForDebugMode): (WebKit::ResourceLoadStatisticsMemoryStore::updateCookieBlocking): * NetworkProcess/Classifier/ResourceLoadStatisticsStore.cpp: (WebKit::domainsToString): (WebKit::ResourceLoadStatisticsStore::removeDataRecords): (WebKit::ResourceLoadStatisticsStore::setResourceLoadStatisticsDebugMode): (WebKit::ResourceLoadStatisticsStore::debugLogDomainsInBatches): * Platform/Logging.h: 2019-06-18 Youenn Fablet <youenn@apple.com> StorageManager::removeAllowedSessionStorageNamespaceConnection should make sure its storageNamespaceID is valid https://bugs.webkit.org/show_bug.cgi?id=198966 rdar://problem/51352080 Reviewed by Alex Christensen. Make sure the namespace ID is a key of the map before using the value. The namespace ID is coming straight from IPC so should not be trusted. Also, namespace IDs are added/removed based on web pages being created/deleted. Namespace IDs are supposed to be scoped by session IDs. Using page IDs for namespace IDs works as long as the page does not change of session ID during its lifetime, which is not guaranteed. * NetworkProcess/WebStorage/StorageManager.cpp: (WebKit::StorageManager::removeAllowedSessionStorageNamespaceConnection): 2019-06-18 David Quesada <david_quesada@apple.com> Network process crash in SandboxExtension::consume() via Download::publishProgress https://bugs.webkit.org/show_bug.cgi?id=198968 rdar://problem/51732997 Reviewed by Alex Christensen. Add an early return if the network process fails to resolve a sandbox extension handle for publishing progress on a download. Creating the NSProgress doesn't do much since the progress reporting service won't honor the attempt to publish progress on a URL the process does not have access to, and nothing else in the Network process makes any use of the progress. * NetworkProcess/Downloads/cocoa/DownloadCocoa.mm: (WebKit::Download::publishProgress): 2019-06-18 Adrian Perez de Castro <aperez@igalia.com> Unreviewed. Update OptionsWPE.cmake and NEWS for the 2.25.1 release * wpe/NEWS: Add release notes for 2.25.1 2019-06-18 Tim Horton <timothy_horton@apple.com> Expose DataDetectors context generation on WKContentViewInteraction https://bugs.webkit.org/show_bug.cgi?id=198950 <rdar://problem/51116021> Reviewed by Andy Estes. * UIProcess/ios/WKActionSheetAssistant.h: * UIProcess/ios/WKActionSheetAssistant.mm: (-[WKActionSheetAssistant currentPositionInformation]): (-[WKActionSheetAssistant showDataDetectorsSheet]): * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView dataDetectionContextForPositionInformation:]): (-[WKContentView dataDetectionContextForActionSheetAssistant:]): For use by other clients, add -dataDetectionContextForPositionInformation: and make -dataDetectionContextForActionSheetAssistant: use it. Also, pull the code to augment the context with surrounding text out of from WKActionSheetAssistant. 2019-06-18 Adrian Perez de Castro <aperez@igalia.com> [WPE] Fix building the documentation Unreviewed. * UIProcess/API/wpe/docs/wpe-docs.sgml: Fix typo "2.62" -> "2.26" 2019-06-18 Truitt Savell <tsavell@apple.com> Unreviewed, rolling out r246531. Broke internal builds. Reverted changeset: "Expose DataDetectors context generation on WKContentViewInteraction" https://bugs.webkit.org/show_bug.cgi?id=198950 https://trac.webkit.org/changeset/246531 2019-06-18 Simon Fraser <simon.fraser@apple.com> Convert macOS to scroll by changing layer boundsOrigin https://bugs.webkit.org/show_bug.cgi?id=198917 Reviewed by Antti Koivisto. Remove unreached and confusing code. * UIProcess/RemoteLayerTree/ios/ScrollingTreeFrameScrollingNodeRemoteIOS.mm: (WebKit::ScrollingTreeFrameScrollingNodeRemoteIOS::repositionScrollingLayers): 2019-06-18 Dean Jackson <dino@apple.com> Attachment elements are missing context menu previews https://bugs.webkit.org/show_bug.cgi?id=198946 Reviewed by Tim Horton. When requesting position information on an <attachment> element, we were not providing a snapshot image. * WebProcess/WebPage/WebPage.h: New common method to take a snapshot. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::shareableBitmapSnapshotForNode): New helper. (WebKit::WebPage::positionInformation): If the element is an attachment, then ask for a snapshot. 2019-06-17 Tim Horton <timothy_horton@apple.com> Expose DataDetectors context generation on WKContentViewInteraction https://bugs.webkit.org/show_bug.cgi?id=198950 <rdar://problem/51116021> Reviewed by Andy Estes. * UIProcess/ios/WKActionSheetAssistant.h: * UIProcess/ios/WKActionSheetAssistant.mm: (-[WKActionSheetAssistant currentPositionInformation]): (-[WKActionSheetAssistant showDataDetectorsSheet]): * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView dataDetectionContextForPositionInformation:]): (-[WKContentView dataDetectionContextForActionSheetAssistant:]): For use by other clients, add -dataDetectionContextForPositionInformation: and make -dataDetectionContextForActionSheetAssistant: use it. Also, pull the code to augment the context with surrounding text out of from WKActionSheetAssistant. 2019-06-17 Sihui Liu <sihui_liu@apple.com> -[WKWebsiteDataStore removeDataOfTypes:modifiedSince:completionHandler:] doesn't delete _WKWebsiteDataTypeCredentials https://bugs.webkit.org/show_bug.cgi?id=198854 <rdar://problem/51386058> Reviewed by Geoffrey Garen. Clear persistent credentials in deleteWebsiteData of network process. Also, merge originsWithPersistentCredentials and removeCredentialsWithOrigins into fetchWebsiteData and deleteWebsiteData, and move credentials handling to WebCore. * NetworkProcess/NetworkProcess.cpp: (WebKit::NetworkProcess::fetchWebsiteData): (WebKit::NetworkProcess::deleteWebsiteData): (WebKit::NetworkProcess::deleteWebsiteDataForOrigins): (WebKit::NetworkProcess::originsWithPersistentCredentials): Deleted. (WebKit::NetworkProcess::removeCredentialsWithOrigins): Deleted. * NetworkProcess/NetworkProcess.h: * NetworkProcess/NetworkProcess.messages.in: * NetworkProcess/cocoa/NetworkProcessCocoa.mm: (WebKit::NetworkProcess::originsWithPersistentCredentials): Deleted. (WebKit::NetworkProcess::removeCredentialsWithOrigins): Deleted. * UIProcess/WebsiteData/WebsiteDataStore.cpp: (WebKit::WebsiteDataStore::fetchDataAndApply): (WebKit::computeWebProcessAccessTypeForDataRemoval): (WebKit::WebsiteDataStore::removeData): 2019-06-17 Tim Horton <timothy_horton@apple.com> Fix the build with case-sensitive includes <rdar://problem/51828273> * UIProcess/API/Cocoa/WKContentRuleListStore.mm: FileSystem, not Filesystem. 2019-06-17 Jiewen Tan <jiewen_tan@apple.com> Unreviewed, build fix after r246514 * UIProcess/Cocoa/SOAuthorization/SOAuthorizationNSURLExtras.h: * UIProcess/Cocoa/SOAuthorization/SOAuthorizationNSURLExtras.mm: (+[NSURL _web_canPerformAuthorizationWithURL:]): Expose the above method as a SPI for Safari. * WebKit.xcodeproj/project.pbxproj: 2019-06-17 Alex Christensen <achristensen@webkit.org> Protect StorageManager::m_localStorageNamespaces with a Lock https://bugs.webkit.org/show_bug.cgi?id=198939 <rdar://problem/51784225> Reviewed by Geoff Garen. StorageManager::LocalStorageNamespace::didDestroyStorageArea is called from StorageArea::~StorageArea which is called on the main thread. All other access of m_localStorageNamespaces is from the non-main thread. Sometimes this causes hash table corruption, so wait for a mutex before accessing this member variable. * NetworkProcess/WebStorage/StorageManager.cpp: (WebKit::StorageManager::LocalStorageNamespace::didDestroyStorageArea): (WebKit::StorageManager::cloneSessionStorageNamespace): (WebKit::StorageManager::getLocalStorageOrigins): (WebKit::StorageManager::deleteLocalStorageEntriesForOrigin): (WebKit::StorageManager::deleteLocalStorageOriginsModifiedSince): (WebKit::StorageManager::deleteLocalStorageEntriesForOrigins): (WebKit::StorageManager::getOrCreateLocalStorageNamespace): * NetworkProcess/WebStorage/StorageManager.h: 2019-06-17 Alex Christensen <achristensen@webkit.org> Add null check in WebFrameLoaderClient::assignIdentifierToInitialRequest https://bugs.webkit.org/show_bug.cgi?id=198926 <rdar://problem/50079713> Reviewed by Brady Eidson. * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::assignIdentifierToInitialRequest): WebKitLegacy's version already checks null for the corresponding call. 2019-06-17 Alex Christensen <achristensen@webkit.org> Fix internal build after r246514 https://bugs.webkit.org/show_bug.cgi?id=198874 * UIProcess/API/APINavigationAction.h: A problematic reference to APINavigationActionAdditions.h was left. Its contents had been sprinkled into the correct places, though. 2019-06-17 Jiewen Tan <jiewen_tan@apple.com> Move SOAuthorization from WebKitAdditions to WebKit https://bugs.webkit.org/show_bug.cgi?id=198874 <rdar://problem/47573431> Reviewed by Brent Fulgham. This patch basically moves everything from existing WebKitAdditions to WebKit. It also replaces the LoadOptimizer nonsense with the actual SOAuthorization API. * Configurations/WebKit.xcconfig: * NetworkProcess/cocoa/NetworkSessionCocoa.mm: (WebKit::NetworkSessionCocoa::NetworkSessionCocoa): * PluginProcess/mac/PluginProcessMac.mm: (WebKit::PluginProcess::platformInitializePluginProcess): * SourcesCocoa.txt: * UIProcess/API/APINavigationAction.h: * UIProcess/Cocoa/NavigationState.mm: (WebKit::trySOAuthorization): (WebKit::tryInterceptNavigation): (WebKit::NavigationState::NavigationClient::decidePolicyForNavigationAction): (WebKit::tryOptimizingLoad): Deleted. * UIProcess/Cocoa/SOAuthorization/NavigationSOAuthorizationSession.h: Added. (WebKit::NavigationSOAuthorizationSession::callback): * UIProcess/Cocoa/SOAuthorization/NavigationSOAuthorizationSession.mm: Copied from Tools/TestWebKitAPI/Tests/WebKitCocoa/TestLoadOptimizer.mm. (WebKit::NavigationSOAuthorizationSession::NavigationSOAuthorizationSession): (WebKit::NavigationSOAuthorizationSession::~NavigationSOAuthorizationSession): (WebKit::NavigationSOAuthorizationSession::shouldStartInternal): (WebKit::NavigationSOAuthorizationSession::webViewDidMoveToWindow): * UIProcess/Cocoa/SOAuthorization/PopUpSOAuthorizationSession.h: Added. * UIProcess/Cocoa/SOAuthorization/PopUpSOAuthorizationSession.mm: Added. (-[WKSOSecretDelegate initWithSession:]): (-[WKSOSecretDelegate webViewDidClose:]): (-[WKSOSecretDelegate webView:decidePolicyForNavigationAction:decisionHandler:]): (-[WKSOSecretDelegate webView:didFinishNavigation:]): (WebKit::PopUpSOAuthorizationSession::PopUpSOAuthorizationSession): (WebKit::PopUpSOAuthorizationSession::~PopUpSOAuthorizationSession): (WebKit::PopUpSOAuthorizationSession::shouldStartInternal): (WebKit::PopUpSOAuthorizationSession::fallBackToWebPathInternal): (WebKit::PopUpSOAuthorizationSession::abortInternal): (WebKit::PopUpSOAuthorizationSession::completeInternal): (WebKit::PopUpSOAuthorizationSession::close): (WebKit::PopUpSOAuthorizationSession::initSecretWebView): * UIProcess/Cocoa/SOAuthorization/RedirectSOAuthorizationSession.h: Copied from Tools/TestWebKitAPI/Tests/WebKitCocoa/TestLoadOptimizer.mm. * UIProcess/Cocoa/SOAuthorization/RedirectSOAuthorizationSession.mm: Added. (WebKit::RedirectSOAuthorizationSession::RedirectSOAuthorizationSession): (WebKit::RedirectSOAuthorizationSession::fallBackToWebPathInternal): (WebKit::RedirectSOAuthorizationSession::abortInternal): (WebKit::RedirectSOAuthorizationSession::completeInternal): (WebKit::RedirectSOAuthorizationSession::beforeStart): * UIProcess/Cocoa/SOAuthorization/SOAuthorizationCoordinator.h: Copied from Tools/TestWebKitAPI/Tests/WebKitCocoa/TestLoadOptimizer.mm. * UIProcess/Cocoa/SOAuthorization/SOAuthorizationCoordinator.mm: Added. (WebKit::SOAuthorizationCoordinator::SOAuthorizationCoordinator): (WebKit::SOAuthorizationCoordinator::canAuthorize const): (WebKit::SOAuthorizationCoordinator::tryAuthorize): * UIProcess/Cocoa/SOAuthorization/SOAuthorizationNSURLExtras.h: Copied from Tools/TestWebKitAPI/Tests/WebKitCocoa/TestLoadOptimizer.mm. * UIProcess/Cocoa/SOAuthorization/SOAuthorizationNSURLExtras.mm: Copied from Tools/TestWebKitAPI/Tests/WebKitCocoa/TestLoadOptimizer.mm. (+[NSURL _web_canPerformAuthorizationWithURL:]): * UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.h: Added. (WebKit::SOAuthorizationSession::page const): (WebKit::SOAuthorizationSession::state const): (WebKit::SOAuthorizationSession::setState): (WebKit::SOAuthorizationSession::navigationAction): * UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.mm: Added. (WebKit::SOAuthorizationSession::SOAuthorizationSession): (WebKit::SOAuthorizationSession::~SOAuthorizationSession): (WebKit::SOAuthorizationSession::releaseNavigationAction): (WebKit::SOAuthorizationSession::becomeCompleted): (WebKit::SOAuthorizationSession::shouldStart): (WebKit::SOAuthorizationSession::start): (WebKit::SOAuthorizationSession::fallBackToWebPath): (WebKit::SOAuthorizationSession::abort): (WebKit::SOAuthorizationSession::complete): (WebKit::SOAuthorizationSession::presentViewController): (WebKit::SOAuthorizationSession::dismissViewController): * UIProcess/Cocoa/SOAuthorization/SubFrameSOAuthorizationSession.h: Copied from Tools/TestWebKitAPI/Tests/WebKitCocoa/TestLoadOptimizer.mm. * UIProcess/Cocoa/SOAuthorization/SubFrameSOAuthorizationSession.mm: Added. (WebKit::SubFrameSOAuthorizationSession::SubFrameSOAuthorizationSession): (WebKit::SubFrameSOAuthorizationSession::fallBackToWebPathInternal): (WebKit::SubFrameSOAuthorizationSession::abortInternal): (WebKit::SubFrameSOAuthorizationSession::completeInternal): (WebKit::SubFrameSOAuthorizationSession::beforeStart): (WebKit::SubFrameSOAuthorizationSession::loadDataToFrame): (WebKit::SubFrameSOAuthorizationSession::postDidCancelMessageToParent): * UIProcess/Cocoa/SOAuthorization/WKSOAuthorizationDelegate.h: Renamed from Tools/TestWebKitAPI/Tests/WebKitCocoa/TestLoadOptimizer.mm. * UIProcess/Cocoa/SOAuthorization/WKSOAuthorizationDelegate.mm: Added. (-[WKSOAuthorizationDelegate authorization:presentViewController:withCompletion:]): (-[WKSOAuthorizationDelegate authorizationDidNotHandle:]): (-[WKSOAuthorizationDelegate authorizationDidCancel:]): (-[WKSOAuthorizationDelegate authorizationDidComplete:]): (-[WKSOAuthorizationDelegate authorization:didCompleteWithHTTPAuthorizationHeaders:]): (-[WKSOAuthorizationDelegate authorization:didCompleteWithHTTPResponse:httpBody:]): (-[WKSOAuthorizationDelegate authorization:didCompleteWithError:]): (-[WKSOAuthorizationDelegate setSession:]): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::decidePolicyForNavigationAction): (WebKit::trySOAuthorization): (WebKit::WebPageProxy::createNewPage): (WebKit::tryOptimizingLoad): Deleted. * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::setShouldSuppressSOAuthorizationInAllNavigationPolicyDecision): (WebKit::WebPageProxy::setShouldSuppressSOAuthorizationInNextNavigationPolicyDecision): * UIProcess/WebsiteData/WebsiteDataStore.cpp: (WebKit::WebsiteDataStore::WebsiteDataStore): * UIProcess/WebsiteData/WebsiteDataStore.h: (WebKit::WebsiteDataStore::soAuthorizationCoordinator): * WebKit.xcodeproj/project.pbxproj: * WebProcess/cocoa/WebProcessCocoa.mm: (WebKit::WebProcess::platformInitializeProcess): 2019-06-17 Tim Horton <timothy_horton@apple.com> Fix the build. * UIProcess/Gamepad/ios/UIGamepadProviderIOS.mm: (WebKit::UIGamepadProvider::platformWebPageProxyForGamepadInput): * UIProcess/_WKTouchEventGenerator.mm: (-[_WKTouchEventGenerator _sendHIDEvent:]): (-[_WKTouchEventGenerator _sendMarkerHIDEventWithCompletionBlock:]): 2019-06-17 Dan Bernstein <mitz@apple.com> REGRESSION (r242686): Paths in XPC services’ LC_DYLD_ENVIRONMENT are incorrect in built products directory https://bugs.webkit.org/show_bug.cgi?id=198904 Reviewed by Alex Christensen. After r242686, in local builds, the XPC service executables run from their location at the top of the built products directory, rather than inside the framework. * Configurations/BaseXPCService.xcconfig: Updated the load commands that set DYLD_FRAMEWORK_PATH and DYLD_LIBRARY_PATH for the new location in the built products directory. Also removed WK_XPC_SERVICE_INSERT_LIBRARIES_DIR that had been unused. * WebKit.xcodeproj/project.pbxproj: Made the creation of symbolic links inside the framework’s XPCServices directory predicated on whether this is an install build, rather than on the build configuration, for consistency with the condition used in the .xcconfig. 2019-06-17 Brent Fulgham <bfulgham@apple.com> Ensure ITP state is relayed to Network Process on restart https://bugs.webkit.org/show_bug.cgi?id=198797 <rdar://problem/51646944> Reviewed by Youenn Fablet. Now that the ITP state is maintained in the Network Process, we have to make sure that we update that process with current ITP state if the Network Process crashes and is relaunched. This wasn't a problem in earlier releases because we tracked all ITP state in the UIProcess. This patch does the following: 1. Add a new method to WKWebsiteDataStore to allow us to trigger statistics processing, which has the side effect of syncing ITP state persistently so that it will be available after bouncing the process. 2. Adds a new test that sets a tracking domain, bounces the process, and confirms the state is still consistent. Tested by TestWebKitAPI. * NetworkProcess/Classifier/ResourceLoadStatisticsStore.cpp: (WebKit::ResourceLoadStatisticsStore::processStatisticsAndDataRecords): * UIProcess/API/Cocoa/WKWebsiteDataStore.mm: (-[WKWebsiteDataStore _clearPrevalentDomain:completionHandler:]): (-[WKWebsiteDataStore _processStatisticsAndDataRecords:]): * UIProcess/API/Cocoa/WKWebsiteDataStorePrivate.h: * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::ensureNetworkProcess): (WebKit::WebProcessPool::setResourceLoadStatisticsEnabled): * UIProcess/WebProcessPool.h: * UIProcess/WebsiteData/WebsiteDataStore.cpp: (WebKit::WebsiteDataStore::setResourceLoadStatisticsEnabled): 2019-06-17 Ludovico de Nittis <ludovico.denittis@collabora.com> [GTK] Stop accessing GdkEvent fields when possible https://bugs.webkit.org/show_bug.cgi?id=198829 Reviewed by Michael Catanzaro. Direct access to GdkEvent structs is no longer possible in GTK 4. * Shared/gtk/WebEventFactory.cpp: (WebKit::buttonForEvent): (WebKit::WebEventFactory::createWebMouseEvent): (WebKit::WebEventFactory::createWebWheelEvent): (WebKit::WebEventFactory::createWebKeyboardEvent): (WebKit::WebEventFactory::createWebTouchEvent): * UIProcess/API/gtk/WebKitEmojiChooser.cpp: * UIProcess/API/gtk/WebKitScriptDialogImpl.cpp: (webkitScriptDialogImplKeyPressEvent): * UIProcess/API/gtk/WebKitWebViewBase.cpp: (ClickCounter::currentClickCountForGdkButtonEvent): (webkitWebViewBaseKeyPressEvent): (webkitWebViewBaseHandleMouseEvent): (webkitWebViewBaseCrossingNotifyEvent): (webkitWebViewBaseGetTouchPointsForEvent): (webkitWebViewBaseTouchEvent): (webkitWebViewBaseEvent): * UIProcess/gtk/GestureController.cpp: (WebKit::GestureController::handleEvent): * UIProcess/gtk/InputMethodFilter.cpp: (WebKit::InputMethodFilter::filterKeyEvent): (WebKit::InputMethodFilter::logHandleKeyboardEventForTesting): (WebKit::InputMethodFilter::logHandleKeyboardEventWithCompositionResultsForTesting): * UIProcess/gtk/KeyBindingTranslator.cpp: (WebKit::KeyBindingTranslator::commandsForKeyEvent): * UIProcess/gtk/ViewGestureControllerGtk.cpp: (WebKit::isEventStop): (WebKit::ViewGestureController::PendingSwipeTracker::scrollEventCanInfluenceSwipe): (WebKit::ViewGestureController::PendingSwipeTracker::scrollEventGetScrollingDeltas): (WebKit::ViewGestureController::SwipeProgressTracker::handleEvent): * UIProcess/gtk/WebPopupMenuProxyGtk.cpp: (WebKit::WebPopupMenuProxyGtk::treeViewButtonReleaseEventCallback): (WebKit::WebPopupMenuProxyGtk::keyPressEventCallback): 2019-06-17 Carlos Garcia Campos <cgarcia@igalia.com> Unreviewed. Update OptionsGTK.cmake and NEWS for 2.25.2 release * gtk/NEWS: Add release notes for 2.25.2. 2019-06-17 Carlos Garcia Campos <cgarcia@igalia.com> Unreviewed, rolling out r246467. It broke scrolling with mouse wheel Reverted changeset: "[GTK] Stop accessing GdkEvent fields when possible" https://bugs.webkit.org/show_bug.cgi?id=198829 https://trac.webkit.org/changeset/246467 2019-06-16 Darin Adler <darin@apple.com> Rename AtomicString to AtomString https://bugs.webkit.org/show_bug.cgi?id=195276 Reviewed by Michael Catanzaro. * many files: Let do-webcore-rename do the renaming. 2019-06-16 Simon Fraser <simon.fraser@apple.com> Implement ScrollableArea::scrollOffset() https://bugs.webkit.org/show_bug.cgi?id=198895 Reviewed by Antti Koivisto. * UIProcess/win/WebPopupMenuProxyWin.cpp: (WebKit::PopupMenuWin::scrollPosition const): (WebKit::WebPopupMenuProxyWin::onKeyDown): Just use m_scrollOffset. (WebKit::WebPopupMenuProxyWin::scrollSize const): Deleted. * UIProcess/win/WebPopupMenuProxyWin.h: Remove the one-axis scrollOffset() * WebProcess/Plugins/PDF/PDFPlugin.h: * WebProcess/Plugins/PDF/PDFPlugin.mm: (WebKit::PDFPlugin::scrollSize const): Deleted. (WebKit::PDFPlugin::scrollOffset const): Deleted. * WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::updateScrolledExposedRect): 2019-06-15 Youenn Fablet <youenn@apple.com> WebProcessPool::clearWebProcessHasUploads cannot assume its given processIdentifier is valid https://bugs.webkit.org/show_bug.cgi?id=198865 Unreviewed. * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::clearWebProcessHasUploads): Remove wrong debug assertion in case of WebProcessProxy destruction. 2019-06-15 Ludovico de Nittis <ludovico.denittis@collabora.com> [GTK] Stop accessing GdkEvent fields when possible https://bugs.webkit.org/show_bug.cgi?id=198829 Reviewed by Michael Catanzaro. Direct access to GdkEvent structs is no longer possible in GTK 4. * Shared/gtk/WebEventFactory.cpp: (WebKit::buttonForEvent): (WebKit::WebEventFactory::createWebMouseEvent): (WebKit::WebEventFactory::createWebWheelEvent): (WebKit::WebEventFactory::createWebKeyboardEvent): (WebKit::WebEventFactory::createWebTouchEvent): * UIProcess/API/gtk/WebKitEmojiChooser.cpp: * UIProcess/API/gtk/WebKitScriptDialogImpl.cpp: (webkitScriptDialogImplKeyPressEvent): * UIProcess/API/gtk/WebKitWebViewBase.cpp: (ClickCounter::currentClickCountForGdkButtonEvent): (webkitWebViewBaseKeyPressEvent): (webkitWebViewBaseHandleMouseEvent): (webkitWebViewBaseCrossingNotifyEvent): (webkitWebViewBaseGetTouchPointsForEvent): (webkitWebViewBaseTouchEvent): (webkitWebViewBaseEvent): * UIProcess/gtk/GestureController.cpp: (WebKit::GestureController::handleEvent): * UIProcess/gtk/InputMethodFilter.cpp: (WebKit::InputMethodFilter::filterKeyEvent): (WebKit::InputMethodFilter::logHandleKeyboardEventForTesting): (WebKit::InputMethodFilter::logHandleKeyboardEventWithCompositionResultsForTesting): * UIProcess/gtk/KeyBindingTranslator.cpp: (WebKit::KeyBindingTranslator::commandsForKeyEvent): * UIProcess/gtk/ViewGestureControllerGtk.cpp: (WebKit::isEventStop): (WebKit::ViewGestureController::PendingSwipeTracker::scrollEventCanInfluenceSwipe): (WebKit::ViewGestureController::PendingSwipeTracker::scrollEventGetScrollingDeltas): (WebKit::ViewGestureController::SwipeProgressTracker::handleEvent): * UIProcess/gtk/WebPopupMenuProxyGtk.cpp: (WebKit::WebPopupMenuProxyGtk::treeViewButtonReleaseEventCallback): (WebKit::WebPopupMenuProxyGtk::keyPressEventCallback): 2019-06-15 Rob Buis <rbuis@igalia.com> Store prefetch redirects in the prefetch cache https://bugs.webkit.org/show_bug.cgi?id=197371 Reviewed by Youenn Fablet. Store prefetch redirects in the prefetch cache and use them when navigating. * NetworkProcess/NetworkResourceLoader.cpp: (WebKit::NetworkResourceLoader::retrieveCacheEntry): (WebKit::NetworkResourceLoader::willSendRedirectedRequest): (WebKit::NetworkResourceLoader::didFinishWithRedirectResponse): * NetworkProcess/NetworkResourceLoader.h: * NetworkProcess/cache/PrefetchCache.cpp: (WebKit::PrefetchCache::Entry::Entry): (WebKit::PrefetchCache::storeRedirect): * NetworkProcess/cache/PrefetchCache.h: 2019-06-14 Devin Rousso <drousso@apple.com> waitForNavigationToComplete may be called before WebPageProxy knows it's loading https://bugs.webkit.org/show_bug.cgi?id=198741 <rdar://problem/31164316> Reviewed by Joseph Pecoraro. There's a potential race in `WebAutomationSession::waitForNavigationToCompleteOnPage` when querying for the `WebPageProxy`'s loading state (via `PageLoadingState::isLoading`), in that a pending load may be committed _after_ the `WebAutomationSession` checks it's value. This makes the automation session think that it isn't loading, so it will continue running commands, which can lead to a JavaScript error ("Callback was not called before the unload event") as any injected scripts will be cleared by the impending navigation, leaving the script evaluation callbacks "dangling". Expose more information from `PageLoadState` about whether it thinks there _may_ be a navigation currently happening, which the `WebAutomationSession` can use to delay commands. In the best case, no navigations are "missed". In the worst case, the automation session will wait `pageLoadTimeout` before continuing. * UIProcess/Automation/WebAutomationSession.cpp: (WebKit::WebAutomationSession::waitForNavigationToCompleteOnPage): * UIProcess/PageLoadState.h: * UIProcess/PageLoadState.cpp: (WebKit::PageLoadState::hasUncommittedLoad const): Added. 2019-06-14 Youenn Fablet <youenn@apple.com> WebProcessPool::clearWebProcessHasUploads cannot assume its given processIdentifier is valid https://bugs.webkit.org/show_bug.cgi?id=198865 <rdar://problem/51618878> Reviewed by Brady Eidson. NetworkProcess currently instructs UIProcess whether a given WebProcess is doing upload. There is no guarantee though that the WebProcessProxy is still there when the IPC is arriving at UIProcess. Instead, let WebProcess handles its upload state and notify WebProcessPool about its state. Make sure WebProcessProxy unregisters itself in case of crash. In case of NetworkProcess crash, WebProcesses will see all their uploads fail and will notify automatically UIProcess to update their state. Since the processID given to WebProcessPool is coming from IPC, we cannot not trust it. Add early return in case of not finding a WebProcessProxy for WebProcessPool clear/set methods. * NetworkProcess/NetworkConnectionToWebProcess.cpp: (WebKit::NetworkConnectionToWebProcess::NetworkConnectionToWebProcess): * NetworkProcess/NetworkConnectionToWebProcess.h: * NetworkProcess/NetworkConnectionToWebProcess.messages.in: * NetworkProcess/NetworkResourceLoadMap.cpp: (WebKit::NetworkResourceLoadMap::add): (WebKit::NetworkResourceLoadMap::take): * NetworkProcess/NetworkResourceLoadMap.h: * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::setWebProcessHasUploads): (WebKit::WebProcessPool::clearWebProcessHasUploads): * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::~WebProcessProxy): * WebProcess/Network/WebLoaderStrategy.cpp: (WebKit::WebLoaderStrategy::scheduleLoadFromNetworkProcess): (WebKit::WebLoaderStrategy::remove): (WebKit::WebLoaderStrategy::tryLoadingSynchronouslyUsingURLSchemeHandler): * WebProcess/Network/WebLoaderStrategy.h: * WebProcess/WebProcess.cpp: (WebKit::WebProcess::ensureNetworkProcessConnection): 2019-06-14 Youenn Fablet <youenn@apple.com> WebResourceLoadStatisticsStore should not use its network session if invalidated https://bugs.webkit.org/show_bug.cgi?id=198814 Reviewed by Geoffrey Garen. Tell WebResourceLoadStatisticsStore that its network session is invalidated. WebResourceLoadStatisticsStore will then clear its reference to the network session. * NetworkProcess/Classifier/ResourceLoadStatisticsMemoryStore.cpp: (WebKit::ResourceLoadStatisticsMemoryStore::updateCookieBlocking): Added for test purposes to trigger further cookie processing. * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp: (WebKit::WebResourceLoadStatisticsStore::invalidateAndCancel): * NetworkProcess/Classifier/WebResourceLoadStatisticsStore.h: * NetworkProcess/NetworkSession.cpp: (WebKit::NetworkSession::invalidateAndCancel): 2019-06-14 Joseph Pecoraro <pecoraro@apple.com> [Cocoa] NSFileWrapper associated with _WKAttachment https://bugs.webkit.org/show_bug.cgi?id=198871 <rdar://problem/51760625> Reviewed by Wenson Hsieh. * UIProcess/API/Cocoa/_WKAttachment.mm: (-[_WKAttachment dealloc]): Ensure we destruct the API::Object associated with this so RetainPtrs can release. 2019-06-14 Tim Horton <timothy_horton@apple.com> WebKit's NSAttributedString.h is not included in the WebKit.h umbrella header https://bugs.webkit.org/show_bug.cgi?id=198869 <rdar://problem/51754437> Reviewed by Timothy Hatcher. * Shared/API/Cocoa/WebKit.h: Make the new API available to modularized clients and folks who just import WebKit.h 2019-06-14 Jiewen Tan <jiewen_tan@apple.com> Disable AppSSO for web processes and plugin processes https://bugs.webkit.org/show_bug.cgi?id=198843 <rdar://problem/51642920> Reviewed by Sam Weinig. This patch moves the disabling of AppSSO from AuxiliaryProcess to PluginProcess and WebProcess such that NetworkingProcess will not be affected. * PluginProcess/mac/PluginProcessMac.mm: (WebKit::PluginProcess::platformInitializePluginProcess): * Shared/ios/AuxiliaryProcessIOS.mm: (WebKit::AuxiliaryProcess::platformInitialize): * Shared/mac/AuxiliaryProcessMac.mm: (WebKit::AuxiliaryProcess::platformInitialize): * WebProcess/cocoa/WebProcessCocoa.mm: (WebKit::WebProcess::platformInitializeProcess): 2019-06-14 Megan Gardner <megan_gardner@apple.com> Move Synthetic Editing Commands to behind an experimental feature flag https://bugs.webkit.org/show_bug.cgi?id=198842 <rdar://problem/50594700> Reviewed by Simon Fraser. Add a feature flag to gate synthetic editing commands. * Shared/WebPreferences.yaml: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::getFocusedElementInformation): 2019-06-13 Megan Gardner <megan_gardner@apple.com> Fix selection hang in Mail https://bugs.webkit.org/show_bug.cgi?id=198845 <rdar://problem/51388180> Reviewed by Tim Horton. SelectionDidChange requires a selectionWillChange in order to keep things in line. * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _selectionChanged]): 2019-06-13 Tim Horton <timothy_horton@apple.com> No content shows up for WKWebView while locked even with _canShowWhileLocked is YES https://bugs.webkit.org/show_bug.cgi?id=198819 <rdar://problem/51636240> Reviewed by Simon Fraser. * UIProcess/Cocoa/WebPageProxyCocoa.mm: (WebKit::WebPageProxy::didCreateContextForVisibilityPropagation): * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::contextIDForVisibilityPropagation const): * UIProcess/WebPageProxy.messages.in: * UIProcess/WebProcessProxy.h: (WebKit::WebProcessProxy::contextIDForVisibilityPropagation): Deleted. * UIProcess/WebProcessProxy.messages.in: * UIProcess/ios/WKContentView.mm: (-[WKContentView _setupVisibilityPropagationView]): * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::didCreateContextForVisibilityPropagation): Deleted. * UIProcess/ios/WebProcessProxyIOS.mm: (WebKit::WebProcessProxy::didCreateContextForVisibilityPropagation): Deleted. * WebProcess/WebPage/WebPage.cpp: (WebKit::m_shrinkToFitContentTimer): * WebProcess/WebPage/WebPage.h: * WebProcess/WebProcess.h: * WebProcess/cocoa/WebProcessCocoa.mm: (WebKit::WebProcess::platformInitializeWebProcess): Move the creation of the visibility propagation context to WebPage instead of WebProcess, because canShowWhileLocked is per-page, not per-process. Also, pass canShowWhileLocked into the context creation function for the visibility propagation context, not just RemoteLayerTree contexts. 2019-06-13 Antoine Quint <graouts@apple.com> "display: contents" Content click does not trigger https://bugs.webkit.org/show_bug.cgi?id=198559 <rdar://problem/51488524> Reviewed by Antti Koivisto. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::commitPotentialTap): 2019-06-13 Takashi Komori <Takashi.Komori@sony.com> [curl] Remove member objects of CurlRequest not to share by different threads. https://bugs.webkit.org/show_bug.cgi?id=198747 Reviewed by Fujii Hironori. * NetworkProcess/curl/NetworkDataTaskCurl.cpp: (WebKit::NetworkDataTaskCurl::curlDidReceiveResponse): (WebKit::NetworkDataTaskCurl::curlDidComplete): (WebKit::NetworkDataTaskCurl::curlDidFailWithError): * NetworkProcess/curl/NetworkDataTaskCurl.h: 2019-06-13 Zan Dobersek <zdobersek@igalia.com> [Nicosia] Add SceneIntegration https://bugs.webkit.org/show_bug.cgi?id=198791 Reviewed by Carlos Garcia Campos. Have the LayerTreeHost own the SceneIntegration object that's to be associated with layers used inside the LayerTreeHost's scene. The class now also inherits the SceneIntegration::Client interface, with the requestUpdate() method scheduling a scene update in ThreadedCompositor. CompositingCoordinator now retrieves the SceneIntegration object from the LayerTreeHost instance and manages association to that object for layers under the coordinator's control. ThreadedCompositor class gets a new public updateScene() method that schedules an update, enabling the SceneIntegration class to invoke scene updates. * Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp: (WebKit::ThreadedCompositor::updateScene): * Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.h: * WebProcess/WebPage/CoordinatedGraphics/CompositingCoordinator.cpp: (WebKit::CompositingCoordinator::createGraphicsLayer): (WebKit::CompositingCoordinator::detachLayer): (WebKit::CompositingCoordinator::attachLayer): * WebProcess/WebPage/CoordinatedGraphics/CompositingCoordinator.h: * WebProcess/WebPage/CoordinatedGraphics/LayerTreeHost.cpp: (WebKit::LayerTreeHost::LayerTreeHost): (WebKit::LayerTreeHost::sceneIntegration): (WebKit::LayerTreeHost::requestUpdate): * WebProcess/WebPage/CoordinatedGraphics/LayerTreeHost.h: 2019-06-13 Ludovico de Nittis <ludovico.denittis@collabora.com> [GTK] gdk_display_get_device_manager and gdk_screen_get_width/height are deprecated https://bugs.webkit.org/show_bug.cgi?id=198822 Reviewed by Carlos Garcia Campos. GdkSeat and GdkRectangle should be used, respectively. * UIProcess/Automation/gtk/WebAutomationSessionGtk.cpp: (WebKit::doMouseEvent): (WebKit::doMotionEvent): (WebKit::doKeyStrokeEvent): 2019-06-12 Antoine Quint <graouts@apple.com> Show the web page URL when sharing an AR model https://bugs.webkit.org/show_bug.cgi?id=198812 <rdar://problem/48689498> Reviewed by Dean Jackson. * UIProcess/Cocoa/DownloadClient.mm: (WebKit::DownloadClient::didStart): * UIProcess/Cocoa/SystemPreviewControllerCocoa.mm: (-[_WKPreviewControllerDataSource initWithMIMEType:originatingPageURL:]): (-[_WKPreviewControllerDataSource previewController:previewItemAtIndex:]): (WebKit::SystemPreviewController::start): (-[_WKPreviewControllerDataSource initWithMIMEType:]): Deleted. * UIProcess/SystemPreviewController.h: 2019-06-12 Antti Koivisto <antti@apple.com> Try to fix iOS build. * NetworkProcess/Downloads/DownloadMap.cpp: 2019-06-12 Youenn Fablet <youenn@apple.com> Use NSURLSession for WebSocket https://bugs.webkit.org/show_bug.cgi?id=198568 Reviewed by Geoffrey Garen. Implement socket channel provider on WebProcess level by sending IPC to NetworkProcess. On NetworkProcess side, use NSURLSession API to implement the WebSocket functionality. This is a partial implementation: - inspector integration is not working. - some error cases are not well handled or are not producing the same error messages. - some features are not implemented (extensions, subprotocols, handshake authentication challenge, cookie handling...). * CMakeLists.txt: * DerivedSources-input.xcfilelist: * DerivedSources-output.xcfilelist: * DerivedSources.make: * NetworkProcess/NetworkConnectionToWebProcess.cpp: (WebKit::NetworkConnectionToWebProcess::didReceiveMessage): (WebKit::NetworkConnectionToWebProcess::createSocketChannel): (WebKit::NetworkConnectionToWebProcess::removeSocketChannel): * NetworkProcess/NetworkConnectionToWebProcess.h: * NetworkProcess/NetworkConnectionToWebProcess.messages.in: * NetworkProcess/NetworkSession.cpp: (WebKit::NetworkSession::createWebSocketTask): * NetworkProcess/NetworkSession.h: (WebKit::NetworkSession::removeWebSocketTask): (WebKit::NetworkSession::addWebSocketTask): * NetworkProcess/NetworkSocketChannel.cpp: Added. (WebKit::NetworkSocketChannel::create): (WebKit::NetworkSocketChannel::NetworkSocketChannel): (WebKit::NetworkSocketChannel::~NetworkSocketChannel): (WebKit::NetworkSocketChannel::sendString): (WebKit::NetworkSocketChannel::sendData): (WebKit::NetworkSocketChannel::finishClosingIfPossible): (WebKit::NetworkSocketChannel::close): (WebKit::NetworkSocketChannel::didConnect): (WebKit::NetworkSocketChannel::didReceiveText): (WebKit::NetworkSocketChannel::didReceiveBinaryData): (WebKit::NetworkSocketChannel::didClose): (WebKit::NetworkSocketChannel::messageSenderConnection const): * NetworkProcess/NetworkSocketChannel.h: Added. * NetworkProcess/NetworkSocketChannel.messages.in: Added. * NetworkProcess/NetworkSocketStream.messages.in: * NetworkProcess/WebSocketTask.h: Added. (WebKit::WebSocketTask::sendString): (WebKit::WebSocketTask::sendData): (WebKit::WebSocketTask::close): (WebKit::WebSocketTask::cancel): (WebKit::WebSocketTask::resume): * NetworkProcess/cocoa/NetworkSessionCocoa.h: * NetworkProcess/cocoa/NetworkSessionCocoa.mm: (-[WKNetworkSessionDelegate existingWebSocketTask:]): (-[WKNetworkSessionDelegate URLSession:webSocketTask:didOpenWithProtocol:]): (-[WKNetworkSessionDelegate URLSession:webSocketTask:didCloseWithCode:reason:]): (WebKit::NetworkSessionCocoa::continueDidReceiveChallenge): (WebKit::NetworkSessionCocoa::createWebSocketTask): (WebKit::NetworkSessionCocoa::addWebSocketTask): (WebKit::NetworkSessionCocoa::removeWebSocketTask): (WebKit::NetworkSessionCocoa::webSocketDataTaskForIdentifier): * NetworkProcess/cocoa/WebSocketTaskCocoa.h: Added. * NetworkProcess/cocoa/WebSocketTaskCocoa.mm: Added. (WebKit::WebSocketTask::WebSocketTask): (WebKit::WebSocketTask::~WebSocketTask): (WebKit::WebSocketTask::readNextMessage): (WebKit::WebSocketTask::cancel): (WebKit::WebSocketTask::resume): (WebKit::WebSocketTask::didConnect): (WebKit::WebSocketTask::didClose): (WebKit::WebSocketTask::sendString): (WebKit::WebSocketTask::sendData): (WebKit::WebSocketTask::close): (WebKit::WebSocketTask::identifier const): * Shared/WebPreferences.yaml: * WebKit.xcodeproj/project.pbxproj: * WebProcess/Network/NetworkProcessConnection.cpp: (WebKit::NetworkProcessConnection::didReceiveMessage): * WebProcess/Network/WebSocketChannel.cpp: Added. (WebKit::WebSocketChannel::create): (WebKit::WebSocketChannel::WebSocketChannel): (WebKit::WebSocketChannel::~WebSocketChannel): (WebKit::WebSocketChannel::messageSenderConnection const): (WebKit::WebSocketChannel::messageSenderDestinationID const): (WebKit::WebSocketChannel::subprotocol): (WebKit::WebSocketChannel::extensions): (WebKit::WebSocketChannel::connect): (WebKit::WebSocketChannel::send): (WebKit::WebSocketChannel::bufferedAmount const): (WebKit::WebSocketChannel::close): (WebKit::WebSocketChannel::fail): (WebKit::WebSocketChannel::disconnect): (WebKit::WebSocketChannel::didConnect): (WebKit::WebSocketChannel::didReceiveText): (WebKit::WebSocketChannel::didReceiveBinaryData): (WebKit::WebSocketChannel::didClose): (WebKit::WebSocketChannel::didFail): (WebKit::WebSocketChannel::networkProcessCrashed): * WebProcess/Network/WebSocketChannel.h: Added. * WebProcess/Network/WebSocketChannel.messages.in: Added. * WebProcess/Network/WebSocketChannelManager.cpp: Added. (WebKit::WebSocketChannelManager::createWebSocketChannel): (WebKit::WebSocketChannelManager::networkProcessCrashed): (WebKit::WebSocketChannelManager::didReceiveMessage): * WebProcess/Network/WebSocketChannelManager.h: Added. * WebProcess/Network/WebSocketProvider.cpp: (WebKit::WebSocketProvider::createWebSocketChannel): * WebProcess/Network/WebSocketProvider.h: * WebProcess/Network/WebSocketStream.cpp: * WebProcess/Network/WebSocketStream.messages.in: * WebProcess/WebProcess.cpp: (WebKit::WebProcess::networkProcessConnectionClosed): * WebProcess/WebProcess.h: (WebKit::WebProcess::webSocketChannelManager): 2019-06-12 Sihui Liu <sihui_liu@apple.com> Add assertions to help debug crash at WebKit::HistoryEntryDataEncoder::operator<< https://bugs.webkit.org/show_bug.cgi?id=198766 Reviewed by Geoffrey Garen. * Shared/SessionState.h: (WebKit::FrameState::~FrameState): * UIProcess/API/C/WKPage.cpp: (WKPageCopySessionState): * UIProcess/mac/LegacySessionStateCoding.cpp: (WebKit::HistoryEntryDataEncoder::encodeFixedLengthData): (WebKit::encodeFrameStateNode): 2019-06-12 Ludovico de Nittis <ludovico.denittis@collabora.com> [GTK] GTK_STOCK_* types have been deprecated since GTK 3.10 https://bugs.webkit.org/show_bug.cgi?id=198787 Reviewed by Michael Catanzaro. We completely remove the gtkStockIDFromContextMenuAction function in order to get rid of the stock items. This function was used only in "createActionIfNeeded" where now we pass a nullptr as a stock_id variable. * Shared/glib/WebContextMenuItemGlib.cpp: (WebKit::gtkStockIDFromContextMenuAction): 2019-06-12 Brent Fulgham <bfulgham@apple.com> Unreviewed fix after rr246360. The current code accidentally calls the completion handler twice. * UIProcess/API/Cocoa/WKWebsiteDataStore.mm: (-[WKWebsiteDataStore _setPrevalentDomain:completionHandler:]): 2019-06-12 Jiewen Tan <jiewen_tan@apple.com> REGRESSION (r245043) [Mac WK2 Debug] ASSERTION FAILED: m_services.isEmpty() && transports.size() <= maxTransportNumber seen with two http/wpt/webauthn/public-key-credential-* tests https://bugs.webkit.org/show_bug.cgi?id=197917 <rdar://problem/51524958> Reviewed by Brent Fulgham. This is a race condition that when a new request comes in the middle between the previous one finishes and the clearStateAsync is queued in the main thread. Therefore, when the new request starts discovery, it will still see previous request's state. To fix this issue, clearState() will be called unconditionally for every request. And a guard is added to clearState() to prevent double clearance. * UIProcess/WebAuthentication/AuthenticatorManager.cpp: (WebKit::AuthenticatorManager::makeCredential): (WebKit::AuthenticatorManager::getAssertion): (WebKit::AuthenticatorManager::clearState): 2019-06-12 Brent Fulgham <bfulgham@apple.com> Add mechanism and test case to check if ITP is active https://bugs.webkit.org/show_bug.cgi?id=198694 <rdar://problem/51557704> Reviewed by Youenn Fablet. Add a new private SPI call on the WebsiteDataStore object that allows test code to mark a domain as prevalent, and check the prevalance of a resource. This is then used to build a test to confirm ITP is active and working. * UIProcess/API/Cocoa/WKWebsiteDataStore.mm: (-[WKWebsiteDataStore _setPrevalentDomain:completionHandler:]): (-[WKWebsiteDataStore _getIsPrevalentDomain:completionHandler:]): * UIProcess/API/Cocoa/WKWebsiteDataStorePrivate.h: 2019-06-12 Wenson Hsieh <wenson_hsieh@apple.com> Many layout tests are failing on iPad simulator due to unexpected viewport dimensions https://bugs.webkit.org/show_bug.cgi?id=198789 <rdar://problem/51595519> Reviewed by Simon Fraser. Prevent the shrink-to-fit-content timer from activating on layout tests that use the testing viewport configuration. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::immediatelyShrinkToFitContent): 2019-06-12 Michael Catanzaro <mcatanzaro@igalia.com> [WPE][GTK] Deprecate WebSQL APIs https://bugs.webkit.org/show_bug.cgi?id=195011 Reviewed by Carlos Garcia Campos. * UIProcess/API/glib/WebKitSettings.cpp: (webkit_settings_class_init): * UIProcess/API/glib/WebKitWebContext.cpp: (webkitWebContextConstructed): * UIProcess/API/glib/WebKitWebsiteDataManager.cpp: (webkitWebsiteDataManagerGetProperty): (webkit_website_data_manager_class_init): * UIProcess/API/gtk/WebKitWebsiteData.h: * UIProcess/API/gtk/WebKitWebsiteDataManager.h: * UIProcess/API/wpe/WebKitWebsiteData.h: * UIProcess/API/wpe/WebKitWebsiteDataManager.h: 2019-06-12 Michael Catanzaro <mcatanzaro@igalia.com> [WPE][GTK] Enable hyperlink auditing https://bugs.webkit.org/show_bug.cgi?id=197845 Reviewed by Carlos Garcia Campos. * UIProcess/API/glib/WebKitSettings.cpp: (webkit_settings_class_init): 2019-06-12 Ludovico de Nittis <ludovico.denittis@collabora.com> [GTK] gtk_misc_set_alignment is deprecated since GTK 3.14 https://bugs.webkit.org/show_bug.cgi?id=198785 Reviewed by Carlos Garcia Campos. Replace the deprecated gtk_misc_set_alignment with halign and valign. * UIProcess/API/gtk/WebKitAuthenticationDialog.cpp: (createLabelWithLineWrap): 2019-06-11 Wenson Hsieh <wenson_hsieh@apple.com> [iOS] Idempotent text autosizing needs to react properly to viewport changes https://bugs.webkit.org/show_bug.cgi?id=198736 <rdar://problem/50591911> Reviewed by Zalan Bujtas. If idempotent text autosizing is enabled, respond to viewport initial scale changes by forcing a style recalc, since the amount by which idempotent text autosizing boosts font sizes depends on the Page's initial scale. * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::resetIdempotentTextAutosizingIfNeeded): (WebKit::WebPage::viewportConfigurationChanged): 2019-06-11 Zalan Bujtas <zalan@apple.com> LayoutTests/fast/events/touch/ios/double-tap-for-double-click* test cases are failing https://bugs.webkit.org/show_bug.cgi?id=198764 <rdar://problem/51035459> Reviewed by Wenson Hsieh. This patch replaces the existing, _doubleTapGestureRecognizerForDoubleClick based double click handling with a WebProcess based implementation using the potentialTapAtPosition/commitPotentialTap infrastructure. * Shared/WebPageCreationParameters.cpp: (WebKit::WebPageCreationParameters::encode const): (WebKit::WebPageCreationParameters::decode): * Shared/WebPageCreationParameters.h: * UIProcess/PageClient.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::creationParameters): * UIProcess/WebPageProxy.h: * UIProcess/ios/PageClientImplIOS.h: * UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::doubleTapForDoubleClickDelay): (WebKit::PageClientImpl::doubleTapForDoubleClickRadius): * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _ensureNonBlockingDoubleTapGestureRecognizer]): (-[WKContentView setupInteraction]): (-[WKContentView cleanupInteraction]): (-[WKContentView _removeDefaultGestureRecognizers]): (-[WKContentView _addDefaultGestureRecognizers]): (-[WKContentView gestureRecognizer:shouldRecognizeSimultaneouslyWithGestureRecognizer:]): (-[WKContentView gestureRecognizerShouldBegin:]): (-[WKContentView _didStartProvisionalLoadForMainFrame]): (-[WKContentView _doubleTapForDoubleClickDelay]): (-[WKContentView _doubleTapForDoubleClickRadius]): (-[WKContentView _doubleTapRecognizedForDoubleClick:]): Deleted. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::handleDoubleTapForDoubleClickAtPoint): Deleted. * WebProcess/WebPage/WebPage.cpp: * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::handlePotentialDoubleTapForDoubleClickAtPoint): (WebKit::WebPage::commitPotentialTap): (WebKit::WebPage::handleDoubleTapForDoubleClickAtPoint): Deleted. 2019-06-11 Andy Estes <aestes@apple.com> [Apple Pay] ASSERTION FAILED: m_state == State::Activating under WebPaymentCoordinatorProxy::showPaymentUI https://bugs.webkit.org/show_bug.cgi?id=198776 <rdar://problem/49123795> Reviewed by Brian Weinstein. It's possible that an active session is aborted before the completion handler passed to platformShowPaymentUI() has executed. When that happens, m_state will be Idle even though we assert that it is Activating. Fix this by returning early in the platformShowPaymentUI() completion handler when m_state is Idle. It's not possible to write a layout test for this because MockPaymentCoordinator handles showing payment UI directly in the web process, so this code is not executed in layout tests. The assertion can be reproduced manually by loading https://w3c-test.org/payment-request/payment-is-showing.https.html and clicking the button. * Shared/ApplePay/WebPaymentCoordinatorProxy.cpp: (WebKit::WebPaymentCoordinatorProxy::showPaymentUI): 2019-06-11 Patrick Griffis <pgriffis@igalia.com> [GTK] Fix a11y support in bubblewrap sandbox https://bugs.webkit.org/show_bug.cgi?id=198777 Reviewed by Michael Catanzaro. * UIProcess/Launcher/glib/BubblewrapLauncher.cpp: (WebKit::bindA11y): 2019-06-11 Timothy Hatcher <timothy@apple.com> Flash when tapping compose button after switching to/from dark mode without restarting Mail. https://bugs.webkit.org/show_bug.cgi?id=198769 rdar://problem/51370037 Reviewed by Tim Horton. Accessing a dynamic color outside a normal UIView choke point without setting UITraitCollection.currentTraitCollection first can cause undefined results. Use LocalCurrentTraitCollection inside scrollViewBackgroundColor when accessing the dynamic system UIColors. Also use systemBackgroundColor instead of white. * UIProcess/API/Cocoa/WKWebView.mm: (scrollViewBackgroundColor): 2019-06-11 Megan Gardner <megan_gardner@apple.com> Integrate scrollbar gestures for iOS https://bugs.webkit.org/show_bug.cgi?id=198767 Reviewed by Tim Horton. * UIProcess/ios/WKContentViewInteraction.mm: (_WKGestureRecognizerIsBuiltInScrollViewGestureRecognizer): (-[WKContentView gestureRecognizer:canPreventGestureRecognizer:]): 2019-06-11 Timothy Hatcher <timothy@apple.com> Scrollbar can show as white on white in dark mode on iOS. https://bugs.webkit.org/show_bug.cgi?id=198772 rdar://problem/51516743 Reviewed by Tim Horton. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _updateScrollViewBackground]): Use UIScrollViewIndicatorStyleBlack instead of UIScrollViewIndicatorStyleDefault to prevent getting a white scrollbar in dark mode. 2019-06-11 Michael Catanzaro <mcatanzaro@igalia.com> Unreviewed build warning fixes Silence -Wunused-variable warning * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::clearWebProcessIsPlayingAudibleMedia): 2019-06-11 Simon Fraser <simon.fraser@apple.com> Fix non-internal builds after r246327. * Platform/spi/ios/UIKitSPI.h: 2019-06-10 Simon Fraser <simon.fraser@apple.com> Add logging for UI-side compositing hit-testing https://bugs.webkit.org/show_bug.cgi?id=198739 Reviewed by Antti Koivisto. Make it easier to debug UI-side compositing hit-testing issues with a UIHitTesting log channel, which logs information about the UIView hierarchy, which views are found by hit-testing, and what touch-actions apply. This log channel can be set by passing the argument '-WebKit2Logging "UIHitTesting"' when launching a debug iOS MobileSafari instance. * Platform/Logging.h: * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm: (-[UIView _web_findDescendantViewAtPoint:withEvent:]): * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView hitTest:withEvent:]): (-[WKContentView _handleTouchActionsForTouchEvent:]): 2019-06-11 Antti Koivisto <antti@apple.com> REGRESSION (iOS): Can't scroll litter-robot.com checkout form's dropdown menus https://bugs.webkit.org/show_bug.cgi?id=198753 <rdar://problem/51355686> Reviewed by Simon Fraser. If an element with 'overflow:scroll' also had 'visibility:hidden' or 'pointer-events:none' it would capture touches and prevent scrolling of any overlapped scrollers. * UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm: (WebKit::collectDescendantViewsAtPoint): Filter out views with 'isUserInteractionEnabled == NO' (set for hidden and pointer-events:none layers). This prevents it being considered as the first view hit when determining scrolling relationships. (-[UIView _web_findDescendantViewAtPoint:withEvent:]): No need to skip here anymore. 2019-06-11 Wenson Hsieh <wenson_hsieh@apple.com> Quotes are always inserted as smart quotes on stackblitz.com, causing compilation errors https://bugs.webkit.org/show_bug.cgi?id=198735 <rdar://problem/51557159> Reviewed by Megan Gardner. Add a flag in FocusedElementInformation to indicate whether spellchecking is allowed in the focused element. If spellchecking is not allowed, then disable smart quotes and dashes, which matches behavior on macOS. * Shared/FocusedElementInformation.cpp: (WebKit::FocusedElementInformation::encode const): (WebKit::FocusedElementInformation::decode): * Shared/FocusedElementInformation.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView textInputTraits]): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::getFocusedElementInformation): 2019-06-11 Carlos Garcia Campos <cgarcia@igalia.com> [GTK] Remove option REDIRECTED_XCOMPOSITE_WINDOW https://bugs.webkit.org/show_bug.cgi?id=198748 Reviewed by Žan Doberšek. It's unused and untested, we kept that code path only because the redirected window caused performance issues in some drivers in embedded devices. Nowadays there are much better solutions for those cases like using WPE port or GTK port under wayland instead of X11. * Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp: (WebKit::ThreadedCompositor::create): Remove the ShouldDoFrameSync parameter since it always receives Yes. (WebKit::ThreadedCompositor::ThreadedCompositor): Ditto. (WebKit::ThreadedCompositor::createGLContext): Remove the code to handle the case of ShouldDoFrameSync being No, since it's always Yes. (WebKit::ThreadedCompositor::setNativeSurfaceHandleForCompositing): Deleted. * Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.h: * UIProcess/API/gtk/WebKitWebViewBase.cpp: (webkitWebViewBaseRealize): Remove the code for !USE(REDIRECTED_XCOMPOSITE_WINDOW). (webkitWebViewBaseUnrealize): Ditto. (webkitWebViewBaseDraw): acceleratedBackingStore member can't be nullptr now. (webkitWebViewBaseEnterAcceleratedCompositingMode): Ditto. (webkitWebViewBaseUpdateAcceleratedCompositingMode): Ditto. (webkitWebViewBaseExitAcceleratedCompositingMode): Ditto. (webkitWebViewBaseMakeGLContextCurrent): Ditto. (webkitWebViewBaseDidRelaunchWebProcess): Remove the code for !USE(REDIRECTED_XCOMPOSITE_WINDOW). (webkitWebViewBasePageClosed): Ditto. (webkitWebViewBaseRenderHostFileDescriptor): acceleratedBackingStore member can't be nullptr now. * UIProcess/CoordinatedGraphics/DrawingAreaProxyCoordinatedGraphics.cpp: (WebKit::DrawingAreaProxyCoordinatedGraphics::didUpdateBackingStoreState): Remove the code for !USE(REDIRECTED_XCOMPOSITE_WINDOW). (WebKit::DrawingAreaProxyCoordinatedGraphics::setNativeSurfaceHandleForCompositing): Deleted. (WebKit::DrawingAreaProxyCoordinatedGraphics::destroyNativeSurfaceHandleForCompositing): Deleted. * UIProcess/CoordinatedGraphics/DrawingAreaProxyCoordinatedGraphics.h: * UIProcess/gtk/AcceleratedBackingStore.cpp: (WebKit::AcceleratedBackingStore::create): Add an assert to ensure we create an AcceleratedBackingStore. * UIProcess/gtk/AcceleratedBackingStoreX11.cpp: * UIProcess/gtk/AcceleratedBackingStoreX11.h: * UIProcess/gtk/HardwareAccelerationManager.cpp: (WebKit::HardwareAccelerationManager::HardwareAccelerationManager): Remove the code for !USE(REDIRECTED_XCOMPOSITE_WINDOW). * WebProcess/WebPage/AcceleratedSurface.cpp: (WebKit::AcceleratedSurface::create): Add an assert to ensure we create an AcceleratedSurface. * WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp: (WebKit::DrawingAreaCoordinatedGraphics::enterAcceleratedCompositingMode): Remove the code for !USE(REDIRECTED_XCOMPOSITE_WINDOW). (WebKit::DrawingAreaCoordinatedGraphics::setNativeSurfaceHandleForCompositing): Deleted. (WebKit::DrawingAreaCoordinatedGraphics::destroyNativeSurfaceHandleForCompositing): Deleted. * WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.h: * WebProcess/WebPage/CoordinatedGraphics/LayerTreeHost.cpp: (WebKit::LayerTreeHost::LayerTreeHost): m_surface can't be nullptr now. (WebKit::LayerTreeHost::sizeDidChange): Ditto. (WebKit::LayerTreeHost::deviceOrPageScaleFactorChanged): Ditto. (WebKit::LayerTreeHost::nativeSurfaceHandleForCompositing): Ditto. (WebKit::LayerTreeHost::didDestroyGLContext): Ditto. (WebKit::LayerTreeHost::willRenderFrame): Ditto. (WebKit::LayerTreeHost::didRenderFrame): Ditto. (WebKit::LayerTreeHost::setNativeSurfaceHandleForCompositing): Deleted. * WebProcess/WebPage/CoordinatedGraphics/LayerTreeHost.h: * WebProcess/WebPage/DrawingArea.h: * WebProcess/WebPage/DrawingArea.messages.in: * WebProcess/WebPage/WebPage.h: (WebKit::WebPage::nativeWindowHandle): Deleted. * WebProcess/WebPage/gtk/AcceleratedSurfaceX11.cpp: * WebProcess/WebPage/gtk/AcceleratedSurfaceX11.h: 2019-06-11 Michael Catanzaro <mcatanzaro@igalia.com> [WPE][GTK] bubblewrap sandbox should grant access to web extensions directory https://bugs.webkit.org/show_bug.cgi?id=198734 Reviewed by Carlos Garcia Campos. * UIProcess/API/glib/WebKitWebContext.cpp: (webkit_web_context_set_web_extensions_directory): 2019-06-10 Andy Estes <aestes@apple.com> [iOS] Use PDFKit SPI for taking snapshots when the hosting app is not entitled for global capture https://bugs.webkit.org/show_bug.cgi?id=198731 <rdar://problem/46215174> Reviewed by Tim Horton. PDFHostViewController renders PDF contents in a view service, and apps are unable to snapshot views rendered out-of-process without an entitlement. When an app is missing this entitlement and calls WKWebView's takeSnapshotWithConfiguration: API when a PDF is displayed, fall back to calling PDFHostViewController's snapshotting SPI. Testing is blocked by <https://webkit.org/b/175204>. * Platform/spi/ios/PDFKitSPI.h: * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _snapshotRect:intoImageOfWidth:completionHandler:]): * UIProcess/Cocoa/WKWebViewContentProvider.h: * UIProcess/ios/WKPDFView.mm: (+[WKPDFView web_requiresCustomSnapshotting]): (-[WKPDFView web_snapshotRectInContentViewCoordinates:snapshotWidth:completionHandler:]): * UIProcess/ios/WKSystemPreviewView.mm: (+[WKSystemPreviewView web_requiresCustomSnapshotting]): 2019-06-10 Sam Weinig <weinig@apple.com> Remove Dashboard support https://bugs.webkit.org/show_bug.cgi?id=198615 Reviewed by Ryosuke Niwa. * Configurations/FeatureDefines.xcconfig: * WebProcess/InjectedBundle/API/c/WKBundle.cpp: (WKBundleSetUseDashboardCompatibilityMode): Deleted. * WebProcess/InjectedBundle/API/c/WKBundlePrivate.h: * WebProcess/InjectedBundle/InjectedBundle.cpp: (WebKit::InjectedBundle::setUseDashboardCompatibilityMode): Deleted. * WebProcess/InjectedBundle/InjectedBundle.h: * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::annotatedRegionsChanged): Deleted. * WebProcess/WebCoreSupport/WebChromeClient.h: 2019-06-10 Wenson Hsieh <wenson_hsieh@apple.com> [iOS] fast/xsl tests are flaky when run after certain viewport shrink-to-fit tests https://bugs.webkit.org/show_bug.cgi?id=198699 <rdar://problem/50501718> Reviewed by Simon Fraser. Lift logic that sets the "IsKnownToLayOutWiderThanViewport" flag out of resetViewportDefaultConfiguration, and into didCommitLoad instead (along with other logic for resetting viewport arguments). The previous method, resetViewportDefaultConfiguration, was being triggered very frequently undo didReceiveMobileDocType, causing the shrink-to-fit heuristic to sometimes take no effect. The original intention here was simply to reset the flag upon page load. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::didCommitLoad): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::resetViewportDefaultConfiguration): 2019-06-10 Timothy Hatcher <timothy@apple.com> Integrate dark mode support for iOS. https://bugs.webkit.org/show_bug.cgi?id=198687 rdar://problem/51545643 Reviewed by Tim Horton. * Configurations/FeatureDefines.xcconfig: * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _effectiveAppearanceIsDark]): (-[WKWebView _effectiveAppearanceIsInactive]): (-[WKWebView _dynamicUserInterfaceTraitDidChange]): * UIProcess/API/Cocoa/WKWebViewInternal.h: * UIProcess/ios/PageClientImplIOS.h: * UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::effectiveAppearanceIsDark const): (WebKit::PageClientImpl::effectiveAppearanceIsInactive const): * UIProcess/ios/WKPasswordView.mm: (-[WKPasswordView showInScrollView:]): (configureScrollView): Deleted. 2019-06-10 Sihui Liu <sihui_liu@apple.com> [WKHTTPCookieStore getAllCookies:] may return duplicate cookies https://bugs.webkit.org/show_bug.cgi?id=198635 <rdar://problem/46010232> Reviewed by Ryosuke Niwa. When there is no process pool, we store cookies set in memory with HashSet m_pendingCookies of WebsiteDataStore. HashSet does not contain duplicate Cookies that are completely identical, but it may contain Cookies that have all the other properties identical other than value. This is not correct because Cookies with same name, domain and path should be treated as the same cookie. When a cookie is set via API, we should either insert the cookie into m_pendingCookies if the cookie does not exist, or update the cookie value if it already exists. Note that we still use HashSet with CookieHash for m_pendingCookies because in cookie deletion, we only delete cookie when there is a complete match. If some cookie from m_pendingCookies has all other properties the same as the cookie specified in the deletion function, but the value is different, it will not be removed. * UIProcess/WebsiteData/WebsiteDataStore.cpp: (WebKit::WebsiteDataStore::addPendingCookie): 2019-06-10 Philippe Normand <pnormand@igalia.com> [WPE][Qt] Port to new wpe_fdo_egl_exported_image API https://bugs.webkit.org/show_bug.cgi?id=198713 Reviewed by Carlos Garcia Campos. * UIProcess/API/wpe/qt/WPEQtViewBackend.cpp: (WPEQtViewBackend::WPEQtViewBackend): (WPEQtViewBackend::texture): (WPEQtViewBackend::displayImage): * UIProcess/API/wpe/qt/WPEQtViewBackend.h: 2019-06-09 Brent Fulgham <bfulgham@apple.com> [iOS] ResourceLoadStatistics state is not properly relayed to the NetworkProcess https://bugs.webkit.org/show_bug.cgi?id=198692 <rdar://problem/51538088> Reviewed by Maciej Stachowiak. * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::setResourceLoadStatisticsEnabled): Message the NetworkProcess on state change. 2019-06-08 Dean Jackson <dino@apple.com> Drag starting state can get stuck even though the drag has ended https://bugs.webkit.org/show_bug.cgi?id=198696 <rdar://problem/51556045> Reviewed by Wenson Hsieh. In iOS 13, we're seeing cases of the DragSession not correctly ending, and thus leaving m_isStartingDrag in an incorrect state. Temporarily force this to be reset in ::dragEnded while investigating * UIProcess/ios/WKContentViewInteraction.mm: Add some more release logging while here. (-[WKContentView dragInteraction:willAnimateLiftWithAnimator:session:]): (-[WKContentView dragInteraction:item:willAnimateCancelWithAnimator:]): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::dragEnded): 2019-06-08 Wenson Hsieh <wenson_hsieh@apple.com> [iOS] The default application name for user agent when requesting desktop content is still "Mobile/15E148" https://bugs.webkit.org/show_bug.cgi?id=198693 <rdar://problem/51555371> Reviewed by Tim Horton. Fixes the bug by introducing an applicationNameForDesktopUserAgent member to WebPageProxy. This applicationNameForDesktopUserAgent is set alongside the regular applicationNameForUserAgent; however, in the case where it is being set via WKWebViewConfiguration, use WKWebViewConfiguration's _applicationNameForDesktopUserAgent instead. See below for more details. Tested by adding to the existing API test PreferredContentMode.ApplicationNameForDesktopUserAgent. * UIProcess/API/APIWebsitePolicies.cpp: (API::WebsitePolicies::copy const): * UIProcess/API/APIWebsitePolicies.h: Drive-by fix: rename applicationNameForUserAgentWithModernCompatibility to applicationNameForDesktopUserAgent in a few places. * UIProcess/API/Cocoa/WKBrowsingContextController.mm: (-[WKBrowsingContextController setApplicationNameForUserAgent:]): * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _initializeWithConfiguration:]): (-[WKWebView _setApplicationNameForUserAgent:]): * UIProcess/API/Cocoa/WKWebViewConfiguration.mm: Change _applicationNameForUserAgent into an Optional<RetainPtr<NSString>>. A value of WTF::nullopt allows us to know that the default application name should be used (which is different when requesting desktop content). (-[WKWebViewConfiguration encodeWithCoder:]): (-[WKWebViewConfiguration initWithCoder:]): (-[WKWebViewConfiguration copyWithZone:]): (-[WKWebViewConfiguration _applicationNameForDesktopUserAgent]): Add _applicationNameForDesktopUserAgent to the web view configuration. This behaves like applicationNameForUserAgent, with one exception: in the case where the default applicationNameForUserAgent is used (i.e. the client has not specified any application name), default to `nil` as the application name for user agent, rather than "Mobile/15E148". (-[WKWebViewConfiguration applicationNameForUserAgent]): (-[WKWebViewConfiguration setApplicationNameForUserAgent:]): * UIProcess/API/Cocoa/WKWebViewConfigurationInternal.h: * UIProcess/API/Cocoa/WKWebpagePreferences.mm: (-[WKWebpagePreferences _applicationNameForUserAgentWithModernCompatibility]): (-[WKWebpagePreferences _setApplicationNameForUserAgentWithModernCompatibility:]): * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::setApplicationNameForDesktopUserAgent): (WebKit::WebPageProxy::applicationNameForDesktopUserAgent const): * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::effectiveContentModeAfterAdjustingPolicies): 2019-06-08 Andy Estes <aestes@apple.com> [Apple Pay] If we have a bound interface identifier, set it on new PKPaymentRequests https://bugs.webkit.org/show_bug.cgi?id=198690 <rdar://problem/48041803> Reviewed by Tim Horton. * NetworkProcess/cocoa/NetworkSessionCocoa.h: * NetworkProcess/cocoa/NetworkSessionCocoa.mm: (WebKit::NetworkSessionCocoa::boundInterfaceIdentifier const): Implemented a public getter for m_boundInterfaceIdentifier. * NetworkProcess/NetworkConnectionToWebProcess.h: * NetworkProcess/ios/NetworkConnectionToWebProcessIOS.mm: (WebKit::NetworkConnectionToWebProcess::paymentCoordinatorBoundInterfaceIdentifier): Implemented an override for paymentCoordinatorBoundInterfaceIdentifier. * Shared/ApplePay/WebPaymentCoordinatorProxy.h: Declared paymentCoordinatorBoundInterfaceIdentifier for clients to override. * Shared/ApplePay/cocoa/WebPaymentCoordinatorProxyCocoa.mm: (WebKit::WebPaymentCoordinatorProxy::platformPaymentRequest): If the client has a non-empty bound interface identifier, set it on the new PKPaymentRequest. * UIProcess/WebPageProxy.h: * UIProcess/Cocoa/WebPageProxyCocoa.mm: (WebKit::WebPageProxy::paymentCoordinatorBoundInterfaceIdentifier): Implemented an override for paymentCoordinatorBoundInterfaceIdentifier. 2019-06-07 Antti Koivisto <antti@apple.com> REGRESSION (r245006): Setting scrollview.scrollEnabled clobbers any scrollEnabled set by a client https://bugs.webkit.org/show_bug.cgi?id=198656 <rdar://problem/51494585> Reviewed by Tim Horton. Allow client to disable scrolling and zooming. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _didCommitLayerTree:]): * UIProcess/ios/WKScrollView.h: * UIProcess/ios/WKScrollView.mm: (-[WKScrollView initWithFrame:]): (-[WKScrollView setScrollEnabled:]): (-[WKScrollView _setScrollEnabledInternal:]): (-[WKScrollView _updateScrollability]): (-[WKScrollView setZoomEnabled:]): (-[WKScrollView _setZoomEnabledInternal:]): (-[WKScrollView _updateZoomability]): 2019-06-07 Wenson Hsieh <wenson_hsieh@apple.com> Allow clients to vend custom -inputView and -inputAccessoryView by overriding WKWebView methods https://bugs.webkit.org/show_bug.cgi?id=198631 <rdar://problem/51505431> Reviewed by Tim Horton. Allow WKWebView API clients to override WKContentView's default input view and/or input accessory view by subclassing WKWebView and implementing -inputView or -inputAccessoryView. * UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView inputAccessoryView]): (-[WKWebView inputView]): * UIProcess/ios/WKContentViewInteraction.h: * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView inputView]): (-[WKContentView inputViewForWebView]): (-[WKContentView inputAccessoryView]): (-[WKContentView inputAccessoryViewForWebView]): 2019-06-07 Tim Horton <timothy_horton@apple.com> Disable focus rings on WKContentView for PLATFORM(IOSMAC) https://bugs.webkit.org/show_bug.cgi?id=198685 Reviewed by Simon Fraser. * Platform/spi/ios/UIKitSPI.h: * UIProcess/ios/WKContentView.mm: (-[WKContentView _commonInitializationWithProcessPool:configuration:]): 2019-06-07 Megan Gardner <megan_gardner@apple.com> Extend quirks to emulate bold/italic/underline in hidden editable areas https://bugs.webkit.org/show_bug.cgi?id=198681 Reviewed by Wenson Hsieh. * Shared/FocusedElementInformation.cpp: (WebKit::FocusedElementInformation::encode const): (WebKit::FocusedElementInformation::decode): * Shared/FocusedElementInformation.h: * Shared/SyntheticEditingCommandType.h: * UIProcess/ios/WKContentView.mm: (-[WKContentView undoManager]): * UIProcess/ios/WKContentViewInteraction.mm: (shouldSynthezieKeyEvents): (-[WKContentView toggleBoldfaceForWebView:]): (-[WKContentView toggleItalicsForWebView:]): (-[WKContentView toggleUnderlineForWebView:]): (-[WKContentView _elementDidBlur]): * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::generateSyntheticEditingCommand): (WebKit::WebPage::getFocusedElementInformation): 2019-06-05 Alex Christensen <achristensen@webkit.org> Introduce new SPI for context menus on iOS https://bugs.webkit.org/show_bug.cgi?id=198590 Reviewed by Tim Horton. Also introduce WKContextMenuElementInfo which is API. This is part of <rdar://problem/51003503> * Shared/API/APIObject.h: * Shared/API/Cocoa/WebKit.h: * Shared/Cocoa/APIObject.mm: (API::Object::newObject): * Sources.txt: * SourcesCocoa.txt: * UIProcess/API/APIContextMenuElementInfo.cpp: Added. (API::ContextMenuElementInfo::ContextMenuElementInfo): * UIProcess/API/APIContextMenuElementInfo.h: Added. * UIProcess/API/Cocoa/WKContextMenuElementInfo.h: Added. * UIProcess/API/Cocoa/WKContextMenuElementInfo.mm: Added. (-[WKContextMenuElementInfo linkURL]): (-[WKContextMenuElementInfo _apiObject]): (-[WKContextMenuElementInfo _activatedElementInfo]): * UIProcess/API/Cocoa/WKContextMenuElementInfoInternal.h: Added. * UIProcess/API/Cocoa/WKContextMenuElementInfoPrivate.h: Added. * UIProcess/API/Cocoa/WKPreviewElementInfo.h: * UIProcess/API/Cocoa/WKUIDelegatePrivate.h: * UIProcess/API/Cocoa/_WKActivatedElementInfo.h: * UIProcess/API/Cocoa/_WKActivatedElementInfo.mm: (-[_WKActivatedElementInfo _initWithInteractionInformationAtPosition:]): (-[_WKActivatedElementInfo isAnimatedImage]): * UIProcess/ios/WKActionSheetAssistant.h: * UIProcess/ios/WKActionSheetAssistant.mm: (-[WKActionSheetAssistant defaultActionsForLinkSheet:]): (-[WKActionSheetAssistant defaultActionsForImageSheet:]): * UIProcess/ios/WKContentView.h: * UIProcess/ios/WKContentViewInteraction.mm: * WebKit.xcodeproj/project.pbxproj: 2019-06-07 Antoine Quint <graouts@apple.com> Restrict fast clicks everywhere to desktop content mode https://bugs.webkit.org/show_bug.cgi?id=198610 <rdar://problem/50114230> Reviewed by Dean Jackson. We now set a new allowsFastClicksEverywhere property on the WebPageProxy when the content mode changes, set to true when we're in desktop browsing mode. We now check on this property to opt into the fast clicks everywhere behavior. This patch had been reverted once because it yielded some regressions in existing tests, notably under fast/events/touch/ios/content-observation. This updated patch addresses this by ensuring the gesture recognizers used for double-tap-to-zoom are disabled in -[WKContentViewInteraction _didStartProvisionalLoadForMainFrame] to ensure that two tests dispatching a tap at the same location don't yield the recognition of a double-tap rathern than the recognition of two single taps. * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::allowsFastClicksEverywhere const): * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _handleSmartMagnificationInformationForPotentialTap:renderRect:fitEntireRect:viewportMinimumScale:viewportMaximumScale:]): (_didStartProvisionalLoadForMainFrame): * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::effectiveContentModeAfterAdjustingPolicies): 2019-06-07 Brent Fulgham <bfulgham@apple.com> [iOS] Update sandboxes to address iokit-get-property errors https://bugs.webkit.org/show_bug.cgi?id=198494 <rdar://problem/51322072> and <rdar://problem/50602737> Reviewed by Per Arne Vollan. * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb: 2019-06-07 Andy Estes <aestes@apple.com> process-swap-on-navigation error when loading blocked website on iOS 12.2 only. https://bugs.webkit.org/show_bug.cgi?id=196930 <rdar://problem/47819301> Reviewed by Chris Dumez. The ContentFilterDidBlockLoadForFrame message needs to be handled by ProvisionalPageProxy in order to look up the blocked frame in the correct WebProcessProxy. * UIProcess/Cocoa/WebPageProxyCocoa.mm: (WebKit::WebPageProxy::contentFilterDidBlockLoadForFrame): (WebKit::WebPageProxy::contentFilterDidBlockLoadForFrameShared): * UIProcess/ProvisionalPageProxy.cpp: (WebKit::ProvisionalPageProxy::contentFilterDidBlockLoadForFrame): (WebKit::ProvisionalPageProxy::didReceiveMessage): * UIProcess/ProvisionalPageProxy.h: * UIProcess/WebPageProxy.h: 2019-06-07 Carlos Garcia Campos <cgarcia@igalia.com> Unreviewed. Fix api used to release wpe_fdo_egl_exported_image in GTK We are using the old deprecated API in AcceleratedBackingStoreWayland::displayBuffer(). * UIProcess/gtk/AcceleratedBackingStoreWayland.cpp: (WebKit::AcceleratedBackingStoreWayland::displayBuffer): 2019-06-06 Carlos Garcia Campos <cgarcia@igalia.com> REGRESSION(r243094): [GTK][WPE] Stale content after restoring the web view session https://bugs.webkit.org/show_bug.cgi?id=198561 Reviewed by Chris Dumez. This is another regression of delaying the web process launch until the first load. If the session is restored before anything has been loaded, which is the normal way, the RestoreSession message is just ignored and the state is sent to the WebPage on creation via creation parameters. The WebPage considers that restoring a session from creation parameters only happens when re-launching a process after a crash or in case of process swap. In those cases, the history item is not marked as restored from session. We need to ensure the session is restored in the web process from the IPC message handler, by launching the initial process before the session is restored. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::restoreFromSessionState): 2019-06-06 Youenn Fablet <youenn@apple.com> Use an enumeration in UserMediaPermissionRequestManagerProxy::getUserMediaPermissionInfo callback https://bugs.webkit.org/show_bug.cgi?id=198548 Reviewed by Eric Carlson. Move from an Optional<bool> to an enum having three values to ease readability. * UIProcess/UserMediaPermissionCheckProxy.cpp: (WebKit::UserMediaPermissionCheckProxy::setUserMediaAccessInfo): (WebKit::UserMediaPermissionCheckProxy::complete): * UIProcess/UserMediaPermissionCheckProxy.h: (WebKit::UserMediaPermissionCheckProxy::invalidate): * UIProcess/UserMediaPermissionRequestManagerProxy.cpp: (WebKit::UserMediaPermissionRequestManagerProxy::captureDevicesChanged): (WebKit::UserMediaPermissionRequestManagerProxy::startProcessingUserMediaPermissionRequest): (WebKit::UserMediaPermissionRequestManagerProxy::getUserMediaPermissionInfo): (WebKit::UserMediaPermissionRequestManagerProxy::enumerateMediaDevicesForFrame): * UIProcess/UserMediaPermissionRequestManagerProxy.h: 2019-06-06 Youenn Fablet <youenn@apple.com> Allow WebKitTestRunner to terminate network process after it finishes service worker file operations https://bugs.webkit.org/show_bug.cgi?id=198584 Reviewed by Geoffrey Garen. Add IPC binding to new internal API. * NetworkProcess/ServiceWorker/WebSWServerConnection.messages.in: * WebProcess/Storage/WebSWClientConnection.cpp: (WebKit::WebSWClientConnection::storeRegistrationsOnDiskForTesting): * WebProcess/Storage/WebSWClientConnection.h: 2019-06-06 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r246165. https://bugs.webkit.org/show_bug.cgi?id=198636 Causing test failures in 7 content-observation tests. (Requested by ShawnRoberts on #webkit). Reverted changeset: "Restrict fast clicks everywhere to desktop content mode" https://bugs.webkit.org/show_bug.cgi?id=198610 https://trac.webkit.org/changeset/246165 2019-06-06 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r246123. https://bugs.webkit.org/show_bug.cgi?id=198634 Causes test failures (Requested by ShawnRoberts on #webkit). Reverted changeset: "[iOS] Update sandboxes to address iokit-get-property errors" https://bugs.webkit.org/show_bug.cgi?id=198494 https://trac.webkit.org/changeset/246123 2019-06-06 Geoffrey Garen <ggaren@apple.com> Crash using WKHTTPCookieStore when you use WKWebView and UIWebView in the same app https://bugs.webkit.org/show_bug.cgi?id=198622 Reviewed by Chris Dumez. Today in a WWDC lab, I saw some crash reports from an app that mixed WKWebView and UIWebView. The proximate cause of the crash is that WKHTTPCookieStore queues a callOnMainThread function, and then UIWebView dequeues it on the WebThread. No test because this crash depends on mixing WKWebView and UIWebView and getting (un)lucky on the timing. * UIProcess/API/APIHTTPCookieStore.cpp: (API::HTTPCookieStore::cookies): (API::HTTPCookieStore::setCookies): (API::HTTPCookieStore::deleteCookie): Avoid using callOnMainThread becuase it is prohibited in the UI process. 2019-06-06 Antoine Quint <graouts@apple.com> Remove duplicated websiteDataStoreParameters code from WebsitePoliciesData::applyToDocumentLoader() https://bugs.webkit.org/show_bug.cgi?id=198608 Reviewed by Wenson Hsieh. Due to a rebasing error, r244218 re-introduced code that was removed in r244197. This patch removes this code for good. * Shared/WebsitePoliciesData.cpp: (WebKit::WebsitePoliciesData::applyToDocumentLoader): 2019-06-06 Antoine Quint <graouts@apple.com> Restrict fast clicks everywhere to desktop content mode https://bugs.webkit.org/show_bug.cgi?id=198610 <rdar://problem/50114230> Reviewed by Dean Jackson. * UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::allowsFastClicksEverywhere const): * UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _handleSmartMagnificationInformationForPotentialTap:renderRect:fitEntireRect:viewportMinimumScale:viewportMaximumScale:]): * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::effectiveContentModeAfterAdjustingPolicies): 2019-06-06 Sihui Liu <sihui_liu@apple.com> NetworkHTTPSUpgradeChecker should construct and destruct database on the background thread https://bugs.webkit.org/show_bug.cgi?id=198496 Reviewed by Chris Dumez. * NetworkProcess/NetworkHTTPSUpgradeChecker.cpp: (WebKit::NetworkHTTPSUpgradeChecker::NetworkHTTPSUpgradeChecker): (WebKit::NetworkHTTPSUpgradeChecker::~NetworkHTTPSUpgradeChecker): * NetworkProcess/NetworkHTTPSUpgradeChecker.h: 2019-06-06 Truitt Savell <tsavell@apple.com> Unreviewed, rolling out r246137. Broke internal builds. Reverted changeset: "Introduce new SPI for context menus on iOS" https://bugs.webkit.org/show_bug.cgi?id=198590 https://trac.webkit.org/changeset/246137 2019-06-06 Antti Koivisto <antti@apple.com> Position fixed is buggy with overflow:auto scrolling inside iframes https://bugs.webkit.org/show_bug.cgi?id=154399 <rdar://problem/24742251> Reviewed by Frederic Wang and Simon Fraser. * UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree): Remove viewportChangedViaDelegatedScrolling call as we were just relying on its side effect of (partially) applying the scrolling tree. Instead call the new applyScrollingTreeLayerPositionsAfterCommit() unconditionally. It only does work if there are local deltas to apply. Local deltas will potentially need to be applied in non-fixed cases too and it is hard to reason about the conditions. * UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.cpp: (WebKit::RemoteScrollingCoordinatorProxy::applyScrollingTreeLayerPositionsAfterCommit): (WebKit::RemoteScrollingCoordinatorProxy::applyScrollingTreeLayerPositions): Deleted. * UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.h: 2019-06-06 Michael Catanzaro <mcatanzaro@igalia.com> [WPE][GTK] Clean up use of initiatingPageID in implementation of webkit_uri_scheme_request_get_web_view() https://bugs.webkit.org/show_bug.cgi?id=198564 Reviewed by Carlos Garcia Campos. Note that we have to use RefPtr rather than Ref here because the priv struct has to remain default-constructible. * UIProcess/API/glib/WebKitURISchemeRequest.cpp: (webkitURISchemeRequestCreate): (webkit_uri_scheme_request_get_web_view): 2019-06-06 Carlos Garcia Campos <cgarcia@igalia.com> [GTK][WPE] Enable PSON https://bugs.webkit.org/show_bug.cgi?id=194979 Reviewed by Žan Doberšek. * Shared/WebPreferencesDefaultValues.h: 2019-06-05 Said Abou-Hallawa <sabouhallawa@apple.com> [Cocoa] REGRESSION(r244182): Inspector thinks CA commits can be nested https://bugs.webkit.org/show_bug.cgi?id=198497 Reviewed by Simon Fraser. Call InspectorController::willComposite() from the CA preCommit handler similar to the call to InspectorController::didComposite() in the CA postCommit handler. Ensure these calls will be once for nested commits. * WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.h: * WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::addCommitHandlers): (WebKit::RemoteLayerTreeDrawingArea::flushLayers): * WebProcess/WebPage/WebPage.h: (WebKit::WebPage::firstFlushAfterCommit const): (WebKit::WebPage::setFirstFlushAfterCommit): * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.h: * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm: (WebKit::TiledCoreAnimationDrawingArea::addCommitHandlers): (WebKit::TiledCoreAnimationDrawingArea::flushLayers): 2019-06-05 Alex Christensen <achristensen@webkit.org> Introduce new SPI for context menus on iOS https://bugs.webkit.org/show_bug.cgi?id=198590 Reviewed by Tim Horton. Also introduce WKContextMenuElementInfo which is API. This is part of <rdar://problem/51003503> * Shared/API/APIObject.h: * Shared/API/Cocoa/WebKit.h: * Shared/Cocoa/APIObject.mm: (API::Object::newObject): * Sources.txt: * SourcesCocoa.txt: * UIProcess/API/APIContextMenuElementInfo.cpp: Added. (API::ContextMenuElementInfo::ContextMenuElementInfo): * UIProcess/API/APIContextMenuElementInfo.h: Added. * UIProcess/API/Cocoa/WKContextMenuElementInfo.h: Added. * UIProcess/API/Cocoa/WKContextMenuElementInfo.mm: Added. (-[WKContextMenuElementInfo linkURL]): (-[WKContextMenuElementInfo _apiObject]): (-[WKContextMenuElementInfo _activatedElementInfo]): * UIProcess/API/Cocoa/WKContextMenuElementInfoInternal.h: Added. * UIProcess/API/Cocoa/WKContextMenuElementInfoPrivate.h: Added. * UIProcess/API/Cocoa/WKPreviewElementInfo.h: * UIProcess/API/Cocoa/WKUIDelegatePrivate.h: * UIProcess/API/Cocoa/_WKActivatedElementInfo.h: * UIProcess/API/Cocoa/_WKActivatedElementInfo.mm: (-[_WKActivatedElementInfo _initWithInteractionInformationAtPosition:]): (-[_WKActivatedElementInfo isAnimatedImage]): * UIProcess/ios/WKActionSheetAssistant.h: * UIProcess/ios/WKActionSheetAssistant.mm: (-[WKActionSheetAssistant defaultActionsForLinkSheet:]): (-[WKActionSheetAssistant defaultActionsForImageSheet:]): * UIProcess/ios/WKContentView.h: * UIProcess/ios/WKContentViewInteraction.mm: * WebKit.xcodeproj/project.pbxproj: 2019-06-05 Jer Noble <jer.noble@apple.com> -[WKWebView _suspendAllMediaPlayback] does not persist across navigation. https://bugs.webkit.org/show_bug.cgi?id=198585 Reviewed by Chris Dumez. Add a new WebPageCreationParameters entry for mediaPlaybackIsSuspended, and pass that value across during WebPage creation. * Shared/WebPageCreationParameters.cpp: (WebKit::WebPageCreationParameters::encode const): (WebKit::WebPageCreationParameters::decode): * Shared/WebPageCreationParameters.h: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::suspendAllMediaPlayback): (WebKit::WebPageProxy::resumeAllMediaPlayback): (WebKit::WebPageProxy::creationParameters): * UIProcess/WebPageProxy.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage): 2019-06-05 Sihui Liu <sihui_liu@apple.com> TestWebKitAPI.WKWebView.LocalStorageProcessSuspends is flaky on release builds https://bugs.webkit.org/show_bug.cgi?id=198582 Reviewed by Youenn Fablet. Initialize the state of StorageManager. * NetworkProcess/WebStorage/StorageManager.h: 2019-06-05 Alex Christensen <achristensen@webkit.org> Re-enable safe browsing in WKWebView https://bugs.webkit.org/show_bug.cgi?id=196161 <rdar://problem/49171413> Reviewed by Ryosuke Niwa. This is mostly just reverting r241728. * Shared/WebPreferences.yaml: * UIProcess/API/Cocoa/WKPreferences.h: * UIProcess/API/Cocoa/WKPreferences.mm: (-[WKPreferences setSafeBrowsingEnabled:]): (-[WKPreferences isSafeBrowsingEnabled]): 2019-06-05 Alex Christensen <achristensen@webkit.org> Progress towards resurrecting Mac CMake build https://bugs.webkit.org/show_bug.cgi?id=197132 Reviewed by Don Olmstead. * PlatformMac.cmake: 2019-06-05 Youenn Fablet <youenn@apple.com> Remove logSiteIdentifier from UserMediaPermissionRequestManagerProxy::requestUserMediaPermissionForFrame https://bugs.webkit.org/show_bug.cgi?id=198575 Reviewed by Eric Carlson. * UIProcess/UserMediaPermissionRequestManagerProxy.cpp: (WebKit::UserMediaPermissionRequestManagerProxy::requestUserMediaPermissionForFrame): == Rolled over to ChangeLog-2019-06-05 ==