2019-09-20 Alan Coon Apply patch. rdar://problem/55564031 2019-09-20 Chris Dumez Regression(r248832): Unable to quicklook HTML files in Mail https://bugs.webkit.org/show_bug.cgi?id=202012 Reviewed by Geoff Garen and Brent Fulgham. r248832 inadvertently reverted the fix for Mail that landed in r247400 by not using the same logic to initialize the sandbox extension if the process had already finished launching or not. In particular, the new code path that happens on process launch unconditionally used '/' as resource directory for the sandbox extension if the client did not provide one. The logic in maybeInitializeSandboxExtensionHandle() would use the file URL's base URL as resource directory when creating a sandbox extension for '/' would fail (which it often does). To address the issue, have the logic that runs on process launch call maybeInitializeSandboxExtensionHandle() so avoid duplicating code and make sure both cases now have the Mail fix. * UIProcess/AuxiliaryProcessProxy.cpp: (WebKit::AuxiliaryProcessProxy::didFinishLaunching): * UIProcess/AuxiliaryProcessProxy.h: (WebKit::AuxiliaryProcessProxy::isLaunching const): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle): (WebKit::WebPageProxy::loadRequestWithNavigationShared): (WebKit::WebPageProxy::loadFile): * UIProcess/WebPageProxy.h: * WebProcess/WebPage/WebPage.messages.in: 2019-09-19 Kocsen Chung Cherry-pick r250069. rdar://problem/55524978 Eagerly create and add the m_layerHostingView to WKWebView. https://bugs.webkit.org/show_bug.cgi?id=201942 Reviewed by Tim Horton. Some apps will add subviews to WKWebView, and by the time we add our m_layerHostingView view we might be adding it behind a view that should have been added behind our layer hosting view subview. This affected the Spark email app, due to changes in order of loading delegate calls and when compositing is enabled. Instead of delayed creation of m_layerHostingView, always create it and add it to to the WKWebView. This ensures proper ordering of subviews when clients add a view behind all existing subviews. * UIProcess/Cocoa/WebViewImpl.mm: (WebKit::WebViewImpl::WebViewImpl): Create and add m_layerHostingView here. (WebKit::WebViewImpl::setAcceleratedCompositingRootLayer): Remove creation and removal of m_layerHostingView. Just set the sublayers of m_layerHostingView's layer here. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250069 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-18 Timothy Hatcher Eagerly create and add the m_layerHostingView to WKWebView. https://bugs.webkit.org/show_bug.cgi?id=201942 Reviewed by Tim Horton. Some apps will add subviews to WKWebView, and by the time we add our m_layerHostingView view we might be adding it behind a view that should have been added behind our layer hosting view subview. This affected the Spark email app, due to changes in order of loading delegate calls and when compositing is enabled. Instead of delayed creation of m_layerHostingView, always create it and add it to to the WKWebView. This ensures proper ordering of subviews when clients add a view behind all existing subviews. * UIProcess/Cocoa/WebViewImpl.mm: (WebKit::WebViewImpl::WebViewImpl): Create and add m_layerHostingView here. (WebKit::WebViewImpl::setAcceleratedCompositingRootLayer): Remove creation and removal of m_layerHostingView. Just set the sublayers of m_layerHostingView's layer here. 2019-09-11 Alan Coon Apply patch. rdar://problem/55240886 2019-09-11 Chris Dumez Nullptr crash in Page::sessionID() via WebKit::WebFrameLoaderClient::detachedFromParent2() https://bugs.webkit.org/show_bug.cgi?id=201625 Reviewed by Ryosuke Niwa. This is based on a patch from Ryosuke Niwa. The crash was caused by WebFrameLoaderClient::sessionID() calling WebPage::sessionID() without checking the nullity of WebPage::m_page which can be null. Added a null check. Because passing a wrong session to RemoveStorageAccessForFrame could result in a leak, this patch also replaces m_hasFrameSpecificStorageAccess boolean with an optioanl struct which stores session ID, frame ID, and page ID even after WebCore::Frame or WebCore::Page had been cleared or before WebFrameLoaderClient::m_frame is set. * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::sessionID const): (WebKit::WebFrameLoaderClient::setHasFrameSpecificStorageAccess): (WebKit::WebFrameLoaderClient::detachedFromParent2): (WebKit::WebFrameLoaderClient::dispatchWillChangeDocument): * WebProcess/WebCoreSupport/WebFrameLoaderClient.h: * WebProcess/WebPage/WebFrame.h: (WebKit::WebFrame::frameLoaderClient const): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::requestStorageAccess): 2019-09-09 Alan Coon Cherry-pick r249649. rdar://problem/55198064 [macOS] Pid is sometimes invalid when creating sandbox extensions by pid. https://bugs.webkit.org/show_bug.cgi?id=201543 Reviewed by Brent Fulgham. There is a race condition when starting a load of a local file, where the WebContent process has not finished launching yet, and its pid is not available. When we try to create a sandbox extension by using the pid of the WebContent process, it is not available in the cases where the WebContent process has just launched and has not finished launching yet. This patch creates a new dummy Web page message, 'LoadRequestWaitingForPID', which will be sent instead of a normal 'LoadRequest' message, and only when the WebContent process has not finished launching. When the WebContent process has finished launching, and we are about to actually send the pending messages, we can detect that a 'LoadRequestWaitingForPID' has been appended for sending, and replace it with a normal 'LoadReqest' message where we have created the sandbox extension issue with a valid pid. The message 'LoadRequestWaitingForPID' is never intended to reach the WebContent process, it is just there to replace with a normal 'LoadRequest' message with a new sandbox extension. In the implementation of the message handler on the WebContent process side, we assert that the method is never called. This patch makes sure the ordering of the Web page messages are the same, even when we modify the message. * UIProcess/AuxiliaryProcessProxy.cpp: (WebKit::AuxiliaryProcessProxy::didFinishLaunching): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle): (WebKit::WebPageProxy::loadRequestWithNavigationShared): (WebKit::WebPageProxy::loadFile): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::fileLoadRequest): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249649 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-09 Per Arne Vollan [macOS] Pid is sometimes invalid when creating sandbox extensions by pid. https://bugs.webkit.org/show_bug.cgi?id=201543 Reviewed by Brent Fulgham. There is a race condition when starting a load of a local file, where the WebContent process has not finished launching yet, and its pid is not available. When we try to create a sandbox extension by using the pid of the WebContent process, it is not available in the cases where the WebContent process has just launched and has not finished launching yet. This patch creates a new dummy Web page message, 'LoadRequestWaitingForPID', which will be sent instead of a normal 'LoadRequest' message, and only when the WebContent process has not finished launching. When the WebContent process has finished launching, and we are about to actually send the pending messages, we can detect that a 'LoadRequestWaitingForPID' has been appended for sending, and replace it with a normal 'LoadReqest' message where we have created the sandbox extension issue with a valid pid. The message 'LoadRequestWaitingForPID' is never intended to reach the WebContent process, it is just there to replace with a normal 'LoadRequest' message with a new sandbox extension. In the implementation of the message handler on the WebContent process side, we assert that the method is never called. This patch makes sure the ordering of the Web page messages are the same, even when we modify the message. * UIProcess/AuxiliaryProcessProxy.cpp: (WebKit::AuxiliaryProcessProxy::didFinishLaunching): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle): (WebKit::WebPageProxy::loadRequestWithNavigationShared): (WebKit::WebPageProxy::loadFile): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::fileLoadRequest): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/WebPage.messages.in: 2019-09-09 Alan Coon Cherry-pick r249454. rdar://problem/55198064 [macOS] Unable to open local file from favorites bar https://bugs.webkit.org/show_bug.cgi?id=201444 Reviewed by Brent Fulgham. The sandbox extension handle should be created providing the pid of the receiving process. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249454 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-03 Per Arne Vollan [macOS] Unable to open local file from favorites bar https://bugs.webkit.org/show_bug.cgi?id=201444 Reviewed by Brent Fulgham. The sandbox extension handle should be created providing the pid of the receiving process. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle): 2019-09-04 Kocsen Chung Cherry-pick r249430. rdar://problem/55031098 [macOS] Correct sandbox violation in Flash plugin https://bugs.webkit.org/show_bug.cgi?id=201228 Reviewed by Alex Christensen. * PluginProcess/mac/com.apple.WebKit.plugin-common.sb.in: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249430 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-28 Brent Fulgham [macOS] Correct sandbox violation in Flash plugin https://bugs.webkit.org/show_bug.cgi?id=201228 Reviewed by Alex Christensen. * PluginProcess/mac/com.apple.WebKit.plugin-common.sb.in: 2019-08-28 Kocsen Chung Cherry-pick r249224. rdar://problem/54819205 Null check webFrame when creating a print preview to prevent a crash. https://bugs.webkit.org/show_bug.cgi?id=201237 Reviewed by Tim Horton. Source/WebKit: Move and expend a null check to keep from crashing when making a print preview. * UIProcess/mac/WKPrintingView.mm: (-[WKPrintingView _drawPreview:]): (-[WKPrintingView drawRect:]): Tools: Test to verify that if we don't have the WebPageProxy, we will not crash when making a print preview. * TestWebKitAPI/Tests/WebKitCocoa/UIDelegate.mm: (TEST): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249224 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-28 Megan Gardner Null check webFrame when creating a print preview to prevent a crash. https://bugs.webkit.org/show_bug.cgi?id=201237 Reviewed by Tim Horton. Move and expend a null check to keep from crashing when making a print preview. * UIProcess/mac/WKPrintingView.mm: (-[WKPrintingView _drawPreview:]): (-[WKPrintingView drawRect:]): 2019-08-27 Alan Coon Revert r249147. rdar://problem/54751753 2019-08-27 Alan Coon 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 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 Removing fullscreen element in rAF() callback after requestFullscreen() can leave fullscreen in inconsistent state. https://bugs.webkit.org/show_bug.cgi?id=201101 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 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 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 [iOS] [WebKit2] Tapping on the “I’m” text suggestion after typing “i’” does nothing https://bugs.webkit.org/show_bug.cgi?id=201085 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 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 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 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 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 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 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 [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 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 Cherry-pick r248959. rdar://problem/54579630 Crash under StringImpl::~StringImpl() in NetworkProcess::deleteWebsiteDataForRegistrableDomains() https://bugs.webkit.org/show_bug.cgi?id=200986 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 Crash under StringImpl::~StringImpl() in NetworkProcess::deleteWebsiteDataForRegistrableDomains() https://bugs.webkit.org/show_bug.cgi?id=200986 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 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 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 [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 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 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 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 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 [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/Cocoa/WebPageProxyCocoa.mm: (WebKit::WebPageProxy::createSandboxExtensionsIfNeeded): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle): (WebKit::WebPageProxy::loadFile): 2019-08-18 Babak Shafiei 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 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 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 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 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 Cherry-pick r248819. rdar://problem/54455005 Content in