2019-03-11 Kocsen Chung Cherry-pick r242770. rdar://problem/48795263 REGRESSION(r236281): YouTube Movies fail with "video format" error https://bugs.webkit.org/show_bug.cgi?id=195598 Reviewed by Jon Lee. Partially revert r236281 for YouTube.com. * page/Quirks.cpp: (WebCore::Quirks::hasBrokenEncryptedMediaAPISupportQuirk const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242770 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-11 Jer Noble REGRESSION(r236281): YouTube Movies fail with "video format" error https://bugs.webkit.org/show_bug.cgi?id=195598 Reviewed by Jon Lee. Partially revert r236281 for YouTube.com. * page/Quirks.cpp: (WebCore::Quirks::hasBrokenEncryptedMediaAPISupportQuirk const): 2019-02-28 Kocsen Chung Cherry-pick r242204. rdar://problem/48483747 Locale names can be nullptr https://bugs.webkit.org/show_bug.cgi?id=195171 Reviewed by Dean Jackson. Nullptr can't be used in keys to HashMaps, so take an early out in this case. This is a partial revert of r241288. * platform/graphics/cocoa/FontDescriptionCocoa.cpp: (WebCore::FontDescription::platformResolveGenericFamily): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242204 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-28 Myles C. Maxfield Locale names can be nullptr https://bugs.webkit.org/show_bug.cgi?id=195171 Reviewed by Dean Jackson. Nullptr can't be used in keys to HashMaps, so take an early out in this case. This is a partial revert of r241288. * platform/graphics/cocoa/FontDescriptionCocoa.cpp: (WebCore::FontDescription::platformResolveGenericFamily): 2019-02-28 Alan Coon Apply patch. rdar://problem/48464969 2019-02-28 Timothy Hatcher REGRESSION: WebKit content crash in Base System (because NSAppearance is NULL). https://bugs.webkit.org/show_bug.cgi?id=195086 rdar://problem/48419124 Reviewed by Tim Horton. * platform/mac/ScrollAnimatorMac.mm: (-[WebScrollerImpDelegate effectiveAppearanceForScrollerImp:]): Always return a valid NSAppearance. 2019-02-24 Babak Shafiei Cherry-pick r241986. rdar://problem/48350373 Crash in SWServerJobQueue::runNextJobSynchronously https://bugs.webkit.org/show_bug.cgi?id=194974 Reviewed by Geoffrey Garen. We suspect the crash is happening due to m_jobQueue being empty in runNextJobSynchronously or there is a timer heap corruption again :( Exit early when m_jobQueue is empty. Also add a debug assert that this should never happen but convert an existing release assert to a debug assert since this appears to be hitting too frequently in wild. * workers/service/server/SWServerJobQueue.cpp: (WebCore::SWServerJobQueue::runNextJobSynchronously): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241986 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-22 Ryosuke Niwa Crash in SWServerJobQueue::runNextJobSynchronously https://bugs.webkit.org/show_bug.cgi?id=194974 Reviewed by Geoffrey Garen. We suspect the crash is happening due to m_jobQueue being empty in runNextJobSynchronously or there is a timer heap corruption again :( Exit early when m_jobQueue is empty. Also add a debug assert that this should never happen but convert an existing release assert to a debug assert since this appears to be hitting too frequently in wild. * workers/service/server/SWServerJobQueue.cpp: (WebCore::SWServerJobQueue::runNextJobSynchronously): 2019-02-24 Babak Shafiei Cherry-pick r241967. rdar://problem/48350358 Crash under IDBServer::IDBConnectionToClient::identifier() const https://bugs.webkit.org/show_bug.cgi?id=194843 Reviewed by Geoffrey Garen. UniqueIDBDatabase should ignore requests from connections that are already closed. Tests are hard to create without some tricks on UniqueIDBDatabase so this fix is verified manually. One test is created by adding delay to UniqueIDBDatabase::openBackingStore on the background thread to make sure disconnection of web process happens before UniqueIDBDatabase::didOpenBackingStore, because didOpenBackingStore may start a version change transaction and ask for identifier from the connection that is already gone. * Modules/indexeddb/server/IDBConnectionToClient.cpp: (WebCore::IDBServer::IDBConnectionToClient::connectionToClientClosed): * Modules/indexeddb/server/IDBConnectionToClient.h: (WebCore::IDBServer::IDBConnectionToClient::isClosed): * Modules/indexeddb/server/UniqueIDBDatabase.cpp: (WebCore::IDBServer::UniqueIDBDatabase::clearStalePendingOpenDBRequests): (WebCore::IDBServer::UniqueIDBDatabase::handleDatabaseOperations): (WebCore::IDBServer::UniqueIDBDatabase::operationAndTransactionTimerFired): * Modules/indexeddb/server/UniqueIDBDatabase.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241967 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-22 Sihui Liu Crash under IDBServer::IDBConnectionToClient::identifier() const https://bugs.webkit.org/show_bug.cgi?id=194843 Reviewed by Geoffrey Garen. UniqueIDBDatabase should ignore requests from connections that are already closed. Tests are hard to create without some tricks on UniqueIDBDatabase so this fix is verified manually. One test is created by adding delay to UniqueIDBDatabase::openBackingStore on the background thread to make sure disconnection of web process happens before UniqueIDBDatabase::didOpenBackingStore, because didOpenBackingStore may start a version change transaction and ask for identifier from the connection that is already gone. * Modules/indexeddb/server/IDBConnectionToClient.cpp: (WebCore::IDBServer::IDBConnectionToClient::connectionToClientClosed): * Modules/indexeddb/server/IDBConnectionToClient.h: (WebCore::IDBServer::IDBConnectionToClient::isClosed): * Modules/indexeddb/server/UniqueIDBDatabase.cpp: (WebCore::IDBServer::UniqueIDBDatabase::clearStalePendingOpenDBRequests): (WebCore::IDBServer::UniqueIDBDatabase::handleDatabaseOperations): (WebCore::IDBServer::UniqueIDBDatabase::operationAndTransactionTimerFired): * Modules/indexeddb/server/UniqueIDBDatabase.h: 2019-02-24 Babak Shafiei Cherry-pick r241915. rdar://problem/48298733 Layout Test fast/text/international/khmer-selection.html is crashing https://bugs.webkit.org/show_bug.cgi?id=191368 Reviewed by Brent Fulgham. Source/WebCore: GlyphBuffer's offset array wasn't getting filled by UniscribeController. Our underlining code requires this array. Uniscribe gives us a character -> glyph mapping, so we just have to compute the inverse and give it to the GlyphBuffer. This patch is written by Myles C. Maxfield. Test: fast/text/international/khmer-selection.html. * platform/graphics/GlyphBuffer.h: (WebCore::GlyphBuffer::add): * platform/graphics/displaylists/DisplayListItems.cpp: (WebCore::DisplayList::DrawGlyphs::generateGlyphBuffer const): * platform/graphics/win/UniscribeController.cpp: (WebCore::UniscribeController::advance): (WebCore::UniscribeController::itemizeShapeAndPlace): (WebCore::UniscribeController::shapeAndPlaceItem): * platform/graphics/win/UniscribeController.h: LayoutTests: * platform/win/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241915 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-21 Per Arne Vollan Layout Test fast/text/international/khmer-selection.html is crashing https://bugs.webkit.org/show_bug.cgi?id=191368 Reviewed by Brent Fulgham. GlyphBuffer's offset array wasn't getting filled by UniscribeController. Our underlining code requires this array. Uniscribe gives us a character -> glyph mapping, so we just have to compute the inverse and give it to the GlyphBuffer. This patch is written by Myles C. Maxfield. Test: fast/text/international/khmer-selection.html. * platform/graphics/GlyphBuffer.h: (WebCore::GlyphBuffer::add): * platform/graphics/displaylists/DisplayListItems.cpp: (WebCore::DisplayList::DrawGlyphs::generateGlyphBuffer const): * platform/graphics/win/UniscribeController.cpp: (WebCore::UniscribeController::advance): (WebCore::UniscribeController::itemizeShapeAndPlace): (WebCore::UniscribeController::shapeAndPlaceItem): * platform/graphics/win/UniscribeController.h: 2019-02-24 Babak Shafiei Cherry-pick r241830. rdar://problem/48248202 REGRESSION (r241788>): ASSERTION FAILED: !m_normalFlowListDirty in TestWebKitAPI.WebKit.ResizeReversePaginatedWebView test https://bugs.webkit.org/show_bug.cgi?id=194866 Reviewed by Antti Koivisto. r241788 removed some calls that updated layer lists (normal flow and z-order) during compositing updates, causing a later call to RenderLayerCompositor::recursiveRepaintLayer() to assert when the lists were dirty. Fix by updating the lists in RenderLayerCompositor::recursiveRepaintLayer(), as we do in various other places. * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::recursiveRepaintLayer): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241830 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-20 Simon Fraser REGRESSION (r241788>): ASSERTION FAILED: !m_normalFlowListDirty in TestWebKitAPI.WebKit.ResizeReversePaginatedWebView test https://bugs.webkit.org/show_bug.cgi?id=194866 Reviewed by Antti Koivisto. r241788 removed some calls that updated layer lists (normal flow and z-order) during compositing updates, causing a later call to RenderLayerCompositor::recursiveRepaintLayer() to assert when the lists were dirty. Fix by updating the lists in RenderLayerCompositor::recursiveRepaintLayer(), as we do in various other places. * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::recursiveRepaintLayer): 2019-02-21 Alan Coon Apply patch. rdar://problem/48229545 2019-02-21 Ryosuke Niwa REGRESSION(r240909): Release assertion in FrameLoader::loadPostRequest when opening new window https://bugs.webkit.org/show_bug.cgi?id=194820 Reviewed by Geoffrey Garen and Brady Eidson. This release assertion was wrong. The invocation of PolicyChecker::checkNewWindowPolicy in FrameLoader doesn’t require PolicyChecker's load type to be set in PolicyChecker because FrameLoader's continueLoadAfterNewWindowPolicy invokes loadWithNavigationAction which sets the load type later, and we don't rely on PolicyChecker's load type until then. Fixed the crash by removing relese asserts before invoking checkNewWindowPolicy accordingly. This patch reverts r241015 since it too was asserting that PolicyChecker's load type is set before invoking checkNewWindowPolicy which is not the right assumption. Test: fast/loader/navigate-with-post-to-new-target-after-back-forward-navigation.html * loader/FrameLoader.cpp: (WebCore::FrameLoader::loadURL): (WebCore::FrameLoader::load): (WebCore::FrameLoader::loadPostRequest): 2019-02-20 Alan Coon Cherry-pick r241848. rdar://problem/48257838 Crash in DOMWindowExtension::suspendForPageCache https://bugs.webkit.org/show_bug.cgi?id=194871 Reviewed by Chris Dumez. This is a speculative fix for a crash in DOMWindowExtension::suspendForPageCache. We think it's possible for DOMWindowExtension::suspendForPageCache notifying the clients via dispatchWillDisconnectDOMWindowExtensionFromGlobalObject to remove other DOMWindowExtension's. Check that each DOMWindowProperty is still in m_properties before invoking suspendForPageCache to avoid the crash. * page/DOMWindow.cpp: (WebCore::DOMWindow::willDestroyCachedFrame): (WebCore::DOMWindow::willDestroyDocumentInFrame): (WebCore::DOMWindow::willDetachDocumentFromFrame): (WebCore::DOMWindow::suspendForPageCache): (WebCore::DOMWindow::resumeFromPageCache): * page/DOMWindowExtension.cpp: (WebCore::DOMWindowExtension::suspendForPageCache): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241848 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-20 Ryosuke Niwa Crash in DOMWindowExtension::suspendForPageCache https://bugs.webkit.org/show_bug.cgi?id=194871 Reviewed by Chris Dumez. This is a speculative fix for a crash in DOMWindowExtension::suspendForPageCache. We think it's possible for DOMWindowExtension::suspendForPageCache notifying the clients via dispatchWillDisconnectDOMWindowExtensionFromGlobalObject to remove other DOMWindowExtension's. Check that each DOMWindowProperty is still in m_properties before invoking suspendForPageCache to avoid the crash. * page/DOMWindow.cpp: (WebCore::DOMWindow::willDestroyCachedFrame): (WebCore::DOMWindow::willDestroyDocumentInFrame): (WebCore::DOMWindow::willDetachDocumentFromFrame): (WebCore::DOMWindow::suspendForPageCache): (WebCore::DOMWindow::resumeFromPageCache): * page/DOMWindowExtension.cpp: (WebCore::DOMWindowExtension::suspendForPageCache): 2019-02-20 Alan Coon Cherry-pick r241788. rdar://problem/48248202 REGRESSION (r238090): Toggling visibility on the element can result in a blank web view https://bugs.webkit.org/show_bug.cgi?id=194827 rdar://problem/47620594 Reviewed by Antti Koivisto. Source/WebCore: Incremental compositing updates, added in rr238090, use repaints as a trigger for re-evaluating layer configurations, since a repaint implies that a layer gains painted content. This is done via the call to setNeedsCompositingConfigurationUpdate() in RenderLayerBacking::setContentsNeedDisplay{InRect}. The RenderView's layer is opted out of this to avoid doing lots of redundant layer config recomputation for the root. The configuration state that matters here is whether the layer contains painted content, and therefore needs backing store; this is computed by RenderLayerBacking::isSimpleContainerCompositingLayer(), and feeds into GraphicsLayer::drawsContent(). However, if starts as "visibility:hidden" or "opacity:0", as some sites do to hide incremental loading, then we'll fail to recompute 'drawsContent' for the root and leave the root with drawsContent=false, which causes RenderLayerBacking::setContentsNeedDisplay{InRect} to short-circuit, and then we paint nothing. Ironically, 'drawsContent' doesn't actually save any backing store for the root, since it has no affect on the root tile caches; we always make tiles. So the simple fix here is to change RenderLayerBacking::isSimpleContainerCompositingLayer() to always return false for the RenderView's layer (the root). Testing this was tricky; ref testing doesn't work because we force repaint, and we normally skip properties of the root in layer tree dumps to hide WK1/WK2 differences. Therefore I had to add LAYER_TREE_INCLUDES_ROOT_LAYER_PROPERTIES and fix RenderLayerBacking::shouldDumpPropertyForLayer to respect it. Test: compositing/visibility/root-visibility-toggle.html * page/Frame.h: * platform/graphics/GraphicsLayer.cpp: (WebCore::GraphicsLayer::dumpProperties const): * platform/graphics/GraphicsLayerClient.h: (WebCore::GraphicsLayerClient::shouldDumpPropertyForLayer const): * rendering/RenderLayerBacking.cpp: (WebCore::RenderLayerBacking::isSimpleContainerCompositingLayer const): (WebCore::RenderLayerBacking::shouldDumpPropertyForLayer const): * rendering/RenderLayerBacking.h: * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::layerTreeAsText): * testing/Internals.cpp: (WebCore::toLayerTreeFlags): * testing/Internals.h: * testing/Internals.idl: LayoutTests: Test dumps layer tree with RenderLayerBacking::shouldDumpPropertyForLayer to show that the root has (drawsContent 1) * compositing/visibility/root-visibility-toggle-expected.txt: Added. * compositing/visibility/root-visibility-toggle.html: Added. * platform/mac-wk1/compositing/visibility/root-visibility-toggle-expected.txt: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241788 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-19 Simon Fraser REGRESSION (r238090): Toggling visibility on the element can result in a blank web view https://bugs.webkit.org/show_bug.cgi?id=194827 rdar://problem/47620594 Reviewed by Antti Koivisto. Incremental compositing updates, added in rr238090, use repaints as a trigger for re-evaluating layer configurations, since a repaint implies that a layer gains painted content. This is done via the call to setNeedsCompositingConfigurationUpdate() in RenderLayerBacking::setContentsNeedDisplay{InRect}. The RenderView's layer is opted out of this to avoid doing lots of redundant layer config recomputation for the root. The configuration state that matters here is whether the layer contains painted content, and therefore needs backing store; this is computed by RenderLayerBacking::isSimpleContainerCompositingLayer(), and feeds into GraphicsLayer::drawsContent(). However, if starts as "visibility:hidden" or "opacity:0", as some sites do to hide incremental loading, then we'll fail to recompute 'drawsContent' for the root and leave the root with drawsContent=false, which causes RenderLayerBacking::setContentsNeedDisplay{InRect} to short-circuit, and then we paint nothing. Ironically, 'drawsContent' doesn't actually save any backing store for the root, since it has no affect on the root tile caches; we always make tiles. So the simple fix here is to change RenderLayerBacking::isSimpleContainerCompositingLayer() to always return false for the RenderView's layer (the root). Testing this was tricky; ref testing doesn't work because we force repaint, and we normally skip properties of the root in layer tree dumps to hide WK1/WK2 differences. Therefore I had to add LAYER_TREE_INCLUDES_ROOT_LAYER_PROPERTIES and fix RenderLayerBacking::shouldDumpPropertyForLayer to respect it. Test: compositing/visibility/root-visibility-toggle.html * page/Frame.h: * platform/graphics/GraphicsLayer.cpp: (WebCore::GraphicsLayer::dumpProperties const): * platform/graphics/GraphicsLayerClient.h: (WebCore::GraphicsLayerClient::shouldDumpPropertyForLayer const): * rendering/RenderLayerBacking.cpp: (WebCore::RenderLayerBacking::isSimpleContainerCompositingLayer const): (WebCore::RenderLayerBacking::shouldDumpPropertyForLayer const): * rendering/RenderLayerBacking.h: * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::layerTreeAsText): * testing/Internals.cpp: (WebCore::toLayerTreeFlags): * testing/Internals.h: * testing/Internals.idl: 2019-02-20 Alan Coon Cherry-pick r241738. rdar://problem/48243338 Uncaught Exception crash in MediaPlayerPrivateAVFoundationObjC::setShouldObserveTimeControlStatus() https://bugs.webkit.org/show_bug.cgi?id=194786 Reviewed by Eric Carlson. Convert a runtime crash to a debug assert by wrapping the call to -[AVPlayer removeObserver:forKeyPath:] in an exception handler. * platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm: (WebCore::MediaPlayerPrivateAVFoundationObjC::setShouldObserveTimeControlStatus): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241738 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-18 Jer Noble Uncaught Exception crash in MediaPlayerPrivateAVFoundationObjC::setShouldObserveTimeControlStatus() https://bugs.webkit.org/show_bug.cgi?id=194786 Reviewed by Eric Carlson. Convert a runtime crash to a debug assert by wrapping the call to -[AVPlayer removeObserver:forKeyPath:] in an exception handler. * platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm: (WebCore::MediaPlayerPrivateAVFoundationObjC::setShouldObserveTimeControlStatus): 2019-02-20 Alan Coon Cherry-pick r241721. rdar://problem/48243376 AX: PSON: Going back from apple.com to search results, cannot interact with HTML content. Disabling Swap Processes on Cross-Site Navigation resolves the issue. https://bugs.webkit.org/show_bug.cgi?id=194742 Reviewed by Chris Dumez. Source/WebCore: With the new process model, WebProcess hits a case where it tries to send the "page loaded" notification before VoiceOver had a chance to register for any notifications. This leads to those notifications being dropped (and thus this bug). This change instead asks the UIProcess to send the notification, which we know VoiceOver has registered for, and can reliably receive notifications. It also sends the notification for "load failures," which to the VO users' perspective amounts to the same thing as a successful page load. * accessibility/mac/AXObjectCacheMac.mm: (WebCore::AXObjectCache::frameLoadingEventPlatformNotification): Source/WebKit: Re-initialize the accessibility web process tokens when swapping processes. Send page load notifications from the UIProcess instead of the WebProcess to improve reliability. * UIProcess/mac/PageClientImplMac.mm: (WebKit::PageClientImpl::didFinishLoadForMainFrame): (WebKit::PageClientImpl::didFailLoadForMainFrame): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::reinitializeWebPage): * WebProcess/WebPage/WebPage.h: * WebProcess/WebPage/gtk/WebPageGtk.cpp: (WebKit::WebPage::platformReinitialize): (WebKit::WebPage::platformDetach): Deleted. (WebKit::WebPage::platformEditorState const): Deleted. (WebKit::WebPage::updateAccessibilityTree): Deleted. (WebKit::WebPage::performDefaultBehaviorForKeyEvent): Deleted. (WebKit::WebPage::platformCanHandleRequest): Deleted. (WebKit::WebPage::platformUserAgent const): Deleted. (WebKit::WebPage::getCenterForZoomGesture): Deleted. (WebKit::WebPage::setInputMethodState): Deleted. (WebKit::WebPage::collapseSelectionInFrame): Deleted. * WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::platformReinitialize): * WebProcess/WebPage/mac/WebPageMac.mm: (WebKit::WebPage::platformReinitialize): * WebProcess/WebPage/win/WebPageWin.cpp: (WebKit::WebPage::platformReinitialize): * WebProcess/WebPage/wpe/WebPageWPE.cpp: (WebKit::WebPage::platformReinitialize): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241721 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-18 Chris Fleizach AX: PSON: Going back from apple.com to search results, cannot interact with HTML content. Disabling Swap Processes on Cross-Site Navigation resolves the issue. https://bugs.webkit.org/show_bug.cgi?id=194742 Reviewed by Chris Dumez. With the new process model, WebProcess hits a case where it tries to send the "page loaded" notification before VoiceOver had a chance to register for any notifications. This leads to those notifications being dropped (and thus this bug). This change instead asks the UIProcess to send the notification, which we know VoiceOver has registered for, and can reliably receive notifications. It also sends the notification for "load failures," which to the VO users' perspective amounts to the same thing as a successful page load. * accessibility/mac/AXObjectCacheMac.mm: (WebCore::AXObjectCache::frameLoadingEventPlatformNotification): 2019-02-20 Alan Coon Cherry-pick r241626. rdar://problem/48243415 Crash in the hit testing code via HTMLPlugInElement::isReplacementObscured() https://bugs.webkit.org/show_bug.cgi?id=194691 Reviewed by Simon Fraser. Source/WebCore: The crash was caused by HTMLPlugInElement::isReplacementObscured updating the document without updating the layout of ancestor documents (i.e. documents in which frame owner elements appear) even though it hit-tests against the top-level document's RenderView. Fixed the bug by updating the layout of the top-level document as needed. Test: plugins/unsupported-plugin-with-replacement-in-iframe-crash.html * html/HTMLPlugInElement.cpp: (WebCore::HTMLPlugInElement::isReplacementObscured): LayoutTests: Added a regression test. It hits the newly added debug assertion without the fix. * platform/mac-wk1/TestExpectations: Skip the test since DumpRenderTree doesn't support testRunner.setPluginSupportedMode. * plugins/unsupported-plugin-with-replacement-in-iframe-crash-expected.txt: Added. * plugins/unsupported-plugin-with-replacement-in-iframe-crash.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241626 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-15 Ryosuke Niwa Crash in the hit testing code via HTMLPlugInElement::isReplacementObscured() https://bugs.webkit.org/show_bug.cgi?id=194691 Reviewed by Simon Fraser. The crash was caused by HTMLPlugInElement::isReplacementObscured updating the document without updating the layout of ancestor documents (i.e. documents in which frame owner elements appear) even though it hit-tests against the top-level document's RenderView. Fixed the bug by updating the layout of the top-level document as needed. Test: plugins/unsupported-plugin-with-replacement-in-iframe-crash.html * html/HTMLPlugInElement.cpp: (WebCore::HTMLPlugInElement::isReplacementObscured): 2019-02-20 Alan Coon Cherry-pick r241567. rdar://problem/48243396 Web Inspector: Occasional crash under WebCore::CSSStyleSheet::item called from Inspector https://bugs.webkit.org/show_bug.cgi?id=194671 Patch by Joseph Pecoraro on 2019-02-14 Reviewed by Devin Rousso. * css/CSSStyleSheet.cpp: (WebCore::CSSStyleSheet::item): A crash may happen if the m_childRuleCSSOMWrappers Vector gets out of sync with the m_contents list of rules. In particular if the wrappers vector is shorter than the rule list. We tried exercising code paths that modify these lists but were not able to reproduce the crash. To avoid a crash we can make this access safer and avoid the original overflow. At the same time we will keep and promote the assertion that would catch the lists getting out of sync in debug builds. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241567 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-14 Joseph Pecoraro Web Inspector: Occasional crash under WebCore::CSSStyleSheet::item called from Inspector https://bugs.webkit.org/show_bug.cgi?id=194671 Reviewed by Devin Rousso. * css/CSSStyleSheet.cpp: (WebCore::CSSStyleSheet::item): A crash may happen if the m_childRuleCSSOMWrappers Vector gets out of sync with the m_contents list of rules. In particular if the wrappers vector is shorter than the rule list. We tried exercising code paths that modify these lists but were not able to reproduce the crash. To avoid a crash we can make this access safer and avoid the original overflow. At the same time we will keep and promote the assertion that would catch the lists getting out of sync in debug builds. 2019-02-20 Alan Coon Cherry-pick r241547. rdar://problem/48220627 Web Inspector: don't include accessibility role in DOM.Node object payloads https://bugs.webkit.org/show_bug.cgi?id=194623 Reviewed by Devin Rousso. Source/JavaScriptCore: Remove property of DOM.Node that is no longer being sent. * inspector/protocol/DOM.json: Source/WebCore: Accessibility properties are complicated to fetch at all the points where we want to build and push nodes immediately. Turning on AX often indirectly causes style recalc and layout. This is bad because we are often building nodes in the first place due to a DOM node tree update (i.e., NodeInserted). It turns out that DOM.getAccessibilityPropertiesForNode is called every time we display the computed role in the Elements Tab > Nodes Sidebar > Accessibility Section. So it is not necessary to collect this information in a problematic way when initially pushing the node, as it will be updated anyway. No new tests, no change in behavior. * inspector/agents/InspectorDOMAgent.cpp: (WebCore::InspectorDOMAgent::buildObjectForNode): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241547 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-13 Brian Burg Web Inspector: don't include accessibility role in DOM.Node object payloads https://bugs.webkit.org/show_bug.cgi?id=194623 Reviewed by Devin Rousso. Accessibility properties are complicated to fetch at all the points where we want to build and push nodes immediately. Turning on AX often indirectly causes style recalc and layout. This is bad because we are often building nodes in the first place due to a DOM node tree update (i.e., NodeInserted). It turns out that DOM.getAccessibilityPropertiesForNode is called every time we display the computed role in the Elements Tab > Nodes Sidebar > Accessibility Section. So it is not necessary to collect this information in a problematic way when initially pushing the node, as it will be updated anyway. No new tests, no change in behavior. * inspector/agents/InspectorDOMAgent.cpp: (WebCore::InspectorDOMAgent::buildObjectForNode): 2019-02-20 Alan Coon Cherry-pick r241492. rdar://problem/48243254 [Mac] PiP window can get "stuck" if PiP is closed while Safari window is minimized. https://bugs.webkit.org/show_bug.cgi?id=194621 Reviewed by Eric Carlson. When Safari is minimized, no rAF() requests are executed. Don't gate responding to presentation change events in the media-controller.js on rAF(). * Modules/modern-media-controls/media/media-controller.js: (MediaController.prototype._returnMediaLayerToInlineIfNeeded): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241492 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-13 Jer Noble [Mac] PiP window can get "stuck" if PiP is closed while Safari window is minimized. https://bugs.webkit.org/show_bug.cgi?id=194621 Reviewed by Eric Carlson. When Safari is minimized, no rAF() requests are executed. Don't gate responding to presentation change events in the media-controller.js on rAF(). * Modules/modern-media-controls/media/media-controller.js: (MediaController.prototype._returnMediaLayerToInlineIfNeeded): 2019-02-20 Alan Coon Revert r237978. rdar://problem/48244945 2019-02-18 Babak Shafiei Apply patch. rdar://problem/48122553 Introduce a WebContent Process cache https://bugs.webkit.org/show_bug.cgi?id=194594 Reviewed by Geoff Garen. Source/WebCore: Update localizable strings. * en.lproj/Localizable.strings: Source/WebKit: Introduce a WebContent Process cache to reduce the number of process launches when process swap on navigation is enabled, and to reduce the power cost of the feature. If a WebProcess loaded pages from a single registrable domain then it is eligible for the cache. When process-swapping on navigation to a new registrable domain, we now attempt to retrieve a process from the cache for the domain in question instead of always launching a new one. The WebProcess cache currently has the following attributes: - It may contains 4 processes per GB of RAM the machine has, up to 30 processes. - WebProcesses automatically get evicted from the cache after 30 minutes. - If the application is no longer the active app, then the cache will get cleared after 5 minutes. - WebProcesses that are in the cache are reported as "(Cached)" in Activity Monitor. The WebProcess cache is currently disabled by default and can by enabled by the client via SPI. * Shared/WebBackForwardListItem.cpp: (WebKit::WebBackForwardListItem::WebBackForwardListItem): * Shared/WebBackForwardListItem.h: (WebKit::WebBackForwardListItem::lastProcessIdentifier const): (WebKit::WebBackForwardListItem::setLastProcessIdentifier): Add new lastProcessIdentifier data member that reflects which process this item was last loaded in. It is normally identical to the identifier of the process that created the item but it gets overriden in case of cross-site client-side redirect, since a new process takes over the item in this case. * Sources.txt: Add new source file. * UIProcess/API/APIProcessPoolConfiguration.cpp: (API::ProcessPoolConfiguration::copy): * UIProcess/API/APIProcessPoolConfiguration.h: * UIProcess/API/C/WKContextConfigurationRef.cpp: (WKContextConfigurationUsesWebProcessCache): (WKContextConfigurationSetUsesWebProcessCache): * UIProcess/API/C/WKContextConfigurationRef.h: * UIProcess/API/Cocoa/_WKProcessPoolConfiguration.h: * UIProcess/API/Cocoa/_WKProcessPoolConfiguration.mm: (-[_WKProcessPoolConfiguration setUsesWebProcessCache:]): (-[_WKProcessPoolConfiguration usesWebProcessCache]): Add new SPI to enable the WebProcess cache. * UIProcess/API/Cocoa/WKProcessPool.mm: (-[WKProcessPool _webProcessCountIgnoringPrewarmedAndCached]): * UIProcess/API/Cocoa/WKProcessPoolPrivate.h: Add new SPI for testing which returns the number of WebProcesses ignoring both prewarmed and cached ones. * UIProcess/Cocoa/WebProcessPoolCocoa.mm: (WebKit::WebProcessPool::registerNotificationObservers): (WebKit::WebProcessPool::unregisterNotificationObservers): Add application active state observers as the WebProcess cache gets cleared when the application resigns active state for more than 5 minutes. * UIProcess/ProvisionalPageProxy.cpp: (WebKit::ProvisionalPageProxy::loadRequest): When doing a load in a new process with the BackForwardList locked (i.e. client-side redirect), make sure we update the last process identifier for the BackForwardListItem. This is important because the logic in WebProcessPool::processForNavigation() relies on this identifier to select which process to do the history navigation into, and we want to do the load in the post-redirect process, not the pre-redirect one. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared): Tell the WebProcess whenever a main frame provisional load is started, providing the URL. * UIProcess/WebProcessCache.cpp: Added. (WebKit::WebProcessCache::WebProcessCache): (WebKit::WebProcessCache::addProcess): (WebKit::WebProcessCache::takeProcess): (WebKit::WebProcessCache::updateMaximumSize): (WebKit::WebProcessCache::clear): (WebKit::WebProcessCache::setApplicationIsActive): (WebKit::WebProcessCache::evictProcess): (WebKit::WebProcessCache::CachedProcess::CachedProcess): (WebKit::WebProcessCache::CachedProcess::~CachedProcess): (WebKit::WebProcessCache::CachedProcess::takeProcess): (WebKit::WebProcessCache::CachedProcess::evictionTimerFired): * UIProcess/WebProcessCache.h: Added. (WebKit::WebProcessCache::maximumSize): (WebKit::WebProcessCache::size const): (WebKit::WebProcessCache::CachedProcess::process): Add process cache implementation. * UIProcess/WebProcessPool.cpp: (WebKit::m_webProcessCache): WebProcessCache is stored on the WebProcessPool via m_webProcessCache data member. (WebKit::WebProcessPool::~WebProcessPool): Clear the WebProcess cache in the destructor. (WebKit::WebProcessPool::setApplicationIsActive): Notify the WebProcessCache whenever the application's active state changes. (WebKit::WebProcessPool::createWebPage): If the state of PSON changes via the experimental features menu, dynamically update the WebProcessCache's size. This is needed because the cache is disabled when PSON is disabled. (WebKit::WebProcessPool::handleMemoryPressureWarning): Clear the WebProcess cache on memory pressure. (WebKit::WebProcessPool::processForNavigationInternal): Query the WebProcessCache before attempting to create a new WebProcess for a cross-site navigation. (WebKit::WebProcessPool::findReusableSuspendedPageProcess): This logic was split out of processForNavigationInternal() to reduce the size of the method. * UIProcess/WebProcessPool.h: * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::setIsInProcessCache): Update the isInProcessCache flag on the WebProcessProxy and send an IPC to the WebContent process so that it can update its name in Activity Monitor. We also need to stop holding a strong reference to the WebProcessPool whenever the process is in the cache, similarly to what we do for pre-warmed processes, given that such processes should not keep the process pool alive. (WebKit::WebProcessProxy::addExistingWebPage): Assert that we never try to add a page to a cached process, it should be taken out of the cache before use. (WebKit::WebProcessProxy::hasProvisionalPageWithID const): (WebKit::WebProcessProxy::isAllowedToUpdateBackForwardItem const): (WebKit::WebProcessProxy::updateBackForwardItem): In case of client-side redirects, the previous process would sometimes send an IPC causing the UIProcess' backforward list item to get updated with the pre-redirect URL after we've already redirected. This previously would be unlikely to occur because we do not suspend client-redirect pages and their process would normally exit before getting a chance to send the IPC. However, with the process cache, the bug became obvious as the process would stay alive and send up the "bad" IPC. To address the issue, we now only let the IPC update the item if the item's page is (still) associated with the process. In the future, we may want to update the IPC so that it gets sent to the WebPageProxy instead of the WebProcessProxy. (WebKit::WebProcessProxy::processDidTerminateOrFailedToLaunch): If a cached WebProcess crashes, remove it from the cache so that we do not attempt to use it for a load later. (WebKit::WebProcessProxy::canBeAddedToWebProcessCache const): Only cache WebProcesses that have loaded a single registrable domain. Also prevent caching for service worker and inspector processes. (WebKit::WebProcessProxy::maybeShutDown): If the process is cacheable, add it to the cache instead of shutting it down right away. (WebKit::WebProcessProxy::canTerminateAuxiliaryProcess): Make sure we do not attempt to terminate a processes that is in the cache. (WebKit::WebProcessProxy::didStartProvisionalLoadForMainFrame): Whenever a main frame provisional load starts, make sure we update the process's associated registrable domain. nullopt indicates that there is no associated domain yet. Null string indicates that the process is associated with several registrable domain and is therefore not eligible for caching. * UIProcess/WebProcessProxy.h: (WebKit::WebProcessProxy::registrableDomain const): (WebKit::WebProcessProxy::isInProcessCache const): (WebKit::WebProcessProxy::provisionalPageCount const): Add convenience getters. * WebKit.xcodeproj/project.pbxproj: Add new files to project. * WebProcess/WebProcess.cpp: (WebKit::WebProcess::setIsInProcessCache): * WebProcess/WebProcess.h: * WebProcess/WebProcess.messages.in: * WebProcess/cocoa/WebProcessCocoa.mm: (WebKit::WebProcess::updateProcessName): Update the WebProcess' name in Activity Monitor whenever it goes into or out of the WebProcess cache. Tools: Update API tests to turn on the WebContent Process cache. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@241556 268f45cc-cd09-0410-ab3c-d52691b4dbfc (cherry picked from commit dc197d35fd5d947ff4c81c2e0f5636b9cad36b3c) 2019-02-14 Chris Dumez [PSON] Introduce a WebContent Process cache https://bugs.webkit.org/show_bug.cgi?id=194594 Reviewed by Geoff Garen. Update localizable strings. * en.lproj/Localizable.strings: 2019-02-13 Babak Shafiei Cherry-pick r241499. rdar://problem/48065634 Crash in DOMTimer::fired https://bugs.webkit.org/show_bug.cgi?id=194638 Reviewed by Brent Fulgham. Source/WebCore: This patch continues the saga of hunting down timer related crashes after r239814, r225985, r227934. The crash was caused by the bug that we don't remove a DOMTimer from NestedTimersMap if a DOMTimer is created & installed inside another DOMTimer's callback (via execute call in DOMTimer::fired). Fixed the crash by using a Ref in NestedTimersMap. This will keep the timer alive until we exit from DOMTimer::fired. Because DOMTimer::fired always calls stopTracking() which clears the map we would not leak these DOM timers. We could, alternatively, use WeakPtr in NestedTimersMap but that would unnecessarily increase the size of DOMTimer for a very marginal benefit of DOMTimer objcets being deleted slightly earlier. Deleting itself in DOMTimer's destructor involves more logic & house keeping in the timer code, and is no longer the preferred approach when dealing with these classes of bugs in WebKit. Test: fast/dom/timer-destruction-during-firing.html * page/DOMTimer.cpp: (WebCore::NestedTimersMap::add): (WebCore::DOMTimer::install): (WebCore::DOMTimer::fired): LayoutTests: Added a regression test. It needs debug assertions without the fix. * fast/dom/timer-destruction-during-firing-expected.txt: Added. * fast/dom/timer-destruction-during-firing.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241499 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-13 Ryosuke Niwa Crash in DOMTimer::fired https://bugs.webkit.org/show_bug.cgi?id=194638 Reviewed by Brent Fulgham. This patch continues the saga of hunting down timer related crashes after r239814, r225985, r227934. The crash was caused by the bug that we don't remove a DOMTimer from NestedTimersMap if a DOMTimer is created & installed inside another DOMTimer's callback (via execute call in DOMTimer::fired). Fixed the crash by using a Ref in NestedTimersMap. This will keep the timer alive until we exit from DOMTimer::fired. Because DOMTimer::fired always calls stopTracking() which clears the map we would not leak these DOM timers. We could, alternatively, use WeakPtr in NestedTimersMap but that would unnecessarily increase the size of DOMTimer for a very marginal benefit of DOMTimer objcets being deleted slightly earlier. Deleting itself in DOMTimer's destructor involves more logic & house keeping in the timer code, and is no longer the preferred approach when dealing with these classes of bugs in WebKit. Test: fast/dom/timer-destruction-during-firing.html * page/DOMTimer.cpp: (WebCore::NestedTimersMap::add): (WebCore::DOMTimer::install): (WebCore::DOMTimer::fired): 2019-02-13 Babak Shafiei Cherry-pick r241494. rdar://problem/48065624 AX: Crash in handleMenuOpen https://bugs.webkit.org/show_bug.cgi?id=194627 Reviewed by Zalan Bujtas. Tests run under libGuardMalloc will cause crashes. This list of objects is a Node list, not an Element list, so we were not removing some nodes when they were being deallocated. * accessibility/AXObjectCache.cpp: (WebCore::AXObjectCache::remove): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241494 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-13 Chris Fleizach AX: Crash in handleMenuOpen https://bugs.webkit.org/show_bug.cgi?id=194627 Reviewed by Zalan Bujtas. Tests run under libGuardMalloc will cause crashes. This list of objects is a Node list, not an Element list, so we were not removing some nodes when they were being deallocated. * accessibility/AXObjectCache.cpp: (WebCore::AXObjectCache::remove): 2019-02-13 Babak Shafiei Cherry-pick r241484. rdar://problem/48065620 Entering fullscreen inside a shadow root will not set fullscreen pseudoclasses outside of root https://bugs.webkit.org/show_bug.cgi?id=194516 Reviewed by Antoine Quint. Source/WebCore: Test: fast/shadow-dom/fullscreen-in-shadow-full-screen-ancestor.html When walking up the element ancestor chain, use parentElementInComposedTree() to walk past the shadow root boundary. * dom/Element.cpp: (WebCore::parentCrossingFrameBoundaries): LayoutTests: * fast/shadow-dom/fullscreen-in-shadow-full-screen-ancestor-expected.txt: Added. * fast/shadow-dom/fullscreen-in-shadow-full-screen-ancestor.html: Added. * platform/ios-wk2/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241484 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-13 Jer Noble Entering fullscreen inside a shadow root will not set fullscreen pseudoclasses outside of root https://bugs.webkit.org/show_bug.cgi?id=194516 Reviewed by Antoine Quint. Test: fast/shadow-dom/fullscreen-in-shadow-full-screen-ancestor.html When walking up the element ancestor chain, use parentElementInComposedTree() to walk past the shadow root boundary. * dom/Element.cpp: (WebCore::parentCrossingFrameBoundaries): 2019-02-13 Babak Shafiei Cherry-pick r241480. rdar://problem/48065618 Further restricting webarchive loads https://bugs.webkit.org/show_bug.cgi?id=194567 Reviewed by Youenn Fablet. Source/WebCore: This patch futher restricts main frame webarchive loads to the followings: 1) loaded by clients; 2) loaded by drag; 3) reloaded from any of the previous two. It moves setAlwaysAllowLocalWebarchive, which is used for testing only, from Document to FrameLoader such that the option is remembered during redirections. Covered by API tests. * dom/Document.h: (WebCore::Document::setAlwaysAllowLocalWebarchive): Deleted. (WebCore::Document::alwaysAllowLocalWebarchive const): Deleted. * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::disallowWebArchive const): * loader/DocumentLoader.h: (WebCore::DocumentLoader::setAllowsWebArchiveForMainFrame): (WebCore::DocumentLoader::allowsWebArchiveForMainFrame): * loader/FrameLoadRequest.h: (WebCore::FrameLoadRequest::setIsRequestFromClientOrUserInput): (WebCore::FrameLoadRequest::isRequestFromClientOrUserInput): * loader/FrameLoader.cpp: (WebCore::FrameLoader::load): (WebCore::FrameLoader::reload): * loader/FrameLoader.h: (WebCore::FrameLoader::setAlwaysAllowLocalWebarchive): (WebCore::FrameLoader::alwaysAllowLocalWebarchive const): * page/DragController.cpp: (WebCore::DragController::performDragOperation): * testing/Internals.cpp: (WebCore::Internals::setAlwaysAllowLocalWebarchive const): * testing/Internals.h: * testing/Internals.idl: Source/WebKit: * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::loadRequest): Set a flag to indicate a load is started from clients. Tools: Besides adding API tests, this patch also enhances DragAndDropSimulator to allow navigations on drop. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/mac/LoadWebArchive.mm: Added. (-[TestLoadWebArchiveNavigationDelegate webView:didFinishNavigation:]): (-[TestLoadWebArchiveNavigationDelegate webView:didFailProvisionalNavigation:withError:]): (-[TestLoadWebArchiveNavigationDelegate webView:createWebViewWithConfiguration:forNavigationAction:windowFeatures:]): (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/mac/helloworld.webarchive: Added. * TestWebKitAPI/Tests/mac/load-web-archive-1.html: Added. * TestWebKitAPI/Tests/mac/load-web-archive-2.html: Added. * TestWebKitAPI/cocoa/DragAndDropSimulator.h: * TestWebKitAPI/mac/DragAndDropSimulatorMac.mm: (-[DragAndDropSimulator initWithWebViewFrame:configuration:]): (-[DragAndDropSimulator _webView:dragDestinationActionMaskForDraggingInfo:]): LayoutTests: * platform/mac/fast/loader/webarchive-encoding-respected.html: * webarchive/loading/cache-expired-subresource.html: * webarchive/loading/javascript-url-iframe-crash.html: * webarchive/loading/mainresource-null-mimetype-crash.html: * webarchive/loading/missing-data.html: * webarchive/loading/object.html: * webarchive/loading/test-loading-archive-subresource-null-mimetype.html: * webarchive/loading/test-loading-archive-subresource.html: * webarchive/loading/test-loading-archive.html: * webarchive/loading/test-loading-top-archive.html: * webarchive/loading/video-in-webarchive.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241480 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-12 Jiewen Tan Further restricting webarchive loads https://bugs.webkit.org/show_bug.cgi?id=194567 Reviewed by Youenn Fablet. This patch futher restricts main frame webarchive loads to the followings: 1) loaded by clients; 2) loaded by drag; 3) reloaded from any of the previous two. It moves setAlwaysAllowLocalWebarchive, which is used for testing only, from Document to FrameLoader such that the option is remembered during redirections. Covered by API tests. * dom/Document.h: (WebCore::Document::setAlwaysAllowLocalWebarchive): Deleted. (WebCore::Document::alwaysAllowLocalWebarchive const): Deleted. * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::disallowWebArchive const): * loader/DocumentLoader.h: (WebCore::DocumentLoader::setAllowsWebArchiveForMainFrame): (WebCore::DocumentLoader::allowsWebArchiveForMainFrame): * loader/FrameLoadRequest.h: (WebCore::FrameLoadRequest::setIsRequestFromClientOrUserInput): (WebCore::FrameLoadRequest::isRequestFromClientOrUserInput): * loader/FrameLoader.cpp: (WebCore::FrameLoader::load): (WebCore::FrameLoader::reload): * loader/FrameLoader.h: (WebCore::FrameLoader::setAlwaysAllowLocalWebarchive): (WebCore::FrameLoader::alwaysAllowLocalWebarchive const): * page/DragController.cpp: (WebCore::DragController::performDragOperation): * testing/Internals.cpp: (WebCore::Internals::setAlwaysAllowLocalWebarchive const): * testing/Internals.h: * testing/Internals.idl: 2019-02-13 Babak Shafiei Cherry-pick r241479. rdar://problem/48065642 Null-deref crash at SourceBufferPrivateAVFObjC::outputObscuredDueToInsufficientExternalProtectionChanged() https://bugs.webkit.org/show_bug.cgi?id=194613 Reviewed by Eric Carlson. * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm: (WebCore::SourceBufferPrivateAVFObjC::outputObscuredDueToInsufficientExternalProtectionChanged): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241479 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-13 Jer Noble Null-deref crash at SourceBufferPrivateAVFObjC::outputObscuredDueToInsufficientExternalProtectionChanged() https://bugs.webkit.org/show_bug.cgi?id=194613 Reviewed by Eric Carlson. * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm: (WebCore::SourceBufferPrivateAVFObjC::outputObscuredDueToInsufficientExternalProtectionChanged): 2019-02-13 Babak Shafiei Cherry-pick r241437. rdar://problem/48065626 [Cocoa] Switch to CVPixelBufferGetBytesPerRow() for calculating CVPixelBuffer base address size. https://bugs.webkit.org/show_bug.cgi?id=194580 Reviewed by Eric Carlson. * platform/cocoa/CoreVideoSoftLink.cpp: * platform/cocoa/CoreVideoSoftLink.h: * platform/graphics/cv/PixelBufferConformerCV.cpp: (WebCore::CVPixelBufferGetBytePointerCallback): (WebCore::PixelBufferConformerCV::createImageFromPixelBuffer): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241437 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-13 Jer Noble [Cocoa] Switch to CVPixelBufferGetBytesPerRow() for calculating CVPixelBuffer base address size. https://bugs.webkit.org/show_bug.cgi?id=194580 Reviewed by Eric Carlson. * platform/cocoa/CoreVideoSoftLink.cpp: * platform/cocoa/CoreVideoSoftLink.h: * platform/graphics/cv/PixelBufferConformerCV.cpp: (WebCore::CVPixelBufferGetBytePointerCallback): (WebCore::PixelBufferConformerCV::createImageFromPixelBuffer): 2019-02-13 Alan Coon Cherry-pick r241319. rdar://problem/48015672 Source/WebCore: Remove setDefersLoading infrastructure from WebKit2 https://bugs.webkit.org/show_bug.cgi?id=194506 Patch by Alex Christensen on 2019-02-12 Reviewed by Brady Eidson. setDefersLoading is inherently racy from WebCore to the NetworkProcess, it adds unwanted complexity to the initialization and use of network objects, and it has led to many unrecoverable hang bugs over the years. We needed to force it into WebKit2 to transition some existing clients who relied on it, but we have recently finished transitioning those clients to other solutions, mostly completion handlers. * inspector/PageScriptDebugServer.cpp: (WebCore::PageScriptDebugServer::setJavaScriptPaused): LayoutTests: BitmapRenderer should handle existing ImageBuffers https://bugs.webkit.org/show_bug.cgi?id=194555 Reviewed by Tim Horton. Test that creates a canvas, triggers an ImageBuffer to be created, then creates the bitmaprenderer context. * fast/canvas/bitmaprenderer-created-after-toBlob-expected.txt: Added. * fast/canvas/bitmaprenderer-created-after-toBlob.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241319 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-12 Dean Jackson BitmapRenderer should handle existing ImageBuffers https://bugs.webkit.org/show_bug.cgi?id=194555 Reviewed by Tim Horton. Our logic in ImageBitmapRenderingContext assumed that it had always created the ImageBuffer being used. However, it's valid to call something like toBlob() or toDataURL() before creating a context, so we need to handle the case where an ImageBuffer already exists. Test: fast/canvas/bitmaprenderer-created-after-toBlob.html * html/HTMLCanvasElement.cpp: (WebCore::HTMLCanvasElement::createImageBuffer const): Move some logic into setImageBuffer. (WebCore::HTMLCanvasElement::setImageBuffer const): Make sure to clear the state saver. 2019-02-13 Alan Coon Cherry-pick r241300. rdar://problem/48016008 Add some null checks in JSNodeCustom.h's root() and generated isReachableFromOpaqueRoots() functions. https://bugs.webkit.org/show_bug.cgi?id=194530 Reviewed by Chris Dumez. This is needed to fix a null pointer dereference that arises from the following scenario: 1. a Document detaches from its StyleSheetList. 2. the JSStyleSheetList that is associated with the detached StyleSheetList has yet to be scanned and collected by the GC. 3. the GC eventually looks for the opaque root of the StyleSheetList's owner, and discovers a null owner pointer. This patch fixes this issue by applying the following null checks: 1. Add a null check in JSNodeCustom.h's root(). root() is called from a isReachableFromOpaqueRoots() generated by CodeGeneratorJS.pm. isReachableFromOpaqueRoots() calls a ownerNode() method and passes its result to root(). However, depending on which class the ownerNode() method belongs to, it can either return a pointer or a reference. The null check only makes sense in the pointer case. To accommodate the 2 forms, root() itself is has an overload that takes a reference instead of a pointer. Since CodeGeneratorJS.pm can't tell what the generated class' ownerNode() returns, it can't discern when the result is a pointer and apply the null check. Instead, we just add the null check to the version of root() that takes a pointer. If the node pointer is null, we'll return a null opaque root. 2. Fix CodeGeneratorJS.pm to null check the opaque root before using it. * bindings/js/JSNodeCustom.h: (WebCore::root): * bindings/scripts/CodeGeneratorJS.pm: (GenerateImplementation): * bindings/scripts/test/JS/JSTestGenerateIsReachable.cpp: (WebCore::JSTestGenerateIsReachableOwner::isReachableFromOpaqueRoots): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241300 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-12 Mark Lam Add some null checks in JSNodeCustom.h's root() and generated isReachableFromOpaqueRoots() functions. https://bugs.webkit.org/show_bug.cgi?id=194530 Reviewed by Chris Dumez. This is needed to fix a null pointer dereference that arises from the following scenario: 1. a Document detaches from its StyleSheetList. 2. the JSStyleSheetList that is associated with the detached StyleSheetList has yet to be scanned and collected by the GC. 3. the GC eventually looks for the opaque root of the StyleSheetList's owner, and discovers a null owner pointer. This patch fixes this issue by applying the following null checks: 1. Add a null check in JSNodeCustom.h's root(). root() is called from a isReachableFromOpaqueRoots() generated by CodeGeneratorJS.pm. isReachableFromOpaqueRoots() calls a ownerNode() method and passes its result to root(). However, depending on which class the ownerNode() method belongs to, it can either return a pointer or a reference. The null check only makes sense in the pointer case. To accommodate the 2 forms, root() itself is has an overload that takes a reference instead of a pointer. Since CodeGeneratorJS.pm can't tell what the generated class' ownerNode() returns, it can't discern when the result is a pointer and apply the null check. Instead, we just add the null check to the version of root() that takes a pointer. If the node pointer is null, we'll return a null opaque root. 2. Fix CodeGeneratorJS.pm to null check the opaque root before using it. * bindings/js/JSNodeCustom.h: (WebCore::root): * bindings/scripts/CodeGeneratorJS.pm: (GenerateImplementation): * bindings/scripts/test/JS/JSTestGenerateIsReachable.cpp: (WebCore::JSTestGenerateIsReachableOwner::isReachableFromOpaqueRoots): 2019-02-13 Alan Coon Cherry-pick r241296. rdar://problem/48015654 Crash in WebCore::ScrollingTree::updateTreeFromStateNode https://bugs.webkit.org/show_bug.cgi?id=194538 Reviewed by Zalan Bujtas. * page/scrolling/ScrollingTree.cpp: (WebCore::ScrollingTree::updateTreeFromStateNode): Make sure we don't leave node entry behind in m_nodeMap in case we failed to add it to the parent. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241296 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-12 Antti Koivisto Crash in WebCore::ScrollingTree::updateTreeFromStateNode https://bugs.webkit.org/show_bug.cgi?id=194538 Reviewed by Zalan Bujtas. * page/scrolling/ScrollingTree.cpp: (WebCore::ScrollingTree::updateTreeFromStateNode): Make sure we don't leave node entry behind in m_nodeMap in case we failed to add it to the parent. 2019-02-13 Alan Coon Cherry-pick r241289. rdar://problem/48015662 AXObjectCache::childrenChanged shouldn't update layout or style during another style recalc https://bugs.webkit.org/show_bug.cgi?id=182280 Reviewed by Alan Bujtas. Source/WebCore: Remove the possibility that changing children calls back into updating layout by handling children changes in a deferred manner. This follows the same architecture as many other deferred changes, but also requires us to check deferred changes in updateBackingStore, because things like aria-hidden changes won't trigger a layout, but will require us to update children. A few tests had to be modified to no longer change the tree and then check the children immediately. * accessibility/AXObjectCache.cpp: (WebCore::AXObjectCache::remove): (WebCore::AXObjectCache::childrenChanged): (WebCore::AXObjectCache::prepareForDocumentDestruction): (WebCore::AXObjectCache::performDeferredCacheUpdate): * accessibility/AXObjectCache.h: * accessibility/AccessibilityObject.cpp: (WebCore::AccessibilityObject::updateBackingStore): * accessibility/mac/WebAccessibilityObjectWrapperBase.mm: (convertToNSArray): (-[WebAccessibilityObjectWrapperBase updateObjectBackingStore]): LayoutTests: * accessibility/aria-hidden-update.html: * accessibility/aria-hidden-updates-alldescendants.html: * accessibility/image-load-on-delay.html: * accessibility/mac/aria-hidden-changes-for-non-ignored-elements.html: * accessibility/removed-anonymous-block-child-causes-crash.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241289 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-08 Chris Fleizach AXObjectCache::childrenChanged shouldn't update layout or style during another style recalc https://bugs.webkit.org/show_bug.cgi?id=182280 Reviewed by Alan Bujtas. Remove the possibility that changing children calls back into updating layout by handling children changes in a deferred manner. This follows the same architecture as many other deferred changes, but also requires us to check deferred changes in updateBackingStore, because things like aria-hidden changes won't trigger a layout, but will require us to update children. A few tests had to be modified to no longer change the tree and then check the children immediately. * accessibility/AXObjectCache.cpp: (WebCore::AXObjectCache::remove): (WebCore::AXObjectCache::childrenChanged): (WebCore::AXObjectCache::prepareForDocumentDestruction): (WebCore::AXObjectCache::performDeferredCacheUpdate): * accessibility/AXObjectCache.h: * accessibility/AccessibilityObject.cpp: (WebCore::AccessibilityObject::updateBackingStore): * accessibility/mac/WebAccessibilityObjectWrapperBase.mm: (convertToNSArray): (-[WebAccessibilityObjectWrapperBase updateObjectBackingStore]): 2019-02-13 Alan Coon Cherry-pick r241288. rdar://problem/47992210 [Cocoa] Ask platform for generic font family mappings https://bugs.webkit.org/show_bug.cgi?id=187723 Reviewed by Brent Fulgham. Source/WebCore: WebKit API allows setting the generic font families for the USCRIPT_COMMON script. When trying to style a character with a generic font family, we first look to see if we have a mapping for the particular script the character is rendered with, and if we don't find a match, we then check USCRIPT_COMMON. In the Cocoa ports, the only way families get set for non-USCRIPT_COMMON scripts (aka the only scripts which won't use the API families) is in SettingsBase::initializeDefaultFontFamilies(). That function only sets the families for the CJK scripts. The mappings inside SettingsBase are incorrect and conflict with our policy regarding user-installed fonts. Instead, we should be consulting with the platform for some of these mappings, by calling CTFontDescriptorCreateForCSSFamily(). However, the WebKit API still has to work to set the mappings for untagged content. Therefore, we use the system mappings for language-tagged content, and the API mappings for non-language-tagged content. This is a good balance that makes sure we always have a good mapping for every language, but API clients can still set the mappings, too. Test: fast/text/ja-sans-serif.html * css/CSSComputedStyleDeclaration.cpp: * css/CSSFontSelector.cpp: (WebCore::resolveGenericFamily): * css/parser/CSSPropertyParser.cpp: (WebCore::consumeFontFamily): * page/cocoa/SettingsBaseCocoa.mm: (WebCore::SettingsBase::initializeDefaultFontFamilies): (WebCore::osakaMonoIsInstalled): Deleted. * platform/graphics/FontDescription.cpp: (WebCore::FontDescription::platformResolveGenericFamily): * platform/graphics/FontDescription.h: * platform/graphics/cocoa/FontDescriptionCocoa.cpp: (WebCore::computeSpecializedChineseLocale): (WebCore::cachedSpecializedChineseLocale): (WebCore::languageChanged): (WebCore::FontDescription::platformResolveGenericFamily): * platform/graphics/cocoa/SystemFontDatabaseCoreText.cpp: (WebCore::SystemFontDatabaseCoreText::clear): (WebCore::genericFamily): (WebCore::SystemFontDatabaseCoreText::serifFamily): (WebCore::SystemFontDatabaseCoreText::sansSerifFamily): (WebCore::SystemFontDatabaseCoreText::cursiveFamily): (WebCore::SystemFontDatabaseCoreText::fantasyFamily): (WebCore::SystemFontDatabaseCoreText::monospaceFamily): * platform/graphics/cocoa/SystemFontDatabaseCoreText.h: Source/WebCore/PAL: * pal/spi/cocoa/CoreTextSPI.h: Source/WTF: Add an ENABLE in Platform. * wtf/Platform.h: Tools: Allow testing infrastructure to use fonts that are returned from CTFontDescriptorCreateForCSSFamily(). * DumpRenderTree/mac/DumpRenderTree.mm: (allowedFontFamilySet): * WebKitTestRunner/mac/TestControllerMac.mm: (WTR::allowedFontFamilySet): LayoutTests: Update the tests to work with this new model. * fast/text/international/font-fallback-to-common-script-expected.html: Removed. * fast/text/international/font-fallback-to-common-script.html: Removed. * fast/text/international/lang-sensitive-fonts-expected.html: * fast/text/international/lang-sensitive-fonts-xml-expected.html: * fast/text/international/lang-sensitive-fonts-xml.xhtml: * fast/text/international/lang-sensitive-fonts.html: * fast/text/international/locale-sensitive-fonts-expected.html: * fast/text/international/locale-sensitive-fonts.html: * fast/text/ja-sans-serif-expected-mismatch.html: Added. * fast/text/ja-sans-serif.html: Added. * platform/ios/fast/block/float/016-expected.txt: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241288 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-11 Myles C. Maxfield [Cocoa] Ask platform for generic font family mappings https://bugs.webkit.org/show_bug.cgi?id=187723 Reviewed by Brent Fulgham. WebKit API allows setting the generic font families for the USCRIPT_COMMON script. When trying to style a character with a generic font family, we first look to see if we have a mapping for the particular script the character is rendered with, and if we don't find a match, we then check USCRIPT_COMMON. In the Cocoa ports, the only way families get set for non-USCRIPT_COMMON scripts (aka the only scripts which won't use the API families) is in SettingsBase::initializeDefaultFontFamilies(). That function only sets the families for the CJK scripts. The mappings inside SettingsBase are incorrect and conflict with our policy regarding user-installed fonts. Instead, we should be consulting with the platform for some of these mappings, by calling CTFontDescriptorCreateForCSSFamily(). However, the WebKit API still has to work to set the mappings for untagged content. Therefore, we use the system mappings for language-tagged content, and the API mappings for non-language-tagged content. This is a good balance that makes sure we always have a good mapping for every language, but API clients can still set the mappings, too. Test: fast/text/ja-sans-serif.html * css/CSSComputedStyleDeclaration.cpp: * css/CSSFontSelector.cpp: (WebCore::resolveGenericFamily): * css/parser/CSSPropertyParser.cpp: (WebCore::consumeFontFamily): * page/cocoa/SettingsBaseCocoa.mm: (WebCore::SettingsBase::initializeDefaultFontFamilies): (WebCore::osakaMonoIsInstalled): Deleted. * platform/graphics/FontDescription.cpp: (WebCore::FontDescription::platformResolveGenericFamily): * platform/graphics/FontDescription.h: * platform/graphics/cocoa/FontDescriptionCocoa.cpp: (WebCore::computeSpecializedChineseLocale): (WebCore::cachedSpecializedChineseLocale): (WebCore::languageChanged): (WebCore::FontDescription::platformResolveGenericFamily): * platform/graphics/cocoa/SystemFontDatabaseCoreText.cpp: (WebCore::SystemFontDatabaseCoreText::clear): (WebCore::genericFamily): (WebCore::SystemFontDatabaseCoreText::serifFamily): (WebCore::SystemFontDatabaseCoreText::sansSerifFamily): (WebCore::SystemFontDatabaseCoreText::cursiveFamily): (WebCore::SystemFontDatabaseCoreText::fantasyFamily): (WebCore::SystemFontDatabaseCoreText::monospaceFamily): * platform/graphics/cocoa/SystemFontDatabaseCoreText.h: 2019-02-13 Alan Coon Cherry-pick r241231. rdar://problem/47971603 [Cocoa] CTLineGetGlyphRuns() might return nullptr https://bugs.webkit.org/show_bug.cgi?id=194467 Reviewed by Simon Fraser. Be somewhat defensive to try to make sure this sort of thing doesn't happen in the future. Covered by find/text/find-backwards.html * platform/graphics/mac/ComplexTextControllerCoreText.mm: (WebCore::ComplexTextController::collectComplexTextRunsForCharacters): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241231 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-08 Myles C. Maxfield [Cocoa] CTLineGetGlyphRuns() might return nullptr https://bugs.webkit.org/show_bug.cgi?id=194467 Reviewed by Simon Fraser. Be somewhat defensive to try to make sure this sort of thing doesn't happen in the future. Covered by find/text/find-backwards.html * platform/graphics/mac/ComplexTextControllerCoreText.mm: (WebCore::ComplexTextController::collectComplexTextRunsForCharacters): 2019-02-13 Alan Coon Cherry-pick r241203. rdar://problem/47971610 [WebVTT] Inline WebVTT styles should start with '::cue' https://bugs.webkit.org/show_bug.cgi?id=194227 Reviewed by Eric Carlson. Source/WebCore: Check that the CSS string starts with '::cue' and is successfully parsed before adding it to the CSS stylesheet list. Also, the caption preferences CSS string should start with '::cue', since it is added inside the video shadow root element. Test: media/track/track-cue-css.html * html/track/WebVTTParser.cpp: (WebCore::WebVTTParser::checkAndStoreStyleSheet): * page/CaptionUserPreferencesMediaAF.cpp: (WebCore::CaptionUserPreferencesMediaAF::captionsStyleSheetOverride const): LayoutTests: * media/track/captions-webvtt/css-styling.vtt: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241203 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-08 Per Arne Vollan [WebVTT] Inline WebVTT styles should start with '::cue' https://bugs.webkit.org/show_bug.cgi?id=194227 Reviewed by Eric Carlson. Check that the CSS string starts with '::cue' and is successfully parsed before adding it to the CSS stylesheet list. Also, the caption preferences CSS string should start with '::cue', since it is added inside the video shadow root element. Test: media/track/track-cue-css.html * html/track/WebVTTParser.cpp: (WebCore::WebVTTParser::checkAndStoreStyleSheet): * page/CaptionUserPreferencesMediaAF.cpp: (WebCore::CaptionUserPreferencesMediaAF::captionsStyleSheetOverride const): 2019-02-13 Alan Coon Cherry-pick r241200. rdar://problem/47971541 Running RTCRtpSender.getCapabilities("video") before initial offer breaks VP8 https://bugs.webkit.org/show_bug.cgi?id=194380 Reviewed by Eric Carlson. Source/WebCore: Set whether VP8 is supported at creation of the page. This ensures that any call creating a peer connection factory will end up supporting the runtime flag configuration. Add internal API to enable resetting the factory to enable proper testing. Covered by updated test. * Modules/mediastream/libwebrtc/LibWebRTCPeerConnectionBackend.cpp: (WebCore::createLibWebRTCPeerConnectionBackend): * page/Page.cpp: (WebCore::m_applicationManifest): * platform/mediastream/libwebrtc/LibWebRTCProvider.h: * testing/Internals.cpp: (WebCore::Internals::clearPeerConnectionFactory): * testing/Internals.h: * testing/Internals.idl: LayoutTests: * webrtc/video-mute-vp8-expected.txt: * webrtc/video-mute-vp8.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241200 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-08 Youenn Fablet Running RTCRtpSender.getCapabilities("video") before initial offer breaks VP8 https://bugs.webkit.org/show_bug.cgi?id=194380 Reviewed by Eric Carlson. Set whether VP8 is supported at creation of the page. This ensures that any call creating a peer connection factory will end up supporting the runtime flag configuration. Add internal API to enable resetting the factory to enable proper testing. Covered by updated test. * Modules/mediastream/libwebrtc/LibWebRTCPeerConnectionBackend.cpp: (WebCore::createLibWebRTCPeerConnectionBackend): * page/Page.cpp: (WebCore::m_applicationManifest): * platform/mediastream/libwebrtc/LibWebRTCProvider.h: * testing/Internals.cpp: (WebCore::Internals::clearPeerConnectionFactory): * testing/Internals.h: * testing/Internals.idl: 2019-02-13 Alan Coon Cherry-pick r241198. rdar://problem/47971587 [WebIDL] Support serializing sequences and FrozenArrays of non-interfaces https://bugs.webkit.org/show_bug.cgi?id=190997 Reviewed by Brent Fulgham. Source/WebCore: Support serializing sequences and FrozenArrays of types that aren't interfaces. This is needed to properly serialize PaymentAddress, which has a FrozenArray of DOMStrings. We should support serializing sequences of interfaces too, but that's slightly more complicated since it involves iterating the sequence and serializing each of its items. I left that as a follow-up task, since I don't see any IDLs that currently need this. We also don't support serializing sequences with the CachedAttribute or CustomGetter extended attributes, because WebIDL specifies that a new array should be created when converting an IDL sequence into an ECMAScript value. Added bindings test cases to TestSerialization.idl and PaymentAddress test cases to http/tests/paymentrequest/payment-address-attributes-and-toJSON-method.https.html. * bindings/scripts/CodeGenerator.pm: (GetInterfaceForType): Renamed from GetInterfaceForAttribute. (IsSerializableType): Modified to allow sequences and FrozenArrays of non-interface types. (hasCachedAttributeOrCustomGetterExtendedAttribute): Added a helper to determine if an attribute has the CachedAttribute or CustomGetter extended attributes. (IsSerializableAttribute): Checked for sequences with the CachedAttribute or CustomGetter extended attributes before calling IsSerializableType. (GetInterfaceForAttribute): Renamed to GetInterfaceForType. * bindings/scripts/test/JS/JSTestSerialization.cpp: * bindings/scripts/test/TestSerialization.idl: LayoutTests: * http/tests/paymentrequest/payment-address-attributes-and-toJSON-method.https.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241198 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-08 Andy Estes [WebIDL] Support serializing sequences and FrozenArrays of non-interfaces https://bugs.webkit.org/show_bug.cgi?id=190997 Reviewed by Brent Fulgham. Support serializing sequences and FrozenArrays of types that aren't interfaces. This is needed to properly serialize PaymentAddress, which has a FrozenArray of DOMStrings. We should support serializing sequences of interfaces too, but that's slightly more complicated since it involves iterating the sequence and serializing each of its items. I left that as a follow-up task, since I don't see any IDLs that currently need this. We also don't support serializing sequences with the CachedAttribute or CustomGetter extended attributes, because WebIDL specifies that a new array should be created when converting an IDL sequence into an ECMAScript value. Added bindings test cases to TestSerialization.idl and PaymentAddress test cases to http/tests/paymentrequest/payment-address-attributes-and-toJSON-method.https.html. * bindings/scripts/CodeGenerator.pm: (GetInterfaceForType): Renamed from GetInterfaceForAttribute. (IsSerializableType): Modified to allow sequences and FrozenArrays of non-interface types. (hasCachedAttributeOrCustomGetterExtendedAttribute): Added a helper to determine if an attribute has the CachedAttribute or CustomGetter extended attributes. (IsSerializableAttribute): Checked for sequences with the CachedAttribute or CustomGetter extended attributes before calling IsSerializableType. (GetInterfaceForAttribute): Renamed to GetInterfaceForType. * bindings/scripts/test/JS/JSTestSerialization.cpp: * bindings/scripts/test/TestSerialization.idl: 2019-02-13 Alan Coon Cherry-pick r241352. rdar://problem/48038900 Release assert in PolicyCheckIdentifier::isValidFor via WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction https://bugs.webkit.org/show_bug.cgi?id=194582 Reviewed by Antti Koivisto. Source/WebCore: Check the zero-ness of m_policyCheck first so that we can differentiate process ID being wrong from the non-generated identifier being sent to us as it was the case in this failure. * loader/PolicyChecker.cpp: (WebCore::PolicyCheckIdentifier::isValidFor): Source/WebKit: The bug was caused by WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction invoking the callback with responseIdentifier even when we had failed to send the policy check IPC. Clearly, responseIdentifier is invalid in that case, and we should be using requestIdentifier instead. Unfortunately no new tests since I'm not aware of a way to make sendSync fail in this case. * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241352 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-13 Ryosuke Niwa Release assert in PolicyCheckIdentifier::isValidFor via WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction https://bugs.webkit.org/show_bug.cgi?id=194582 Reviewed by Antti Koivisto. Check the zero-ness of m_policyCheck first so that we can differentiate process ID being wrong from the non-generated identifier being sent to us as it was the case in this failure. * loader/PolicyChecker.cpp: (WebCore::PolicyCheckIdentifier::isValidFor): 2019-02-07 Babak Shafiei Cherry-pick r241170. rdar://problem/47909341 REGRESSION(r239887): Crash under IDBConnectionToClient::didDeleteDatabase(WebCore::IDBResultData const&) https://bugs.webkit.org/show_bug.cgi?id=194402 Reviewed by Geoffrey Garen. r239887 removed a reference cycle of IDBConnectionToClient so that IDBConnectionToClient would no longer be around forever. Therefore, ServerOpenRequest should keep a reference to IDBConnectionToClient to make sure it is valid during access. * Modules/indexeddb/server/ServerOpenDBRequest.cpp: (WebCore::IDBServer::ServerOpenDBRequest::maybeNotifyRequestBlocked): (WebCore::IDBServer::ServerOpenDBRequest::notifyDidDeleteDatabase): * Modules/indexeddb/server/ServerOpenDBRequest.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241170 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-07 Sihui Liu REGRESSION(r239887): Crash under IDBConnectionToClient::didDeleteDatabase(WebCore::IDBResultData const&) https://bugs.webkit.org/show_bug.cgi?id=194402 Reviewed by Geoffrey Garen. r239887 removed a reference cycle of IDBConnectionToClient so that IDBConnectionToClient would no longer be around forever. Therefore, ServerOpenRequest should keep a reference to IDBConnectionToClient to make sure it is valid during access. * Modules/indexeddb/server/ServerOpenDBRequest.cpp: (WebCore::IDBServer::ServerOpenDBRequest::maybeNotifyRequestBlocked): (WebCore::IDBServer::ServerOpenDBRequest::notifyDidDeleteDatabase): * Modules/indexeddb/server/ServerOpenDBRequest.h: 2019-02-07 Babak Shafiei Cherry-pick r241150. rdar://problem/47908154 Overflow element scrollbar is light for dark mode content. https://bugs.webkit.org/show_bug.cgi?id=194407 rdar://problem/45991585 Reviewed by Beth Dakin. Source/WebCore: Tested by css-dark-mode/supported-color-schemes-scrollbar.html. * page/ChromeClient.h: (WebCore::FrameView::preferredScrollbarOverlayStyle): Return WTF::nullopt by default to avoid short-circuiting auto detection in recalculateScrollbarOverlayStyle() for clients, like WK1, that do not implement preferredScrollbarOverlayStyle(). * page/FrameView.cpp: (WebCore::FrameView::recalculateScrollbarOverlayStyle): Use WTF::nullopt in the false case to auto detect overlay style when page() is null. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::useDarkAppearance const): Added. * rendering/RenderLayer.h: * testing/Internals.cpp: (WebCore::Internals::scrollbarOverlayStyle const): Added Node argument. (WebCore::Internals::scrollbarUsingDarkAppearance const): Added. * testing/Internals.h: * testing/Internals.idl: LayoutTests: Updated tests to look at overflow elements and if dark apearance is used by the scrollbar directly. * css-dark-mode/supported-color-schemes-scrollbar-expected.txt: * css-dark-mode/supported-color-schemes-scrollbar.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241150 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-07 Timothy Hatcher Overflow element scrollbar is light for dark mode content. https://bugs.webkit.org/show_bug.cgi?id=194407 rdar://problem/45991585 Reviewed by Beth Dakin. Tested by css-dark-mode/supported-color-schemes-scrollbar.html. * page/ChromeClient.h: (WebCore::FrameView::preferredScrollbarOverlayStyle): Return WTF::nullopt by default to avoid short-circuiting auto detection in recalculateScrollbarOverlayStyle() for clients, like WK1, that do not implement preferredScrollbarOverlayStyle(). * page/FrameView.cpp: (WebCore::FrameView::recalculateScrollbarOverlayStyle): Use WTF::nullopt in the false case to auto detect overlay style when page() is null. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::useDarkAppearance const): Added. * rendering/RenderLayer.h: * testing/Internals.cpp: (WebCore::Internals::scrollbarOverlayStyle const): Added Node argument. (WebCore::Internals::scrollbarUsingDarkAppearance const): Added. * testing/Internals.h: * testing/Internals.idl: 2019-02-07 Alan Coon Cherry-pick r240710. rdar://problem/47776353 AX: Support color well on iOS https://bugs.webkit.org/show_bug.cgi?id=194010 Reviewed by Joanmarie Diggs. Source/WebCore: Test: accessibility/ios-simulator/color-well.html Add support for color well on iOS. * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper accessibilityCanFuzzyHitTest]): (-[WebAccessibilityObjectWrapper determineIsAccessibilityElement]): (-[WebAccessibilityObjectWrapper accessibilityRoleDescription]): (-[WebAccessibilityObjectWrapper accessibilityColorStringValue]): * en.lproj/Localizable.strings: * platform/LocalizedStrings.cpp: (WebCore::AXColorWellText): * platform/LocalizedStrings.h: Tools: * WebKitTestRunner/InjectedBundle/ios/AccessibilityUIElementIOS.mm: (WTR::AccessibilityUIElement::stringAttributeValue): LayoutTests: * accessibility/ios-simulator/color-well-expected.txt: Added. * accessibility/ios-simulator/color-well.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240710 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-30 Chris Fleizach AX: Support color well on iOS https://bugs.webkit.org/show_bug.cgi?id=194010 Reviewed by Joanmarie Diggs. Test: accessibility/ios-simulator/color-well.html Add support for color well on iOS. * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper accessibilityCanFuzzyHitTest]): (-[WebAccessibilityObjectWrapper determineIsAccessibilityElement]): (-[WebAccessibilityObjectWrapper accessibilityRoleDescription]): (-[WebAccessibilityObjectWrapper accessibilityColorStringValue]): * en.lproj/Localizable.strings: * platform/LocalizedStrings.cpp: (WebCore::AXColorWellText): * platform/LocalizedStrings.h: 2019-02-07 Alan Coon Cherry-pick r241137. rdar://problem/47893603 Unable to sign in leetcode. https://bugs.webkit.org/show_bug.cgi?id=194366 rdar://problem/47259025. Reviewed by Chris Dumez. Source/WebCore: In case a signal is passed as part of a FetchRequestInit, the IDL binding code is throwing an exception in case signal is not an AbortSignal object. This breaks an AbortSignal shim used in some web sites. Relaxed the IDL binding rule by marking signal as any and doing the conversion in FetchRequest. Test: http/wpt/fetch/request-abort.html Also covered by manually signing in to leetcode. * Modules/fetch/FetchRequest.cpp: (WebCore::FetchRequest::initializeWith): * Modules/fetch/FetchRequestInit.h: (WebCore::FetchRequestInit::hasMembers const): * Modules/fetch/FetchRequestInit.idl: LayoutTests: * http/wpt/fetch/request-abort-expected.txt: Added. * http/wpt/fetch/request-abort.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241137 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-07 Youenn Fablet Unable to sign in leetcode. https://bugs.webkit.org/show_bug.cgi?id=194366 rdar://problem/47259025. Reviewed by Chris Dumez. In case a signal is passed as part of a FetchRequestInit, the IDL binding code is throwing an exception in case signal is not an AbortSignal object. This breaks an AbortSignal shim used in some web sites. Relaxed the IDL binding rule by marking signal as any and doing the conversion in FetchRequest. Test: http/wpt/fetch/request-abort.html Also covered by manually signing in to leetcode. * Modules/fetch/FetchRequest.cpp: (WebCore::FetchRequest::initializeWith): * Modules/fetch/FetchRequestInit.h: (WebCore::FetchRequestInit::hasMembers const): * Modules/fetch/FetchRequestInit.idl: 2019-02-07 Alan Coon Cherry-pick r241130. rdar://problem/47893594 HTMLMediaElement registers wrong ScriptExecutionContext with its ActiveDOMObject parent class https://bugs.webkit.org/show_bug.cgi?id=194360 HTMLMediaElement registers the Document used to create it with ActiveDOMObject, when it should really use that Document's contextDocument(). Rather than just fix this in HTMLMediaElement, make sure that the correct document is used everywhere by adding a new ActiveDOMObject constructor taking a Document&, and making an explicitly deleted Document* constructor to catch any new cases. Reviewed by Geoffrey Garen. * Modules/applepay/ApplePaySession.cpp: (WebCore::ApplePaySession::ApplePaySession): * Modules/mediarecorder/MediaRecorder.cpp: (WebCore::MediaRecorder::MediaRecorder): * Modules/mediastream/MediaDevices.cpp: (WebCore::MediaDevices::MediaDevices): * Modules/mediastream/UserMediaRequest.cpp: (WebCore::UserMediaRequest::UserMediaRequest): * Modules/notifications/Notification.cpp: (WebCore::Notification::Notification): * Modules/paymentrequest/PaymentRequest.cpp: (WebCore::PaymentRequest::PaymentRequest): * Modules/webaudio/AudioContext.cpp: (WebCore::AudioContext::AudioContext): * animation/WebAnimation.cpp: (WebCore::WebAnimation::WebAnimation): * css/FontFaceSet.cpp: (WebCore::FontFaceSet::FontFaceSet): * dom/ActiveDOMObject.cpp: (WebCore::ActiveDOMObject::ActiveDOMObject): * dom/ActiveDOMObject.h: * dom/Document.h: (WebCore::ActiveDOMObject::ActiveDOMObject): * html/HTMLMarqueeElement.cpp: (WebCore::HTMLMarqueeElement::HTMLMarqueeElement): * html/HTMLMediaElement.cpp: (WebCore::HTMLMediaElement::HTMLMediaElement): * html/HTMLSourceElement.cpp: (WebCore::HTMLSourceElement::HTMLSourceElement): * page/IntersectionObserver.cpp: (WebCore::IntersectionObserver::IntersectionObserver): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241130 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-07 Jer Noble HTMLMediaElement registers wrong ScriptExecutionContext with its ActiveDOMObject parent class https://bugs.webkit.org/show_bug.cgi?id=194360 HTMLMediaElement registers the Document used to create it with ActiveDOMObject, when it should really use that Document's contextDocument(). Rather than just fix this in HTMLMediaElement, make sure that the correct document is used everywhere by adding a new ActiveDOMObject constructor taking a Document&, and making an explicitly deleted Document* constructor to catch any new cases. Reviewed by Geoffrey Garen. * Modules/applepay/ApplePaySession.cpp: (WebCore::ApplePaySession::ApplePaySession): * Modules/mediarecorder/MediaRecorder.cpp: (WebCore::MediaRecorder::MediaRecorder): * Modules/mediastream/MediaDevices.cpp: (WebCore::MediaDevices::MediaDevices): * Modules/mediastream/UserMediaRequest.cpp: (WebCore::UserMediaRequest::UserMediaRequest): * Modules/notifications/Notification.cpp: (WebCore::Notification::Notification): * Modules/paymentrequest/PaymentRequest.cpp: (WebCore::PaymentRequest::PaymentRequest): * Modules/webaudio/AudioContext.cpp: (WebCore::AudioContext::AudioContext): * animation/WebAnimation.cpp: (WebCore::WebAnimation::WebAnimation): * css/FontFaceSet.cpp: (WebCore::FontFaceSet::FontFaceSet): * dom/ActiveDOMObject.cpp: (WebCore::ActiveDOMObject::ActiveDOMObject): * dom/ActiveDOMObject.h: * dom/Document.h: (WebCore::ActiveDOMObject::ActiveDOMObject): * html/HTMLMarqueeElement.cpp: (WebCore::HTMLMarqueeElement::HTMLMarqueeElement): * html/HTMLMediaElement.cpp: (WebCore::HTMLMediaElement::HTMLMediaElement): * html/HTMLSourceElement.cpp: (WebCore::HTMLSourceElement::HTMLSourceElement): * page/IntersectionObserver.cpp: (WebCore::IntersectionObserver::IntersectionObserver): 2019-02-07 Alan Coon Cherry-pick r241121. rdar://problem/47893559 Infinite recursion via CachedResource::~CachedResource https://bugs.webkit.org/show_bug.cgi?id=194378 Reviewed by Daniel Bates. I don't know the exact steps to trigger this but the mechanism seems clear. 1) An existing resource is removed from or replaced in CachedResourceLoader::m_documentResources map. 2) This decrements the handle count of resource and causes it be deleted. 3) CachedResource::~CachedResource calls m_owningCachedResourceLoader->removeCachedResource(*this). This only happens with resources that are "owned" by CachedResourceLoader which is a rare special case (used by image document and if memory cache is disabled). 4) CachedResourceLoader::removeCachedResource looks up the resource from the map which causes a temporary CachedResourceHandle to be created. This increments the handle count of the resource from 0 back to 1. 5) When the temporary dies, CachedResource::~CachedResource is called again and we cycle back to 3). The fix here is simply to remove CachedResourceLoader::removeCachedResource call from ~CachedResource. It is a leftover from when the map contained raw pointers instead of owning CachedResourceHandles. Since m_documentResources map has a handle to the resource, the only way we are in the destructor is that the resource has been removed from the map already (or is in process of being removed like in this crash). Any call that does anything other than bail out is going to crash. CachedResource::n_owningCachedResourceLoader member and CachedResourceLoader::removeCachedResource function only exist to support this erranous call so they are removed as well. * loader/ImageLoader.cpp: (WebCore::ImageLoader::updateFromElement): * loader/cache/CachedResource.cpp: (WebCore::CachedResource::~CachedResource): This is the substantive change. The rest just removes now-dead code. * loader/cache/CachedResource.h: (WebCore::CachedResource::setOwningCachedResourceLoader): Deleted. * loader/cache/CachedResourceLoader.cpp: (WebCore::CachedResourceLoader::~CachedResourceLoader): (WebCore::CachedResourceLoader::requestUserCSSStyleSheet): (WebCore::CachedResourceLoader::requestResource): (WebCore::CachedResourceLoader::loadResource): (WebCore::CachedResourceLoader::garbageCollectDocumentResources): (WebCore::CachedResourceLoader::removeCachedResource): Deleted. * loader/cache/CachedResourceLoader.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241121 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-07 Antti Koivisto Infinite recursion via CachedResource::~CachedResource https://bugs.webkit.org/show_bug.cgi?id=194378 Reviewed by Daniel Bates. I don't know the exact steps to trigger this but the mechanism seems clear. 1) An existing resource is removed from or replaced in CachedResourceLoader::m_documentResources map. 2) This decrements the handle count of resource and causes it be deleted. 3) CachedResource::~CachedResource calls m_owningCachedResourceLoader->removeCachedResource(*this). This only happens with resources that are "owned" by CachedResourceLoader which is a rare special case (used by image document and if memory cache is disabled). 4) CachedResourceLoader::removeCachedResource looks up the resource from the map which causes a temporary CachedResourceHandle to be created. This increments the handle count of the resource from 0 back to 1. 5) When the temporary dies, CachedResource::~CachedResource is called again and we cycle back to 3). The fix here is simply to remove CachedResourceLoader::removeCachedResource call from ~CachedResource. It is a leftover from when the map contained raw pointers instead of owning CachedResourceHandles. Since m_documentResources map has a handle to the resource, the only way we are in the destructor is that the resource has been removed from the map already (or is in process of being removed like in this crash). Any call that does anything other than bail out is going to crash. CachedResource::n_owningCachedResourceLoader member and CachedResourceLoader::removeCachedResource function only exist to support this erranous call so they are removed as well. * loader/ImageLoader.cpp: (WebCore::ImageLoader::updateFromElement): * loader/cache/CachedResource.cpp: (WebCore::CachedResource::~CachedResource): This is the substantive change. The rest just removes now-dead code. * loader/cache/CachedResource.h: (WebCore::CachedResource::setOwningCachedResourceLoader): Deleted. * loader/cache/CachedResourceLoader.cpp: (WebCore::CachedResourceLoader::~CachedResourceLoader): (WebCore::CachedResourceLoader::requestUserCSSStyleSheet): (WebCore::CachedResourceLoader::requestResource): (WebCore::CachedResourceLoader::loadResource): (WebCore::CachedResourceLoader::garbageCollectDocumentResources): (WebCore::CachedResourceLoader::removeCachedResource): Deleted. * loader/cache/CachedResourceLoader.h: 2019-02-07 Alan Coon Cherry-pick r241105. rdar://problem/47893571 [Payment Request] It should be possible to require a phonetic name for shipping contacts https://bugs.webkit.org/show_bug.cgi?id=194311 Reviewed by Alex Christensen. Source/WebCore: It should be possible to require that a shipping contact has a phonetic name in Payment Request. To accomplish this, move requiredShippingContactFields from ApplePayPaymentRequest to ApplePayRequestBase so that it can be used as part of an Apple Pay payment method data. Since required shipping contact fields can now be specified both in requiredShippingContactFields and PaymentOptions, we merge the required fields from these two sources such that, e.g., email is required if it is specified in either place. So that clients can detect this new feature, the API version number is bumped from 5 to 6. Added test cases to ApplePayRequestShippingContact.https.html and ApplePayRequestShippingContactV3.https.html. * DerivedSources.make: * Modules/applepay/ApplePayPaymentRequest.h: * Modules/applepay/ApplePayPaymentRequest.idl: * Modules/applepay/ApplePayRequestBase.cpp: (WebCore::convertAndValidate): * Modules/applepay/ApplePayRequestBase.h: * Modules/applepay/ApplePayRequestBase.idl: * Modules/applepay/ApplePaySession.cpp: (WebCore::convertAndValidate): * Modules/applepay/PaymentCoordinatorClient.cpp: Added. (WebCore::PaymentCoordinatorClient::supportsVersion): * Modules/applepay/PaymentCoordinatorClient.h: * Modules/applepay/paymentrequest/ApplePayPaymentHandler.cpp: (WebCore::mergePaymentOptions): (WebCore::ApplePayPaymentHandler::show): * SourcesCocoa.txt: * WebCore.xcodeproj/project.pbxproj: * loader/EmptyClients.cpp: * testing/MockPaymentContactFields.h: Added. (WebCore::MockPaymentContactFields::MockPaymentContactFields): * testing/MockPaymentContactFields.idl: Added. * testing/MockPaymentCoordinator.cpp: (WebCore::MockPaymentCoordinator::showPaymentUI): (WebCore::MockPaymentCoordinator::supportsVersion): Deleted. * testing/MockPaymentCoordinator.h: * testing/MockPaymentCoordinator.idl: Source/WebKit: * WebProcess/ApplePay/WebPaymentCoordinator.cpp: (WebKit::WebPaymentCoordinator::supportsVersion): Deleted. * WebProcess/ApplePay/WebPaymentCoordinator.h: Source/WebKitLegacy/mac: * WebCoreSupport/WebPaymentCoordinatorClient.h: * WebCoreSupport/WebPaymentCoordinatorClient.mm: (WebPaymentCoordinatorClient::supportsVersion): Deleted. LayoutTests: * http/tests/ssl/applepay/ApplePayRequestShippingContact.https-expected.txt: * http/tests/ssl/applepay/ApplePayRequestShippingContact.https.html: * http/tests/ssl/applepay/ApplePayRequestShippingContactV3.https-expected.txt: * http/tests/ssl/applepay/ApplePayRequestShippingContactV3.https.html: * http/tests/ssl/applepay/PaymentRequest.https-expected.txt: * http/tests/ssl/applepay/PaymentRequest.https.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241105 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-06 Andy Estes [Payment Request] It should be possible to require a phonetic name for shipping contacts https://bugs.webkit.org/show_bug.cgi?id=194311 Reviewed by Alex Christensen. It should be possible to require that a shipping contact has a phonetic name in Payment Request. To accomplish this, move requiredShippingContactFields from ApplePayPaymentRequest to ApplePayRequestBase so that it can be used as part of an Apple Pay payment method data. Since required shipping contact fields can now be specified both in requiredShippingContactFields and PaymentOptions, we merge the required fields from these two sources such that, e.g., email is required if it is specified in either place. So that clients can detect this new feature, the API version number is bumped from 5 to 6. Added test cases to ApplePayRequestShippingContact.https.html and ApplePayRequestShippingContactV3.https.html. * DerivedSources.make: * Modules/applepay/ApplePayPaymentRequest.h: * Modules/applepay/ApplePayPaymentRequest.idl: * Modules/applepay/ApplePayRequestBase.cpp: (WebCore::convertAndValidate): * Modules/applepay/ApplePayRequestBase.h: * Modules/applepay/ApplePayRequestBase.idl: * Modules/applepay/ApplePaySession.cpp: (WebCore::convertAndValidate): * Modules/applepay/PaymentCoordinatorClient.cpp: Added. (WebCore::PaymentCoordinatorClient::supportsVersion): * Modules/applepay/PaymentCoordinatorClient.h: * Modules/applepay/paymentrequest/ApplePayPaymentHandler.cpp: (WebCore::mergePaymentOptions): (WebCore::ApplePayPaymentHandler::show): * SourcesCocoa.txt: * WebCore.xcodeproj/project.pbxproj: * loader/EmptyClients.cpp: * testing/MockPaymentContactFields.h: Added. (WebCore::MockPaymentContactFields::MockPaymentContactFields): * testing/MockPaymentContactFields.idl: Added. * testing/MockPaymentCoordinator.cpp: (WebCore::MockPaymentCoordinator::showPaymentUI): (WebCore::MockPaymentCoordinator::supportsVersion): Deleted. * testing/MockPaymentCoordinator.h: * testing/MockPaymentCoordinator.idl: 2019-02-07 Alan Coon Cherry-pick r241022. rdar://problem/47893580 CoreAudioCaptureSource should not configure its audio unit until it starts producing data https://bugs.webkit.org/show_bug.cgi?id=194310 Reviewed by Eric Carlson. Delay the configuration of the audio unit until the source is instructed to start producing data. This allows the UIProcess to not start changing the audio unit when checking for constraints during getUserMedia call before the prompt. Covered by manual testing. * platform/mediastream/mac/CoreAudioCaptureSource.cpp: (WebCore::CoreAudioCaptureSource::CoreAudioCaptureSource): (WebCore::CoreAudioCaptureSource::initializeToStartProducingData): (WebCore::CoreAudioCaptureSource::startProducingData): * platform/mediastream/mac/CoreAudioCaptureSource.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241022 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-06 Youenn Fablet CoreAudioCaptureSource should not configure its audio unit until it starts producing data https://bugs.webkit.org/show_bug.cgi?id=194310 Reviewed by Eric Carlson. Delay the configuration of the audio unit until the source is instructed to start producing data. This allows the UIProcess to not start changing the audio unit when checking for constraints during getUserMedia call before the prompt. Covered by manual testing. * platform/mediastream/mac/CoreAudioCaptureSource.cpp: (WebCore::CoreAudioCaptureSource::CoreAudioCaptureSource): (WebCore::CoreAudioCaptureSource::initializeToStartProducingData): (WebCore::CoreAudioCaptureSource::startProducingData): * platform/mediastream/mac/CoreAudioCaptureSource.h: 2019-02-07 Alan Coon Cherry-pick r241021. rdar://problem/47893607 Disable audio ducking at Audio Unit setup time https://bugs.webkit.org/show_bug.cgi?id=194303 Reviewed by Eric Carlson. When creating a CoreAudioCaptureSource, the audio unit might be reconfigured if a past audio capture was done. This might trigger audio ducking which is undone in startInternal. In some cases, startInternal will never call start. In that case, the audio unit will continue ducking the other processing. To ensure ducking is disabled, unduck in setupAudioUnit as well as startInternal. In addition to that, once a shared unit is created, it stays alive until the UIProcess exits. This might affect all applications. Instead, whenever the shared unit is stopped, clean it so as to restore the state as if no capture ever happened. This has noticeable effects in the quality of audio being played on bluetooth devices. Covered by manual tests. * platform/mediastream/mac/CoreAudioCaptureSource.cpp: (WebCore::CoreAudioSharedUnit::setupAudioUnit): (WebCore::CoreAudioSharedUnit::unduck): (WebCore::CoreAudioSharedUnit::startInternal): (WebCore::CoreAudioSharedUnit::captureFailed): (WebCore::CoreAudioSharedUnit::stopProducingData): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241021 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-06 Youenn Fablet Disable audio ducking at Audio Unit setup time https://bugs.webkit.org/show_bug.cgi?id=194303 Reviewed by Eric Carlson. When creating a CoreAudioCaptureSource, the audio unit might be reconfigured if a past audio capture was done. This might trigger audio ducking which is undone in startInternal. In some cases, startInternal will never call start. In that case, the audio unit will continue ducking the other processing. To ensure ducking is disabled, unduck in setupAudioUnit as well as startInternal. In addition to that, once a shared unit is created, it stays alive until the UIProcess exits. This might affect all applications. Instead, whenever the shared unit is stopped, clean it so as to restore the state as if no capture ever happened. This has noticeable effects in the quality of audio being played on bluetooth devices. Covered by manual tests. * platform/mediastream/mac/CoreAudioCaptureSource.cpp: (WebCore::CoreAudioSharedUnit::setupAudioUnit): (WebCore::CoreAudioSharedUnit::unduck): (WebCore::CoreAudioSharedUnit::startInternal): (WebCore::CoreAudioSharedUnit::captureFailed): (WebCore::CoreAudioSharedUnit::stopProducingData): 2019-02-07 Alan Coon Cherry-pick r241018. rdar://problem/47893623 RELEASE_ASSERT(!m_document.isResolvingTreeStyle()) in com.apple.WebKit.WebContent at WebCore: WebCore::StyleResolver::~StyleResolver https://bugs.webkit.org/show_bug.cgi?id=194333 Reviewed by Zalan Bujtas. Source/WebCore: Content extensions may mutate the extension stylesheet in the middle of a style resolution as a result of the legacy animation code triggering a resource load. Test: http/tests/contentextensions/css-display-none-keyframe.html * style/StyleScope.cpp: (WebCore::Style::Scope::scheduleUpdate): Avoid clearing the style resolver if we are in the middle of a style resolution. A better fix that avoid doing this in the first place is tracked by https://bugs.webkit.org/show_bug.cgi?id=194335. LayoutTests: * http/tests/contentextensions/css-display-none-keyframe-expected.txt: Added. * http/tests/contentextensions/css-display-none-keyframe.html: Added. * http/tests/contentextensions/css-display-none-keyframe.html.json: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241018 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-06 Antti Koivisto RELEASE_ASSERT(!m_document.isResolvingTreeStyle()) in com.apple.WebKit.WebContent at WebCore: WebCore::StyleResolver::~StyleResolver https://bugs.webkit.org/show_bug.cgi?id=194333 Reviewed by Zalan Bujtas. Content extensions may mutate the extension stylesheet in the middle of a style resolution as a result of the legacy animation code triggering a resource load. Test: http/tests/contentextensions/css-display-none-keyframe.html * style/StyleScope.cpp: (WebCore::Style::Scope::scheduleUpdate): Avoid clearing the style resolver if we are in the middle of a style resolution. A better fix that avoid doing this in the first place is tracked by https://bugs.webkit.org/show_bug.cgi?id=194335. 2019-02-07 Alan Coon Cherry-pick r240808. rdar://problem/47774548 Revert r238819 which is unneeded and caused a performance regression. https://bugs.webkit.org/show_bug.cgi?id=192272 Source/WebCore: * loader/EmptyFrameLoaderClient.h: * loader/FrameLoader.cpp: (WebCore::FrameLoader::prepareForLoadStart): (WebCore::FrameLoader::continueLoadAfterNavigationPolicy): (WebCore::FrameLoader::loadProvisionalItemFromCachedPage): * loader/FrameLoader.h: * loader/FrameLoaderClient.h: Source/WebKit: * WebProcess/InjectedBundle/API/APIInjectedBundlePageLoaderClient.h: (API::InjectedBundle::PageLoaderClient::didStartProvisionalLoadForFrame): * WebProcess/InjectedBundle/API/Cocoa/WKWebProcessPlugInLoadDelegate.h: * WebProcess/InjectedBundle/API/glib/WebKitWebPage.cpp: * WebProcess/InjectedBundle/API/mac/WKWebProcessPlugInBrowserContextController.mm: (PageLoaderClient::didStartProvisionalLoadForFrame): * WebProcess/InjectedBundle/InjectedBundlePageLoaderClient.cpp: (WebKit::InjectedBundlePageLoaderClient::didStartProvisionalLoadForFrame): * WebProcess/InjectedBundle/InjectedBundlePageLoaderClient.h: * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::dispatchDidStartProvisionalLoad): * WebProcess/WebCoreSupport/WebFrameLoaderClient.h: Source/WebKitLegacy/mac: * WebCoreSupport/WebFrameLoaderClient.h: * WebCoreSupport/WebFrameLoaderClient.mm: (WebFrameLoaderClient::dispatchDidStartProvisionalLoad): Source/WebKitLegacy/win: * WebCoreSupport/WebFrameLoaderClient.cpp: (WebFrameLoaderClient::dispatchDidStartProvisionalLoad): * WebCoreSupport/WebFrameLoaderClient.h: Tools: * TestWebKitAPI/Tests/WebKitCocoa/ParserYieldTokenPlugIn.mm: (-[ParserYieldTokenPlugIn webProcessPlugInBrowserContextController:didCommitLoadForFrame:]): (-[ParserYieldTokenPlugIn webProcessPlugInBrowserContextController:willStartProvisionalLoadForFrame:completionHandler:]): Deleted. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240808 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-31 Alex Christensen Revert r238819 which is unneeded and caused a performance regression. https://bugs.webkit.org/show_bug.cgi?id=192272 * loader/EmptyFrameLoaderClient.h: * loader/FrameLoader.cpp: (WebCore::FrameLoader::prepareForLoadStart): (WebCore::FrameLoader::continueLoadAfterNavigationPolicy): (WebCore::FrameLoader::loadProvisionalItemFromCachedPage): * loader/FrameLoader.h: * loader/FrameLoaderClient.h: 2019-02-07 Alan Coon Cherry-pick r239831. rdar://problem/47776468 [css-grid] Let abspos items reference implicit grid lines https://bugs.webkit.org/show_bug.cgi?id=193313 Patch by Oriol Brufau on 2019-01-10 Reviewed by Manuel Rego Casasnovas. LayoutTests/imported/w3c: Import test changes from WPT. * web-platform-tests/css/css-grid/abspos/grid-positioned-items-padding-001.html: * web-platform-tests/css/css-grid/abspos/grid-positioned-items-unknown-named-grid-line-001.html: Source/WebCore: While they can't create new implicit grid lines, abspos items can reference existing ones as clarified in https://github.com/w3c/csswg-drafts/commit/511bb63 This patch makes WebKit match Blink, Firefox and Edge. Tests: web-platform-tests/css/css-grid/abspos/grid-positioned-items-padding-001.html web-platform-tests/css/css-grid/abspos/grid-positioned-items-unknown-named-grid-line-001.html * rendering/RenderGrid.cpp: (WebCore::RenderGrid::populateExplicitGridAndOrderIterator const): Remove argument from spanSizeForAutoPlacedItem call. (WebCore::RenderGrid::createEmptyGridAreaAtSpecifiedPositionsOutsideGrid const): Remove argument from spanSizeForAutoPlacedItem call. (WebCore::RenderGrid::placeSpecifiedMajorAxisItemsOnGrid const): Remove argument from spanSizeForAutoPlacedItem call. (WebCore::RenderGrid::placeAutoMajorAxisItemOnGrid const): Remove argument from spanSizeForAutoPlacedItem call. (WebCore::RenderGrid::gridAreaBreadthForOutOfFlowChild): Don't treat implicit grid lines as 'auto'. * rendering/RenderGrid.h: Remove unused gridPositionIsAutoForOutOfFlow. * rendering/style/GridPositionsResolver.cpp: (WebCore::adjustGridPositionsFromStyle): Don't treat implicit grid lines as 'auto'. Remove unused gridContainerStyle parameter. (WebCore::GridPositionsResolver::spanSizeForAutoPlacedItem): Remove argument from adjustGridPositionsFromStyle call. Remove unused gridContainerStyle parameter. (WebCore::resolveGridPositionFromStyle): Remove unnecessary assert that uses isValidNamedLineOrArea. (WebCore::GridPositionsResolver::resolveGridPositionsFromStyle): Remove argument from adjustGridPositionsFromStyle call. * rendering/style/GridPositionsResolver.h: Remove unused isValidNamedLineOrArea. Remove unused parameter from spanSizeForAutoPlacedItem. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239831 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-10 Oriol Brufau [css-grid] Let abspos items reference implicit grid lines https://bugs.webkit.org/show_bug.cgi?id=193313 Reviewed by Manuel Rego Casasnovas. While they can't create new implicit grid lines, abspos items can reference existing ones as clarified in https://github.com/w3c/csswg-drafts/commit/511bb63 This patch makes WebKit match Blink, Firefox and Edge. Tests: web-platform-tests/css/css-grid/abspos/grid-positioned-items-padding-001.html web-platform-tests/css/css-grid/abspos/grid-positioned-items-unknown-named-grid-line-001.html * rendering/RenderGrid.cpp: (WebCore::RenderGrid::populateExplicitGridAndOrderIterator const): Remove argument from spanSizeForAutoPlacedItem call. (WebCore::RenderGrid::createEmptyGridAreaAtSpecifiedPositionsOutsideGrid const): Remove argument from spanSizeForAutoPlacedItem call. (WebCore::RenderGrid::placeSpecifiedMajorAxisItemsOnGrid const): Remove argument from spanSizeForAutoPlacedItem call. (WebCore::RenderGrid::placeAutoMajorAxisItemOnGrid const): Remove argument from spanSizeForAutoPlacedItem call. (WebCore::RenderGrid::gridAreaBreadthForOutOfFlowChild): Don't treat implicit grid lines as 'auto'. * rendering/RenderGrid.h: Remove unused gridPositionIsAutoForOutOfFlow. * rendering/style/GridPositionsResolver.cpp: (WebCore::adjustGridPositionsFromStyle): Don't treat implicit grid lines as 'auto'. Remove unused gridContainerStyle parameter. (WebCore::GridPositionsResolver::spanSizeForAutoPlacedItem): Remove argument from adjustGridPositionsFromStyle call. Remove unused gridContainerStyle parameter. (WebCore::resolveGridPositionFromStyle): Remove unnecessary assert that uses isValidNamedLineOrArea. (WebCore::GridPositionsResolver::resolveGridPositionsFromStyle): Remove argument from adjustGridPositionsFromStyle call. * rendering/style/GridPositionsResolver.h: Remove unused isValidNamedLineOrArea. Remove unused parameter from spanSizeForAutoPlacedItem. 2019-02-06 Alan Coon Cherry-pick r241015. rdar://problem/47866495 REGRESSION (r240909): Release assert in FrameLoader::loadURL when navigating with a non-existent target name https://bugs.webkit.org/show_bug.cgi?id=194329 Reviewed by Geoffrey Garen. Source/WebCore: The bug was caused by the code path for when navigating with a specific target frame name that does not exist never setting the load type of PolicyChecker. As a result, we would use whatever load type used in the previous navigation, resulting in this release assertion. Updating the load type here should in theory fix the underlying bug r240909 was meant to catch & fix. Test: fast/loader/navigate-with-new-target-after-back-forward-navigation.html * loader/FrameLoader.cpp: (WebCore::FrameLoader::loadURL): LayoutTests: Added a regression test. * fast/loader/navigate-with-new-target-after-back-forward-navigation-expected.txt: Added. * fast/loader/navigate-with-new-target-after-back-forward-navigation.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241015 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-05 Ryosuke Niwa REGRESSION (r240909): Release assert in FrameLoader::loadURL when navigating with a non-existent target name https://bugs.webkit.org/show_bug.cgi?id=194329 Reviewed by Geoffrey Garen. The bug was caused by the code path for when navigating with a specific target frame name that does not exist never setting the load type of PolicyChecker. As a result, we would use whatever load type used in the previous navigation, resulting in this release assertion. Updating the load type here should in theory fix the underlying bug r240909 was meant to catch & fix. Test: fast/loader/navigate-with-new-target-after-back-forward-navigation.html * loader/FrameLoader.cpp: (WebCore::FrameLoader::loadURL): 2019-02-06 Alan Coon Apply patch. rdar://problem/47822019 2019-02-06 Ryosuke Niwa Validate navigation policy decisions to avoid crashes in continueLoadAfterNavigationPolicy https://bugs.webkit.org/show_bug.cgi?id=194189 Reviewed by Geoffrey Garen. Introduced PolicyCheckIdentifier to pair each navigation policy check request with a decision, and deployed it in PolicyChecker. The identifier is passed from WebContent process to UI process in WebKit2, and passed it back with the policy decision. Because PolicyCheckIdentifier embeds the process identifier from which a navigation policy is checked, we would be able to detect when UI process had sent the decision to a wrong WebContent process. This patch also adds release assertions to make sure history().provisionalItem() is set whenever we're requesting a navigation policy check. These code changes should either: 1. Fix crashes in FrameLoader::continueLoadAfterNavigationPolicy where isBackForwardLoadType would return true yet history().provisionalItem() is null. 2. Detect a bug that UI process can send a navigation policy decision to a wrong WebContent process. 3. Rule out the possibility that (2) exists. * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::willSendRequest): (WebCore::DocumentLoader::responseReceived): * loader/EmptyClients.cpp: (WebCore::EmptyFrameLoaderClient::dispatchDecidePolicyForNewWindowAction): (WebCore::EmptyFrameLoaderClient::dispatchDecidePolicyForNavigationAction): * loader/EmptyFrameLoaderClient.h: * loader/FrameLoader.cpp: (WebCore::FrameLoader::checkContentPolicy): (WebCore::FrameLoader::loadURL): (WebCore::FrameLoader::load): (WebCore::FrameLoader::loadWithDocumentLoader): (WebCore::FrameLoader::loadPostRequest): * loader/FrameLoader.h: * loader/FrameLoaderClient.h: * loader/FrameLoaderTypes.h: (WebCore::PolicyCheckIdentifier): Added. (WebCore::PolicyCheckIdentifier::operator== const): Added. (WebCore::PolicyCheckIdentifier::PolicyCheckIdentifier): Added. (WebCore::PolicyCheckIdentifier::encode const): Added. (WebCore::PolicyCheckIdentifier::decode): Added. * loader/PolicyChecker.cpp: (WebCore::PolicyCheckIdentifier::generate): (WebCore::PolicyCheckIdentifier::isValidFor): Returns true if the identifer matches. Also release asserts that the process ID is same, and that m_check is always not zero (meaning it's a generated value). The failure of these release assertions would indicate that there is a bug in UI process, which results in a policy decision response being sent to a wrong Web process. (WebCore::PolicyChecker::checkNavigationPolicy): Exit early if isValidFor fails. (WebCore::PolicyChecker::checkNewWindowPolicy): 2019-02-06 Alan Coon Cherry-pick r240804. rdar://problem/47774520 [Cocoa][EME] Modern EME uses a different path for SecureStop data than Legacy EME https://bugs.webkit.org/show_bug.cgi?id=193988 Reviewed by Jon Lee. Modern EME is writing SecureStop data as a file at the same path as the directory used by Legacy EME; meaning, when Modern EME attempts to write to that file, it will fail because a directory exists at the same path. Add a migration step to take care of those instances where Modern EME Secure Stop data was already written to disk, and move that previously written data to the correct file path. * platform/graphics/avfoundation/objc/CDMInstanceFairPlayStreamingAVFObjC.h: * platform/graphics/avfoundation/objc/CDMInstanceFairPlayStreamingAVFObjC.mm: (WebCore::CDMInstanceFairPlayStreamingAVFObjC::initializeWithConfiguration): (WebCore::CDMInstanceFairPlayStreamingAVFObjC::setStorageDirectory): (WebCore::CDMInstanceSessionFairPlayStreamingAVFObjC::updateLicense): (WebCore::CDMInstanceSessionFairPlayStreamingAVFObjC::loadSession): (WebCore::CDMInstanceSessionFairPlayStreamingAVFObjC::removeSessionData): (WebCore::CDMInstanceSessionFairPlayStreamingAVFObjC::ensureSession): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240804 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-31 Jer Noble [Cocoa][EME] Modern EME uses a different path for SecureStop data than Legacy EME https://bugs.webkit.org/show_bug.cgi?id=193988 Reviewed by Jon Lee. Modern EME is writing SecureStop data as a file at the same path as the directory used by Legacy EME; meaning, when Modern EME attempts to write to that file, it will fail because a directory exists at the same path. Add a migration step to take care of those instances where Modern EME Secure Stop data was already written to disk, and move that previously written data to the correct file path. * platform/graphics/avfoundation/objc/CDMInstanceFairPlayStreamingAVFObjC.h: * platform/graphics/avfoundation/objc/CDMInstanceFairPlayStreamingAVFObjC.mm: (WebCore::CDMInstanceFairPlayStreamingAVFObjC::initializeWithConfiguration): (WebCore::CDMInstanceFairPlayStreamingAVFObjC::setStorageDirectory): (WebCore::CDMInstanceSessionFairPlayStreamingAVFObjC::updateLicense): (WebCore::CDMInstanceSessionFairPlayStreamingAVFObjC::loadSession): (WebCore::CDMInstanceSessionFairPlayStreamingAVFObjC::removeSessionData): (WebCore::CDMInstanceSessionFairPlayStreamingAVFObjC::ensureSession): 2019-02-06 Alan Coon Cherry-pick r240746. rdar://problem/47774550 [Cocoa][EME] persistent-usage-record data not issued after MediaKeySession.remove() https://bugs.webkit.org/show_bug.cgi?id=193984 Reviewed by Eric Carlson. MediaKeySession.sessionId is empty during the CDMInstance->requestLicense success callback handler. The KVO notification that AVContentKeySession.contentProtectionSessionIdentifier changed isn't called until after the -[AVContentKeyRequest makeStreamingContentKeyRequestDataForApp:contentIdentifier:options:completionHandler:] completion handler is called. Explicitly ask for the -contentProtectionSessionIdentifier inside that handler, and just in case the sessionID changes after that, add a new client callback method to notify the MediaKeySession that the ID has changed. * Modules/encryptedmedia/MediaKeySession.cpp: (WebCore::MediaKeySession::sessionIdChanged): * Modules/encryptedmedia/MediaKeySession.h: * platform/encryptedmedia/CDMInstanceSession.h: * platform/graphics/avfoundation/objc/CDMInstanceFairPlayStreamingAVFObjC.mm: (WebCore::CDMInstanceSessionFairPlayStreamingAVFObjC::didProvideRequest): (WebCore::CDMInstanceSessionFairPlayStreamingAVFObjC::nextRequest): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240746 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-30 Jer Noble [Cocoa][EME] persistent-usage-record data not issued after MediaKeySession.remove() https://bugs.webkit.org/show_bug.cgi?id=193984 Reviewed by Eric Carlson. MediaKeySession.sessionId is empty during the CDMInstance->requestLicense success callback handler. The KVO notification that AVContentKeySession.contentProtectionSessionIdentifier changed isn't called until after the -[AVContentKeyRequest makeStreamingContentKeyRequestDataForApp:contentIdentifier:options:completionHandler:] completion handler is called. Explicitly ask for the -contentProtectionSessionIdentifier inside that handler, and just in case the sessionID changes after that, add a new client callback method to notify the MediaKeySession that the ID has changed. * Modules/encryptedmedia/MediaKeySession.cpp: (WebCore::MediaKeySession::sessionIdChanged): * Modules/encryptedmedia/MediaKeySession.h: * platform/encryptedmedia/CDMInstanceSession.h: * platform/graphics/avfoundation/objc/CDMInstanceFairPlayStreamingAVFObjC.mm: (WebCore::CDMInstanceSessionFairPlayStreamingAVFObjC::didProvideRequest): (WebCore::CDMInstanceSessionFairPlayStreamingAVFObjC::nextRequest): 2019-02-05 Alan Coon Cherry-pick r239752. rdar://problem/47776478 [WebAuthN] Support U2F HID Authenticators on macOS https://bugs.webkit.org/show_bug.cgi?id=191535 Reviewed by Brent Fulgham. Source/WebCore: This patch changes U2fCommandConstructor to produce register commands with enforcing test of user presence. Otherwise, authenticators would silently generate credentials. It also renames readFromU2fSignResponse to readU2fSignResponse. Tests: http/wpt/webauthn/public-key-credential-create-failure-u2f-silent.https.html http/wpt/webauthn/public-key-credential-create-failure-u2f.https.html http/wpt/webauthn/public-key-credential-create-success-u2f.https.html http/wpt/webauthn/public-key-credential-get-failure-u2f-silent.https.html http/wpt/webauthn/public-key-credential-get-failure-u2f.https.html http/wpt/webauthn/public-key-credential-get-success-u2f.https.html * Modules/webauthn/fido/U2fCommandConstructor.cpp: (fido::WebCore::constructU2fRegisterCommand): * Modules/webauthn/fido/U2fResponseConverter.cpp: (fido::readU2fSignResponse): (fido::readFromU2fSignResponse): Deleted. * Modules/webauthn/fido/U2fResponseConverter.h: Source/WebKit: This patch implements the support for U2F authenticators, and enables it for hid devices. It follows the CTAP spec to map WebAuthN requests to U2F commands and return the responses: https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-client-to-authenticator-protocol-v2.0-id-20180227.html#u2f-interoperability Most of the parts are done before this patch, this patch focues on: 7.2.2 and 7.3.2. Besides implementing the U2fHidAuthenticator, this patch also adds support in the mocking environment for U2F authenticators. It is done by extending the stages in MockHidConnection from 4 to indefinite as multi-round communications are expected to map WebAuthN requests to U2F requests. * Sources.txt: * UIProcess/API/C/WKWebsiteDataStoreRef.cpp: (WKWebsiteDataStoreSetWebAuthenticationMockConfiguration): * UIProcess/WebAuthentication/Cocoa/HidService.mm: (WebKit::HidService::continueAddDeviceAfterGetInfo): * UIProcess/WebAuthentication/fido/CtapHidDriver.cpp: (WebKit::CtapHidDriver::continueAfterChannelAllocated): * UIProcess/WebAuthentication/fido/CtapHidDriver.h: (WebKit::CtapHidDriver::setProtocol): * UIProcess/WebAuthentication/fido/U2fHidAuthenticator.cpp: Added. (WebKit::U2fHidAuthenticator::U2fHidAuthenticator): (WebKit::U2fHidAuthenticator::makeCredential): (WebKit::U2fHidAuthenticator::checkExcludeList): (WebKit::U2fHidAuthenticator::issueRegisterCommand): (WebKit::U2fHidAuthenticator::getAssertion): (WebKit::U2fHidAuthenticator::issueSignCommand): (WebKit::U2fHidAuthenticator::issueNewCommand): (WebKit::U2fHidAuthenticator::issueCommand): (WebKit::U2fHidAuthenticator::responseReceived): (WebKit::U2fHidAuthenticator::continueRegisterCommandAfterResponseReceived): (WebKit::U2fHidAuthenticator::continueCheckOnlyCommandAfterResponseReceived): (WebKit::U2fHidAuthenticator::continueBogusCommandAfterResponseReceived): (WebKit::U2fHidAuthenticator::continueSignCommandAfterResponseReceived): * UIProcess/WebAuthentication/fido/U2fHidAuthenticator.h: Added. * UIProcess/WebAuthentication/Mock/MockHidConnection.cpp: (WebKit::MockHidConnection::parseRequest): (WebKit::MockHidConnection::feedReports): * UIProcess/WebAuthentication/Mock/MockHidConnection.h: * UIProcess/WebAuthentication/Mock/MockWebAuthenticationConfiguration.h: * WebKit.xcodeproj/project.pbxproj: Tools: This patch: 1) adds support for U2F mocking mechanism; 2) updates tests to reflect U2fCommandConstructor changes. * TestWebKitAPI/Tests/WebCore/CtapResponseTest.cpp: (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/WebCore/FidoTestData.h: * WebKitTestRunner/InjectedBundle/TestRunner.cpp: (WTR::TestRunner::setWebAuthenticationMockConfiguration): LayoutTests: Besiding adding tests for U2F authenticators, it also changes payloadBase64 from a string to a vector of strings. New tests are skipped for iOS. * http/wpt/webauthn/ctap-hid-failure.https.html: * http/wpt/webauthn/ctap-hid-success.https.html: * http/wpt/webauthn/public-key-credential-create-failure-hid-silent.https.html: * http/wpt/webauthn/public-key-credential-create-failure-hid.https.html: * http/wpt/webauthn/public-key-credential-create-failure-u2f-silent.https-expected.txt: Added. * http/wpt/webauthn/public-key-credential-create-failure-u2f-silent.https.html: Added. * http/wpt/webauthn/public-key-credential-create-failure-u2f.https-expected.txt: Added. * http/wpt/webauthn/public-key-credential-create-failure-u2f.https.html: Added. * http/wpt/webauthn/public-key-credential-create-success-hid.https.html: * http/wpt/webauthn/public-key-credential-create-success-u2f.https-expected.txt: Added. * http/wpt/webauthn/public-key-credential-create-success-u2f.https.html: Copied from LayoutTests/http/wpt/webauthn/public-key-credential-create-success-hid.https.html. * http/wpt/webauthn/public-key-credential-get-failure-hid-silent.https.html: * http/wpt/webauthn/public-key-credential-get-failure-hid.https.html: * http/wpt/webauthn/public-key-credential-get-failure-u2f-silent.https-expected.txt: Added. * http/wpt/webauthn/public-key-credential-get-failure-u2f-silent.https.html: Added. * http/wpt/webauthn/public-key-credential-get-failure-u2f.https-expected.txt: Added. * http/wpt/webauthn/public-key-credential-get-failure-u2f.https.html: Added. * http/wpt/webauthn/public-key-credential-get-success-hid.https.html: * http/wpt/webauthn/public-key-credential-get-success-u2f.https-expected.txt: Added. * http/wpt/webauthn/public-key-credential-get-success-u2f.https.html: Added. * http/wpt/webauthn/resources/util.js: * platform/ios-wk2/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239752 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-08 Jiewen Tan [WebAuthN] Support U2F HID Authenticators on macOS https://bugs.webkit.org/show_bug.cgi?id=191535 Reviewed by Brent Fulgham. This patch changes U2fCommandConstructor to produce register commands with enforcing test of user presence. Otherwise, authenticators would silently generate credentials. It also renames readFromU2fSignResponse to readU2fSignResponse. Tests: http/wpt/webauthn/public-key-credential-create-failure-u2f-silent.https.html http/wpt/webauthn/public-key-credential-create-failure-u2f.https.html http/wpt/webauthn/public-key-credential-create-success-u2f.https.html http/wpt/webauthn/public-key-credential-get-failure-u2f-silent.https.html http/wpt/webauthn/public-key-credential-get-failure-u2f.https.html http/wpt/webauthn/public-key-credential-get-success-u2f.https.html * Modules/webauthn/fido/U2fCommandConstructor.cpp: (fido::WebCore::constructU2fRegisterCommand): * Modules/webauthn/fido/U2fResponseConverter.cpp: (fido::readU2fSignResponse): (fido::readFromU2fSignResponse): Deleted. * Modules/webauthn/fido/U2fResponseConverter.h: 2019-02-05 Alan Coon Cherry-pick r240930. rdar://problem/47810469 Make sure to remove the device observer in AVVideoCaptureSource https://bugs.webkit.org/show_bug.cgi?id=194181 Reviewed by Eric Carlson. Make sure to remove the device observer when the observer is destroyed. To simplify things, add the observer in AVVideoCaptureSource constructor and remove it in the destructor. Make also sure the session observer is also removed whenever the session is released by AVVideoCaptureSource. Covered by manual test. * platform/mediastream/mac/AVVideoCaptureSource.h: * platform/mediastream/mac/AVVideoCaptureSource.mm: (WebCore::AVVideoCaptureSource::AVVideoCaptureSource): (WebCore::AVVideoCaptureSource::~AVVideoCaptureSource): (WebCore::AVVideoCaptureSource::initializeSession): (WebCore::AVVideoCaptureSource::clearSession): (WebCore::AVVideoCaptureSource::stopProducingData): (WebCore::AVVideoCaptureSource::setupSession): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240930 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-04 Youenn Fablet Make sure to remove the device observer in AVVideoCaptureSource https://bugs.webkit.org/show_bug.cgi?id=194181 Reviewed by Eric Carlson. Make sure to remove the device observer when the observer is destroyed. To simplify things, add the observer in AVVideoCaptureSource constructor and remove it in the destructor. Make also sure the session observer is also removed whenever the session is released by AVVideoCaptureSource. Covered by manual test. * platform/mediastream/mac/AVVideoCaptureSource.h: * platform/mediastream/mac/AVVideoCaptureSource.mm: (WebCore::AVVideoCaptureSource::AVVideoCaptureSource): (WebCore::AVVideoCaptureSource::~AVVideoCaptureSource): (WebCore::AVVideoCaptureSource::initializeSession): (WebCore::AVVideoCaptureSource::clearSession): (WebCore::AVVideoCaptureSource::stopProducingData): (WebCore::AVVideoCaptureSource::setupSession): 2019-02-05 Alan Coon Cherry-pick r240880. rdar://problem/47774545 REGRESSION: Flaky ASSERTION FAILED: m_uncommittedState.state == State::Committed on http/tests/cookies/same-site/fetch-after-top-level-navigation-initiated-from-iframe-in-cross-origin-page.html https://bugs.webkit.org/show_bug.cgi?id=193740 Reviewed by Alex Christensen. Source/WebCore: * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::willSendRequest): (WebCore::DocumentLoader::continueAfterContentPolicy): * loader/FrameLoader.cpp: (WebCore::FrameLoader::loadURL): (WebCore::FrameLoader::loadWithDocumentLoader): (WebCore::FrameLoader::continueLoadAfterNavigationPolicy): * loader/FrameLoader.h: * loader/FrameLoaderTypes.h: * loader/PolicyChecker.cpp: (WebCore::PolicyChecker::checkNavigationPolicy): (WebCore::PolicyChecker::checkNewWindowPolicy): * loader/PolicyChecker.h: Source/WebKit: The issue was happening when the page is triggering a cross-site navigation while in the middle of parsing. This would cause us to start a new provisional load in a new process before the previous process sends the DidFinishLoadForFrame() IPC to the UIProcess. Getting such IPC after a provisional load has started would mess up our state machine and trip assertions. This patch restores non-PSON behavior which is that the previous load in the old process now gets stopped so that no DidFinishLoadForFrame() / DidFailLoadForFrame() gets sent. To achieve this behavior, I introduced a new "StopAllLoads" PolicyAction that we now send the old process when the load is continuing in a new process, instead of sending it "Ignore". * NetworkProcess/NetworkDataTaskBlob.cpp: (WebKit::NetworkDataTaskBlob::dispatchDidReceiveResponse): * NetworkProcess/cocoa/NetworkSessionCocoa.mm: (toNSURLSessionResponseDisposition): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::receivedNavigationPolicyDecision): Tools: Add API test coverage. * TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240880 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-01 Chris Dumez REGRESSION: Flaky ASSERTION FAILED: m_uncommittedState.state == State::Committed on http/tests/cookies/same-site/fetch-after-top-level-navigation-initiated-from-iframe-in-cross-origin-page.html https://bugs.webkit.org/show_bug.cgi?id=193740 Reviewed by Alex Christensen. * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::willSendRequest): (WebCore::DocumentLoader::continueAfterContentPolicy): * loader/FrameLoader.cpp: (WebCore::FrameLoader::loadURL): (WebCore::FrameLoader::loadWithDocumentLoader): (WebCore::FrameLoader::continueLoadAfterNavigationPolicy): * loader/FrameLoader.h: * loader/FrameLoaderTypes.h: * loader/PolicyChecker.cpp: (WebCore::PolicyChecker::checkNavigationPolicy): (WebCore::PolicyChecker::checkNewWindowPolicy): * loader/PolicyChecker.h: 2019-02-05 Alan Coon Cherry-pick r240833. rdar://problem/47774523 [Cocoa][EME] AirPlaying a FairPlay-protected HLS stream fails to decrypt https://bugs.webkit.org/show_bug.cgi?id=194114 Reviewed by Eric Carlson. The AVAssetResourceLoaderDelegate must explicitly... delegate responsibility for FairPlay key requests to the AVContentKeySession. * platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm: (WebCore::MediaPlayerPrivateAVFoundationObjC::shouldWaitForLoadingOfResource): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240833 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-31 Jer Noble [Cocoa][EME] AirPlaying a FairPlay-protected HLS stream fails to decrypt https://bugs.webkit.org/show_bug.cgi?id=194114 Reviewed by Eric Carlson. The AVAssetResourceLoaderDelegate must explicitly... delegate responsibility for FairPlay key requests to the AVContentKeySession. * platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm: (WebCore::MediaPlayerPrivateAVFoundationObjC::shouldWaitForLoadingOfResource): 2019-02-05 Alan Coon Cherry-pick r240822. rdar://problem/47774539 [Mac] Requesting PiP from two different WebViews gets PiP window "stuck" https://bugs.webkit.org/show_bug.cgi?id=194099 Reviewed by Eric Carlson. When a different client requests the PiP window, the PiP framework will call -pipDidClose: without first calling -pipActionStop:. This leaves the internal fullscreen state in a confused state where the WebView will attempt to re-enter PiP once it gets focus, and can lead to a state where the two WebViews will constantly try to steal PiP from one another, ad infinitum. When receiving a notification that the PiP window closed when our internal state tells us that the close was not requested, notify the client that PiP mode was exited, allowing them to set their expected state to a correct and sane value. * platform/mac/VideoFullscreenInterfaceMac.mm: (-[WebVideoFullscreenInterfaceMacObjC pipDidClose:]): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240822 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-31 Jer Noble [Mac] Requesting PiP from two different WebViews gets PiP window "stuck" https://bugs.webkit.org/show_bug.cgi?id=194099 Reviewed by Eric Carlson. When a different client requests the PiP window, the PiP framework will call -pipDidClose: without first calling -pipActionStop:. This leaves the internal fullscreen state in a confused state where the WebView will attempt to re-enter PiP once it gets focus, and can lead to a state where the two WebViews will constantly try to steal PiP from one another, ad infinitum. When receiving a notification that the PiP window closed when our internal state tells us that the close was not requested, notify the client that PiP mode was exited, allowing them to set their expected state to a correct and sane value. * platform/mac/VideoFullscreenInterfaceMac.mm: (-[WebVideoFullscreenInterfaceMacObjC pipDidClose:]): 2019-02-05 Alan Coon Cherry-pick r240773. rdar://problem/47774755 ASSERTION FAILED: cache under WebCore::AXObjectCache::postTextStateChangePlatformNotification https://bugs.webkit.org/show_bug.cgi?id=189094 Reviewed by Zalan Bujtas. Source/WebCore: Protect against access to objects and cache's that can be removed while an object is still in memory. Unskipped flaky tests on mac-wk2. * accessibility/mac/AXObjectCacheMac.mm: (WebCore::AXObjectCache::postTextStateChangePlatformNotification): * accessibility/mac/WebAccessibilityObjectWrapperMac.mm: (textMarkerForVisiblePosition): (textMarkerRangeFromVisiblePositions): LayoutTests: Unskip flaky test with crash resolved. * platform/mac-wk2/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240773 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-31 Chris Fleizach ASSERTION FAILED: cache under WebCore::AXObjectCache::postTextStateChangePlatformNotification https://bugs.webkit.org/show_bug.cgi?id=189094 Reviewed by Zalan Bujtas. Protect against access to objects and cache's that can be removed while an object is still in memory. Unskipped flaky tests on mac-wk2. * accessibility/mac/AXObjectCacheMac.mm: (WebCore::AXObjectCache::postTextStateChangePlatformNotification): * accessibility/mac/WebAccessibilityObjectWrapperMac.mm: (textMarkerForVisiblePosition): (textMarkerRangeFromVisiblePositions): 2019-02-05 Alan Coon Cherry-pick r240750. rdar://problem/47774507 Regression(PSON) History navigations to twitter.com lead to a 403 HTTP error https://bugs.webkit.org/show_bug.cgi?id=194023 Reviewed by Geoffrey Garen. Source/WebCore: The issue was caused by the 'isTopSite' flag not getting properly set on the network request in case of a cross-site history navigation (with process-swap). As a result, twitter.com was not getting its same-site lax cookies. The 'isTopSite' flag normally gets set by FrameLoader::addExtraFieldsToRequest(), but we were bypassing this method entirely when continuing a load in a new process after a swap. This was intentional as the network request is normally already fully populated by the previous process and we do not want the new process to modify the request in any way (e.g. we would not want to add a Origin header back after it was removed by the previous process). However, in case of a History navigation, we do not actually pass a request along from one process to another. Instead, we pass a HistoryItem and then build a fresh new request from the HistoryItem in the new process. In this case, we *want* addExtraFieldsToRequest() to be called on the new request, even though we are technically continuing a load in a new process. We thus address the issue by bypassing FrameLoader::addExtraFieldsToRequest() only if we're continuing a load with a request and not when we're continuing a load with a HistoryItem. Test: http/tests/cookies/same-site/lax-samesite-cookie-after-cross-site-history-load.php * loader/FrameLoader.cpp: (WebCore::FrameLoader::load): (WebCore::FrameLoader::loadWithDocumentLoader): (WebCore::FrameLoader::addExtraFieldsToRequest): (WebCore::FrameLoader::loadDifferentDocumentItem): * loader/FrameLoader.h: (WebCore::FrameLoader::shouldTreatCurrentLoadAsContinuingLoad const): LayoutTests: Add layout test coverage. * http/tests/cookies/same-site/lax-samesite-cookie-after-cross-site-history-load-expected.txt: Added. * http/tests/cookies/same-site/lax-samesite-cookie-after-cross-site-history-load.php: Added. * http/tests/cookies/same-site/resources/navigate-back.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240750 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-30 Chris Dumez Regression(PSON) History navigations to twitter.com lead to a 403 HTTP error https://bugs.webkit.org/show_bug.cgi?id=194023 Reviewed by Geoffrey Garen. The issue was caused by the 'isTopSite' flag not getting properly set on the network request in case of a cross-site history navigation (with process-swap). As a result, twitter.com was not getting its same-site lax cookies. The 'isTopSite' flag normally gets set by FrameLoader::addExtraFieldsToRequest(), but we were bypassing this method entirely when continuing a load in a new process after a swap. This was intentional as the network request is normally already fully populated by the previous process and we do not want the new process to modify the request in any way (e.g. we would not want to add a Origin header back after it was removed by the previous process). However, in case of a History navigation, we do not actually pass a request along from one process to another. Instead, we pass a HistoryItem and then build a fresh new request from the HistoryItem in the new process. In this case, we *want* addExtraFieldsToRequest() to be called on the new request, even though we are technically continuing a load in a new process. We thus address the issue by bypassing FrameLoader::addExtraFieldsToRequest() only if we're continuing a load with a request and not when we're continuing a load with a HistoryItem. Test: http/tests/cookies/same-site/lax-samesite-cookie-after-cross-site-history-load.php * loader/FrameLoader.cpp: (WebCore::FrameLoader::load): (WebCore::FrameLoader::loadWithDocumentLoader): (WebCore::FrameLoader::addExtraFieldsToRequest): (WebCore::FrameLoader::loadDifferentDocumentItem): * loader/FrameLoader.h: (WebCore::FrameLoader::shouldTreatCurrentLoadAsContinuingLoad const): 2019-02-05 Alan Coon Cherry-pick r240727. rdar://problem/47776358 LayoutTests/imported/w3c: ServiceWorkerJob should notify its client in case its job is cancelled https://bugs.webkit.org/show_bug.cgi?id=193747 Reviewed by Chris Dumez. * web-platform-tests/service-workers/service-worker/registration-security-error.https-expected.txt: Source/WebCore: Refactor ServiceWorkerJob management by ServiceWorkerContainer to make it more memory safe https://bugs.webkit.org/show_bug.cgi?id=193747 Reviewed by Chris Dumez. Make ServiceWorkerJob be no longer ref counted. Instead its lifetime is fully controlled by ServiceWorkerContainer. Make sure that a failing load will remove the job from ServiceWorkerContainer job map. This allows to ensure that these jobs do not stay forever. Before the patch, the jobs map was never cleared, which is creating a ref cycle whenever a job is not succesful. Before the patch, unsetPendingActivity was only called for successful jobs finishing. In case of failing loads, ServiceWorkerContainer would leak. Make sure that setPendingActivity/unsetPendingActivity is balanced by storing a pending activity in the job map next to the job. When ServiceWorkerContainer is stopped, notify that all jobs are cancelled to NetworkProcess. This makes these jobs in NetworkProcess-side to not stay until the corresponding WebProcess is gone. Simplify ServiceWorkerJob promise rejection handling so that it is clear when promise is rejected and when it is not. Update type of exception to be SecurityError when load fails due to AccessControl. Covered by existing tests. * workers/service/ServiceWorkerContainer.cpp: (WebCore::ServiceWorkerContainer::addRegistration): (WebCore::ServiceWorkerContainer::removeRegistration): (WebCore::ServiceWorkerContainer::updateRegistration): (WebCore::ServiceWorkerContainer::scheduleJob): (WebCore::ServiceWorkerContainer::jobFailedWithException): (WebCore::ServiceWorkerContainer::jobResolvedWithRegistration): (WebCore::ServiceWorkerContainer::jobResolvedWithUnregistrationResult): (WebCore::ServiceWorkerContainer::jobFailedLoadingScript): (WebCore::ServiceWorkerContainer::jobDidFinish): (WebCore::ServiceWorkerContainer::stop): (WebCore::ServiceWorkerContainer::job): * workers/service/ServiceWorkerContainer.h: * workers/service/ServiceWorkerJob.cpp: (WebCore::ServiceWorkerJob::failedWithException): (WebCore::ServiceWorkerJob::resolvedWithRegistration): (WebCore::ServiceWorkerJob::resolvedWithUnregistrationResult): (WebCore::ServiceWorkerJob::startScriptFetch): (WebCore::ServiceWorkerJob::didReceiveResponse): (WebCore::ServiceWorkerJob::notifyFinished): (WebCore::ServiceWorkerJob::cancelPendingLoad): * workers/service/ServiceWorkerJob.h: (WebCore::ServiceWorkerJob::hasPromise const): (WebCore::ServiceWorkerJob::takePromise): * workers/service/ServiceWorkerJobClient.h: * workers/service/server/SWServerJobQueue.cpp: (WebCore::SWServerJobQueue::scriptFetchFinished): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240727 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-30 Youenn Fablet Refactor ServiceWorkerJob management by ServiceWorkerContainer to make it more memory safe https://bugs.webkit.org/show_bug.cgi?id=193747 Reviewed by Chris Dumez. Make ServiceWorkerJob be no longer ref counted. Instead its lifetime is fully controlled by ServiceWorkerContainer. Make sure that a failing load will remove the job from ServiceWorkerContainer job map. This allows to ensure that these jobs do not stay forever. Before the patch, the jobs map was never cleared, which is creating a ref cycle whenever a job is not succesful. Before the patch, unsetPendingActivity was only called for successful jobs finishing. In case of failing loads, ServiceWorkerContainer would leak. Make sure that setPendingActivity/unsetPendingActivity is balanced by storing a pending activity in the job map next to the job. When ServiceWorkerContainer is stopped, notify that all jobs are cancelled to NetworkProcess. This makes these jobs in NetworkProcess-side to not stay until the corresponding WebProcess is gone. Simplify ServiceWorkerJob promise rejection handling so that it is clear when promise is rejected and when it is not. Update type of exception to be SecurityError when load fails due to AccessControl. Covered by existing tests. * workers/service/ServiceWorkerContainer.cpp: (WebCore::ServiceWorkerContainer::addRegistration): (WebCore::ServiceWorkerContainer::removeRegistration): (WebCore::ServiceWorkerContainer::updateRegistration): (WebCore::ServiceWorkerContainer::scheduleJob): (WebCore::ServiceWorkerContainer::jobFailedWithException): (WebCore::ServiceWorkerContainer::jobResolvedWithRegistration): (WebCore::ServiceWorkerContainer::jobResolvedWithUnregistrationResult): (WebCore::ServiceWorkerContainer::jobFailedLoadingScript): (WebCore::ServiceWorkerContainer::jobDidFinish): (WebCore::ServiceWorkerContainer::stop): (WebCore::ServiceWorkerContainer::job): * workers/service/ServiceWorkerContainer.h: * workers/service/ServiceWorkerJob.cpp: (WebCore::ServiceWorkerJob::failedWithException): (WebCore::ServiceWorkerJob::resolvedWithRegistration): (WebCore::ServiceWorkerJob::resolvedWithUnregistrationResult): (WebCore::ServiceWorkerJob::startScriptFetch): (WebCore::ServiceWorkerJob::didReceiveResponse): (WebCore::ServiceWorkerJob::notifyFinished): (WebCore::ServiceWorkerJob::cancelPendingLoad): * workers/service/ServiceWorkerJob.h: (WebCore::ServiceWorkerJob::hasPromise const): (WebCore::ServiceWorkerJob::takePromise): * workers/service/ServiceWorkerJobClient.h: * workers/service/server/SWServerJobQueue.cpp: (WebCore::SWServerJobQueue::scriptFetchFinished): 2019-02-05 Alan Coon Cherry-pick r240709. rdar://problem/47776349 AX: Role=switch not returning correct accessibilityValue https://bugs.webkit.org/show_bug.cgi?id=194006 Reviewed by Joanmarie Diggs. Source/WebCore: Return the toggle state of a role=switch element. Test: accessibility/ios-simulator/role-switch.html * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper accessibilityValue]): LayoutTests: * accessibility/ios-simulator/role-switch-expected.txt: Added. * accessibility/ios-simulator/role-switch.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240709 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-30 Chris Fleizach AX: Role=switch not returning correct accessibilityValue https://bugs.webkit.org/show_bug.cgi?id=194006 Reviewed by Joanmarie Diggs. Return the toggle state of a role=switch element. Test: accessibility/ios-simulator/role-switch.html * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper accessibilityValue]): 2019-02-05 Alan Coon Cherry-pick r240697. rdar://problem/47774541 Make sure we have a frame before trying to access its loader https://bugs.webkit.org/show_bug.cgi?id=193985 Reviewed by Ryosuke Niwa. * loader/ResourceLoadObserver.cpp: (WebCore::ResourceLoadObserver::logUserInteractionWithReducedTimeResolution): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240697 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-29 Brent Fulgham Make sure we have a frame before trying to access its loader https://bugs.webkit.org/show_bug.cgi?id=193985 Reviewed by Ryosuke Niwa. * loader/ResourceLoadObserver.cpp: (WebCore::ResourceLoadObserver::logUserInteractionWithReducedTimeResolution): 2019-02-05 Alan Coon Cherry-pick r240643. rdar://problem/47774515 webkitcurrentplaybacktargetiswirelesschanged and webkitCurrentPlaybackIsWireless are non-deterministic. https://bugs.webkit.org/show_bug.cgi?id=193923 Reviewed by Eric Carlson. The value of webkitCurrentPlaybackTargetIsWireless can change in between when the event is scheduled and when it's actually dispatched. To make this more deterministic, use a GenericTaskQueue to enqueue setting m_isPlayingToWirelessTarget and dispatch the changed event in the same run-loop. * html/HTMLMediaElement.cpp: (WebCore::HTMLMediaElement::clearMediaPlayer): (WebCore::HTMLMediaElement::mediaPlayerCurrentPlaybackTargetIsWirelessChanged): (WebCore::HTMLMediaElement::setIsPlayingToWirelessTarget): (WebCore::HTMLMediaElement::dispatchEvent): * html/HTMLMediaElement.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240643 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-28 Jer Noble webkitcurrentplaybacktargetiswirelesschanged and webkitCurrentPlaybackIsWireless are non-deterministic. https://bugs.webkit.org/show_bug.cgi?id=193923 Reviewed by Eric Carlson. The value of webkitCurrentPlaybackTargetIsWireless can change in between when the event is scheduled and when it's actually dispatched. To make this more deterministic, use a GenericTaskQueue to enqueue setting m_isPlayingToWirelessTarget and dispatch the changed event in the same run-loop. * html/HTMLMediaElement.cpp: (WebCore::HTMLMediaElement::clearMediaPlayer): (WebCore::HTMLMediaElement::mediaPlayerCurrentPlaybackTargetIsWirelessChanged): (WebCore::HTMLMediaElement::setIsPlayingToWirelessTarget): (WebCore::HTMLMediaElement::dispatchEvent): * html/HTMLMediaElement.h: 2019-02-05 Alan Coon Cherry-pick r240537. rdar://problem/47774500