2019-08-27 Alan Coon Revert r249140. rdar://problem/54749102 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. 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: 2019-08-27 Alan Coon Cherry-pick r249140. rdar://problem/54749102 Image pasted from screenshot into Mail compose window via share sheet has the wrong aspect ratio https://bugs.webkit.org/show_bug.cgi?id=201171 Reviewed by Tim Horton. Augments an existing app-specific hack to include the Mail composition service, in addition to Mail. * platform/RuntimeApplicationChecks.h: * platform/cocoa/RuntimeApplicationChecksCocoa.mm: (WebCore::IOSApplication::isMailCompositionService): Add a new bundle checking method for the Mail composition service (com.apple.MailCompositionService). * platform/ios/PlatformPasteboardIOS.mm: (WebCore::PlatformPasteboard::informationForItemAtIndex): Only plumb the preferred presentation height through to the web process if the application is neither Mail nor the Mail composition service. In the future, we should consider putting this hack behind SPI, or maybe only expose the preferred presentation width in all apps (it isn't difficult to imagine a use case where a "Mail- compose-like" web app has `img { max-width: 100%; }` in their stylesheet). git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249140 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-27 Wenson Hsieh Image pasted from screenshot into Mail compose window via share sheet has the wrong aspect ratio https://bugs.webkit.org/show_bug.cgi?id=201171 Reviewed by Tim Horton. Augments an existing app-specific hack to include the Mail composition service, in addition to Mail. * platform/RuntimeApplicationChecks.h: * platform/cocoa/RuntimeApplicationChecksCocoa.mm: (WebCore::IOSApplication::isMailCompositionService): Add a new bundle checking method for the Mail composition service (com.apple.MailCompositionService). * platform/ios/PlatformPasteboardIOS.mm: (WebCore::PlatformPasteboard::informationForItemAtIndex): Only plumb the preferred presentation height through to the web process if the application is neither Mail nor the Mail composition service. In the future, we should consider putting this hack behind SPI, or maybe only expose the preferred presentation width in all apps (it isn't difficult to imagine a use case where a "Mail- compose-like" web app has `img { max-width: 100%; }` in their stylesheet). 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. 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: 2019-08-27 Alan Coon Cherry-pick r248886. rdar://problem/54365278 Source/WebCore: [Cocoa] Fix misspelling of -preventsDisplaySleepForVideoPlayback https://bugs.webkit.org/show_bug.cgi?id=200774 Reviewed by Eric Carlson. Only declare the API on platforms where that API is undefined, so as to catch this kind of misspelling at compile time. * platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm: (WebCore::MediaPlayerPrivateMediaSourceAVFObjC::ensureLayer): Source/WebCore/PAL: [Cocoa] Adopt -preventDisplaySleepForVideoPlayback https://bugs.webkit.org/show_bug.cgi?id=200774 Reviewed by Eric Carlson. * pal/spi/mac/AVFoundationSPI.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248886 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-19 Jer Noble [Cocoa] Fix misspelling of -preventsDisplaySleepForVideoPlayback https://bugs.webkit.org/show_bug.cgi?id=200774 Reviewed by Eric Carlson. Only declare the API on platforms where that API is undefined, so as to catch this kind of misspelling at compile time. * platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm: (WebCore::MediaPlayerPrivateMediaSourceAVFObjC::ensureLayer): 2019-08-23 Kocsen Chung Cherry-pick r248969. rdar://problem/54643450 Crash under StringImpl::~StringImpl() in IDBServer::computeSpaceUsedForOrigin() https://bugs.webkit.org/show_bug.cgi?id=200989 Reviewed by Alex Christensen. Make sure we call isolatedCopy() on IDBServer::m_databaseDirectoryPath before using it from background threads. * Modules/indexeddb/server/IDBServer.cpp: (WebCore::IDBServer::IDBServer::createBackingStore): (WebCore::IDBServer::IDBServer::performGetAllDatabaseNames): (WebCore::IDBServer::IDBServer::removeDatabasesModifiedSinceForVersion): (WebCore::IDBServer::IDBServer::performCloseAndDeleteDatabasesModifiedSince): (WebCore::IDBServer::IDBServer::removeDatabasesWithOriginsForVersion): (WebCore::IDBServer::IDBServer::performCloseAndDeleteDatabasesForOrigins): (WebCore::IDBServer::IDBServer::computeSpaceUsedForOrigin): (WebCore::IDBServer::IDBServer::upgradeFilesIfNecessary): * Modules/indexeddb/server/IDBServer.h: (WebCore::IDBServer::IDBServer::databaseDirectoryPath const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248969 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-21 Chris Dumez Crash under StringImpl::~StringImpl() in IDBServer::computeSpaceUsedForOrigin() https://bugs.webkit.org/show_bug.cgi?id=200989 Reviewed by Alex Christensen. Make sure we call isolatedCopy() on IDBServer::m_databaseDirectoryPath before using it from background threads. * Modules/indexeddb/server/IDBServer.cpp: (WebCore::IDBServer::IDBServer::createBackingStore): (WebCore::IDBServer::IDBServer::performGetAllDatabaseNames): (WebCore::IDBServer::IDBServer::removeDatabasesModifiedSinceForVersion): (WebCore::IDBServer::IDBServer::performCloseAndDeleteDatabasesModifiedSince): (WebCore::IDBServer::IDBServer::removeDatabasesWithOriginsForVersion): (WebCore::IDBServer::IDBServer::performCloseAndDeleteDatabasesForOrigins): (WebCore::IDBServer::IDBServer::computeSpaceUsedForOrigin): (WebCore::IDBServer::IDBServer::upgradeFilesIfNecessary): * Modules/indexeddb/server/IDBServer.h: (WebCore::IDBServer::IDBServer::databaseDirectoryPath const): 2019-08-23 Kocsen Chung Cherry-pick r248971. rdar://problem/54643440 Crash under StringImpl::endsWith() in SQLiteIDBBackingStore::fullDatabaseDirectoryWithUpgrade() https://bugs.webkit.org/show_bug.cgi?id=200990 Reviewed by Alex Christensen. Make sure we call isolatedCopy() on SQLiteIDBBackingStore::m_databaseRootDirectory before using it from background threads. * Modules/indexeddb/server/SQLiteIDBBackingStore.cpp: (WebCore::IDBServer::SQLiteIDBBackingStore::fullDatabaseDirectoryWithUpgrade): (WebCore::IDBServer::SQLiteIDBBackingStore::databasesSizeForOrigin const): (WebCore::IDBServer::SQLiteIDBBackingStore::deleteBackingStore): * Modules/indexeddb/server/SQLiteIDBBackingStore.h: (WebCore::IDBServer::SQLiteIDBBackingStore::databaseRootDirectory const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248971 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-21 Chris Dumez Crash under StringImpl::endsWith() in SQLiteIDBBackingStore::fullDatabaseDirectoryWithUpgrade() https://bugs.webkit.org/show_bug.cgi?id=200990 Reviewed by Alex Christensen. Make sure we call isolatedCopy() on SQLiteIDBBackingStore::m_databaseRootDirectory before using it from background threads. * Modules/indexeddb/server/SQLiteIDBBackingStore.cpp: (WebCore::IDBServer::SQLiteIDBBackingStore::fullDatabaseDirectoryWithUpgrade): (WebCore::IDBServer::SQLiteIDBBackingStore::databasesSizeForOrigin const): (WebCore::IDBServer::SQLiteIDBBackingStore::deleteBackingStore): * Modules/indexeddb/server/SQLiteIDBBackingStore.h: (WebCore::IDBServer::SQLiteIDBBackingStore::databaseRootDirectory const): 2019-08-23 Kocsen Chung Cherry-pick r248967. rdar://problem/54643456 Crash under StringImpl::endsWith() in RegistrationDatabase::openSQLiteDatabase() https://bugs.webkit.org/show_bug.cgi?id=200991 Reviewed by Geoffrey Garen. Make sure we call isolatedCopy() on RegistrationDatabase::m_databaseDirectory before using it from background threads. * workers/service/server/RegistrationDatabase.cpp: (WebCore::RegistrationDatabase::openSQLiteDatabase): (WebCore::RegistrationDatabase::clearAll): * workers/service/server/RegistrationDatabase.h: (WebCore::RegistrationDatabase::databaseDirectory const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248967 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-21 Chris Dumez Crash under StringImpl::endsWith() in RegistrationDatabase::openSQLiteDatabase() https://bugs.webkit.org/show_bug.cgi?id=200991 Reviewed by Geoffrey Garen. Make sure we call isolatedCopy() on RegistrationDatabase::m_databaseDirectory before using it from background threads. * workers/service/server/RegistrationDatabase.cpp: (WebCore::RegistrationDatabase::openSQLiteDatabase): (WebCore::RegistrationDatabase::clearAll): * workers/service/server/RegistrationDatabase.h: (WebCore::RegistrationDatabase::databaseDirectory const): 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. 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): 2019-08-22 Kocsen Chung Cherry-pick r248977. rdar://problem/54599960 Do not adjust viewport if editing selection is already visible https://bugs.webkit.org/show_bug.cgi?id=200907 Reviewed by Simon Fraser. Source/WebCore: Test: fast/scrolling/ios/autoscroll-input-when-very-zoomed.html Currently due to scrolling being mostly handled by integers, we are getting issues with rounding errors when trying to adjust the viewport while editing text when we are significantly zoomed in. The real fix would be to start dealing with scrolling with floats/doubles, but until such time, we should early out of adjusting selections that we are certain are currently visible. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::scrollRectToVisible): LayoutTests: * fast/scrolling/ios/autoscroll-input-when-very-zoomed-expected.txt: Added. * fast/scrolling/ios/autoscroll-input-when-very-zoomed.html: Added. * resources/ui-helper.js: (window.UIHelper.immediateZoomToScale): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248977 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-21 Megan Gardner Do not adjust viewport if editing selection is already visible https://bugs.webkit.org/show_bug.cgi?id=200907 Reviewed by Simon Fraser. Test: fast/scrolling/ios/autoscroll-input-when-very-zoomed.html Currently due to scrolling being mostly handled by integers, we are getting issues with rounding errors when trying to adjust the viewport while editing text when we are significantly zoomed in. The real fix would be to start dealing with scrolling with floats/doubles, but until such time, we should early out of adjusting selections that we are certain are currently visible. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::scrollRectToVisible): 2019-08-22 Kocsen Chung Cherry-pick r248997. rdar://problem/54579627 Unreviewed build fix; add a 'final' declaration on shouldOverridePauseDuringRouteChange(). * Modules/mediastream/MediaStream.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248997 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-21 Jer Noble Unreviewed build fix; add a 'final' declaration on shouldOverridePauseDuringRouteChange(). * Modules/mediastream/MediaStream.h: 2019-08-21 Kocsen Chung Cherry-pick r248978. rdar://problem/54579627 Adopt AVSystemController_ActiveAudioRouteDidChangeNotification https://bugs.webkit.org/show_bug.cgi?id=200992 Reviewed by Eric Carlson. Follow-up to r248962: When the active audio route changes, and the system instructs us to pause, only pause the currently audible sessions. * platform/audio/ios/MediaSessionManagerIOS.h: * platform/audio/ios/MediaSessionManagerIOS.mm: (WebCore::MediaSessionManageriOS::activeAudioRouteDidChange): (-[WebMediaSessionHelper activeAudioRouteDidChange:]): (WebCore::MediaSessionManageriOS::activeRouteDidChange): Deleted. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248978 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-21 Jer Noble Adopt AVSystemController_ActiveAudioRouteDidChangeNotification https://bugs.webkit.org/show_bug.cgi?id=200992 Reviewed by Eric Carlson. Follow-up to r248962: When the active audio route changes, and the system instructs us to pause, only pause the currently audible sessions. * platform/audio/ios/MediaSessionManagerIOS.h: * platform/audio/ios/MediaSessionManagerIOS.mm: (WebCore::MediaSessionManageriOS::activeAudioRouteDidChange): (-[WebMediaSessionHelper activeAudioRouteDidChange:]): (WebCore::MediaSessionManageriOS::activeRouteDidChange): Deleted. 2019-08-21 Kocsen Chung Cherry-pick r248962. rdar://problem/54579627 Adopt AVSystemController_ActiveAudioRouteDidChangeNotification https://bugs.webkit.org/show_bug.cgi?id=200992 Reviewed by Eric Carlson. When the system notifies us that the active audio route has changed in such a way that necessitates pausing, pause all media sessions, exempting those that are associated with WebRTC, since "pausing" an active audio conference isn't really possible. * Modules/mediastream/MediaStream.h: * platform/audio/PlatformMediaSession.cpp: (WebCore::PlatformMediaSession::shouldOverridePauseDuringRouteChange const): * platform/audio/PlatformMediaSession.h: (WebCore::PlatformMediaSessionClient::shouldOverridePauseDuringRouteChange const): * platform/audio/ios/MediaSessionManagerIOS.h: * platform/audio/ios/MediaSessionManagerIOS.mm: (WebCore::MediaSessionManageriOS::activeRouteDidChange): (-[WebMediaSessionHelper initWithCallback:]): (-[WebMediaSessionHelper activeAudioRouteDidChange:]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248962 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-21 Jer Noble Adopt AVSystemController_ActiveAudioRouteDidChangeNotification https://bugs.webkit.org/show_bug.cgi?id=200992 Reviewed by Eric Carlson. When the system notifies us that the active audio route has changed in such a way that necessitates pausing, pause all media sessions, exempting those that are associated with WebRTC, since "pausing" an active audio conference isn't really possible. * Modules/mediastream/MediaStream.h: * platform/audio/PlatformMediaSession.cpp: (WebCore::PlatformMediaSession::shouldOverridePauseDuringRouteChange const): * platform/audio/PlatformMediaSession.h: (WebCore::PlatformMediaSessionClient::shouldOverridePauseDuringRouteChange const): * platform/audio/ios/MediaSessionManagerIOS.h: * platform/audio/ios/MediaSessionManagerIOS.mm: (WebCore::MediaSessionManageriOS::activeRouteDidChange): (-[WebMediaSessionHelper initWithCallback:]): (-[WebMediaSessionHelper activeAudioRouteDidChange:]): 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. 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. 2019-08-21 Kocsen Chung Cherry-pick r248952. rdar://problem/54579626 [iOS] HLS streams disappear from Now Playing when paused on the lock screen https://bugs.webkit.org/show_bug.cgi?id=200951 Reviewed by Eric Carlson. The AVPlayerItemTracks will get recreated on occasion (during seeks, and when changing buffering policy) which can result in a player which no longer reports that it has audio, which in turn results in Now Playing no longer considering the web page to be an eligable now playing application. Bridge this gap by also taking AVPlayerItem.hasEnabledAudio into account when determining whether the player has audio. * platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm: (WebCore::MediaPlayerPrivateAVFoundationObjC::tracksChanged): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248952 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-21 Jer Noble [iOS] HLS streams disappear from Now Playing when paused on the lock screen https://bugs.webkit.org/show_bug.cgi?id=200951 Reviewed by Eric Carlson. The AVPlayerItemTracks will get recreated on occasion (during seeks, and when changing buffering policy) which can result in a player which no longer reports that it has audio, which in turn results in Now Playing no longer considering the web page to be an eligable now playing application. Bridge this gap by also taking AVPlayerItem.hasEnabledAudio into account when determining whether the player has audio. * platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm: (WebCore::MediaPlayerPrivateAVFoundationObjC::tracksChanged): 2019-08-21 Kocsen Chung Cherry-pick r248944. rdar://problem/54579628 REGRESSION: naver.com - Multiple taps are required to open email https://bugs.webkit.org/show_bug.cgi?id=200979 Patch by Antoine Quint on 2019-08-21 Reviewed by Dean Jackson. The "click" events on subjects in the message list are prevented by preventDefault() being called from a "mouseup" event listener. This shouldn't actually happen, but due to how simulated mouse events are implemented, there is no current distinction between "touchend" and "mouseup" events. It is safe however to opt mail.naver.com out of simulated mouse events altogether. * page/Quirks.cpp: (WebCore::Quirks::shouldDispatchSimulatedMouseEvents const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248944 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-21 Antoine Quint REGRESSION: naver.com - Multiple taps are required to open email https://bugs.webkit.org/show_bug.cgi?id=200979 Reviewed by Dean Jackson. The "click" events on subjects in the message list are prevented by preventDefault() being called from a "mouseup" event listener. This shouldn't actually happen, but due to how simulated mouse events are implemented, there is no current distinction between "touchend" and "mouseup" events. It is safe however to opt mail.naver.com out of simulated mouse events altogether. * page/Quirks.cpp: (WebCore::Quirks::shouldDispatchSimulatedMouseEvents const): 2019-08-20 Babak Shafiei Cherry-pick r248909. rdar://problem/54543354 Clicking the search icon on ae.com hangs the web content process https://bugs.webkit.org/show_bug.cgi?id=200889 Reviewed by Ryosuke Niwa. Source/WebCore: The hang occurs under FrameSelection::selectionAtSentenceStart, while computing an EditorState to send to the UI process. This act of determining whether the given positon is at the start of sentence entails moving backwards from the start of the current visible selection until the start of a paragraph or sentence is found, using VisiblePosition::previous to iterate backwards through VisiblePositions. However, on this website, VisiblePosition::previous ends up just returning the current position, and we loop infinitely as a result because we never actually move backwards. This happens because VisiblePosition::previous first uses previousVisuallyDistinctCandidate to find a candidate Position before the current position, but when the position is canonicalized to create a VisiblePosition, it is moved back to its original Position as the deep equivalent. In the attached test case (which is representative of the relevant part of the DOM on ae.com), we try to find the previous VisiblePosition from (#c, 0). The previous visually distinct candidate we initially find is (#b, 0), since: 1. The enclosing renderer is a RenderBlock with a non-zero height. 2. The enclosing renderer has no rendered children. 3. The position is at the first editing position in the node (i.e. the span element). However, when canonicalizing the position, we find that neither the upstream nor the downstream position is a candidate because both the upstream and downstream nodes end up well outside of the span (the upstream node ends up being at the start of the body element, and the downstream position ends up right before the start of #c's container). The downstream position is at the end of a text node with a leading newline, it's not a candidate because its last caret offset is less than the length of the text node. As a result, even though the given position (#b, 0) is a candidate itself, its downstream and upstream positions are not. Thus, VisiblePosition::canonicalPosition expands the scope of its candidate positions to the next closest candidate positions; the next candidate position is (#c, 0). Both of these candidates are outside of the containing block, so we (somewhat arbitrarily) break the tie by choosing the next visible position, bringing us back to (#c, 0). There are several ways to fix this, one of which involves fixing the downstream/upstream positions of (#b, 0) so that they no longer jump out of the containing block of #b and cause (#b, 0) to be an invalid visible position despite being a candidate position. This can be achieved by adjusting the heuristic in endsOfNodeAreVisuallyDistinctPositions (used when moving upstream or downstream). Currently, this helper function returns false for #b because they contain a single (non-rendered) whitespace character. Removing this extraneous whitespace character actually causes the problem to stop reproducing, since #b and #c no longer contain any child nodes. This is important because the heuristic in Position::downstream attempts to keep the downstream position within the confines of the enclosing visual boundary, which (currently) ends up being the entire body element because endsOfNodeAreVisuallyDistinctPositions returns false for #b. To avoid this scenario, we teach endsOfNodeAreVisuallyDistinctPositions to treat inline-block containers that are empty (that is, contain no rendered content) but may have children for editing in the same way as inline- block containers that don't have any children; in both scenarios, they may contain a candidate position, so we should treat the ends of the container node as being visually distinct. Doing so causes the downstream position of (#b, 0) to be kept within the immediate containing span element, which then allows (#b, 0) to be a canonical VisiblePosition. Tests: fast/events/focus-anchor-with-tabindex-hang.html editing/selection/modify-backward-inline-block-containers.html * editing/VisiblePosition.cpp: (WebCore::VisiblePosition::previous const): LayoutTests: * editing/selection/modify-backward-inline-block-containers-expected.txt: Added. * editing/selection/modify-backward-inline-block-containers.html: Added. Add a layout test to ensure that the selection may be moved through empty inline-block containers that span the width of the page. * fast/events/focus-anchor-with-tabindex-hang-expected.txt: Added. * fast/events/focus-anchor-with-tabindex-hang.html: Added. Add a layout test to ensure that clicking an empty span under a focusable anchor element moves focus to the anchor element instead of hanging the web content process or hitting a debug assertion. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248909 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-20 Wenson Hsieh Clicking the search icon on ae.com hangs the web content process https://bugs.webkit.org/show_bug.cgi?id=200889 Reviewed by Ryosuke Niwa. The hang occurs under FrameSelection::selectionAtSentenceStart, while computing an EditorState to send to the UI process. This act of determining whether the given positon is at the start of sentence entails moving backwards from the start of the current visible selection until the start of a paragraph or sentence is found, using VisiblePosition::previous to iterate backwards through VisiblePositions. However, on this website, VisiblePosition::previous ends up just returning the current position, and we loop infinitely as a result because we never actually move backwards. This happens because VisiblePosition::previous first uses previousVisuallyDistinctCandidate to find a candidate Position before the current position, but when the position is canonicalized to create a VisiblePosition, it is moved back to its original Position as the deep equivalent. In the attached test case (which is representative of the relevant part of the DOM on ae.com), we try to find the previous VisiblePosition from (#c, 0). The previous visually distinct candidate we initially find is (#b, 0), since: 1. The enclosing renderer is a RenderBlock with a non-zero height. 2. The enclosing renderer has no rendered children. 3. The position is at the first editing position in the node (i.e. the span element). However, when canonicalizing the position, we find that neither the upstream nor the downstream position is a candidate because both the upstream and downstream nodes end up well outside of the span (the upstream node ends up being at the start of the body element, and the downstream position ends up right before the start of #c's container). The downstream position is at the end of a text node with a leading newline, it's not a candidate because its last caret offset is less than the length of the text node. As a result, even though the given position (#b, 0) is a candidate itself, its downstream and upstream positions are not. Thus, VisiblePosition::canonicalPosition expands the scope of its candidate positions to the next closest candidate positions; the next candidate position is (#c, 0). Both of these candidates are outside of the containing block, so we (somewhat arbitrarily) break the tie by choosing the next visible position, bringing us back to (#c, 0). There are several ways to fix this, one of which involves fixing the downstream/upstream positions of (#b, 0) so that they no longer jump out of the containing block of #b and cause (#b, 0) to be an invalid visible position despite being a candidate position. This can be achieved by adjusting the heuristic in endsOfNodeAreVisuallyDistinctPositions (used when moving upstream or downstream). Currently, this helper function returns false for #b because they contain a single (non-rendered) whitespace character. Removing this extraneous whitespace character actually causes the problem to stop reproducing, since #b and #c no longer contain any child nodes. This is important because the heuristic in Position::downstream attempts to keep the downstream position within the confines of the enclosing visual boundary, which (currently) ends up being the entire body element because endsOfNodeAreVisuallyDistinctPositions returns false for #b. To avoid this scenario, we teach endsOfNodeAreVisuallyDistinctPositions to treat inline-block containers that are empty (that is, contain no rendered content) but may have children for editing in the same way as inline- block containers that don't have any children; in both scenarios, they may contain a candidate position, so we should treat the ends of the container node as being visually distinct. Doing so causes the downstream position of (#b, 0) to be kept within the immediate containing span element, which then allows (#b, 0) to be a canonical VisiblePosition. Tests: fast/events/focus-anchor-with-tabindex-hang.html editing/selection/modify-backward-inline-block-containers.html * editing/VisiblePosition.cpp: (WebCore::VisiblePosition::previous 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. 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): 2019-08-18 Babak Shafiei Cherry-pick r248815. rdar://problem/54454993 [macOS] Emoji with variation selectors are rendered in text style, not emoji style https://bugs.webkit.org/show_bug.cgi?id=200830 Reviewed by Simon Fraser. Source/WebCore: When mapping characters to glyphs, Core Text is giving us the deleted glyph ID, which is unexpected. We were treating it as a valid glyph ID, but it rather should be treated as an invalid glyph ID. Test: fast/text/emoji-variation-selector.html * platform/graphics/mac/GlyphPageMac.cpp: (WebCore::GlyphPage::fill): LayoutTests: * fast/text/emoji-variation-selector-expected-mismatch.html: Added. * fast/text/emoji-variation-selector.html: Added. * platform/win/TestExpectations: Mark as failing on Windows, because it doesn't support variation selectors. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248815 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-16 Myles C. Maxfield [macOS] Emoji with variation selectors are rendered in text style, not emoji style https://bugs.webkit.org/show_bug.cgi?id=200830 Reviewed by Simon Fraser. When mapping characters to glyphs, Core Text is giving us the deleted glyph ID, which is unexpected. We were treating it as a valid glyph ID, but it rather should be treated as an invalid glyph ID. Test: fast/text/emoji-variation-selector.html * platform/graphics/mac/GlyphPageMac.cpp: (WebCore::GlyphPage::fill): 2019-08-18 Babak Shafiei Cherry-pick r248747. rdar://problem/54365278 [Cocoa] Adopt -preventDisplaySleepForVideoPlayback https://bugs.webkit.org/show_bug.cgi?id=200774 Reviewed by Eric Carlson. * platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm: (WebCore::MediaPlayerPrivateMediaSourceAVFObjC::ensureLayer): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248747 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-15 Jer Noble [Cocoa] Adopt -preventDisplaySleepForVideoPlayback https://bugs.webkit.org/show_bug.cgi?id=200774 Reviewed by Eric Carlson. * platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm: (WebCore::MediaPlayerPrivateMediaSourceAVFObjC::ensureLayer): 2019-08-18 Babak Shafiei Cherry-pick r248028. rdar://problem/54454990 ASSERTion failure under takeSnapshot after r247846 * page/TextIndicator.cpp: (WebCore::takeSnapshots): We now sometimes inflate the scale factor; allow this. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248028 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-30 Tim Horton ASSERTion failure under takeSnapshot after r247846 * page/TextIndicator.cpp: (WebCore::takeSnapshots): We now sometimes inflate the scale factor; allow this. 2019-08-15 Alan Coon Cherry-pick r248722. rdar://problem/54360866 Negative size box with border radius causes hang under WebCore::approximateAsRegion https://bugs.webkit.org/show_bug.cgi?id=200769 Reviewed by Alex Christensen. Source/WebCore: If a box's width or height computes negative the rounded border rect will also be negative. This caused near-infinite loop during rounded border region approximation. Test: fast/css/border-radius-negative-size.html * platform/graphics/RoundedRect.cpp: (WebCore::approximateAsRegion): Bail out if the region is empty (which includes negative sizes). For safety also limit the number of rectangles we generate for corner arc approximation. LayoutTests: * fast/css/border-radius-negative-size-expected.txt: Added. * fast/css/border-radius-negative-size.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248722 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-15 Antti Koivisto Negative size box with border radius causes hang under WebCore::approximateAsRegion https://bugs.webkit.org/show_bug.cgi?id=200769 Reviewed by Alex Christensen. If a box's width or height computes negative the rounded border rect will also be negative. This caused near-infinite loop during rounded border region approximation. Test: fast/css/border-radius-negative-size.html * platform/graphics/RoundedRect.cpp: (WebCore::approximateAsRegion): Bail out if the region is empty (which includes negative sizes). For safety also limit the number of rectangles we generate for corner arc approximation. 2019-08-15 Alan Coon Cherry-pick r248648. rdar://problem/54333931 Focus rings are black https://bugs.webkit.org/show_bug.cgi?id=200593 Patch by Daniel Bates on 2019-08-13 Reviewed by Wenson Hsieh. Work around and make focus rings a pretty blue. * rendering/RenderThemeIOS.mm: (WebCore::RenderThemeIOS::platformFocusRingColor const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248648 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-13 Daniel Bates Focus rings are black https://bugs.webkit.org/show_bug.cgi?id=200593 Reviewed by Wenson Hsieh. Work around and make focus rings a pretty blue. * rendering/RenderThemeIOS.mm: (WebCore::RenderThemeIOS::platformFocusRingColor const): 2019-08-13 Alan Coon Cherry-pick r248604. rdar://problem/54282801 Source/WebCore: Event region collection should take clipping into account https://bugs.webkit.org/show_bug.cgi?id=200668 Reviewed by Simon Fraser. Test: pointerevents/ios/touch-action-region-clip-and-transform.html * rendering/EventRegion.cpp: (WebCore::EventRegionContext::pushClip): (WebCore::EventRegionContext::popClip): Maintain clip rect stack. (WebCore::EventRegionContext::unite): Apply both transforms and clipping. * rendering/EventRegion.h: * rendering/RenderBlock.cpp: * rendering/RenderBox.cpp: (WebCore::RenderBox::pushContentsClip): (WebCore::RenderBox::popContentsClip): Update clip for non-self-painting layers. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::clipToRect): (WebCore::RenderLayer::restoreClip): Update clip for self-painting layers. LayoutTests: Event regions collection should take clipping into account https://bugs.webkit.org/show_bug.cgi?id=200668 Reviewed by Simon Fraser. * pointerevents/ios/touch-action-region-clip-and-transform-expected.txt: Added. * pointerevents/ios/touch-action-region-clip-and-transform.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248604 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-13 Antti Koivisto Event region collection should take clipping into account https://bugs.webkit.org/show_bug.cgi?id=200668 Reviewed by Simon Fraser. Test: pointerevents/ios/touch-action-region-clip-and-transform.html * rendering/EventRegion.cpp: (WebCore::EventRegionContext::pushClip): (WebCore::EventRegionContext::popClip): Maintain clip rect stack. (WebCore::EventRegionContext::unite): Apply both transforms and clipping. * rendering/EventRegion.h: * rendering/RenderBlock.cpp: * rendering/RenderBox.cpp: (WebCore::RenderBox::pushContentsClip): (WebCore::RenderBox::popContentsClip): Update clip for non-self-painting layers. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::clipToRect): (WebCore::RenderLayer::restoreClip): Update clip for self-painting layers. 2019-08-13 Alan Coon Cherry-pick r248597. rdar://problem/54282817 Make sure UniqueIDBDatabaseConnection unregister itself from IDBServer https://bugs.webkit.org/show_bug.cgi?id=200650 Reviewed by Youenn Fablet. We register UniqueIDBDatabaseConnection unconditionally to IDBServer but fail to unregister if UniqueIDBDatabase of UniqueIDBDatabaseConnection is gone. * Modules/indexeddb/server/UniqueIDBDatabaseConnection.cpp: (WebCore::IDBServer::UniqueIDBDatabaseConnection::UniqueIDBDatabaseConnection): (WebCore::IDBServer::UniqueIDBDatabaseConnection::~UniqueIDBDatabaseConnection): * Modules/indexeddb/server/UniqueIDBDatabaseConnection.h: (WebCore::IDBServer::UniqueIDBDatabaseConnection::server): * Modules/indexeddb/server/UniqueIDBDatabaseTransaction.cpp: (WebCore::IDBServer::UniqueIDBDatabaseTransaction::UniqueIDBDatabaseTransaction): (WebCore::IDBServer::UniqueIDBDatabaseTransaction::~UniqueIDBDatabaseTransaction): * Modules/indexeddb/server/UniqueIDBDatabaseTransaction.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248597 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-13 Sihui Liu Make sure UniqueIDBDatabaseConnection unregister itself from IDBServer https://bugs.webkit.org/show_bug.cgi?id=200650 Reviewed by Youenn Fablet. We register UniqueIDBDatabaseConnection unconditionally to IDBServer but fail to unregister if UniqueIDBDatabase of UniqueIDBDatabaseConnection is gone. * Modules/indexeddb/server/UniqueIDBDatabaseConnection.cpp: (WebCore::IDBServer::UniqueIDBDatabaseConnection::UniqueIDBDatabaseConnection): (WebCore::IDBServer::UniqueIDBDatabaseConnection::~UniqueIDBDatabaseConnection): * Modules/indexeddb/server/UniqueIDBDatabaseConnection.h: (WebCore::IDBServer::UniqueIDBDatabaseConnection::server): * Modules/indexeddb/server/UniqueIDBDatabaseTransaction.cpp: (WebCore::IDBServer::UniqueIDBDatabaseTransaction::UniqueIDBDatabaseTransaction): (WebCore::IDBServer::UniqueIDBDatabaseTransaction::~UniqueIDBDatabaseTransaction): * Modules/indexeddb/server/UniqueIDBDatabaseTransaction.h: 2019-08-13 Alan Coon Cherry-pick r248499. rdar://problem/54237800 Can’t sort videos on a YouTube channel page on iPad https://bugs.webkit.org/show_bug.cgi?id=200573 Reviewed by Darin Adler. Add a quirk to make touch events non-cancelable (preventDefault() does nothing). * page/Quirks.cpp: (WebCore::Quirks::shouldMakeTouchEventNonCancelableForTarget const): * page/Quirks.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248499 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-10 Antti Koivisto Can’t sort videos on a YouTube channel page on iPad https://bugs.webkit.org/show_bug.cgi?id=200573 Reviewed by Darin Adler. Add a quirk to make touch events non-cancelable (preventDefault() does nothing). * page/Quirks.cpp: (WebCore::Quirks::shouldMakeTouchEventNonCancelableForTarget const): * page/Quirks.h: 2019-08-13 Alan Coon Cherry-pick r248513. rdar://problem/54237806 Accessibility client cannot navigate to internal links targets on iOS. https://bugs.webkit.org/show_bug.cgi?id=200559 Patch by Andres Gonzalez on 2019-08-10 Reviewed by Zalan Bujtas. Source/WebCore: The cause of the problem on iOS is that AccessibilityObject::firstAccessibleObjectFromNode used in AccessibilityRenderObject::linkedUIElements may return an object that is ignored by accessibility clients on iOS, and thus the client would not track the target of an internal link. This change ensures that accessibilityLinkedElement will return a valid accessibility element to the client, if it is exists. * accessibility/AccessibilityObject.cpp: (WebCore::AccessibilityObject::firstAccessibleObjectFromNode): (WebCore::firstAccessibleObjectFromNode): * accessibility/AccessibilityObject.h: * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper accessibilityLinkedElement]): LayoutTests: Extneded this test to not only check that internal links expose their target, but also that the target is an accessible element. Added a second test case where the target is contained in a grouping element. * accessibility/ios-simulator/internal-link-expected.txt: * accessibility/ios-simulator/internal-link.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248513 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-10 Andres Gonzalez Accessibility client cannot navigate to internal links targets on iOS. https://bugs.webkit.org/show_bug.cgi?id=200559 Reviewed by Zalan Bujtas. The cause of the problem on iOS is that AccessibilityObject::firstAccessibleObjectFromNode used in AccessibilityRenderObject::linkedUIElements may return an object that is ignored by accessibility clients on iOS, and thus the client would not track the target of an internal link. This change ensures that accessibilityLinkedElement will return a valid accessibility element to the client, if it is exists. * accessibility/AccessibilityObject.cpp: (WebCore::AccessibilityObject::firstAccessibleObjectFromNode): (WebCore::firstAccessibleObjectFromNode): * accessibility/AccessibilityObject.h: * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper accessibilityLinkedElement]): 2019-08-13 Alan Coon Cherry-pick r248514. rdar://problem/54236213 REGRESSION (r245974): Missing content on habitburger.com, amazon.com https://bugs.webkit.org/show_bug.cgi?id=200618 rdar://problem/53920224 Reviewed by Zalan Bujtas. Source/WebCore: In r245974 TileController::adjustTileCoverageRect() started to intersect the coverage rect with the bounds of the layer, which is wrong because this coverage rect is passed down to descendant layers, and they may project outside the bounds of this tiled layer. This caused missing dropdowns on amazon.com, and a missing menu on habitburger.com on iPhone. The fix is to just not do the intersection with the bounds. TileGrid::getTileIndexRangeForRect() already ensures that we never make tiles outside the bounds of a TileController. Test: compositing/backing/layer-outside-tiled-parent.html * platform/graphics/ca/TileController.cpp: (WebCore::TileController::adjustTileCoverageRect): * platform/graphics/ca/TileGrid.cpp: (WebCore::TileGrid::ensureTilesForRect): LayoutTests: * compositing/backing/layer-outside-tiled-parent-expected.txt: Added. * compositing/backing/layer-outside-tiled-parent.html: Added. * platform/ios-wk2/compositing/backing/layer-outside-tiled-parent-expected.txt: Added. * tiled-drawing/tile-coverage-iframe-to-zero-coverage-expected.txt: * tiled-drawing/tiled-backing-in-window-expected.txt: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248514 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-10 Simon Fraser REGRESSION (r245974): Missing content on habitburger.com, amazon.com https://bugs.webkit.org/show_bug.cgi?id=200618 rdar://problem/53920224 Reviewed by Zalan Bujtas. In r245974 TileController::adjustTileCoverageRect() started to intersect the coverage rect with the bounds of the layer, which is wrong because this coverage rect is passed down to descendant layers, and they may project outside the bounds of this tiled layer. This caused missing dropdowns on amazon.com, and a missing menu on habitburger.com on iPhone. The fix is to just not do the intersection with the bounds. TileGrid::getTileIndexRangeForRect() already ensures that we never make tiles outside the bounds of a TileController. Test: compositing/backing/layer-outside-tiled-parent.html * platform/graphics/ca/TileController.cpp: (WebCore::TileController::adjustTileCoverageRect): * platform/graphics/ca/TileGrid.cpp: (WebCore::TileGrid::ensureTilesForRect): 2019-08-13 Alan Coon Cherry-pick r248301. rdar://problem/54237793 Adopt -expectMinimumUpcomingSampleBufferPresentationTime: https://bugs.webkit.org/show_bug.cgi?id=200457 Reviewed by Eric Carlson. Source/WebCore: Test: media/media-source/media-source-minimumupcomingpresentationtime.html Adopt a new API vended by AVSampleBufferDisplayLayer, piped from SourceBuffer down through SourceBufferPrivate to SourceBufferPrivateAVFObjC. This value should be reset and updated when new samples are appended. * Modules/mediasource/SourceBuffer.cpp: (WebCore::SourceBuffer::sourceBufferPrivateDidReceiveSample): (WebCore::SourceBuffer::provideMediaData): (WebCore::SourceBuffer::updateMinimumUpcomingPresentationTime): (WebCore::SourceBuffer::resetMinimumUpcomingPresentationTime): (WebCore::SourceBuffer::minimumUpcomingPresentationTimeForTrackID): (WebCore::SourceBuffer::setMaximumQueueDepthForTrackID): * Modules/mediasource/SourceBuffer.h: * platform/graphics/SourceBufferPrivate.h: (WebCore::SourceBufferPrivate::canSetMinimumUpcomingPresentationTime const): (WebCore::SourceBufferPrivate::setMinimumUpcomingPresentationTime): (WebCore::SourceBufferPrivate::clearMinimumUpcomingPresentationTime): (WebCore::SourceBufferPrivate::enqueuedSamplesForTrackID): (WebCore::SourceBufferPrivate::minimumUpcomingPresentationTimeForTrackID): (WebCore::SourceBufferPrivate::setMaximumQueueDepthForTrackID): * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.h: * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm: (WebCore::SourceBufferPrivateAVFObjC::canSetMinimumUpcomingPresentationTime const): (WebCore::SourceBufferPrivateAVFObjC::setMinimumUpcomingPresentationTime): (WebCore::SourceBufferPrivateAVFObjC::clearMinimumUpcomingPresentationTime): * platform/mock/mediasource/MockSourceBufferPrivate.cpp: (WebCore::MockSourceBufferPrivate::minimumUpcomingPresentationTimeForTrackID): (WebCore::MockSourceBufferPrivate::setMaximumQueueDepthForTrackID): (WebCore::MockSourceBufferPrivate::canSetMinimumUpcomingPresentationTime const): (WebCore::MockSourceBufferPrivate::setMinimumUpcomingPresentationTime): (WebCore::MockSourceBufferPrivate::clearMinimumUpcomingPresentationTime): * platform/mock/mediasource/MockSourceBufferPrivate.h: * testing/Internals.cpp: (WebCore::Internals::minimumUpcomingPresentationTimeForTrackID): (WebCore::Internals::setMaximumQueueDepthForTrackID): * testing/Internals.h: * testing/Internals.idl: LayoutTests: * media/media-source/media-source-minimumupcomingpresentationtime-expected.txt: Added. * media/media-source/media-source-minimumupcomingpresentationtime.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248301 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-06 Jer Noble Adopt -expectMinimumUpcomingSampleBufferPresentationTime: https://bugs.webkit.org/show_bug.cgi?id=200457 Reviewed by Eric Carlson. Test: media/media-source/media-source-minimumupcomingpresentationtime.html Adopt a new API vended by AVSampleBufferDisplayLayer, piped from SourceBuffer down through SourceBufferPrivate to SourceBufferPrivateAVFObjC. This value should be reset and updated when new samples are appended. * Modules/mediasource/SourceBuffer.cpp: (WebCore::SourceBuffer::sourceBufferPrivateDidReceiveSample): (WebCore::SourceBuffer::provideMediaData): (WebCore::SourceBuffer::updateMinimumUpcomingPresentationTime): (WebCore::SourceBuffer::resetMinimumUpcomingPresentationTime): (WebCore::SourceBuffer::minimumUpcomingPresentationTimeForTrackID): (WebCore::SourceBuffer::setMaximumQueueDepthForTrackID): * Modules/mediasource/SourceBuffer.h: * platform/graphics/SourceBufferPrivate.h: (WebCore::SourceBufferPrivate::canSetMinimumUpcomingPresentationTime const): (WebCore::SourceBufferPrivate::setMinimumUpcomingPresentationTime): (WebCore::SourceBufferPrivate::clearMinimumUpcomingPresentationTime): (WebCore::SourceBufferPrivate::enqueuedSamplesForTrackID): (WebCore::SourceBufferPrivate::minimumUpcomingPresentationTimeForTrackID): (WebCore::SourceBufferPrivate::setMaximumQueueDepthForTrackID): * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.h: * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm: (WebCore::SourceBufferPrivateAVFObjC::canSetMinimumUpcomingPresentationTime const): (WebCore::SourceBufferPrivateAVFObjC::setMinimumUpcomingPresentationTime): (WebCore::SourceBufferPrivateAVFObjC::clearMinimumUpcomingPresentationTime): * platform/mock/mediasource/MockSourceBufferPrivate.cpp: (WebCore::MockSourceBufferPrivate::minimumUpcomingPresentationTimeForTrackID): (WebCore::MockSourceBufferPrivate::setMaximumQueueDepthForTrackID): (WebCore::MockSourceBufferPrivate::canSetMinimumUpcomingPresentationTime const): (WebCore::MockSourceBufferPrivate::setMinimumUpcomingPresentationTime): (WebCore::MockSourceBufferPrivate::clearMinimumUpcomingPresentationTime): * platform/mock/mediasource/MockSourceBufferPrivate.h: * testing/Internals.cpp: (WebCore::Internals::minimumUpcomingPresentationTimeForTrackID): (WebCore::Internals::setMaximumQueueDepthForTrackID): * testing/Internals.h: * testing/Internals.idl: 2019-08-13 Alan Coon Cherry-pick r248295. rdar://problem/54237762 REGRESSION: Cannot tap on any buttons on m.naver.com home screen on iPad https://bugs.webkit.org/show_bug.cgi?id=200466 Reviewed by Zalan Bujtas. The page calls preventDefault() for a mouse event generated by a site specific quirk. * page/Quirks.cpp: (WebCore::Quirks::shouldDispatchSimulatedMouseEvents const): Disable the quirk for the "m." subdomain. This is a mobile site that don't need or expect them. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248295 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-06 Antti Koivisto REGRESSION: Cannot tap on any buttons on m.naver.com home screen on iPad https://bugs.webkit.org/show_bug.cgi?id=200466 Reviewed by Zalan Bujtas. The page calls preventDefault() for a mouse event generated by a site specific quirk. * page/Quirks.cpp: (WebCore::Quirks::shouldDispatchSimulatedMouseEvents const): Disable the quirk for the "m." subdomain. This is a mobile site that don't need or expect them. 2019-08-13 Alan Coon Cherry-pick r248292. rdar://problem/54236220 [iPadOS] Unable to increase zoom level on Google using the Aa menu https://bugs.webkit.org/show_bug.cgi?id=200453 Reviewed by Tim Horton. Source/WebCore: Makes a couple of minor adjustments to how layout size scale factor is handled in ViewportConfiguration, to address some scenarios in which adjusting WKWebView's _viewScale does not have any apparent effect on the page. See changes below for more detail. Tests: fast/viewport/ios/non-responsive-viewport-after-changing-view-scale.html fast/viewport/ios/responsive-viewport-with-minimum-width-after-changing-view-scale.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::initialScaleFromSize const): When the page is either zoomed in or zoomed out using _viewScale, let the specified initial scale take precedence over the scale computed by fitting the content width to the view width, or the scale computed by fitting the content height to the view height. This avoids a scenario in which nothing happens when increasing view scale in a responsively designed web page that has a fixed minimum width. Before this change, when computing the initial scale at a view scale that would not allow the entire content width of the page to fit within the viewport, the new initial scale would remain unchanged if the initial scale in the meta viewport is not also set to 1, because a new initial scale would be computed in ViewportConfiguration::initialScaleFromSize to accomodate for the entire content width. Our new behavior allows us to zoom into the page, even if doing so would cause horizontal scrolling. (WebCore::ViewportConfiguration::updateConfiguration): When the page is either zoomed in or zoomed out using _viewScale and the default viewport configuration has a fixed width (e.g. on iPhone), then adjust the width of the default viewport configuration to account for the _viewScale. For example, the default width of a viewport-less web page is 980px on iPhone; at a view scale of 2, this would become 490px instead, and at 0.5 view scale, it would become 1960px. This ensures that on iPhone, for web pages without a meta viewport, changing the view scale still changes the layout and initial scale of the web page. * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::layoutSizeIsExplicitlyScaled const): LayoutTests: Adds a couple of layout tests (with device-specific expectations) to verify that the two scenarios targeted by this change are fixed. * fast/viewport/ios/non-responsive-viewport-after-changing-view-scale-expected.txt: Added. * fast/viewport/ios/non-responsive-viewport-after-changing-view-scale.html: Added. Verifies that, for a page with no viewport meta tag (where we fall back to a fixed 980px viewport on iPhone), changing view scale still changes page scale and window size. * fast/viewport/ios/responsive-viewport-with-minimum-width-after-changing-view-scale-expected.txt: Added. * fast/viewport/ios/responsive-viewport-with-minimum-width-after-changing-view-scale.html: Added. Verifies that, for a page with a responsive meta viewport tag containing a fixed-width element that forces a minimum width for the page, setting the view scale such that the page scrolls horizontally (2.5) doesn't result in the initial scale being adjusted back to the maximum scale that would accomodate the full contents of the page (2). * platform/ipad/fast/viewport/ios/non-responsive-viewport-after-changing-view-scale-expected.txt: Added. * platform/ipad/fast/viewport/ios/responsive-viewport-with-minimum-width-after-changing-view-scale-expected.txt: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248292 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-06 Wenson Hsieh [iPadOS] Unable to increase zoom level on Google using the Aa menu https://bugs.webkit.org/show_bug.cgi?id=200453 Reviewed by Tim Horton. Makes a couple of minor adjustments to how layout size scale factor is handled in ViewportConfiguration, to address some scenarios in which adjusting WKWebView's _viewScale does not have any apparent effect on the page. See changes below for more detail. Tests: fast/viewport/ios/non-responsive-viewport-after-changing-view-scale.html fast/viewport/ios/responsive-viewport-with-minimum-width-after-changing-view-scale.html * page/ViewportConfiguration.cpp: (WebCore::ViewportConfiguration::initialScaleFromSize const): When the page is either zoomed in or zoomed out using _viewScale, let the specified initial scale take precedence over the scale computed by fitting the content width to the view width, or the scale computed by fitting the content height to the view height. This avoids a scenario in which nothing happens when increasing view scale in a responsively designed web page that has a fixed minimum width. Before this change, when computing the initial scale at a view scale that would not allow the entire content width of the page to fit within the viewport, the new initial scale would remain unchanged if the initial scale in the meta viewport is not also set to 1, because a new initial scale would be computed in ViewportConfiguration::initialScaleFromSize to accomodate for the entire content width. Our new behavior allows us to zoom into the page, even if doing so would cause horizontal scrolling. (WebCore::ViewportConfiguration::updateConfiguration): When the page is either zoomed in or zoomed out using _viewScale and the default viewport configuration has a fixed width (e.g. on iPhone), then adjust the width of the default viewport configuration to account for the _viewScale. For example, the default width of a viewport-less web page is 980px on iPhone; at a view scale of 2, this would become 490px instead, and at 0.5 view scale, it would become 1960px. This ensures that on iPhone, for web pages without a meta viewport, changing the view scale still changes the layout and initial scale of the web page. * page/ViewportConfiguration.h: (WebCore::ViewportConfiguration::layoutSizeIsExplicitlyScaled const): 2019-08-13 Alan Coon Cherry-pick r248188. rdar://problem/54237663 Add accessibility object method to determine whether an element is inside a table cell. Needed for iOS accessibility client. https://bugs.webkit.org/show_bug.cgi?id=200394 Patch by Andres Gonzalez on 2019-08-02 Reviewed by Chris Fleizach. Explicitly returning BOOL to avoid error in some compiler configurations. * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper _accessibilityIsInTableCell]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248188 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-02 Andres Gonzalez Add accessibility object method to determine whether an element is inside a table cell. Needed for iOS accessibility client. https://bugs.webkit.org/show_bug.cgi?id=200394 Reviewed by Chris Fleizach. Explicitly returning BOOL to avoid error in some compiler configurations. * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper _accessibilityIsInTableCell]): 2019-08-13 Alan Coon Cherry-pick r248169. rdar://problem/54237663 Add accessibility object method to determine whether an element is inside a table cell. Needed for iOS accessibility client. https://bugs.webkit.org/show_bug.cgi?id=200394 Patch by Andres Gonzalez on 2019-08-02 Reviewed by Chris Fleizach. Source/WebCore: Test: accessibility/ios-simulator/element-in-table-cell.html Added _accessibilityIsInTableCell needed for iOS accessibility client. * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper _accessibilityIsInTableCell]): Tools: Glue code to exercise new method [WebAccessibilityObjectWrapper _accessibilityIsInTableCell]. * WebKitTestRunner/InjectedBundle/AccessibilityUIElement.cpp: (WTR::AccessibilityUIElement::isInTableCell const): * WebKitTestRunner/InjectedBundle/AccessibilityUIElement.h: * WebKitTestRunner/InjectedBundle/Bindings/AccessibilityUIElement.idl: * WebKitTestRunner/InjectedBundle/ios/AccessibilityUIElementIOS.mm: (WTR::AccessibilityUIElement::isInTableCell const): LayoutTests: New test that exercises [WebAccessibilityObjectWrapper _accessibilityIsInTableCell]. * accessibility/ios-simulator/element-in-table-cell-expected.txt: Added. * accessibility/ios-simulator/element-in-table-cell.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248169 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-02 Andres Gonzalez Add accessibility object method to determine whether an element is inside a table cell. Needed for iOS accessibility client. https://bugs.webkit.org/show_bug.cgi?id=200394 Reviewed by Chris Fleizach. Test: accessibility/ios-simulator/element-in-table-cell.html Added _accessibilityIsInTableCell needed for iOS accessibility client. * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper _accessibilityIsInTableCell]): 2019-08-12 Alan Coon 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 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 Disable ContentChangeObserver TouchEvent adjustment on youtube.com on iOS in mobile browsing mode https://bugs.webkit.org/show_bug.cgi?id=200609 Reviewed by Maciej Stachowiak. 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): 2019-08-12 Alan Coon 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 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 [iOS] Add a quirk for gmail.com messages on iPhone iOS13 https://bugs.webkit.org/show_bug.cgi?id=200605 Reviewed by Maciej Stachowiak. 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): 2019-08-12 Alan Coon Cherry-pick r248494. rdar://problem/54171876 Universal XSS in JSObject::putInlineSlow and JSValue::putToPrimitive https://bugs.webkit.org/show_bug.cgi?id=199864 Reviewed by Saam Barati. Source/JavaScriptCore: Our JSObject::put implementation is not correct in term of the spec. Our [[Put]] implementation is something like this. JSObject::put(object): if (can-do-fast-path(object)) return fast-path(object); // slow-path do { object-put-check-and-setter-calls(object); // (1) object = object->prototype; } while (is-object(object)); return do-put(object); Since JSObject::put is registered in the methodTable, the derived classes can override it. Some of classes are adding extra checks to this put. Derived::put(object): if (do-extra-check(object)) fail return JSObject::put(object) The problem is that Derived::put is only called when the |this| object is the Derived class. When traversing [[Prototype]] in JSObject::put, at (1), we do not perform the extra checks added in Derived::put even if `object` is Derived one. This means that we skip the check. Currently, JSObject::put and WebCore checking mechanism are broken. JSObject::put should call getOwnPropertySlot at (1) to perform the additional checks. This behavior is matching against the spec. However, currently, our JSObject::getOwnPropertySlot does not propagate setter information. This is required to cache cacheable [[Put]] at (1) for CustomValue, CustomAccessor, and Accessors. We also need to reconsider how to integrate static property setters to this mechanism. So, basically, this involves large refactoring to renew our JSObject::put and JSObject::getOwnPropertySlot. To work-around for now, we add a new TypeInfo flag, HasPutPropertySecurityCheck . And adding this flag to DOM objects that implements the addition checks. We also add doPutPropertySecurityCheck method hook to perform the check in JSObject. When we found this flag at (1), we perform doPutPropertySecurityCheck to properly perform the checks. Since our JSObject::put code is old and it does not match against the spec now, we should refactor it largely. This is tracked separately in [1]. [1]: https://bugs.webkit.org/show_bug.cgi?id=200562 * runtime/ClassInfo.h: * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitive): * runtime/JSCell.cpp: (JSC::JSCell::doPutPropertySecurityCheck): * runtime/JSCell.h: * runtime/JSObject.cpp: (JSC::JSObject::putInlineSlow): (JSC::JSObject::getOwnPropertyDescriptor): * runtime/JSObject.h: (JSC::JSObject::doPutPropertySecurityCheck): * runtime/JSTypeInfo.h: (JSC::TypeInfo::hasPutPropertySecurityCheck const): Source/WebCore: Test: http/tests/security/cross-frame-access-object-put-optimization.html * bindings/js/JSDOMWindowCustom.cpp: (WebCore::JSDOMWindow::doPutPropertySecurityCheck): * bindings/js/JSLocationCustom.cpp: (WebCore::JSLocation::doPutPropertySecurityCheck): * bindings/scripts/CodeGeneratorJS.pm: (GenerateHeader): * bindings/scripts/test/JS/JSTestActiveDOMObject.h: LayoutTests: * http/tests/security/cross-frame-access-object-put-optimization-expected.txt: Added. * http/tests/security/cross-frame-access-object-put-optimization.html: Added. * http/tests/security/resources/cross-frame-iframe-for-object-put-optimization-test.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248494 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-09 Yusuke Suzuki Universal XSS in JSObject::putInlineSlow and JSValue::putToPrimitive https://bugs.webkit.org/show_bug.cgi?id=199864 Reviewed by Saam Barati. Test: http/tests/security/cross-frame-access-object-put-optimization.html * bindings/js/JSDOMWindowCustom.cpp: (WebCore::JSDOMWindow::doPutPropertySecurityCheck): * bindings/js/JSLocationCustom.cpp: (WebCore::JSLocation::doPutPropertySecurityCheck): * bindings/scripts/CodeGeneratorJS.pm: (GenerateHeader): * bindings/scripts/test/JS/JSTestActiveDOMObject.h: 2019-08-12 Alan Coon Cherry-pick r248491. rdar://problem/54130636 Don't allow cross-origin iframes to autofocus https://bugs.webkit.org/show_bug.cgi?id=200515 Reviewed by Ryosuke Niwa. Source/WebCore: According to Step 6 in the WhatWG Spec (https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofocusing-a-form-control:-the-autofocus-attribute), the 'autofocus' attribute shouldn't work for cross-origin iframes. This change is based on the Blink change (patch by ): Also disallow cross-origin iframes from focusing programmatically without ever having had any user interaction. * dom/Element.cpp: Check if an invalid frame is trying to grab the focus. (WebCore::Element::focus): * html/HTMLFormControlElement.cpp: Check if the focus is moving to an invalid frame. (WebCore::shouldAutofocus): * page/DOMWindow.cpp: Check if an invalid frame is trying to grab the focus. (WebCore::DOMWindow::focus): Tools: Make WebKit.FocusedFrameAfterCrash use same-origin iframes instead of cross-origin iframes, since it depends on focusing one of the frames. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKit/ReloadPageAfterCrash.cpp: (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/WebKit/many-same-origin-iframes.html: Added. LayoutTests: Add test coverage, and simulate user interaction in existing tests that require focusing a cross-origin frame. * http/tests/security/clipboard/resources/copy-html.html: * http/tests/security/clipboard/resources/copy-mso-list.html: * http/tests/security/clipboard/resources/copy-url.html: * http/wpt/html/interaction/focus/no-cross-origin-element-focus-expected.txt: Added. * http/wpt/html/interaction/focus/no-cross-origin-element-focus.html: Added. * http/wpt/html/interaction/focus/no-cross-origin-window-focus-expected.txt: Added. * http/wpt/html/interaction/focus/no-cross-origin-window-focus.html: Added. * http/wpt/html/interaction/focus/resources/child-focus-element.html: Added. * http/wpt/html/interaction/focus/resources/child-focus-window.html: Added. * http/wpt/html/semantics/forms/autofocus/no-cross-origin-autofocus.sub-expected.txt: Added. * http/wpt/html/semantics/forms/autofocus/no-cross-origin-autofocus.sub.html: Added. * http/wpt/html/semantics/forms/autofocus/resources/child-autofocus.html: Added. * http/wpt/webauthn/resources/last-layer-frame.https.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248491 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-09 Ali Juma Don't allow cross-origin iframes to autofocus https://bugs.webkit.org/show_bug.cgi?id=200515 Reviewed by Ryosuke Niwa. According to Step 6 in the WhatWG Spec (https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofocusing-a-form-control:-the-autofocus-attribute), the 'autofocus' attribute shouldn't work for cross-origin iframes. This change is based on the Blink change (patch by ): Also disallow cross-origin iframes from focusing programmatically without ever having had any user interaction. * dom/Element.cpp: Check if an invalid frame is trying to grab the focus. (WebCore::Element::focus): * html/HTMLFormControlElement.cpp: Check if the focus is moving to an invalid frame. (WebCore::shouldAutofocus): * page/DOMWindow.cpp: Check if an invalid frame is trying to grab the focus. (WebCore::DOMWindow::focus): 2019-08-12 Alan Coon Cherry-pick r248471. rdar://problem/54130624 Disable CSSOM View Scrolling API for IMDb iOS app https://bugs.webkit.org/show_bug.cgi?id=200586 Patch by Alex Christensen 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 Disable CSSOM View Scrolling API for IMDb iOS app https://bugs.webkit.org/show_bug.cgi?id=200586 Reviewed by Simon Fraser. 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): 2019-08-12 Alan Coon Cherry-pick r248463. rdar://problem/54139782 REGRESSION (iOS 13): united.com web forms do not respond to taps https://bugs.webkit.org/show_bug.cgi?id=200531 Reviewed by Antti Koivisto and Wenson Hsieh. The bug is caused by the content change observer detecting “Site Feedback” link at the bottom of the page (https://www.united.com/ual/en/US/account/enroll/default) constantly getting re-generated in every frame via requestAnimationFrame when the page is opened with iPhone UA string. Note that the content re-generation can be reproduced even in Chrome if iPhone UA string is used. Ignore this constant content change in ContentChangeObserver as a site specific quirk. In the future, we should make ContentChangeObserver observe the final location of each element being observed so that we can ignore content that like this which is placed outside the viewport, and/or far away from where the user tapped. * page/Quirks.cpp: (WebCore::Quirks::shouldIgnoreContentChange const): Added. * page/Quirks.h: * page/ios/ContentChangeObserver.cpp: (WebCore::ContentChangeObserver::shouldObserveVisibilityChangeForElement): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248463 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-09 Ryosuke Niwa REGRESSION (iOS 13): united.com web forms do not respond to taps https://bugs.webkit.org/show_bug.cgi?id=200531 Reviewed by Antti Koivisto and Wenson Hsieh. The bug is caused by the content change observer detecting “Site Feedback” link at the bottom of the page (https://www.united.com/ual/en/US/account/enroll/default) constantly getting re-generated in every frame via requestAnimationFrame when the page is opened with iPhone UA string. Note that the content re-generation can be reproduced even in Chrome if iPhone UA string is used. Ignore this constant content change in ContentChangeObserver as a site specific quirk. In the future, we should make ContentChangeObserver observe the final location of each element being observed so that we can ignore content that like this which is placed outside the viewport, and/or far away from where the user tapped. * page/Quirks.cpp: (WebCore::Quirks::shouldIgnoreContentChange const): Added. * page/Quirks.h: * page/ios/ContentChangeObserver.cpp: (WebCore::ContentChangeObserver::shouldObserveVisibilityChangeForElement): 2019-08-12 Alan Coon 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 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 [iOS] Position image information should respect the image orientation https://bugs.webkit.org/show_bug.cgi?id=200487 Reviewed by Simon Fraser. 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: 2019-08-12 Alan Coon Cherry-pick r248410. rdar://problem/54084721 Do not allow navigations of frames about to get replaced by the result of evaluating javascript: URLs and https://bugs.webkit.org/show_bug.cgi?id=198786 Reviewed by Geoff Garen. Source/WebCore: Covered by API Test Add a "willReplaceWithResultOfExecutingJavascriptURL" flag which is respected inside FrameLoader::isNavigationAllowed * bindings/js/ScriptController.cpp: (WebCore::ScriptController::executeIfJavaScriptURL): * bindings/js/ScriptController.h: (WebCore::ScriptController::willReplaceWithResultOfExecutingJavascriptURL const): * loader/FrameLoader.cpp: (WebCore::FrameLoader::isNavigationAllowed const): Tools: * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/mac/JavascriptURLNavigation.mm: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248410 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-08 Brady Eidson Do not allow navigations of frames about to get replaced by the result of evaluating javascript: URLs and https://bugs.webkit.org/show_bug.cgi?id=198786 Reviewed by Geoff Garen. Covered by API Test Add a "willReplaceWithResultOfExecutingJavascriptURL" flag which is respected inside FrameLoader::isNavigationAllowed * bindings/js/ScriptController.cpp: (WebCore::ScriptController::executeIfJavaScriptURL): * bindings/js/ScriptController.h: (WebCore::ScriptController::willReplaceWithResultOfExecutingJavascriptURL const): * loader/FrameLoader.cpp: (WebCore::FrameLoader::isNavigationAllowed const): 2019-08-12 Alan Coon Cherry-pick r248368. rdar://problem/54037153 Extra space inserted at start of line when inserting a newline in Mail compose https://bugs.webkit.org/show_bug.cgi?id=200490 Reviewed by Antti Koivisto. Source/WebCore: This started happening after r244494, which deferred editor state computation until the next layer tree flush when changing selection. After inserting a paragraph, the act of computing an editor state ensured that the text node containing the caret drops out of simple line layout, while grabbing the characters near the selection (i.e., calling charactersAroundPosition). This meant that when we subsequently ask positionAfterSplit whether it isRenderedCharacter() at the end of the command, we are guaranteed to have line boxes, so we get a meaningful answer and avoid inserting an extra non-breaking space. However, after r244494, we defer the editor state computation until the end of the edit command; this means that we may not have line boxes for positionAfterSplit's text node renderer, due to remaining in simple line layout. In turn, this means that we end up hitting the assertion in containsRenderedCharacterOffset in debug builds; on release builds, we simply return false from containsRenderedCharacterOffset, which causes us to insert an extra space. To fix this, we educate RenderText::containsRenderedCharacterOffset about simple line layout. Test: editing/inserting/insert-paragraph-in-designmode-document.html * rendering/RenderText.cpp: (WebCore::RenderText::containsRenderedCharacterOffset const): (WebCore::RenderText::containsCaretOffset const): Changed to use SimpleLineLayout::containsOffset. * rendering/SimpleLineLayoutFunctions.h: (WebCore::SimpleLineLayout::containsOffset): I first contrasted the behavior of RenderTextLineBoxes::containsOffset in the cases where the OffsetType is CaretOffset or CharacterOffset, and found that the only interesting differences were: 1. The caret offset type case has special handling for line breaks. 2. Both offset types have handling for reversed text. 3. The end offset of a line box contains a caret offset, but not a character offset. For the purposes of OffsetType CharacterOffset, (1) is irrelevant; furthermore, (2) is already not handled by logic in containsCaretOffset(). Thus, the only major difference in the CharacterOffset case should be (3), which we handle by only allowing the case where the given offset is equal to the very end of a text run for caret offsets, and not character offsets. (WebCore::SimpleLineLayout::containsCaretOffset): Deleted. Renamed to just containsOffset. LayoutTests: Add a new test to verify that inserting a newline in the middle of text in a document with designMode "on" doesn't insert an extra space at the beginning of the newly inserted line. * editing/inserting/insert-paragraph-in-designmode-document-expected.txt: Added. * editing/inserting/insert-paragraph-in-designmode-document.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248368 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-07 Wenson Hsieh Extra space inserted at start of line when inserting a newline in Mail compose https://bugs.webkit.org/show_bug.cgi?id=200490 Reviewed by Antti Koivisto. This started happening after r244494, which deferred editor state computation until the next layer tree flush when changing selection. After inserting a paragraph, the act of computing an editor state ensured that the text node containing the caret drops out of simple line layout, while grabbing the characters near the selection (i.e., calling charactersAroundPosition). This meant that when we subsequently ask positionAfterSplit whether it isRenderedCharacter() at the end of the command, we are guaranteed to have line boxes, so we get a meaningful answer and avoid inserting an extra non-breaking space. However, after r244494, we defer the editor state computation until the end of the edit command; this means that we may not have line boxes for positionAfterSplit's text node renderer, due to remaining in simple line layout. In turn, this means that we end up hitting the assertion in containsRenderedCharacterOffset in debug builds; on release builds, we simply return false from containsRenderedCharacterOffset, which causes us to insert an extra space. To fix this, we educate RenderText::containsRenderedCharacterOffset about simple line layout. Test: editing/inserting/insert-paragraph-in-designmode-document.html * rendering/RenderText.cpp: (WebCore::RenderText::containsRenderedCharacterOffset const): (WebCore::RenderText::containsCaretOffset const): Changed to use SimpleLineLayout::containsOffset. * rendering/SimpleLineLayoutFunctions.h: (WebCore::SimpleLineLayout::containsOffset): I first contrasted the behavior of RenderTextLineBoxes::containsOffset in the cases where the OffsetType is CaretOffset or CharacterOffset, and found that the only interesting differences were: 1. The caret offset type case has special handling for line breaks. 2. Both offset types have handling for reversed text. 3. The end offset of a line box contains a caret offset, but not a character offset. For the purposes of OffsetType CharacterOffset, (1) is irrelevant; furthermore, (2) is already not handled by logic in containsCaretOffset(). Thus, the only major difference in the CharacterOffset case should be (3), which we handle by only allowing the case where the given offset is equal to the very end of a text run for caret offsets, and not character offsets. (WebCore::SimpleLineLayout::containsCaretOffset): Deleted. Renamed to just containsOffset. 2019-08-12 Alan Coon Cherry-pick r248265. rdar://problem/54017842 Ping loads should not prevent page caching https://bugs.webkit.org/show_bug.cgi?id=200418 Reviewed by Darin Adler. Source/WebCore: We normally prevent page caching if there were any pending subresource loads when navigating, to avoid caching partial / broken content. However, this should not apply to Ping / Beacon loads since those do not impact page rendering and can outlive the page. Tests: http/tests/navigation/page-cache-pending-ping-load-cross-origin.html http/tests/navigation/page-cache-pending-ping-load-same-origin.html * history/PageCache.cpp: (WebCore::PageCache::addIfCacheable): After we've fired the 'pagehide' event in each frame, stop all the loads again. This is needed since pages are allowed to start ping / beacon loads in their 'pagehide' handlers. If we do not stop those loads, then the next call to canCachePage() would fail because the DocumentLoader is still loading. Note that we're not actually preventing these ping loads from hitting the server since we never cancel page loads and those can outlive their page. * loader/DocumentLoader.cpp: (WebCore::shouldPendingCachedResourceLoadPreventPageCache): (WebCore::areAllLoadersPageCacheAcceptable): Make sure that Ping / Beacon / Prefetches / Icon loads do not prevent page caching. (WebCore::DocumentLoader::addSubresourceLoader): Tweak assertion that was incorrect since we actually allow ping / beacon loads when the document is about to enter PageCache (while firing pagehide event). Tools: Add TestOption to enable PageCache at UIProcess-level so that we can test page caching when navigating cross-origin with PSON enabled. * WebKitTestRunner/TestController.cpp: (WTR::TestController::resetPreferencesToConsistentValues): (WTR::updateTestOptionsFromTestHeader): * WebKitTestRunner/TestOptions.h: (WTR::TestOptions::hasSameInitializationOptions const): LayoutTests: Add layout test coverage. * http/tests/navigation/page-cache-pending-ping-load-cross-origin-expected.txt: Added. * http/tests/navigation/page-cache-pending-ping-load-cross-origin.html: Added. * http/tests/navigation/page-cache-pending-ping-load-same-origin-expected.txt: Added. * http/tests/navigation/page-cache-pending-ping-load-same-origin.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248265 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-04 Chris Dumez Ping loads should not prevent page caching https://bugs.webkit.org/show_bug.cgi?id=200418 Reviewed by Darin Adler. We normally prevent page caching if there were any pending subresource loads when navigating, to avoid caching partial / broken content. However, this should not apply to Ping / Beacon loads since those do not impact page rendering and can outlive the page. Tests: http/tests/navigation/page-cache-pending-ping-load-cross-origin.html http/tests/navigation/page-cache-pending-ping-load-same-origin.html * history/PageCache.cpp: (WebCore::PageCache::addIfCacheable): After we've fired the 'pagehide' event in each frame, stop all the loads again. This is needed since pages are allowed to start ping / beacon loads in their 'pagehide' handlers. If we do not stop those loads, then the next call to canCachePage() would fail because the DocumentLoader is still loading. Note that we're not actually preventing these ping loads from hitting the server since we never cancel page loads and those can outlive their page. * loader/DocumentLoader.cpp: (WebCore::shouldPendingCachedResourceLoadPreventPageCache): (WebCore::areAllLoadersPageCacheAcceptable): Make sure that Ping / Beacon / Prefetches / Icon loads do not prevent page caching. (WebCore::DocumentLoader::addSubresourceLoader): Tweak assertion that was incorrect since we actually allow ping / beacon loads when the document is about to enter PageCache (while firing pagehide event). 2019-08-12 Alan Coon Cherry-pick r248148. rdar://problem/54017840 Pages using MessagePorts should be PageCacheable https://bugs.webkit.org/show_bug.cgi?id=200366 Reviewed by Geoffrey Garen. Source/WebCore: Allow a page to enter PageCache, even if it has MessagePorts (potentially with pending messages). If there are pending messages on the MessagePorts when entering PageCache, those will get dispatched upon restoring from PageCache. Test: fast/history/page-cache-MessagePort-pending-message.html * dom/MessagePort.cpp: (WebCore::MessagePort::messageAvailable): (WebCore::MessagePort::dispatchMessages): Do not dispatch messages while in PageCache. (WebCore::MessagePort::canSuspendForDocumentSuspension const): Allow pages with MessagePort objects to enter PageCache. * dom/ScriptExecutionContext.cpp: (WebCore::ScriptExecutionContext::resumeActiveDOMObjects): Make sure pending messages on MessagePorts get dispatched asynchronously after restoring from PageCache. * loader/DocumentLoader.cpp: (WebCore::areAllLoadersPageCacheAcceptable): Make sure only CachedResources that are still loading upon load cancelation prevent entering PageCache. LayoutTests: Add layout test coverage. * fast/history/page-cache-MessagePort-pending-message-expected.txt: Added. * fast/history/page-cache-MessagePort-pending-message.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248148 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-01 Chris Dumez Pages using MessagePorts should be PageCacheable https://bugs.webkit.org/show_bug.cgi?id=200366 Reviewed by Geoffrey Garen. Allow a page to enter PageCache, even if it has MessagePorts (potentially with pending messages). If there are pending messages on the MessagePorts when entering PageCache, those will get dispatched upon restoring from PageCache. Test: fast/history/page-cache-MessagePort-pending-message.html * dom/MessagePort.cpp: (WebCore::MessagePort::messageAvailable): (WebCore::MessagePort::dispatchMessages): Do not dispatch messages while in PageCache. (WebCore::MessagePort::canSuspendForDocumentSuspension const): Allow pages with MessagePort objects to enter PageCache. * dom/ScriptExecutionContext.cpp: (WebCore::ScriptExecutionContext::resumeActiveDOMObjects): Make sure pending messages on MessagePorts get dispatched asynchronously after restoring from PageCache. * loader/DocumentLoader.cpp: (WebCore::areAllLoadersPageCacheAcceptable): Make sure only CachedResources that are still loading upon load cancelation prevent entering PageCache. 2019-08-12 Alan Coon Cherry-pick r248112. rdar://problem/53836593 [Text autosizing] [iPadOS] Add targeted hacks to address some remaining text autosizing issues https://bugs.webkit.org/show_bug.cgi?id=200271 Reviewed by Zalan Bujtas. Source/WebCore: Makes some targeted adjustments to the text autosizing heuristic, to ensure compatibility with several high- profile websites. See changes below for more detail. Tests: fast/text-autosizing/ios/idempotentmode/idempotent-autosizing-candidate-special-cases.html fast/text-autosizing/ios/idempotentmode/line-height-boosting.html * css/StyleResolver.cpp: (WebCore::StyleResolver::adjustRenderStyleForTextAutosizing): Avoid clipped sidebar links on sohu.com by not performing line-height boosting in the case where the element probably has a small, fixed number of lines. See below for more detail. Additionally, don't attempt to adjust the line height using the boosted font size, in the case where the element is not a candidate for idempotent text autosizing. * rendering/style/RenderStyle.cpp: (WebCore::RenderStyle::isIdempotentTextAutosizingCandidate const): Make various targeted hacks to fix a few websites: - Add a special case for top navigation bar links on yandex.ru, where line height greatly exceeds the specified font size. - Avoid boosting some related video links on v.youku.com by considering the line-clamp CSS property when determining the maximum number of lines of text an element is expected to contain. - Avoid boosting some front page links on asahi.com, which have non-repeating background images. - Add several other adjustments to more aggressively boost pieces of text on Google search results, such as taking the `word-break` CSS property into account. The bottom few pixels of sidebar links on naver.com are also no longer clipped after these changes. * rendering/style/TextSizeAdjustment.cpp: (WebCore::AutosizeStatus::probablyContainsASmallFixedNumberOfLines): Pulls out a piece of the heuristic added to fix sephora.com in r247467 out into a separate helper method. To recap, this heuristic identifies elements with both a fixed height and fixed line height, for which the fixed height is close to an integer multiple of the line height. Also makes several small tweaks in the process: (1) change the max difference between fixed line height and font size from 6 to 5 to ensure that some multiline caption text on Google search results is boosted, and (2) replace usages of `lineHeight()` with `specifiedLineHeight()`, which current prevents this function from being truly idempotent. (WebCore::AutosizeStatus::updateStatus): * rendering/style/TextSizeAdjustment.h: LayoutTests: Add tests to cover some changes to line height boosting and the idempotent text autosizing candidate heuristic. * fast/text-autosizing/ios/idempotentmode/idempotent-autosizing-candidate-special-cases-expected.txt: Added. * fast/text-autosizing/ios/idempotentmode/idempotent-autosizing-candidate-special-cases.html: Added. * fast/text-autosizing/ios/idempotentmode/line-height-boosting-expected.txt: * fast/text-autosizing/ios/idempotentmode/line-height-boosting.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248112 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-01 Wenson Hsieh [Text autosizing] [iPadOS] Add targeted hacks to address some remaining text autosizing issues https://bugs.webkit.org/show_bug.cgi?id=200271 Reviewed by Zalan Bujtas. Makes some targeted adjustments to the text autosizing heuristic, to ensure compatibility with several high- profile websites. See changes below for more detail. Tests: fast/text-autosizing/ios/idempotentmode/idempotent-autosizing-candidate-special-cases.html fast/text-autosizing/ios/idempotentmode/line-height-boosting.html * css/StyleResolver.cpp: (WebCore::StyleResolver::adjustRenderStyleForTextAutosizing): Avoid clipped sidebar links on sohu.com by not performing line-height boosting in the case where the element probably has a small, fixed number of lines. See below for more detail. Additionally, don't attempt to adjust the line height using the boosted font size, in the case where the element is not a candidate for idempotent text autosizing. * rendering/style/RenderStyle.cpp: (WebCore::RenderStyle::isIdempotentTextAutosizingCandidate const): Make various targeted hacks to fix a few websites: - Add a special case for top navigation bar links on yandex.ru, where line height greatly exceeds the specified font size. - Avoid boosting some related video links on v.youku.com by considering the line-clamp CSS property when determining the maximum number of lines of text an element is expected to contain. - Avoid boosting some front page links on asahi.com, which have non-repeating background images. - Add several other adjustments to more aggressively boost pieces of text on Google search results, such as taking the `word-break` CSS property into account. The bottom few pixels of sidebar links on naver.com are also no longer clipped after these changes. * rendering/style/TextSizeAdjustment.cpp: (WebCore::AutosizeStatus::probablyContainsASmallFixedNumberOfLines): Pulls out a piece of the heuristic added to fix sephora.com in r247467 out into a separate helper method. To recap, this heuristic identifies elements with both a fixed height and fixed line height, for which the fixed height is close to an integer multiple of the line height. Also makes several small tweaks in the process: (1) change the max difference between fixed line height and font size from 6 to 5 to ensure that some multiline caption text on Google search results is boosted, and (2) replace usages of `lineHeight()` with `specifiedLineHeight()`, which current prevents this function from being truly idempotent. (WebCore::AutosizeStatus::updateStatus): * rendering/style/TextSizeAdjustment.h: 2019-08-12 Alan Coon Cherry-pick r248095. rdar://problem/53820658 REGRESSION (r240942): first visually non-empty layout milestone is not reached in media documents until after the video finishes loading https://bugs.webkit.org/show_bug.cgi?id=200293 Reviewed by Alex Christensen. Source/WebCore: r240942 changed FrameView::qualifiesAsVisuallyNonEmpty() to consider only documents in the Interactive or Complete ready states as "finished parsing". Documents considered finished parsing can qualify as visually non-empty even without exceeding the visual character or pixel thresholds, but documents considered not finished must first exceed one of these thresholds in order to qualify as visually non-empty. HTMLDocuments are placed in the Interactive ready state by their HTMLDocumentParsers. However, HTMLDocument subclasses like ImageDocument and MediaDocument use their own custom parsers that never set the Interactive ready state on their documents; these documents go from Loading directly to Complete. In order for these HTMLDocument subclasses to be considered visually non-empty before they finish loading they must render something that exceeds the visual character or pixel thresholds. For image documents, rendering the image is usually enough to cross the threshold, but for media documents the visual pixel threshold was never crossed because videos did not contribute to the visually non-empty pixel count. As a result, media documents are not considered visually non-empty until the main resource finishes loading. On iOS this means that the layer tree remains frozen until this point, even though the media might have started autoplaying with audio long before it finished loading. Fix this by teaching RenderVideo to contribute the video player's size to FrameView's visually non-empty pixel count once the video player has loaded enough data to determine its intrinsic size. Videos that render more than 1024 pixels will qualify a media document as visually non-empty even when it is still loading its main resource. Added a new API test. * rendering/RenderImage.cpp: (WebCore::RenderImage::imageChanged): (WebCore::RenderImage::incrementVisuallyNonEmptyPixelCountIfNeeded): * rendering/RenderImage.h: * rendering/RenderVideo.cpp: (WebCore::RenderVideo::updateIntrinsicSize): Tools: * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKitCocoa/FirstVisuallyNonEmptyMilestone.mm: Renamed from Tools/TestWebKitAPI/Tests/WebKit/FirstVisuallyNonEmptyMilestoneWithDeferredScript.mm. (-[FirstPaintMessageHandler userContentController:didReceiveScriptMessage:]): (-[RenderingProgressNavigationDelegate _webView:renderingProgressDidChange:]): (-[RenderingProgressNavigationDelegate webView:didFinishNavigation:]): (TEST): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248095 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-31 Andy Estes REGRESSION (r240942): first visually non-empty layout milestone is not reached in media documents until after the video finishes loading https://bugs.webkit.org/show_bug.cgi?id=200293 Reviewed by Alex Christensen. r240942 changed FrameView::qualifiesAsVisuallyNonEmpty() to consider only documents in the Interactive or Complete ready states as "finished parsing". Documents considered finished parsing can qualify as visually non-empty even without exceeding the visual character or pixel thresholds, but documents considered not finished must first exceed one of these thresholds in order to qualify as visually non-empty. HTMLDocuments are placed in the Interactive ready state by their HTMLDocumentParsers. However, HTMLDocument subclasses like ImageDocument and MediaDocument use their own custom parsers that never set the Interactive ready state on their documents; these documents go from Loading directly to Complete. In order for these HTMLDocument subclasses to be considered visually non-empty before they finish loading they must render something that exceeds the visual character or pixel thresholds. For image documents, rendering the image is usually enough to cross the threshold, but for media documents the visual pixel threshold was never crossed because videos did not contribute to the visually non-empty pixel count. As a result, media documents are not considered visually non-empty until the main resource finishes loading. On iOS this means that the layer tree remains frozen until this point, even though the media might have started autoplaying with audio long before it finished loading. Fix this by teaching RenderVideo to contribute the video player's size to FrameView's visually non-empty pixel count once the video player has loaded enough data to determine its intrinsic size. Videos that render more than 1024 pixels will qualify a media document as visually non-empty even when it is still loading its main resource. Added a new API test. * rendering/RenderImage.cpp: (WebCore::RenderImage::imageChanged): (WebCore::RenderImage::incrementVisuallyNonEmptyPixelCountIfNeeded): * rendering/RenderImage.h: * rendering/RenderVideo.cpp: (WebCore::RenderVideo::updateIntrinsicSize): 2019-08-12 Alan Coon 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 Apply patch. rdar://problem/53992160 2019-08-06 Per Arne Vollan [Win] Fix AppleWin build https://bugs.webkit.org/show_bug.cgi?id=200414 Reviewed by Brent Fulgham. * CMakeLists.txt: * PlatformPlayStation.cmake: * PlatformWPE.cmake: * PlatformWin.cmake: 2019-08-01 Alan Coon Apply patch. rdar://problem/53764238 2019-08-01 Ryosuke Niwa The maximum subframe count check should not be skipped for empty URLs. https://bugs.webkit.org/show_bug.cgi?id=200032 Based on the patch by Sergei Glazunov (r247924). Move the check closer to the actual frame creation code in loadSubframe. Tests: fast/dom/connected-subframe-counter-overflow.html * dom/Document.cpp: (WebCore::Document::prepareForDestruction): Assert that all child frames have been detached. * html/HTMLFrameElementBase.cpp: (WebCore::HTMLFrameElementBase::isURLAllowed const): * loader/SubframeLoader.cpp: (WebCore::SubframeLoader::loadSubframe): Added the check here. * page/Frame.cpp: (WebCore::Frame::isURLAllowed const): 2019-07-31 Alan Coon Cherry-pick r248080. rdar://problem/53788956 [ContentChangeObserver] twitch.tv video controls do not always respond to taps in fullscreen https://bugs.webkit.org/show_bug.cgi?id=200309 Reviewed by Simon Fraser. Source/WebCore: Do not consider an element visible if it is not a descendant of the active fullscreen element. This patch fixes the cases when the user taps on a button in fullscreen mode while the non-fullscreen content is being mutated and the ContentChangeObserver mistakenly registers it as a valid, actionable change and as a result we don't fire the click event (stay at hover). Test: fast/events/touch/ios/content-observation/non-visible-content-change-in-fullscreen-mode.html * page/ios/ContentChangeObserver.cpp: (WebCore::fullscreenElement): (WebCore::ContentChangeObserver::isVisuallyHidden): LayoutTests: * fast/events/touch/ios/content-observation/non-visible-content-change-in-fullscreen-mode-expected.txt: Added. * fast/events/touch/ios/content-observation/non-visible-content-change-in-fullscreen-mode.html: Added. * platform/ios/TestExpectations: Fullscreen API is not yet enabled on iOS. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248080 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-31 Zalan Bujtas [ContentChangeObserver] twitch.tv video controls do not always respond to taps in fullscreen https://bugs.webkit.org/show_bug.cgi?id=200309 Reviewed by Simon Fraser. Do not consider an element visible if it is not a descendant of the active fullscreen element. This patch fixes the cases when the user taps on a button in fullscreen mode while the non-fullscreen content is being mutated and the ContentChangeObserver mistakenly registers it as a valid, actionable change and as a result we don't fire the click event (stay at hover). Test: fast/events/touch/ios/content-observation/non-visible-content-change-in-fullscreen-mode.html * page/ios/ContentChangeObserver.cpp: (WebCore::fullscreenElement): (WebCore::ContentChangeObserver::isVisuallyHidden): 2019-07-31 Alan Coon Cherry-pick r248079. rdar://problem/53788988 [iPadOS] Enable simulated mouse events on iqiyi.com to fix the video controls https://bugs.webkit.org/show_bug.cgi?id=200322 rdar://problem/53235709 Reviewed by Wenson Hsieh. iqiyi.com needs to get mouseMove events for dragging the video scrubber to work. * page/Quirks.cpp: (WebCore::Quirks::shouldDispatchSimulatedMouseEvents const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248079 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-31 Alan Coon Cherry-pick r248071. rdar://problem/53789003 Use CTFontCreateForCharactersWithLanguageAndOption if available instead of CTFontCreateForCharactersWithLanguage https://bugs.webkit.org/show_bug.cgi?id=200241 Source/WebCore: Reviewed by Myles C. Maxfield. We can use CTFontCreateForCharactersWithLanguageAndOption instead of CTFontCreateForCharactersWithLanguage as it allows setting more easily the fallback option. This allows us to never fallback to user installed fonts. In such a case, we no longer need to wrap the fonts to change the fallback option. We also prewarm the fonts with the same SPI and use system fallback as the default value. Covered by existing tests. * platform/graphics/cocoa/FontCacheCoreText.cpp: (WebCore::preparePlatformFont): (WebCore::lookupFallbackFont): (WebCore::FontCache::systemFallbackForCharacters): (WebCore::FontCache::prewarm): (WebCore::fontFamiliesForPrewarming): Source/WebCore/PAL: Reviewed by Myles C. Maxfield. Add new SPI. * pal/spi/cocoa/CoreTextSPI.h: Source/WTF: Reviewed by Myles C. Maxfield. * wtf/Platform.h: Add macro to enable/disable new SPI. LayoutTests: We update the tests to flush font caches as otherwise some debug asserts would be hit. This is due to changing the user installed font runtime flag while browsing which is not a typical situation. Reviewed by Myles C. Maxfield. * fast/text/user-installed-fonts/extended-character-with-user-font.html: * fast/text/user-installed-fonts/extended-character.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248071 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-31 Youenn Fablet Use CTFontCreateForCharactersWithLanguageAndOption if available instead of CTFontCreateForCharactersWithLanguage https://bugs.webkit.org/show_bug.cgi?id=200241 Reviewed by Myles C. Maxfield. We can use CTFontCreateForCharactersWithLanguageAndOption instead of CTFontCreateForCharactersWithLanguage as it allows setting more easily the fallback option. This allows us to never fallback to user installed fonts. In such a case, we no longer need to wrap the fonts to change the fallback option. We also prewarm the fonts with the same SPI and use system fallback as the default value. Covered by existing tests. * platform/graphics/cocoa/FontCacheCoreText.cpp: (WebCore::preparePlatformFont): (WebCore::lookupFallbackFont): (WebCore::FontCache::systemFallbackForCharacters): (WebCore::FontCache::prewarm): (WebCore::fontFamiliesForPrewarming): 2019-07-31 Alan Coon Cherry-pick r248046. rdar://problem/53788952 Owners of MultiChannelResampler should make sure that the output bus given to it has the same number of channels https://bugs.webkit.org/show_bug.cgi?id=200248 Reviewed by Eric Carlson. Source/WebCore: When a track's number of channels changes, MediaStreamAudioSourceNode is expected to update its MultiChannelResampler and its output number of channels. MultiChannelResampler expects to have the same number of channels as the output but it is not always the case since the channel numbers are changed in different threads and locks do not help there. Instead, whenever detecting that the number of channels do not match, render silence and wait for the next rendering where the number of channels should again match. Add internals API to change the number of channels from 2 to 1 or 1 to 2 to allow testing that code path (iOS only as MacOS audio capture is in UIProcess). Covered by updated test. * Modules/webaudio/MediaElementAudioSourceNode.cpp: (WebCore::MediaElementAudioSourceNode::process): * Modules/webaudio/MediaStreamAudioSourceNode.cpp: (WebCore::MediaStreamAudioSourceNode::process): * platform/audio/MultiChannelResampler.cpp: (WebCore::MultiChannelResampler::process): * platform/mediastream/RealtimeMediaSource.h: * platform/mediastream/mac/MockRealtimeAudioSourceMac.mm: (WebCore::MockRealtimeAudioSourceMac::reconfigure): * platform/mock/MockRealtimeAudioSource.cpp: (WebCore::MockRealtimeAudioSource::setChannelCount): * platform/mock/MockRealtimeAudioSource.h: (isType): * platform/mock/MockRealtimeVideoSource.h: * testing/Internals.cpp: (WebCore::Internals::setMockAudioTrackChannelNumber): * testing/Internals.h: * testing/Internals.idl: LayoutTests: * fast/mediastream/getUserMedia-webaudio-expected.txt: * fast/mediastream/getUserMedia-webaudio.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248046 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-31 Youenn Fablet Owners of MultiChannelResampler should make sure that the output bus given to it has the same number of channels https://bugs.webkit.org/show_bug.cgi?id=200248 Reviewed by Eric Carlson. When a track's number of channels changes, MediaStreamAudioSourceNode is expected to update its MultiChannelResampler and its output number of channels. MultiChannelResampler expects to have the same number of channels as the output but it is not always the case since the channel numbers are changed in different threads and locks do not help there. Instead, whenever detecting that the number of channels do not match, render silence and wait for the next rendering where the number of channels should again match. Add internals API to change the number of channels from 2 to 1 or 1 to 2 to allow testing that code path (iOS only as MacOS audio capture is in UIProcess). Covered by updated test. * Modules/webaudio/MediaElementAudioSourceNode.cpp: (WebCore::MediaElementAudioSourceNode::process): * Modules/webaudio/MediaStreamAudioSourceNode.cpp: (WebCore::MediaStreamAudioSourceNode::process): * platform/audio/MultiChannelResampler.cpp: (WebCore::MultiChannelResampler::process): * platform/mediastream/RealtimeMediaSource.h: * platform/mediastream/mac/MockRealtimeAudioSourceMac.mm: (WebCore::MockRealtimeAudioSourceMac::reconfigure): * platform/mock/MockRealtimeAudioSource.cpp: (WebCore::MockRealtimeAudioSource::setChannelCount): * platform/mock/MockRealtimeAudioSource.h: (isType): * platform/mock/MockRealtimeVideoSource.h: * testing/Internals.cpp: (WebCore::Internals::setMockAudioTrackChannelNumber): * testing/Internals.h: * testing/Internals.idl: 2019-07-31 Alan Coon Cherry-pick r248037. rdar://problem/53764079 AX: Re-enable accessibility/set-selected-text-range-after-newline.html test. https://bugs.webkit.org/show_bug.cgi?id=199431 Patch by Andres Gonzalez on 2019-07-31 Reviewed by Chris Fleizach. Source/WebCore: - Re-enabled LayoutTests/accessibility/set-selected-text-range-after-newline.html. - Put back workaround in visiblePositionForIndexUsingCharacterIterator that is needed for several accessibility issues. - This workaround was rolled back because it was thought the cause of: https://bugs.webkit.org/show_bug.cgi?id=199434 It turned out that the actual cause of that hang was unrelated and was fixed in: https://bugs.webkit.org/show_bug.cgi?id=199845 * editing/Editing.cpp: (WebCore::visiblePositionForIndexUsingCharacterIterator): LayoutTests: * TestExpectations: * accessibility/ios-simulator/set-selected-text-range-after-newline.html: Removed because it was the same as the one in the parent accessibility directory, so enabling it for iOS in ios-wk2/TestExpectations. * platform/ios-wk2/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248037 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-31 Andres Gonzalez AX: Re-enable accessibility/set-selected-text-range-after-newline.html test. https://bugs.webkit.org/show_bug.cgi?id=199431 Reviewed by Chris Fleizach. - Re-enabled LayoutTests/accessibility/set-selected-text-range-after-newline.html. - Put back workaround in visiblePositionForIndexUsingCharacterIterator that is needed for several accessibility issues. - This workaround was rolled back because it was thought the cause of: https://bugs.webkit.org/show_bug.cgi?id=199434 It turned out that the actual cause of that hang was unrelated and was fixed in: https://bugs.webkit.org/show_bug.cgi?id=199845 * editing/Editing.cpp: (WebCore::visiblePositionForIndexUsingCharacterIterator): 2019-07-31 Alan Coon Cherry-pick r248024. rdar://problem/53764047 WorkerGlobalScope::wrapCryptoKey/unwrapCryptoKey should use local heap objects for replies https://bugs.webkit.org/show_bug.cgi?id=200179 Reviewed by Brent Fulgham. Based on the patch by Jiewen Tan. WorkerGlobalScope::wrapCryptoKey and WorkerGlobalScope::unwrapCryptoKey had a bug that they could exit the function before the main thread had finished writing to the result vector passed in to these functions when the worker's runloop receives MessageQueueTerminated before the main thread finishes writing. Fixed the bug by creating a new temporary Vector inside a ThreadSafeRefCounted object shared between the main thread and the worker thread, which extends the lifetime of the Vector until when the worker thread receives the result or when the main thread finishes writing to the Vector, whichever happens last. Unfortunately no new tests since there is no reproducible test case, and this crash is highly racy. * workers/WorkerGlobalScope.cpp: (WebCore::CryptoBufferContainer): Added. (WebCore::CryptoBufferContainer::create): Added. (WebCore::CryptoBufferContainer::buffer): Added. (WebCore::WorkerGlobalScope::wrapCryptoKey): (WebCore::WorkerGlobalScope::unwrapCryptoKey): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248024 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-29 Ryosuke Niwa WorkerGlobalScope::wrapCryptoKey/unwrapCryptoKey should use local heap objects for replies https://bugs.webkit.org/show_bug.cgi?id=200179 Reviewed by Brent Fulgham. Based on the patch by Jiewen Tan. WorkerGlobalScope::wrapCryptoKey and WorkerGlobalScope::unwrapCryptoKey had a bug that they could exit the function before the main thread had finished writing to the result vector passed in to these functions when the worker's runloop receives MessageQueueTerminated before the main thread finishes writing. Fixed the bug by creating a new temporary Vector inside a ThreadSafeRefCounted object shared between the main thread and the worker thread, which extends the lifetime of the Vector until when the worker thread receives the result or when the main thread finishes writing to the Vector, whichever happens last. Unfortunately no new tests since there is no reproducible test case, and this crash is highly racy. * workers/WorkerGlobalScope.cpp: 2019-08-08 Simon Fraser 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 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: (WebCore::CryptoBufferContainer): Added. (WebCore::CryptoBufferContainer::create): Added. (WebCore::CryptoBufferContainer::buffer): Added. (WebCore::WorkerGlobalScope::wrapCryptoKey): (WebCore::WorkerGlobalScope::unwrapCryptoKey): 2019-07-31 Alan Coon Cherry-pick r248018. rdar://problem/53764057 REGRESSION(r241288): Text on Yahoo Japan mobile looks too bold https://bugs.webkit.org/show_bug.cgi?id=200065 Reviewed by Simon Fraser. Source/WebCore: Before r241288, we were mapping Japanese sans-serif to Hiragino Kaku Gothic ProN, which has a 300 weight and a 600 weight. However, we can't use that font because it's user-installed, so in r241288 we switched to using Hiragino Sans, which has a 300 weight, a 600 weight, and an 800 weight. According to the CSS font selection algorithm, sites that request a weight of 700 would get the 800 weight instead of the 600 weight, which caused the text to look too heavy. Therefore, the apparent visual change is from a weight change from 600 to 800. In general, this is working as intended. However, text on Yahoo Japan looks too heavy in weight 800. Instead, this patch adds a quirk specific to Yahoo Japan that overwrites any font requests to give them a weight of 600 instead of 700. This way, the lighter font will be used. No new tests because quirks cannot be tested. * css/CSSFontSelector.cpp: (WebCore::resolveGenericFamily): (WebCore::CSSFontSelector::fontRangesForFamily): * page/Quirks.cpp: (WebCore::Quirks::shouldLightenJapaneseBoldSansSerif const): * page/Quirks.h: Source/WTF: * wtf/Platform.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248018 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-30 Myles C. Maxfield REGRESSION(r241288): Text on Yahoo Japan mobile looks too bold https://bugs.webkit.org/show_bug.cgi?id=200065 Reviewed by Simon Fraser. Before r241288, we were mapping Japanese sans-serif to Hiragino Kaku Gothic ProN, which has a 300 weight and a 600 weight. However, we can't use that font because it's user-installed, so in r241288 we switched to using Hiragino Sans, which has a 300 weight, a 600 weight, and an 800 weight. According to the CSS font selection algorithm, sites that request a weight of 700 would get the 800 weight instead of the 600 weight, which caused the text to look too heavy. Therefore, the apparent visual change is from a weight change from 600 to 800. In general, this is working as intended. However, text on Yahoo Japan looks too heavy in weight 800. Instead, this patch adds a quirk specific to Yahoo Japan that overwrites any font requests to give them a weight of 600 instead of 700. This way, the lighter font will be used. No new tests because quirks cannot be tested. * css/CSSFontSelector.cpp: (WebCore::resolveGenericFamily): (WebCore::CSSFontSelector::fontRangesForFamily): * page/Quirks.cpp: (WebCore::Quirks::shouldLightenJapaneseBoldSansSerif const): * page/Quirks.h: 2019-07-31 Alan Coon Cherry-pick r247934. rdar://problem/53764085 MediaSource.isTypeSupported claims FLAC-in-MP4 support on iOS and macOS, but plays silence https://bugs.webkit.org/show_bug.cgi?id=198583 Reviewed by Maciej Stachowiak. * platform/graphics/avfoundation/objc/AVStreamDataParserMIMETypeCache.h: (WebCore::AVStreamDataParserMIMETypeCache::canDecodeType): Use anParseExtendedMIMEType: when it is available. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247934 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-29 Eric Carlson MediaSource.isTypeSupported claims FLAC-in-MP4 support on iOS and macOS, but plays silence https://bugs.webkit.org/show_bug.cgi?id=198583 Reviewed by Maciej Stachowiak. * platform/graphics/avfoundation/objc/AVStreamDataParserMIMETypeCache.h: (WebCore::AVStreamDataParserMIMETypeCache::canDecodeType): Use anParseExtendedMIMEType: when it is available. 2019-07-31 Alan Coon Cherry-pick r247915. rdar://problem/53764061 Force Reveal to always lookup from menu https://bugs.webkit.org/show_bug.cgi?id=200186 2019-07-31 Simon Fraser [iPadOS] Enable simulated mouse events on iqiyi.com to fix the video controls https://bugs.webkit.org/show_bug.cgi?id=200322 rdar://problem/53235709 Reviewed by Wenson Hsieh. iqiyi.com needs to get mouseMove events for dragging the video scrubber to work. * page/Quirks.cpp: (WebCore::Quirks::shouldDispatchSimulatedMouseEvents const): Reviewed by Tim Horton. We currently only have the 'lookup' menu item, so we should always force the 'lookup' action from it. Reveal is not currently testable. * editing/cocoa/DictionaryLookup.mm: (WebCore::showPopupOrCreateAnimationController): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247915 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-29 Megan Gardner Force Reveal to always lookup from menu https://bugs.webkit.org/show_bug.cgi?id=200186 Reviewed by Tim Horton. We currently only have the 'lookup' menu item, so we should always force the 'lookup' action from it. Reveal is not currently testable. * editing/cocoa/DictionaryLookup.mm: (WebCore::showPopupOrCreateAnimationController): 2019-07-31 Alan Coon Cherry-pick r247912. rdar://problem/53764200 REGRESSION (r246899): Subtitles show twice when controls show/hide on hulu.com https://bugs.webkit.org/show_bug.cgi?id=200187 rdar://problem/53511121 Reviewed by Zalan Bujtas. Source/WebCore: When a layer that painted into shared backing moved, we'd fail to repaint its old position because the RenderLayer's repaint rects are cleared via BackingSharingState::updateBeforeDescendantTraversal(). Recomputing repaint rects is expensive, so we only want to do it when necessary, which is for layers that start and stop sharing (going into and out of compositing already recomputes them). So add logic to RenderLayerBacking::setBackingSharingLayers() that recomputes repaint rects on layers that will no longer use shared backing, and those that are newly using shared backing. Test: compositing/shared-backing/backing-sharing-repaint.html * rendering/RenderLayer.cpp: (WebCore::RenderLayer::setBackingProviderLayer): * rendering/RenderLayerBacking.cpp: (WebCore::RenderLayerBacking::setBackingSharingLayers): * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::BackingSharingState::appendSharingLayer): (WebCore::RenderLayerCompositor::updateBacking): LayoutTests: * compositing/shared-backing/backing-sharing-repaint-expected.html: Added. * compositing/shared-backing/backing-sharing-repaint.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247912 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-29 Simon Fraser REGRESSION (r246899): Subtitles show twice when controls show/hide on hulu.com https://bugs.webkit.org/show_bug.cgi?id=200187 rdar://problem/53511121 Reviewed by Zalan Bujtas. When a layer that painted into shared backing moved, we'd fail to repaint its old position because the RenderLayer's repaint rects are cleared via BackingSharingState::updateBeforeDescendantTraversal(). Recomputing repaint rects is expensive, so we only want to do it when necessary, which is for layers that start and stop sharing (going into and out of compositing already recomputes them). So add logic to RenderLayerBacking::setBackingSharingLayers() that recomputes repaint rects on layers that will no longer use shared backing, and those that are newly using shared backing. Test: compositing/shared-backing/backing-sharing-repaint.html * rendering/RenderLayer.cpp: (WebCore::RenderLayer::setBackingProviderLayer): * rendering/RenderLayerBacking.cpp: (WebCore::RenderLayerBacking::setBackingSharingLayers): * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::BackingSharingState::appendSharingLayer): (WebCore::RenderLayerCompositor::updateBacking): 2019-07-31 Alan Coon Cherry-pick r247909. rdar://problem/53764231 The touch-action property was ignored on replaced elements (canvas, img etc) https://bugs.webkit.org/show_bug.cgi?id=200205 rdar://problem/53331224 Reviewed by Antti Koivisto. Source/WebCore: The event region painting code didn't handle replaced elements correctly, causing touch-action to get ignored for , etc. Fix by handling region painting in RenderReplaced. This still doesn't fix