2021-04-27 Alan Coon Added blobOwner declaration from trac.webkit.org/r276230. 2021-04-27 Russell Epstein Cherry-pick r276357. rdar://problem/77211423 REGRESSION(r256107): Text moves around when selecting at https://www.tokyo-sports.co.jp/entame/news/2834187/ https://bugs.webkit.org/show_bug.cgi?id=224839 Reviewed by Darin Adler. Source/WebCore: Pass in locale information when constructing the text iterator for the content (locale affects soft wrap opportunities). Test: fast/text/line-break-with-locale.html * layout/inlineformatting/InlineTextItem.cpp: (WebCore::Layout::InlineTextItem::createAndAppendTextItems): * layout/inlineformatting/text/TextUtil.cpp: In addition to locale, add missing line breaking mode. (WebCore::Layout::TextUtil::lineBreakIteratorMode): * layout/inlineformatting/text/TextUtil.h: LayoutTests: * fast/text/line-break-with-locale-expected.html: Added. * fast/text/line-break-with-locale.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@276357 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-04-21 Zalan Bujtas REGRESSION(r256107): Text moves around when selecting at https://www.tokyo-sports.co.jp/entame/news/2834187/ https://bugs.webkit.org/show_bug.cgi?id=224839 Reviewed by Darin Adler. Pass in locale information when constructing the text iterator for the content (locale affects soft wrap opportunities). Test: fast/text/line-break-with-locale.html * layout/inlineformatting/InlineTextItem.cpp: (WebCore::Layout::InlineTextItem::createAndAppendTextItems): * layout/inlineformatting/text/TextUtil.cpp: In addition to locale, add missing line breaking mode. (WebCore::Layout::TextUtil::lineBreakIteratorMode): * layout/inlineformatting/text/TextUtil.h: 2021-04-27 Russell Epstein Cherry-pick r276352. rdar://problem/77211405 Use BlobURL::getOriginURL in more places https://bugs.webkit.org/show_bug.cgi?id=224857 Reviewed by Alex Christensen. Covered by existing tests. * loader/PolicyChecker.cpp: (WebCore::FrameLoader::PolicyChecker::extendBlobURLLifetimeIfNecessary const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@276352 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-04-21 Youenn Fablet Use BlobURL::getOriginURL in more places https://bugs.webkit.org/show_bug.cgi?id=224857 Reviewed by Alex Christensen. Covered by existing tests. * loader/PolicyChecker.cpp: (WebCore::FrameLoader::PolicyChecker::extendBlobURLLifetimeIfNecessary const): 2021-04-27 Russell Epstein Cherry-pick r276012. rdar://problem/77211405 REGRESSION(Safari 14): iframe with blob url does not work with sandboxing https://bugs.webkit.org/show_bug.cgi?id=222312 Reviewed by Chris Dumez. Source/WebCore: In https://trac.webkit.org/r275884, we correctly compute whether a blob is to be considered secure or not. For that, we need to have the blob URL registered with its document origin. Update PolicyChecker to properly register the temporoary blob URL with its document origin. Test: http/tests/security/sandbox-iframe-and-blob.https.html * loader/PolicyChecker.cpp: (WebCore::FrameLoader::PolicyChecker::extendBlobURLLifetimeIfNecessary const): LayoutTests: * http/tests/security/resources/sandbox-iframe-and-blob-frame.html: Added. * http/tests/security/sandbox-iframe-and-blob.https-expected.txt: Added. * http/tests/security/sandbox-iframe-and-blob.https.html: Added. * platform/win/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@276012 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-04-15 Youenn Fablet REGRESSION(Safari 14): iframe with blob url does not work with sandboxing https://bugs.webkit.org/show_bug.cgi?id=222312 Reviewed by Chris Dumez. In https://trac.webkit.org/r275884, we correctly compute whether a blob is to be considered secure or not. For that, we need to have the blob URL registered with its document origin. Update PolicyChecker to properly register the temporoary blob URL with its document origin. Test: http/tests/security/sandbox-iframe-and-blob.https.html * loader/PolicyChecker.cpp: (WebCore::FrameLoader::PolicyChecker::extendBlobURLLifetimeIfNecessary const): 2021-04-27 Russell Epstein Cherry-pick r276611. rdar://problem/77211533 Remove redundant frameDetached() from the SVGImage destructor https://bugs.webkit.org/show_bug.cgi?id=221616 Reviewed by Chris Dumez. SVGImage was originally written such that it has two separate objects: a page and a frame; see https://trac.webkit.org/r18470. So it made sense at that time to clean up the page and the frame separately. The Frame was cleaned up by telling the frame's loader that the frameDetached(). This code is not necessary right now since the page owns the main frame. And its destructor recursively detaches itself from all the frames. * svg/graphics/SVGImage.cpp: (WebCore::SVGImage::~SVGImage): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@276611 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-04-26 Said Abou-Hallawa Remove redundant frameDetached() from the SVGImage destructor https://bugs.webkit.org/show_bug.cgi?id=221616 Reviewed by Chris Dumez. SVGImage was originally written such that it has two separate objects: a page and a frame; see https://trac.webkit.org/r18470. So it made sense at that time to clean up the page and the frame separately. The Frame was cleaned up by telling the frame's loader that the frameDetached(). This code is not necessary right now since the page owns the main frame. And its destructor recursively detaches itself from all the frames. * svg/graphics/SVGImage.cpp: (WebCore::SVGImage::~SVGImage): 2021-04-27 Russell Epstein Cherry-pick r276530. rdar://problem/77211441 Crash in constructCustomElementSynchronously https://bugs.webkit.org/show_bug.cgi?id=224992 Reviewed by Tadeu Zagallo. Exit early when the global object is nullptr although this shouldn't happen. No new tests since we have no reproductions. * bindings/js/JSCustomElementInterface.cpp: (WebCore::JSCustomElementInterface::tryToConstructCustomElement): Added a null check. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@276530 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-04-23 Ryosuke Niwa Crash in constructCustomElementSynchronously https://bugs.webkit.org/show_bug.cgi?id=224992 Reviewed by Tadeu Zagallo. Exit early when the global object is nullptr although this shouldn't happen. No new tests since we have no reproductions. * bindings/js/JSCustomElementInterface.cpp: (WebCore::JSCustomElementInterface::tryToConstructCustomElement): Added a null check. 2021-04-27 Russell Epstein Cherry-pick r274170. rdar://problem/77194450 REGRESSION (r273003): Animated style may lose original display property value https://bugs.webkit.org/show_bug.cgi?id=222979 rdar://75056684 Reviewed by Zalan Bujtas. Source/WebCore: Test: fast/animation/animation-display-style-adjustment.html The original (non-blockified) display property value is saved in the beginning of Style::Adjuster::adjust. It is needed to implement absolute positioning correctly in some situations. However with animations the style adjustment code may run twice on the same style and the second run will clobber the saved original value. * rendering/RenderTheme.cpp: (WebCore::RenderTheme::adjustStyle): * rendering/style/RenderStyle.h: (WebCore::RenderStyle::setDisplay): Always save the original value when setting the property normally. (WebCore::RenderStyle::setEffectiveDisplay): (WebCore::RenderStyle::setOriginalDisplay): Deleted. Add setEffectiveDisplay that doesn't affect the original value for adjuster use. * style/StyleAdjuster.cpp: (WebCore::Style::Adjuster::adjust const): Remove the saving of the original value. Use setEffectiveDisplay in all adjuster code, preserving the original value. (WebCore::Style::Adjuster::adjustDisplayContentsStyle const): (WebCore::Style::Adjuster::adjustSVGElementStyle): (WebCore::Style::Adjuster::adjustForSiteSpecificQuirks const): LayoutTests: * fast/animation/animation-display-style-adjustment-expected.html: Added. * fast/animation/animation-display-style-adjustment.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274170 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-09 Antti Koivisto REGRESSION (r273003): Animated style may lose original display property value https://bugs.webkit.org/show_bug.cgi?id=222979 rdar://75056684 Reviewed by Zalan Bujtas. Test: fast/animation/animation-display-style-adjustment.html The original (non-blockified) display property value is saved in the beginning of Style::Adjuster::adjust. It is needed to implement absolute positioning correctly in some situations. However with animations the style adjustment code may run twice on the same style and the second run will clobber the saved original value. * rendering/RenderTheme.cpp: (WebCore::RenderTheme::adjustStyle): * rendering/style/RenderStyle.h: (WebCore::RenderStyle::setDisplay): Always save the original value when setting the property normally. (WebCore::RenderStyle::setEffectiveDisplay): (WebCore::RenderStyle::setOriginalDisplay): Deleted. Add setEffectiveDisplay that doesn't affect the original value for adjuster use. * style/StyleAdjuster.cpp: (WebCore::Style::Adjuster::adjust const): Remove the saving of the original value. Use setEffectiveDisplay in all adjuster code, preserving the original value. (WebCore::Style::Adjuster::adjustDisplayContentsStyle const): (WebCore::Style::Adjuster::adjustSVGElementStyle): (WebCore::Style::Adjuster::adjustForSiteSpecificQuirks const): 2021-04-21 Ruben Turcios Cherry-pick r276010. rdar://problem/76962988 REGRESSION(r272900): Nullptr crash in ComposedTreeIterator::traverseNextInShadowTree() via ShadowRoot::hostChildElementDidChange https://bugs.webkit.org/show_bug.cgi?id=222720 Patch by Carlos Garcia Campos on 2021-04-15 Reviewed by Ryosuke Niwa. This patch reverts r274064 to apply a different fix. Instead of null-checking the nodes returned by SlotAssignment::assignedNodesForSlot(), assigned nodes are removed from the list when they are about to be removed from the parent. That ensures we never return nullptr nodes nor nodes with a nullptr parent from the assigned nodes vector. * dom/ComposedTreeIterator.cpp: (WebCore::ComposedTreeIterator::traverseNextInShadowTree): (WebCore::ComposedTreeIterator::advanceInSlot): * dom/ContainerNode.cpp: (WebCore::ContainerNode::removeBetween): * dom/Node.h: (WebCore::Node::hasShadowRootContainingSlots const): (WebCore::Node::setHasShadowRootContainingSlots): * dom/ShadowRoot.h: * dom/SlotAssignment.cpp: (WebCore::SlotAssignment::addSlotElementByName): (WebCore::SlotAssignment::removeSlotElementByName): (WebCore::SlotAssignment::willRemoveAssignedNode): * dom/SlotAssignment.h: (WebCore::ShadowRoot::willRemoveAssignedNode): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@276010 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-04-15 Carlos Garcia Campos REGRESSION(r272900): Nullptr crash in ComposedTreeIterator::traverseNextInShadowTree() via ShadowRoot::hostChildElementDidChange https://bugs.webkit.org/show_bug.cgi?id=222720 Reviewed by Ryosuke Niwa. This patch reverts r274064 to apply a different fix. Instead of null-checking the nodes returned by SlotAssignment::assignedNodesForSlot(), assigned nodes are removed from the list when they are about to be removed from the parent. That ensures we never return nullptr nodes nor nodes with a nullptr parent from the assigned nodes vector. * dom/ComposedTreeIterator.cpp: (WebCore::ComposedTreeIterator::traverseNextInShadowTree): (WebCore::ComposedTreeIterator::advanceInSlot): * dom/ContainerNode.cpp: (WebCore::ContainerNode::removeBetween): * dom/Node.h: (WebCore::Node::hasShadowRootContainingSlots const): (WebCore::Node::setHasShadowRootContainingSlots): * dom/ShadowRoot.h: * dom/SlotAssignment.cpp: (WebCore::SlotAssignment::addSlotElementByName): (WebCore::SlotAssignment::removeSlotElementByName): (WebCore::SlotAssignment::willRemoveAssignedNode): * dom/SlotAssignment.h: (WebCore::ShadowRoot::willRemoveAssignedNode): 2021-04-21 Ruben Turcios Cherry-pick r276206. rdar://problem/76962916 Perform port blocking earlier in the load https://bugs.webkit.org/show_bug.cgi?id=224525 Unreviewed follow-up (suggested by David Kilzer) * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::willSendRequest): Restore an m_frame nullptr check., git-svn-id: https://svn.webkit.org/repository/webkit/trunk@276206 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-04-17 Brent Fulgham Perform port blocking earlier in the load https://bugs.webkit.org/show_bug.cgi?id=224525 Unreviewed follow-up (suggested by David Kilzer) * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::willSendRequest): Restore an m_frame nullptr check., 2021-04-21 Ruben Turcios Cherry-pick r276193. rdar://problem/76962916 Perform port blocking earlier in the load https://bugs.webkit.org/show_bug.cgi?id=224525 Reviewed by Darin Adler. Source/WebCore: WebKit blocks loads to URLs with any of the prohibited ports defined in the engine. This blocking happens late in the load process, allowing connections to be made (and observed). Instead, we should stop the load early, at the same time we perform other checks. Test: http/tests/security/form-blocked-port.html * html/HTMLMediaElement.cpp: (WebCore::HTMLMediaElement::isSafeToLoadURL): Add a check for prohibited ports, and block (with relevant logging) if a load to a denied port is attempted. * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::willSendRequest): Ditto. * loader/FrameLoader.cpp: (WebCore::FrameLoader::loadFrameRequest): Ditto. (WebCore::FrameLoader::reportBlockedLoadFailed): Ditto. * loader/FrameLoader.h: * loader/PingLoader.cpp: (WebCore::PingLoader::loadImage): Ditto. * loader/ResourceLoader.cpp: (WebCore::ResourceLoader::init): Ditto. * loader/SubframeLoader.cpp: (WebCore::FrameLoader::SubframeLoader::pluginIsLoadable): Ditto. (WebCore::FrameLoader::SubframeLoader::loadSubframe): Ditto. * loader/cache/CachedResourceLoader.cpp: (WebCore::CachedResourceLoader::canRequest): Ditto. (WebCore::CachedResourceLoader::canRequestAfterRedirection const): Ditto. Tools: Update URLScheme test to use a non-prohibited port for the test. Tests of failed fetches are already handled in WPT and other tests, so using a valid port here should continue to be a valid test. * TestWebKitAPI/Tests/WebKitCocoa/WKURLSchemeHandler-1.mm: (-[FrameSchemeHandler webView:startURLSchemeTask:]): Use allowed port or the test instead of 123. LayoutTests: WebKit blocks loads to URLs with any of the prohibited ports defined in the engine. This blocking happens late in the load process, allowing connections to be made (and observed). Instead, we should stop the load early, at the same time we perform other checks. Note: The fact that we now block loads earlier means that we do not fire 'willSendRequestForFrame' for blocked ports, so WebKitTestRunner no longer outputs a message to stdout. Those errors are reported in the JS console, but since some test paths are specified to always output JS console messages to stderrr (for example the WPT tests), we have to revise out test expectations for a few cases. * fast/loader/cancel-load-during-port-block-timer.html: Revised expectation to reflect new console error message. * http/tests/cache/cancel-during-failure-crash-expected.txt: Ditto. * http/tests/preload/download_resources_from_invalid_headers-expected.txt: Update to reflect a preflight is not executed for a blocked port. * http/tests/preload/resources/nph-invalid_resources_from_header.pl: Update to reflect that we do not preload from restricted ports. * http/tests/security/blocked-on-redirect-expected.txt: Revised expectation to match revised error message. * http/tests/security/form-blocked-port.html: Added. * http/tests/security/form-blocked-port-expected.txt: Added. * http/tests/xmlhttprequest/cross-origin-redirect-responseURL-expected.txt: Revised expectation for revised error message. * http/tests/xmlhttprequest/redirect-cross-origin-2-expected.txt: Ditto. * http/tests/xmlhttprequest/redirect-cross-origin-expected.txt: Ditto. * http/tests/xmlhttprequest/simple-cross-origin-denied-events.html: Instead of using a port WebKit blocks (7), use one that is not blocked but is unlikely to be active (as originally intended). This retains the expected test behavior since we now block loads to restricted ports earlier in the load process. * http/tests/xmlhttprequest/simple-cross-origin-denied-events-post.html: Ditto. * http/tests/xmlhttprequest/simple-cross-origin-denied-events-post-expected.txt: Update test output to reflect that we are attempting to load from port 8 instead of port 7. * http/wpt/beacon/beacon-async-error-logging-expected.txt: Ditto. * http/wpt/beacon/beacon-async-error-logging.html: Update to reflect a preflight is not executed for a blocked port. * imported/w3c/web-platform-tests/fetch/api/request/request-bad-port.any-expected.txt: Since we block before executing the load, TestRunner no longer outputs an error message to stdout. Instead, they appear in stderr (since all 'wpt' tests are marked to dump console.log output to stderr). * imported/w3c/web-platform-tests/fetch/api/request/request-bad-port.any.worker-expected.txt: Ditto. * platform/mac-wk1/http/tests/xmlhttprequest/redirect-cross-origin-post-expected.txt: Revise to reflect change in console logging (the functional test results are identical). * platform/mac-wk1/http/tests/xmlhttprequest/simple-cross-origin-denied-events-post-expected.txt: Ditto. * platform/win/http/tests/xmlhttprequest/redirect-cross-origin-post-expected.txt: Ditto. * platform/win/http/tests/xmlhttprequest/simple-cross-origin-denied-events-post-expected.txt: Ditto. * platform/wk2/http/tests/security/blocked-on-redirect-expected.txt: Ditto. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@276193 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-04-16 Brent Fulgham Perform port blocking earlier in the load https://bugs.webkit.org/show_bug.cgi?id=224525 Reviewed by Darin Adler. WebKit blocks loads to URLs with any of the prohibited ports defined in the engine. This blocking happens late in the load process, allowing connections to be made (and observed). Instead, we should stop the load early, at the same time we perform other checks. Test: http/tests/security/form-blocked-port.html * html/HTMLMediaElement.cpp: (WebCore::HTMLMediaElement::isSafeToLoadURL): Add a check for prohibited ports, and block (with relevant logging) if a load to a denied port is attempted. * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::willSendRequest): Ditto. * loader/FrameLoader.cpp: (WebCore::FrameLoader::loadFrameRequest): Ditto. (WebCore::FrameLoader::reportBlockedLoadFailed): Ditto. * loader/FrameLoader.h: * loader/PingLoader.cpp: (WebCore::PingLoader::loadImage): Ditto. * loader/ResourceLoader.cpp: (WebCore::ResourceLoader::init): Ditto. * loader/SubframeLoader.cpp: (WebCore::FrameLoader::SubframeLoader::pluginIsLoadable): Ditto. (WebCore::FrameLoader::SubframeLoader::loadSubframe): Ditto. * loader/cache/CachedResourceLoader.cpp: (WebCore::CachedResourceLoader::canRequest): Ditto. (WebCore::CachedResourceLoader::canRequestAfterRedirection const): Ditto. 2021-04-21 Alan Coon Cherry-pick r274064. rdar://problem/76962988 REGRESSION(r272900): Nullptr crash in ComposedTreeIterator::traverseNextInShadowTree() via ShadowRoot::hostChildElementDidChange https://bugs.webkit.org/show_bug.cgi?id=222720 Patch by Carlos Garcia Campos on 2021-03-08 Reviewed by Ryosuke Niwa. Source/WebCore: The list of assigned nodes contains weak pointers, we should check the node hasn't been destroyed. Test: fast/html/details-set-inner-text-crash.html * dom/ComposedTreeIterator.cpp: (WebCore::ComposedTreeIterator::traverseNextInShadowTree): LayoutTests: * fast/html/details-set-inner-text-crash-expected.txt: Added. * fast/html/details-set-inner-text-crash.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274064 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-08 Carlos Garcia Campos REGRESSION(r272900): Nullptr crash in ComposedTreeIterator::traverseNextInShadowTree() via ShadowRoot::hostChildElementDidChange https://bugs.webkit.org/show_bug.cgi?id=222720 Reviewed by Ryosuke Niwa. The list of assigned nodes contains weak pointers, we should check the node hasn't been destroyed. Test: fast/html/details-set-inner-text-crash.html * dom/ComposedTreeIterator.cpp: (WebCore::ComposedTreeIterator::traverseNextInShadowTree): 2021-04-16 Russell Epstein Cherry-pick r275485. rdar://problem/76412930 Make sure we no longer show the previous page when running a JS prompt https://bugs.webkit.org/show_bug.cgi?id=215782 Reviewed by Darin Adler. Source/WebCore: Add linked-on-after check for the behavior change to minimize the risk of breakage. * platform/cocoa/VersionChecks.h: Source/WebKit: Make sure we no longer show the previous page when running a JS prompt. If we have not yet done a layer tree commit since the last load commit, then we are likely still showing the previous page. If we are asked to run a JS prompt / alert / confirm at this point, it would be confusing to still show the previous page. In order to address the issue, we now make the view blank in such scenario (ideally, we'd have painted the new page but this is currently not a trivial thing to do). To make the view blank, the approach chosen is the set the opacity of our root layer to 0 when the JS prompt is requested (before the first paint) and set the opacity back to 1 after the first paint. To minimize the risks of breakage, the behavior change is behind a linked-on-after check. Also, we only trigger this behavior if the WKWebView client actually implements the corresponding JS prompt delegate. * UIProcess/Cocoa/UIDelegate.mm: (WebKit::UIDelegate::UIClient::runJavaScriptAlert): (WebKit::UIDelegate::UIClient::runJavaScriptConfirm): (WebKit::UIDelegate::UIClient::runJavaScriptPrompt): * UIProcess/PageClient.h: (WebKit::PageClient::makeViewBlank): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::stopMakingViewBlankDueToLackOfRenderingUpdate): (WebKit::WebPageProxy::makeViewBlankIfUnpaintedSinceLastLoadCommit): (WebKit::WebPageProxy::didCommitLoadForFrame): (WebKit::WebPageProxy::runJavaScriptAlert): * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * UIProcess/ios/PageClientImplIOS.h: * UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::makeViewBlank): * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::didCommitLayerTree): * UIProcess/mac/PageClientImplMac.h: * UIProcess/mac/PageClientImplMac.mm: (WebKit::PageClientImpl::makeViewBlank): * UIProcess/mac/WebPageProxyMac.mm: (WebKit::WebPageProxy::didUpdateRenderingAfterCommittingLoad): * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::runJavaScriptAlert): (WebKit::WebChromeClient::runJavaScriptConfirm): (WebKit::WebChromeClient::runJavaScriptPrompt): Add flag to make sure pending async messages are processed *before* the JS prompt sync IPCs. Without this, it was possible for the UIProcess to receive the JS prompt IPC *before* the DidCommitLoadForFrame IPC, which would confuse our logic, since we would think this is a JS prompt for the previous page. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::didCommitLoad): * WebProcess/WebPage/WebPage.h: (WebKit::WebPage::sendSyncWithDelayedReply): * WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm: (WebKit::TiledCoreAnimationDrawingArea::updateRendering): * WebProcess/WebPage/mac/WebPageMac.mm: (WebKit::WebPage::didUpdateRendering): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@275485 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-04-05 Chris Dumez Make sure we no longer show the previous page when running a JS prompt https://bugs.webkit.org/show_bug.cgi?id=215782 Reviewed by Darin Adler. Add linked-on-after check for the behavior change to minimize the risk of breakage. * platform/cocoa/VersionChecks.h: 2021-04-16 Russell Epstein Cherry-pick r274819. rdar://problem/76373741 AVAudioSessionCaptureDeviceManager should use crossThreadCopy https://bugs.webkit.org/show_bug.cgi?id=223565 Reviewed by Youenn Fablet. Tested manually, this can only be tested on device. * platform/mediastream/CaptureDevice.h: Change access restriction for member variables from `private:` to `protected:` so derived classes can access them directly. * platform/mediastream/ios/AVAudioSessionCaptureDevice.h: * platform/mediastream/ios/AVAudioSessionCaptureDevice.mm: (WebCore::AVAudioSessionCaptureDevice::AVAudioSessionCaptureDevice): New constructor. (WebCore::AVAudioSessionCaptureDevice::isolatedCopy const): New. * platform/mediastream/ios/AVAudioSessionCaptureDeviceManager.mm: (WebCore::AVAudioSessionCaptureDeviceManager::refreshAudioCaptureDevices): Use `WTFMove(deviceList).isolatedCopy()` when moving from AVAudioSession queue to main thread. (WebCore::AVAudioSessionCaptureDeviceManager::getCaptureDevices): Ditto. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274819 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-22 Eric Carlson AVAudioSessionCaptureDeviceManager should use crossThreadCopy https://bugs.webkit.org/show_bug.cgi?id=223565 Reviewed by Youenn Fablet. Tested manually, this can only be tested on device. * platform/mediastream/CaptureDevice.h: Change access restriction for member variables from `private:` to `protected:` so derived classes can access them directly. * platform/mediastream/ios/AVAudioSessionCaptureDevice.h: * platform/mediastream/ios/AVAudioSessionCaptureDevice.mm: (WebCore::AVAudioSessionCaptureDevice::AVAudioSessionCaptureDevice): New constructor. (WebCore::AVAudioSessionCaptureDevice::isolatedCopy const): New. * platform/mediastream/ios/AVAudioSessionCaptureDeviceManager.mm: (WebCore::AVAudioSessionCaptureDeviceManager::refreshAudioCaptureDevices): Use `WTFMove(deviceList).isolatedCopy()` when moving from AVAudioSession queue to main thread. (WebCore::AVAudioSessionCaptureDeviceManager::getCaptureDevices): Ditto. 2021-04-16 Russell Epstein Apply patch. rdar://problem/76375504 2021-04-16 Antti Koivisto Animated pseudo element style resolved against wrong parent style https://bugs.webkit.org/show_bug.cgi?id=223990 rdar://74997361 In createAnimatedElementUpdate we get the parent and parent box styles from the parent stack. This is wrong for pseudo elements. Their parent style should the host style which is not pushed to the stack. This matters in style adjuster which may apply wrong adjustments as a result. Test: fast/animation/pseudo-element-style-adjuster.html * style/StyleTreeResolver.cpp: (WebCore::Style::TreeResolver::resolveElement): (WebCore::Style::TreeResolver::resolvePseudoStyle): (WebCore::Style::TreeResolver::createAnimatedElementUpdate): Make static and provide the parent and parent box styles as parameters. * style/StyleTreeResolver.h: 2021-04-15 Russell Epstein Cherry-pick r274403. rdar://problem/76374004 Cancel image loader events after first dispatch https://bugs.webkit.org/show_bug.cgi?id=218556 Patch by Rob Buis on 2021-03-14 Reviewed by Darin Adler. Address post review comments. * dom/EventSender.h: (WebCore::EventSender::dispatchPendingEvents): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274403 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-14 Rob Buis Cancel image loader events after first dispatch https://bugs.webkit.org/show_bug.cgi?id=218556 Reviewed by Darin Adler. Address post review comments. * dom/EventSender.h: (WebCore::EventSender::dispatchPendingEvents): 2021-04-15 Russell Epstein Cherry-pick r274357. rdar://problem/76374004 Cancel image loader events after first dispatch https://bugs.webkit.org/show_bug.cgi?id=218556 Patch by Rob Buis on 2021-03-12 Reviewed by Ryosuke Niwa. Cancel image loader events after first dispatch. Also change EventSender to use WeakPtr. * dom/EventSender.h: (WebCore::EventSender::dispatchEventSoon): (WebCore::EventSender::dispatchPendingEvents): * loader/ImageLoader.cpp: (WebCore::ImageLoader::dispatchPendingErrorEvent): * loader/ImageLoader.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274357 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-12 Rob Buis Cancel image loader events after first dispatch https://bugs.webkit.org/show_bug.cgi?id=218556 Reviewed by Ryosuke Niwa. Cancel image loader events after first dispatch. Also change EventSender to use WeakPtr. * dom/EventSender.h: (WebCore::EventSender::dispatchEventSoon): (WebCore::EventSender::dispatchPendingEvents): * loader/ImageLoader.cpp: (WebCore::ImageLoader::dispatchPendingErrorEvent): * loader/ImageLoader.h: 2021-04-15 Russell Epstein Cherry-pick r275876. rdar://problem/76727236 Skip style update https://bugs.webkit.org/show_bug.cgi?id=223365 Patch by Rob Buis on 2021-04-13 Reviewed by Ryosuke Niwa. Skip style update for getting the SVG bounding box since boundingClientRect already updated style. * dom/Element.cpp: (WebCore::Element::boundingAbsoluteRectWithoutLayout): * svg/SVGElement.cpp: (WebCore::SVGElement::getBoundingBox): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@275876 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-04-13 Rob Buis Skip style update https://bugs.webkit.org/show_bug.cgi?id=223365 Reviewed by Ryosuke Niwa. Skip style update for getting the SVG bounding box since boundingClientRect already updated style. * dom/Element.cpp: (WebCore::Element::boundingAbsoluteRectWithoutLayout): * svg/SVGElement.cpp: (WebCore::SVGElement::getBoundingBox): 2021-04-15 Russell Epstein Cherry-pick r275807. rdar://problem/76732495 Store InputType in a Ref before calling setValueAsDecimal https://bugs.webkit.org/show_bug.cgi?id=223535 Patch by Rob Buis on 2021-04-11 Reviewed by Ryosuke Niwa. Store InputType in a Ref before calling setValueAsDecimal. * html/InputType.cpp: (WebCore::InputType::applyStep): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@275807 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-04-11 Rob Buis Store InputType in a Ref before calling setValueAsDecimal https://bugs.webkit.org/show_bug.cgi?id=223535 Reviewed by Ryosuke Niwa. Store InputType in a Ref before calling setValueAsDecimal. * html/InputType.cpp: (WebCore::InputType::applyStep): 2021-04-15 Russell Epstein Cherry-pick r275933. rdar://problem/76727571 AudioSourceProviderAVFObjC should lock all multithreaded objects https://bugs.webkit.org/show_bug.cgi?id=224230 Patch by Kimmo Kinnunen on 2021-04-13 Reviewed by Eric Carlson. Lock following objects with TapStorage::lock: AudioSourceProviderAVFObjC::m_tapStorage AudioSourceProviderAVFObjC::m_avPlayerItem Do not clear the tapStorage nor the _this pointer from the audio thread. This is a race that cannot be overcome since the main thread needs to access the m_tapStorage pointer to lock the m_tapStorage pointer for modification. Initialize m_tap in more robust way, in case initialization fails. Do not leave stale m_tapStorage present when destroying the mixer. * platform/graphics/avfoundation/AudioSourceProviderAVFObjC.h: * platform/graphics/avfoundation/AudioSourceProviderAVFObjC.mm: (WebCore::AudioSourceProviderAVFObjC::~AudioSourceProviderAVFObjC): (WebCore::AudioSourceProviderAVFObjC::destroyMixIfNeeded): (WebCore::AudioSourceProviderAVFObjC::createMixIfNeeded): (WebCore::AudioSourceProviderAVFObjC::initCallback): (WebCore::AudioSourceProviderAVFObjC::finalizeCallback): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@275933 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-04-13 Kimmo Kinnunen AudioSourceProviderAVFObjC should lock all multithreaded objects https://bugs.webkit.org/show_bug.cgi?id=224230 Reviewed by Eric Carlson. Lock following objects with TapStorage::lock: AudioSourceProviderAVFObjC::m_tapStorage AudioSourceProviderAVFObjC::m_avPlayerItem Do not clear the tapStorage nor the _this pointer from the audio thread. This is a race that cannot be overcome since the main thread needs to access the m_tapStorage pointer to lock the m_tapStorage pointer for modification. Initialize m_tap in more robust way, in case initialization fails. Do not leave stale m_tapStorage present when destroying the mixer. * platform/graphics/avfoundation/AudioSourceProviderAVFObjC.h: * platform/graphics/avfoundation/AudioSourceProviderAVFObjC.mm: (WebCore::AudioSourceProviderAVFObjC::~AudioSourceProviderAVFObjC): (WebCore::AudioSourceProviderAVFObjC::destroyMixIfNeeded): (WebCore::AudioSourceProviderAVFObjC::createMixIfNeeded): (WebCore::AudioSourceProviderAVFObjC::initCallback): (WebCore::AudioSourceProviderAVFObjC::finalizeCallback): 2021-04-15 Russell Epstein Cherry-pick r275897. rdar://problem/76727571 AudioSourceProviderAVFObjC should check for m_client when dispatching setFormat https://bugs.webkit.org/show_bug.cgi?id=224479 Patch by Kimmo Kinnunen on 2021-04-13 Reviewed by Eric Carlson. Use a weak pointer to schedule the setFormat client callback. If client is unset before any callback is run, cancel the pending callbacks. * platform/graphics/avfoundation/AudioSourceProviderAVFObjC.h: * platform/graphics/avfoundation/AudioSourceProviderAVFObjC.mm: (WebCore::AudioSourceProviderAVFObjC::destroyMixIfNeeded): (WebCore::AudioSourceProviderAVFObjC::createMixIfNeeded): (WebCore::AudioSourceProviderAVFObjC::prepare): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@275897 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-04-13 Kimmo Kinnunen AudioSourceProviderAVFObjC should check for m_client when dispatching setFormat https://bugs.webkit.org/show_bug.cgi?id=224479 Reviewed by Eric Carlson. Use a weak pointer to schedule the setFormat client callback. If client is unset before any callback is run, cancel the pending callbacks. * platform/graphics/avfoundation/AudioSourceProviderAVFObjC.h: * platform/graphics/avfoundation/AudioSourceProviderAVFObjC.mm: (WebCore::AudioSourceProviderAVFObjC::destroyMixIfNeeded): (WebCore::AudioSourceProviderAVFObjC::createMixIfNeeded): (WebCore::AudioSourceProviderAVFObjC::prepare): 2021-04-15 Russell Epstein Cherry-pick r275896. rdar://problem/76727571 AudioSourceProviderAVFObjC::setClient should check for m_avAssetTrack https://bugs.webkit.org/show_bug.cgi?id=224478 Patch by Kimmo Kinnunen on 2021-04-13 Reviewed by Eric Carlson. Check for m_avAssetTrack when setting the client. This is done for consistency, it is unclear if this affects real world content. * platform/graphics/avfoundation/AudioSourceProviderAVFObjC.h: * platform/graphics/avfoundation/AudioSourceProviderAVFObjC.mm: (WebCore::AudioSourceProviderAVFObjC::setClient): (WebCore::AudioSourceProviderAVFObjC::setPlayerItem): (WebCore::AudioSourceProviderAVFObjC::setAudioTrack): (WebCore::AudioSourceProviderAVFObjC::destroyMixIfNeeded): (WebCore::AudioSourceProviderAVFObjC::createMixIfNeeded): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@275896 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-04-13 Kimmo Kinnunen AudioSourceProviderAVFObjC::setClient should check for m_avAssetTrack https://bugs.webkit.org/show_bug.cgi?id=224478 Reviewed by Eric Carlson. Check for m_avAssetTrack when setting the client. This is done for consistency, it is unclear if this affects real world content. * platform/graphics/avfoundation/AudioSourceProviderAVFObjC.h: * platform/graphics/avfoundation/AudioSourceProviderAVFObjC.mm: (WebCore::AudioSourceProviderAVFObjC::setClient): (WebCore::AudioSourceProviderAVFObjC::setPlayerItem): (WebCore::AudioSourceProviderAVFObjC::setAudioTrack): (WebCore::AudioSourceProviderAVFObjC::destroyMixIfNeeded): (WebCore::AudioSourceProviderAVFObjC::createMixIfNeeded): 2021-04-15 Russell Epstein Cherry-pick r275845. rdar://problem/76727387 Modernize uses of ConsoleClient https://bugs.webkit.org/show_bug.cgi?id=224398 Reviewed by David Kilzer. ConsoleClient acts like a delegate, so its callers should be using weak references to it. Source/JavaScriptCore: * inspector/JSGlobalObjectInspectorController.cpp: (Inspector::JSGlobalObjectInspectorController::consoleClient const): * inspector/JSGlobalObjectInspectorController.h: * runtime/ConsoleClient.h: * runtime/ConsoleObject.cpp: (JSC::consoleLogWithLevel): (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::setConsoleClient): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::consoleClient const): (JSC::JSGlobalObject::setConsoleClient): Deleted. Source/WebCore: * bindings/js/ScriptCachedFrameData.cpp: (WebCore::ScriptCachedFrameData::restore): * bindings/js/ScriptController.cpp: (WebCore::ScriptController::initScriptForWindowProxy): * bindings/js/WindowProxy.cpp: (WebCore::WindowProxy::setDOMWindow): * workers/WorkerOrWorkletScriptController.cpp: (WebCore::WorkerOrWorkletScriptController::initScriptWithSubclass): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@275845 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-04-12 BJ Burg Modernize uses of ConsoleClient https://bugs.webkit.org/show_bug.cgi?id=224398 Reviewed by David Kilzer. ConsoleClient acts like a delegate, so its callers should be using weak references to it. * bindings/js/ScriptCachedFrameData.cpp: (WebCore::ScriptCachedFrameData::restore): * bindings/js/ScriptController.cpp: (WebCore::ScriptController::initScriptForWindowProxy): * bindings/js/WindowProxy.cpp: (WebCore::WindowProxy::setDOMWindow): * workers/WorkerOrWorkletScriptController.cpp: (WebCore::WorkerOrWorkletScriptController::initScriptWithSubclass): 2021-04-15 Russell Epstein Cherry-pick r275756. rdar://problem/76727458 Teardown shadow root renderers on SlotAssignment::didChangeSlot https://bugs.webkit.org/show_bug.cgi?id=221386 Patch by Carlos Garcia Campos on 2021-04-09 Reviewed by Ryosuke Niwa. This reverts r272900 to move the call to RenderTreeUpdater::tearDownRenderers() from hostChildElementDidChange() to didChangeSlot(). This ensures the renderers are also cleared for other shadow root trees not using details element. * dom/SlotAssignment.cpp: (WebCore::SlotAssignment::addSlotElementByName): (WebCore::SlotAssignment::didChangeSlot): * dom/SlotAssignment.h: (WebCore::ShadowRoot::hostChildElementDidChange): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@275756 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-04-09 Carlos Garcia Campos Teardown shadow root renderers on SlotAssignment::didChangeSlot https://bugs.webkit.org/show_bug.cgi?id=221386 Reviewed by Ryosuke Niwa. This reverts r272900 to move the call to RenderTreeUpdater::tearDownRenderers() from hostChildElementDidChange() to didChangeSlot(). This ensures the renderers are also cleared for other shadow root trees not using details element. * dom/SlotAssignment.cpp: (WebCore::SlotAssignment::addSlotElementByName): (WebCore::SlotAssignment::didChangeSlot): * dom/SlotAssignment.h: (WebCore::ShadowRoot::hostChildElementDidChange): 2021-04-15 Russell Epstein Cherry-pick r275656. rdar://problem/76727574 Update SFrame implementation to latest version https://bugs.webkit.org/show_bug.cgi?id=224276 Reviewed by Eric Carlson. Source/WebCore: Update implementation according to latest draft at https://github.com/eomara/sframe/blob/master/draft-omara-sframe.md. In particular, we derive keys with new algorithm and the generation of the signature by including header and data length as well as nonce. Test: webrtc/sframe-test-vectors.html * Modules/mediastream/RTCRtpSFrameTransform.cpp: (WebCore::RTCRtpSFrameTransform::setCounterForTesting): * Modules/mediastream/RTCRtpSFrameTransform.h: * Modules/mediastream/RTCRtpSFrameTransformer.cpp: (WebCore::computeIV): (WebCore::RTCRtpSFrameTransformer::updateEncryptionKey): (WebCore::RTCRtpSFrameTransformer::decryptFrame): (WebCore::RTCRtpSFrameTransformer::encryptFrame): (WebCore::RTCRtpSFrameTransformer::computeEncryptedDataSignature): * Modules/mediastream/RTCRtpSFrameTransformer.h: * Modules/mediastream/RTCRtpSFrameTransformerCocoa.cpp: (WebCore::RTCRtpSFrameTransformer::computeSaltKey): (WebCore::createBaseSFrameKey): (WebCore::RTCRtpSFrameTransformer::computeAuthenticationKey): (WebCore::RTCRtpSFrameTransformer::computeEncryptionKey): (WebCore::encodeBigEndian): (WebCore::RTCRtpSFrameTransformer::computeEncryptedDataSignature): * testing/Internals.cpp: (WebCore::Internals::setSFrameCounter): * testing/Internals.h: * testing/Internals.idl: Tools: Update tests according new way of deriving keys and generating the signature. * TestWebKitAPI/Tests/WebCore/RTCRtpSFrameTransformerTests.cpp: (TestWebKitAPI::TEST): LayoutTests: * webrtc/sframe-test-vectors-expected.txt: Added. * webrtc/sframe-test-vectors.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@275656 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-04-08 Youenn Fablet Update SFrame implementation to latest version https://bugs.webkit.org/show_bug.cgi?id=224276 Reviewed by Eric Carlson. Update implementation according to latest draft at https://github.com/eomara/sframe/blob/master/draft-omara-sframe.md. In particular, we derive keys with new algorithm and the generation of the signature by including header and data length as well as nonce. Test: webrtc/sframe-test-vectors.html * Modules/mediastream/RTCRtpSFrameTransform.cpp: (WebCore::RTCRtpSFrameTransform::setCounterForTesting): * Modules/mediastream/RTCRtpSFrameTransform.h: * Modules/mediastream/RTCRtpSFrameTransformer.cpp: (WebCore::computeIV): (WebCore::RTCRtpSFrameTransformer::updateEncryptionKey): (WebCore::RTCRtpSFrameTransformer::decryptFrame): (WebCore::RTCRtpSFrameTransformer::encryptFrame): (WebCore::RTCRtpSFrameTransformer::computeEncryptedDataSignature): * Modules/mediastream/RTCRtpSFrameTransformer.h: * Modules/mediastream/RTCRtpSFrameTransformerCocoa.cpp: (WebCore::RTCRtpSFrameTransformer::computeSaltKey): (WebCore::createBaseSFrameKey): (WebCore::RTCRtpSFrameTransformer::computeAuthenticationKey): (WebCore::RTCRtpSFrameTransformer::computeEncryptionKey): (WebCore::encodeBigEndian): (WebCore::RTCRtpSFrameTransformer::computeEncryptedDataSignature): * testing/Internals.cpp: (WebCore::Internals::setSFrameCounter): * testing/Internals.h: * testing/Internals.idl: 2021-04-15 Russell Epstein Cherry-pick r275212. rdar://problem/76727522 Ensure that GlobalPropertyInfo is allocated on the stack. https://bugs.webkit.org/show_bug.cgi?id=223911 rdar://75865742 Reviewed by Yusuke Suzuki. Source/JavaScriptCore: We rely on GlobalPropertyInfo being allocated on the stack to allow its JSValue value to be scanned by the GC. Unfortunately, an ASAN compilation would choose to allocate the GlobalPropertyInfo on a side buffer instead of directly on the stack. This prevents the GC from doing the needed scan. We'll fix this by suppressing ASAN on the functions that allocated GlobalPropertyInfo arrays. Also added an ASSERT in the GlobalPropertyInfo constructor to assert that it is allocated on the stack. * Scripts/wkbuiltins/builtins_generate_internals_wrapper_implementation.py: (BuiltinsInternalsWrapperImplementationGenerator.generate_initialize_method): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::initStaticGlobals): (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::exposeDollarVM): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::GlobalPropertyInfo::GlobalPropertyInfo): Source/WebCore: * bindings/js/JSDOMGlobalObject.cpp: (WebCore::JSDOMGlobalObject::addBuiltinGlobals): * bindings/js/JSDOMWindowBase.cpp: (WebCore::JSDOMWindowBase::finishCreation): (WebCore::JSDOMWindowBase::initStaticGlobals): * bindings/js/JSDOMWindowBase.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@275212 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-30 Mark Lam Ensure that GlobalPropertyInfo is allocated on the stack. https://bugs.webkit.org/show_bug.cgi?id=223911 rdar://75865742 Reviewed by Yusuke Suzuki. * bindings/js/JSDOMGlobalObject.cpp: (WebCore::JSDOMGlobalObject::addBuiltinGlobals): * bindings/js/JSDOMWindowBase.cpp: (WebCore::JSDOMWindowBase::finishCreation): (WebCore::JSDOMWindowBase::initStaticGlobals): * bindings/js/JSDOMWindowBase.h: 2021-04-15 Russell Epstein Cherry-pick r275130. rdar://problem/76727598 Dirty layout for floating children of inline on full layout https://bugs.webkit.org/show_bug.cgi?id=223660 Patch by Ian Gilbert on 2021-03-26 Reviewed by Zalan Bujtas. Avoid consuming an object on an empty line when that object is floating or out-of-flow. * rendering/line/BreakingContext.h: (WebCore::BreakingContext::handleEndOfLine): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@275130 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-26 Ian Gilbert Dirty layout for floating children of inline on full layout https://bugs.webkit.org/show_bug.cgi?id=223660 Reviewed by Zalan Bujtas. Avoid consuming an object on an empty line when that object is floating or out-of-flow. * rendering/line/BreakingContext.h: (WebCore::BreakingContext::handleEndOfLine): 2021-04-15 Russell Epstein Cherry-pick r274862. rdar://problem/76416505 Nullptr crash in HTMLConverter::convert https://bugs.webkit.org/show_bug.cgi?id=221719 Patch by Frédéric Wang on 2021-03-23 Reviewed by Ryosuke Niwa. When the "Undo" command is called after DOM changes, one of the selection's position anchors may have been moved to a new document. In that case, just clear the selection. Also add asserts to ensure the selection is in good state after unapply and reapply commands. * editing/CompositeEditCommand.cpp: (WebCore::EditCommandComposition::unapply): Add security assert to ensure selection is in good state. (WebCore::EditCommandComposition::reapply): Ditto. * editing/FrameSelection.cpp: (WebCore::FrameSelection::setSelectionWithoutUpdatingAppearance): If the selection's position anchors have been moved to a new document then just clear the selection. (WebCore::FrameSelection::isConnectedToDocument const): New method to verify that all the positions of the visible selection are in m_document. * editing/FrameSelection.h: Declare new method. * editing/VisibleSelection.cpp: (WebCore::VisibleSelection::document const): New method that returns a common document for all positions or nullptr otherwise. * editing/VisibleSelection.h: Declare new method. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274862 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-23 Frédéric Wang Nullptr crash in HTMLConverter::convert https://bugs.webkit.org/show_bug.cgi?id=221719 Reviewed by Ryosuke Niwa. When the "Undo" command is called after DOM changes, one of the selection's position anchors may have been moved to a new document. In that case, just clear the selection. Also add asserts to ensure the selection is in good state after unapply and reapply commands. * editing/CompositeEditCommand.cpp: (WebCore::EditCommandComposition::unapply): Add security assert to ensure selection is in good state. (WebCore::EditCommandComposition::reapply): Ditto. * editing/FrameSelection.cpp: (WebCore::FrameSelection::setSelectionWithoutUpdatingAppearance): If the selection's position anchors have been moved to a new document then just clear the selection. (WebCore::FrameSelection::isConnectedToDocument const): New method to verify that all the positions of the visible selection are in m_document. * editing/FrameSelection.h: Declare new method. * editing/VisibleSelection.cpp: (WebCore::VisibleSelection::document const): New method that returns a common document for all positions or nullptr otherwise. * editing/VisibleSelection.h: Declare new method. 2021-04-15 Russell Epstein Cherry-pick r272928. rdar://problem/76416505 EventHandler::updateSelectionForMouseDownDispatchingSelectStart should not use an orphaned selection https://bugs.webkit.org/show_bug.cgi?id=221942 Reviewed by Wenson Hsieh. Source/WebCore: In r272777, we re-introduced a nullptr check in DOMSelection::getRangeAt as we were getting crash reports in this code but we weren't sure of the root cause. Since then we've identified that one of the root causes is that EventHandler::updateSelectionForMouseDownDispatchingSelectStart doesn't check if VisibleSelection is still in a good state after dispatching selectstart event. This results in FrameSelection's setSelectionWithoutUpdatingAppearance getting called with a selection with end points already being orphaned. This patch fixes this bug in setSelectionWithoutUpdatingAppearance and also adds an additional check in FrameSelection::setSelectionWithoutUpdatingAppearance itself to avoid using an orphaned selection. It also introduces a number of release and debug assertions in a number of places to help catch similar bugs. Test: editing/selection/click-selection-with-selectstart-node-removal.html * dom/ContainerNode.cpp: (WebCore::ContainerNode::removeAllChildrenWithScriptAssertion): Added a debug-only assertion. (WebCore::ContainerNode::removeNodeWithScriptAssertion): Ditto. * dom/Document.cpp: (WebCore::Document::removedLastRef): Disallow script execution in this code entirely. Also release assert that the selection had already been cleared by this point. (WebCore::Document::willBeRemovedFromFrame): Disallow script execution once we've unloaded subframes. * editing/FrameSelection.cpp: (WebCore::FrameSelection::setSelectionWithoutUpdatingAppearance): Return early if the new selection's end points had been orphaned, and disallow script execution between that and until we update the selection. * editing/VisibleSelection.cpp: (WebCore::VisibleSelection::isOrphan const): Added. * editing/VisibleSelection.h: * page/DOMSelection.cpp: (WebCore::DOMSelection::getRangeAt): Removed nullptr check added in r272777. * page/EventHandler.cpp: (WebCore::EventHandler::updateSelectionForMouseDownDispatchingSelectStart): Fixed what is now believed to be the root cause of the bug 221786. LayoutTests: Added a regression test for the bug 221786 / r272777. Also updated a test imported from blink to expect rangeCount of 0 instead of 1 since we no longer update the selection when the target node has been removed during selectstart. * editing/selection/click-selection-with-selectstart-node-removal-expected.txt: Added. * editing/selection/click-selection-with-selectstart-node-removal.html: Added. * imported/blink/editing/selection/selectstart-event-crash.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272928 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-16 Ryosuke Niwa EventHandler::updateSelectionForMouseDownDispatchingSelectStart should not use an orphaned selection https://bugs.webkit.org/show_bug.cgi?id=221942 Reviewed by Wenson Hsieh. In r272777, we re-introduced a nullptr check in DOMSelection::getRangeAt as we were getting crash reports in this code but we weren't sure of the root cause. Since then we've identified that one of the root causes is that EventHandler::updateSelectionForMouseDownDispatchingSelectStart doesn't check if VisibleSelection is still in a good state after dispatching selectstart event. This results in FrameSelection's setSelectionWithoutUpdatingAppearance getting called with a selection with end points already being orphaned. This patch fixes this bug in setSelectionWithoutUpdatingAppearance and also adds an additional check in FrameSelection::setSelectionWithoutUpdatingAppearance itself to avoid using an orphaned selection. It also introduces a number of release and debug assertions in a number of places to help catch similar bugs. Test: editing/selection/click-selection-with-selectstart-node-removal.html * dom/ContainerNode.cpp: (WebCore::ContainerNode::removeAllChildrenWithScriptAssertion): Added a debug-only assertion. (WebCore::ContainerNode::removeNodeWithScriptAssertion): Ditto. * dom/Document.cpp: (WebCore::Document::removedLastRef): Disallow script execution in this code entirely. Also release assert that the selection had already been cleared by this point. (WebCore::Document::willBeRemovedFromFrame): Disallow script execution once we've unloaded subframes. * editing/FrameSelection.cpp: (WebCore::FrameSelection::setSelectionWithoutUpdatingAppearance): Return early if the new selection's end points had been orphaned, and disallow script execution between that and until we update the selection. * editing/VisibleSelection.cpp: (WebCore::VisibleSelection::isOrphan const): Added. * editing/VisibleSelection.h: * page/DOMSelection.cpp: (WebCore::DOMSelection::getRangeAt): Removed nullptr check added in r272777. * page/EventHandler.cpp: (WebCore::EventHandler::updateSelectionForMouseDownDispatchingSelectStart): Fixed what is now believed to be the root cause of the bug 221786. 2021-04-15 Russell Epstein Cherry-pick r274877. rdar://problem/76373841 Enable the quirk to disable firing "webkitendfullscreen" event when a video enters picture-in-picture from fullscreen on espn.com https://bugs.webkit.org/show_bug.cgi?id=223610 Reviewed by Jer Noble. A video element entering picture-in-picture from fullscreen will fire a "webkitendfullscreen" event since r266728, but some sites (e.g., espn.com) do not handle the event properly. Because they assume the video will resume to inline after exiting fullscreen. This patch enables the quirk for espn.com to disable firing "webkitendfullscreen" event in that scenario before they fix the issue in the event handler. * page/Quirks.cpp: (WebCore::Quirks::shouldDisableEndFullscreenEventWhenEnteringPictureInPictureFromFullscreenQuirk const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274877 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-23 Peng Liu Enable the quirk to disable firing "webkitendfullscreen" event when a video enters picture-in-picture from fullscreen on espn.com https://bugs.webkit.org/show_bug.cgi?id=223610 Reviewed by Jer Noble. A video element entering picture-in-picture from fullscreen will fire a "webkitendfullscreen" event since r266728, but some sites (e.g., espn.com) do not handle the event properly. Because they assume the video will resume to inline after exiting fullscreen. This patch enables the quirk for espn.com to disable firing "webkitendfullscreen" event in that scenario before they fix the issue in the event handler. * page/Quirks.cpp: (WebCore::Quirks::shouldDisableEndFullscreenEventWhenEnteringPictureInPictureFromFullscreenQuirk const): 2021-04-08 Russell Epstein Cherry-pick r274491. rdar://problem/76374243 Terminate network process when making new WebProcessPool in Lutron App https://bugs.webkit.org/show_bug.cgi?id=223194 Reviewed by Geoff Garen. Source/WebCore: * platform/RuntimeApplicationChecks.h: * platform/cocoa/RuntimeApplicationChecksCocoa.mm: (WebCore::IOSApplication::isLutron): * platform/cocoa/VersionChecks.h: Source/WebKit: The Lutron App uses allocation of a new WKProcessPool as a way to stop using old session cookies. Since r267763 we keep the session cookies for the lifetime of a WKWebsiteDataStore instead of making a new process for each WKProcessPool. Add a quirk for this app until they update to use a new WKWebsiteDataStore or use WKHTTPCookieStore API to clear the cookies properly. I manually verified this causes the logging out to succeed. * UIProcess/WebProcessPool.cpp: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274491 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-16 Alex Christensen Terminate network process when making new WebProcessPool in Lutron App https://bugs.webkit.org/show_bug.cgi?id=223194 Reviewed by Geoff Garen. * platform/RuntimeApplicationChecks.h: * platform/cocoa/RuntimeApplicationChecksCocoa.mm: (WebCore::IOSApplication::isLutron): * platform/cocoa/VersionChecks.h: 2021-04-08 Russell Epstein Cherry-pick r272707. rdar://problem/76375033 Use event loop to set title https://bugs.webkit.org/show_bug.cgi?id=218496 Patch by Rob Buis on 2021-02-10 Reviewed by Darin Adler. Source/WebCore: Use event loop to set title to avoid calling WebFrameLoaderClient within HTMLTitleElement::insertedIntoAncestor. * dom/Document.cpp: (WebCore::Document::updateTitle): * dom/Document.h: (WebCore::Document::titleWithDirection const): * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::setTitle): * loader/EmptyClients.h: * page/Chrome.cpp: (WebCore::Chrome::print): * page/ChromeClient.h: Source/WebKit: Add title parameter to PrintFrame message. * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::printFrame): * UIProcess/WebPageProxy.h: * UIProcess/WebPageProxy.messages.in: * WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::print): * WebProcess/WebCoreSupport/WebChromeClient.h: Source/WebKitLegacy/mac: Adjust to API change. * WebCoreSupport/WebChromeClient.h: * WebCoreSupport/WebChromeClient.mm: (WebChromeClient::print): Source/WebKitLegacy/win: Adjust to API change. * WebCoreSupport/WebChromeClient.cpp: (WebChromeClient::print): * WebCoreSupport/WebChromeClient.h: Tools: Adapt unit tests to wait for title change tasks to be processed. * TestWebKitAPI/Tests/WebKit/PageLoadState.cpp: (TestWebKitAPI::didChangeTitle): (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/WebKitCocoa/UIDelegate.mm: (TEST): * TestWebKitAPI/Tests/WebKitGLib/TestAuthentication.cpp: (testWebViewAuthenticationFailure): (testWebViewAuthenticationNoCredential): (testWebViewAuthenticationSuccess): (testWebViewAuthenticationEmptyRealm): * TestWebKitAPI/Tests/WebKitGLib/TestBackForwardList.cpp: (testBackForwardListNavigation): * TestWebKitAPI/Tests/WebKitGLib/TestLoaderClient.cpp: (testWebViewTitle): * TestWebKitAPI/Tests/WebKitGLib/TestSSL.cpp: (testLoadFailedWithTLSErrors): * TestWebKitAPI/Tests/WebKitGLib/TestWebKitSettings.cpp: (testWebKitSettingsJavaScriptMarkup): * TestWebKitAPI/Tests/WebKitGLib/TestWebKitWebView.cpp: (testWebViewTitleChange): LayoutTests: Adapt tests to make sure pending title change tasks are processed before the test is done. * TestExpectations: * fast/dom/title-text-property-2.html: * fast/dom/title-text-property-assigning-empty-string.html: * fast/dom/title-text-property.html: * http/tests/globalhistory/history-delegate-basic-title-expected.txt: * http/tests/globalhistory/history-delegate-basic-title.html: * http/tests/loading/basic-auth-load-URL-with-consecutive-slashes-expected.txt: * http/tests/loading/basic-auth-load-URL-with-consecutive-slashes.html: * http/tests/loading/redirect-with-no-location-crash-expected.txt: * http/tests/loading/redirect-with-no-location-crash.html: * platform/mac-wk2/TestExpectations: * platform/win/http/tests/loading/basic-auth-load-URL-with-consecutive-slashes-expected.txt: Copied from LayoutTests/http/tests/loading/basic-auth-load-URL-with-consecutive-slashes-expected.txt. * platform/wk2/http/tests/loading/basic-auth-load-URL-with-consecutive-slashes-expected.txt: * platform/wk2/http/tests/loading/redirect-with-no-location-crash-expected.txt: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272707 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-10 Rob Buis Use event loop to set title https://bugs.webkit.org/show_bug.cgi?id=218496 Reviewed by Darin Adler. Use event loop to set title to avoid calling WebFrameLoaderClient within HTMLTitleElement::insertedIntoAncestor. * dom/Document.cpp: (WebCore::Document::updateTitle): * dom/Document.h: (WebCore::Document::titleWithDirection const): * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::setTitle): * loader/EmptyClients.h: * page/Chrome.cpp: (WebCore::Chrome::print): * page/ChromeClient.h: 2021-04-08 Russell Epstein Cherry-pick r275535. rdar://problem/76375208 WebCrypto in Safari will not AES-GCM encrypt 0 bytes https://bugs.webkit.org/show_bug.cgi?id=224083 Reviewed by Youenn Fablet. Source/WebCore: CommonCrypto will bail out both the encryption and decryption process if the dataOut is a null pointer. To workaround the issue, this patch forces the dataOut to be a non-null pointer. Test: crypto/subtle/aes-gcm-generate-key-encrypt-decrypt-null-plain-text.html * crypto/mac/CryptoAlgorithmAES_GCMMac.cpp: (WebCore::encryptAES_GCM): (WebCore::decyptAES_GCM): LayoutTests: * crypto/subtle/aes-gcm-generate-key-encrypt-decrypt-null-plain-text-expected.txt: Added. * crypto/subtle/aes-gcm-generate-key-encrypt-decrypt-null-plain-text.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@275535 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-04-06 Jiewen Tan WebCrypto in Safari will not AES-GCM encrypt 0 bytes https://bugs.webkit.org/show_bug.cgi?id=224083 Reviewed by Youenn Fablet. CommonCrypto will bail out both the encryption and decryption process if the dataOut is a null pointer. To workaround the issue, this patch forces the dataOut to be a non-null pointer. Test: crypto/subtle/aes-gcm-generate-key-encrypt-decrypt-null-plain-text.html * crypto/mac/CryptoAlgorithmAES_GCMMac.cpp: (WebCore::encryptAES_GCM): (WebCore::decyptAES_GCM): 2021-04-08 Russell Epstein Cherry-pick r275475. rdar://problem/76416845 Make sure the Frame always gets destroyed on the main thread https://bugs.webkit.org/show_bug.cgi?id=224213 Reviewed by Alex Christensen. Make sure the Frame always gets destroyed on the main thread. Since http://trac.webkit.org/changeset/181791, Frame is ThreadSafeRefCounted and captured on other threads. We should make sure the Frame is always destroyed on the main thread though, since it is a main thread object and we hold WeakPtrs to it in many places. * page/AbstractFrame.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@275475 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-04-05 Chris Dumez Make sure the Frame always gets destroyed on the main thread https://bugs.webkit.org/show_bug.cgi?id=224213 Reviewed by Alex Christensen. Make sure the Frame always gets destroyed on the main thread. Since http://trac.webkit.org/changeset/181791, Frame is ThreadSafeRefCounted and captured on other threads. We should make sure the Frame is always destroyed on the main thread though, since it is a main thread object and we hold WeakPtrs to it in many places. * page/AbstractFrame.h: 2021-04-08 Russell Epstein Cherry-pick r275450. rdar://problem/76374359 PendingImageBitmap gets created on a stopped script execution context. https://bugs.webkit.org/show_bug.cgi?id=223971 Reviewed by Youenn Fablet. Don't create a PendingImageBitmap in PendingImageBitmap::fetch if the associated script execution context had already been stoppped. The new behavior matches of Chrome although it's technically incorrect. Correcting it to match the spec & Firefox will refactor a larger fix around how script execution context is used by the threaded loader. * html/ImageBitmap.cpp: (WebCore::PendingImageBitmap::fetch): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@275450 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-04-02 Ryosuke Niwa PendingImageBitmap gets created on a stopped script execution context. https://bugs.webkit.org/show_bug.cgi?id=223971 Reviewed by Youenn Fablet. Don't create a PendingImageBitmap in PendingImageBitmap::fetch if the associated script execution context had already been stoppped. The new behavior matches of Chrome although it's technically incorrect. Correcting it to match the spec & Firefox will refactor a larger fix around how script execution context is used by the threaded loader. * html/ImageBitmap.cpp: (WebCore::PendingImageBitmap::fetch): 2021-04-08 Russell Epstein Cherry-pick r275230. rdar://problem/76412999 Nullptr crash in applyCommonButtonPaddingToStyle https://bugs.webkit.org/show_bug.cgi?id=223917 rdar://57262957 Reviewed by Zalan Bujtas. * rendering/RenderThemeIOS.mm: (WebCore::applyCommonButtonPaddingToStyle): Null check frame. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@275230 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-30 Antti Koivisto Nullptr crash in applyCommonButtonPaddingToStyle https://bugs.webkit.org/show_bug.cgi?id=223917 rdar://57262957 Reviewed by Zalan Bujtas. * rendering/RenderThemeIOS.mm: (WebCore::applyCommonButtonPaddingToStyle): Null check frame. 2021-04-08 Russell Epstein Cherry-pick r275168. rdar://problem/76374982 Make a Ref to HTMLPlugInElement when resolving callback https://bugs.webkit.org/show_bug.cgi?id=223846 Patch by Ian Gilbert on 2021-03-29 Reviewed by Ryosuke Niwa. Take a Ref to the HTMLPlugInElement to keep it alive while invoking HTMLPlugInElement::swapRendererTimerFired() * html/HTMLPlugInElement.cpp: (WebCore::HTMLPlugInElement::swapRendererTimerFired): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@275168 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-29 Ian Gilbert Make a Ref to HTMLPlugInElement when resolving callback https://bugs.webkit.org/show_bug.cgi?id=223846 Reviewed by Ryosuke Niwa. Take a Ref to the HTMLPlugInElement to keep it alive while invoking HTMLPlugInElement::swapRendererTimerFired() * html/HTMLPlugInElement.cpp: (WebCore::HTMLPlugInElement::swapRendererTimerFired): 2021-04-08 Russell Epstein Cherry-pick r275142. rdar://problem/76411405 UBSan: runtime error: load of value , which is not a valid value for type 'const WebCore::RealtimeMediaSourceCapabilities::EchoCancellation' Reviewed by Chris Dumez. Tests: fast/mediastream/MediaDevices-addEventListener.html fast/mediastream/constraint-intrinsic-size.html http/tests/media/media-stream/enumerate-devices-iframe-allow-attribute.html http/tests/media/media-stream/get-display-media-iframe-allow-attribute.html imported/w3c/web-platform-tests/mediacapture-record/MediaRecorder-bitrate.https.html webrtc/addICECandidate-closed.html webrtc/ice-candidate-sdpMLineIndex.html webrtc/libwebrtc/descriptionGetters.html webrtc/peerconnection-page-cache.html * platform/mediastream/RealtimeMediaSourceCapabilities.h: (WebCore::CapabilityValueOrRange::union ValueUnion): - Make asDouble the first union member so C++ member initializers set all memory. (WebCore::CapabilityValueOrRange::m_minOrValue): (WebCore::CapabilityValueOrRange::m_max): (WebCore::CapabilityValueOrRange::m_type): (WebCore::RealtimeMediaSourceCapabilities::m_echoCancellation): - Provide member initializers. Setting a default value for m_echoCancellation fixes the bug. (WebCore::RealtimeMediaSourceCapabilities::encode const): - Drive-by clean-up of encoder statement. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@275142 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-27 David Kilzer UBSan: runtime error: load of value , which is not a valid value for type 'const WebCore::RealtimeMediaSourceCapabilities::EchoCancellation' Reviewed by Chris Dumez. Tests: fast/mediastream/MediaDevices-addEventListener.html fast/mediastream/constraint-intrinsic-size.html http/tests/media/media-stream/enumerate-devices-iframe-allow-attribute.html http/tests/media/media-stream/get-display-media-iframe-allow-attribute.html imported/w3c/web-platform-tests/mediacapture-record/MediaRecorder-bitrate.https.html webrtc/addICECandidate-closed.html webrtc/ice-candidate-sdpMLineIndex.html webrtc/libwebrtc/descriptionGetters.html webrtc/peerconnection-page-cache.html * platform/mediastream/RealtimeMediaSourceCapabilities.h: (WebCore::CapabilityValueOrRange::union ValueUnion): - Make asDouble the first union member so C++ member initializers set all memory. (WebCore::CapabilityValueOrRange::m_minOrValue): (WebCore::CapabilityValueOrRange::m_max): (WebCore::CapabilityValueOrRange::m_type): (WebCore::RealtimeMediaSourceCapabilities::m_echoCancellation): - Provide member initializers. Setting a default value for m_echoCancellation fixes the bug. (WebCore::RealtimeMediaSourceCapabilities::encode const): - Drive-by clean-up of encoder statement. 2021-04-08 Russell Epstein Cherry-pick r274776. rdar://problem/76373875 Better validate JSArrays in AudioWorkletProcessor https://bugs.webkit.org/show_bug.cgi?id=223548 Reviewed by Geoffrey Garen. Better validate JSArrays in AudioWorkletProcessor. Replaces debug assertions with runtime checks for robustness. * Modules/webaudio/AudioWorkletProcessor.cpp: (WebCore::copyDataFromBusesToJSArray): (WebCore::copyDataFromParameterMapToJSObject): (WebCore::zeroJSArray): (WebCore::AudioWorkletProcessor::buildJSArguments): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274776 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-22 Chris Dumez Better validate JSArrays in AudioWorkletProcessor https://bugs.webkit.org/show_bug.cgi?id=223548 Reviewed by Geoffrey Garen. Better validate JSArrays in AudioWorkletProcessor. Replaces debug assertions with runtime checks for robustness. * Modules/webaudio/AudioWorkletProcessor.cpp: (WebCore::copyDataFromBusesToJSArray): (WebCore::copyDataFromParameterMapToJSObject): (WebCore::zeroJSArray): (WebCore::AudioWorkletProcessor::buildJSArguments): 2021-04-08 Russell Epstein Cherry-pick r274723. rdar://problem/76375575 Protect frame before calling didBeginDocument https://bugs.webkit.org/show_bug.cgi?id=217185 Patch by Rob Buis on 2021-03-19 Reviewed by Alex Christensen. Protect frame before calling didBeginDocument since it could potentially delete the frame through event handling. * loader/DocumentWriter.cpp: (WebCore::DocumentWriter::begin): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274723 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-19 Rob Buis Protect frame before calling didBeginDocument https://bugs.webkit.org/show_bug.cgi?id=217185 Reviewed by Alex Christensen. Protect frame before calling didBeginDocument since it could potentially delete the frame through event handling. * loader/DocumentWriter.cpp: (WebCore::DocumentWriter::begin): 2021-04-08 Russell Epstein Cherry-pick r274675. rdar://problem/76374314 Protect frame before calling setPrinting https://bugs.webkit.org/show_bug.cgi?id=222664 Patch by Rob Buis on 2021-03-18 Reviewed by Ryosuke Niwa. Protect frame before calling setPrinting since it could potentially delete the frame through event handling. * page/PrintContext.cpp: (WebCore::PrintContext::begin): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274675 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-18 Rob Buis Protect frame before calling setPrinting https://bugs.webkit.org/show_bug.cgi?id=222664 Reviewed by Ryosuke Niwa. Protect frame before calling setPrinting since it could potentially delete the frame through event handling. * page/PrintContext.cpp: (WebCore::PrintContext::begin): 2021-04-08 Russell Epstein Cherry-pick r274626. rdar://problem/76374269 ASSERTION FAILED: node.isConnected() in matchSlottedPseudoElementRules https://bugs.webkit.org/show_bug.cgi?id=221440 Patch by Frédéric Wang on 2021-03-18 Reviewed by Ryosuke Niwa. ReplaceSelectionCommand::doApply() removes a
from an element and immediately calls highestNodeToRemoveInPruning() on that element. The former operation may destroy the element's renderer and confuses the latter operation. This happens in particular for a element which ends up being removed from the tree. This in turn causes unexpected issues such as a debug assertion failure in matchSlottedPseudoElementRules. To address that problem, ensure the document is laid out before calling highestNodeToRemoveInPruning(). This patch also increases and improves use of RefPtr. * editing/CompositeEditCommand.cpp: (WebCore::CompositeEditCommand::removeNodeAndPruneAncestors): Use auto & makeRefPtr. (WebCore::CompositeEditCommand::prune): Store local highestNodeToRemove variable in a RefPtr. (WebCore::CompositeEditCommand::cleanupAfterDeletion): Store local node variable in a RefPtr. (WebCore::CompositeEditCommand::breakOutOfEmptyMailBlockquotedParagraph): Store local parentNode variable in a RefPtr. * editing/Editing.cpp: (WebCore::highestNodeToRemoveInPruning): Store local currentNode variable in a a RefPtr. * editing/ReplaceSelectionCommand.cpp: (WebCore::ReplaceSelectionCommand::doApply): Use auto & makeRefPtr. Store local odeToRemove variable in a RefPtr. Ensure the document is laid out before calling highestNodeToRemoveInPruning. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274626 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-18 Frédéric Wang ASSERTION FAILED: node.isConnected() in matchSlottedPseudoElementRules https://bugs.webkit.org/show_bug.cgi?id=221440 Reviewed by Ryosuke Niwa. ReplaceSelectionCommand::doApply() removes a
from an element and immediately calls highestNodeToRemoveInPruning() on that element. The former operation may destroy the element's renderer and confuses the latter operation. This happens in particular for a element which ends up being removed from the tree. This in turn causes unexpected issues such as a debug assertion failure in matchSlottedPseudoElementRules. To address that problem, ensure the document is laid out before calling highestNodeToRemoveInPruning(). This patch also increases and improves use of RefPtr. * editing/CompositeEditCommand.cpp: (WebCore::CompositeEditCommand::removeNodeAndPruneAncestors): Use auto & makeRefPtr. (WebCore::CompositeEditCommand::prune): Store local highestNodeToRemove variable in a RefPtr. (WebCore::CompositeEditCommand::cleanupAfterDeletion): Store local node variable in a RefPtr. (WebCore::CompositeEditCommand::breakOutOfEmptyMailBlockquotedParagraph): Store local parentNode variable in a RefPtr. * editing/Editing.cpp: (WebCore::highestNodeToRemoveInPruning): Store local currentNode variable in a a RefPtr. * editing/ReplaceSelectionCommand.cpp: (WebCore::ReplaceSelectionCommand::doApply): Use auto & makeRefPtr. Store local odeToRemove variable in a RefPtr. Ensure the document is laid out before calling highestNodeToRemoveInPruning. 2021-04-08 Russell Epstein Cherry-pick r274387. rdar://problem/76373770 Mark the line dirty when list marker goes from inline to block https://bugs.webkit.org/show_bug.cgi?id=223132 Reviewed by Antti Koivisto. This patch ensures that the line layout has a chance to clean up the inline boxes when the marker goes from inline to block. Instead of deleting the inline box wrapper (InlineElement) here let's 1. mark both the renderer and the line dirty and let the inline layout code run its normal cleanup process on dirty lines. 2. detach the inline box wrapper from the now-block list marker. * rendering/RenderListMarker.cpp: (WebCore::RenderListMarker::styleDidChange): * rendering/RootInlineBox.cpp: (WebCore::RootInlineBox::verticalPositionForBox): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274387 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-13 Zalan Bujtas Mark the line dirty when list marker goes from inline to block https://bugs.webkit.org/show_bug.cgi?id=223132 Reviewed by Antti Koivisto. This patch ensures that the line layout has a chance to clean up the inline boxes when the marker goes from inline to block. Instead of deleting the inline box wrapper (InlineElement) here let's 1. mark both the renderer and the line dirty and let the inline layout code run its normal cleanup process on dirty lines. 2. detach the inline box wrapper from the now-block list marker. * rendering/RenderListMarker.cpp: (WebCore::RenderListMarker::styleDidChange): * rendering/RootInlineBox.cpp: (WebCore::RootInlineBox::verticalPositionForBox): 2021-04-08 Russell Epstein Cherry-pick r274154. rdar://problem/76375184 MediaRecorder.requestData() not returning all captured media after a pause https://bugs.webkit.org/show_bug.cgi?id=222285 Reviewed by Eric Carlson. Source/WebCore: Previously, when flushing, we are called on a background thread and we hop to the main thread to append data. In some cases, we were resolving the completion handlers before appending all data. To prevent this, we now append data from a background thread. To do so, we lock when accessing m_data, either to append or take the data. In addition, we cancel writing when clearing the writer. This allows to clean the writer delegate without fearing that write operations are happening. Covered by updated test. * platform/mediarecorder/cocoa/MediaRecorderPrivateWriterCocoa.h: * platform/mediarecorder/cocoa/MediaRecorderPrivateWriterCocoa.mm: (-[WebAVAssetWriterDelegate initWithWriter:]): (-[WebAVAssetWriterDelegate assetWriter:didProduceFragmentedHeaderData:]): (-[WebAVAssetWriterDelegate assetWriter:didProduceFragmentedMediaData:fragmentedMediaDataReport:]): (WebCore::MediaRecorderPrivateWriter::initialize): (WebCore::MediaRecorderPrivateWriter::clear): (WebCore::MediaRecorderPrivateWriter::stopRecording): (WebCore::MediaRecorderPrivateWriter::completeFetchData): (WebCore::MediaRecorderPrivateWriter::appendData): (WebCore::MediaRecorderPrivateWriter::takeData): LayoutTests: * http/wpt/mediarecorder/pause-recording-expected.txt: * http/wpt/mediarecorder/pause-recording.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274154 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-09 Youenn Fablet MediaRecorder.requestData() not returning all captured media after a pause https://bugs.webkit.org/show_bug.cgi?id=222285 Reviewed by Eric Carlson. Previously, when flushing, we are called on a background thread and we hop to the main thread to append data. In some cases, we were resolving the completion handlers before appending all data. To prevent this, we now append data from a background thread. To do so, we lock when accessing m_data, either to append or take the data. In addition, we cancel writing when clearing the writer. This allows to clean the writer delegate without fearing that write operations are happening. Covered by updated test. * platform/mediarecorder/cocoa/MediaRecorderPrivateWriterCocoa.h: * platform/mediarecorder/cocoa/MediaRecorderPrivateWriterCocoa.mm: (-[WebAVAssetWriterDelegate initWithWriter:]): (-[WebAVAssetWriterDelegate assetWriter:didProduceFragmentedHeaderData:]): (-[WebAVAssetWriterDelegate assetWriter:didProduceFragmentedMediaData:fragmentedMediaDataReport:]): (WebCore::MediaRecorderPrivateWriter::initialize): (WebCore::MediaRecorderPrivateWriter::clear): (WebCore::MediaRecorderPrivateWriter::stopRecording): (WebCore::MediaRecorderPrivateWriter::completeFetchData): (WebCore::MediaRecorderPrivateWriter::appendData): (WebCore::MediaRecorderPrivateWriter::takeData): 2021-04-08 Russell Epstein Cherry-pick r274146. rdar://problem/76374119 Suspend widget hierarchy updates while executing node insertion https://bugs.webkit.org/show_bug.cgi?id=222719 Patch by Carlos Garcia Campos on 2021-03-09 Reviewed by Ryosuke Niwa. * dom/ContainerNode.cpp: (WebCore::executeNodeInsertionWithScriptAssertion): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274146 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-09 Carlos Garcia Campos Suspend widget hierarchy updates while executing node insertion https://bugs.webkit.org/show_bug.cgi?id=222719 Reviewed by Ryosuke Niwa. * dom/ContainerNode.cpp: (WebCore::executeNodeInsertionWithScriptAssertion): 2021-04-08 Russell Epstein Cherry-pick r274054. rdar://problem/76374004 Use counters for pending events https://bugs.webkit.org/show_bug.cgi?id=218556 Patch by Rob Buis on 2021-03-07 Reviewed by Ryosuke Niwa. Source/WebCore: Use counters for pending events instead of flags since it is allowed to schedule multiple events: https://html.spec.whatwg.org/multipage/images.html#update-the-image-data * loader/ImageLoader.cpp: (WebCore::ImageLoader::ImageLoader): (WebCore::ImageLoader::~ImageLoader): (WebCore::ImageLoader::clearImageWithoutConsideringPendingLoadEvent): (WebCore::ImageLoader::updateFromElement): (WebCore::ImageLoader::notifyFinished): (WebCore::ImageLoader::updatedHasPendingEvent): (WebCore::ImageLoader::dispatchPendingBeforeLoadEvent): (WebCore::ImageLoader::dispatchPendingLoadEvent): (WebCore::ImageLoader::dispatchPendingErrorEvent): * loader/ImageLoader.h: (WebCore::ImageLoader::hasPendingBeforeLoadEvent const): (WebCore::ImageLoader::hasPendingActivity const): LayoutTests: The onerror can be called multiple times, after the first call container will have no parent, so protect against that in subsequent calls. * fast/dom/modify-node-and-while-in-the-callback-too-crash.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274054 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-07 Rob Buis Use counters for pending events https://bugs.webkit.org/show_bug.cgi?id=218556 Reviewed by Ryosuke Niwa. Use counters for pending events instead of flags since it is allowed to schedule multiple events: https://html.spec.whatwg.org/multipage/images.html#update-the-image-data * loader/ImageLoader.cpp: (WebCore::ImageLoader::ImageLoader): (WebCore::ImageLoader::~ImageLoader): (WebCore::ImageLoader::clearImageWithoutConsideringPendingLoadEvent): (WebCore::ImageLoader::updateFromElement): (WebCore::ImageLoader::notifyFinished): (WebCore::ImageLoader::updatedHasPendingEvent): (WebCore::ImageLoader::dispatchPendingBeforeLoadEvent): (WebCore::ImageLoader::dispatchPendingLoadEvent): (WebCore::ImageLoader::dispatchPendingErrorEvent): * loader/ImageLoader.h: (WebCore::ImageLoader::hasPendingBeforeLoadEvent const): (WebCore::ImageLoader::hasPendingActivity const): 2021-04-08 Russell Epstein Cherry-pick r274025. rdar://problem/76375235 CanvasRenderingContext2DBase::canDrawTextWithParams() needs to resolve styles before using the drawingContext https://bugs.webkit.org/show_bug.cgi?id=221257 Reviewed by Ryosuke Niwa. Simply call fontProxy() (which internally resolves styles) before calling drawingContext(). Test: fast/text/canvas-synchronous-events.html * html/canvas/CanvasRenderingContext2DBase.cpp: (WebCore::CanvasRenderingContext2DBase::canDrawTextWithParams): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274025 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-05 Myles C. Maxfield CanvasRenderingContext2DBase::canDrawTextWithParams() needs to resolve styles before using the drawingContext https://bugs.webkit.org/show_bug.cgi?id=221257 Reviewed by Ryosuke Niwa. Simply call fontProxy() (which internally resolves styles) before calling drawingContext(). Test: fast/text/canvas-synchronous-events.html * html/canvas/CanvasRenderingContext2DBase.cpp: (WebCore::CanvasRenderingContext2DBase::canDrawTextWithParams): 2021-04-08 Russell Epstein Cherry-pick r273938. rdar://problem/76411908 Deploy Ref in SVGUseElement.cpp https://bugs.webkit.org/show_bug.cgi?id=222637 Patch by Julian Gonzalez on 2021-03-04 Reviewed by Ryosuke Niwa. Remove usage of raw pointers in a few functions here that showed issues in 222397. Thanks to Darin Adler for the initial version of this patch and Ryosuke Niwa for refinements. * svg/SVGUseElement.cpp: (WebCore::disassociateAndRemoveClones): (WebCore::removeDisallowedElementsFromSubtree): (WebCore::removeSymbolElementsFromSubtree): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273938 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-04 Julian Gonzalez Deploy Ref in SVGUseElement.cpp https://bugs.webkit.org/show_bug.cgi?id=222637 Reviewed by Ryosuke Niwa. Remove usage of raw pointers in a few functions here that showed issues in 222397. Thanks to Darin Adler for the initial version of this patch and Ryosuke Niwa for refinements. * svg/SVGUseElement.cpp: (WebCore::disassociateAndRemoveClones): (WebCore::removeDisallowedElementsFromSubtree): (WebCore::removeSymbolElementsFromSubtree): 2021-04-08 Russell Epstein Cherry-pick r273935. rdar://problem/76373961 "precustomized" state of custom elements can become HTMLUnknownElement https://bugs.webkit.org/show_bug.cgi?id=221652 Reviewed by Darin Adler. The bug was caused by createJSHTMLWrapper in JSHTMLElementWrapperFactory.cpp relying on !isCustomElementUpgradeCandidate() to create HTMLUnknownElement as JS wrapper of the element. This is problematic after r266269 since that change re-purposes CustomElementState::Failed on a custom element as "precustomized" state instead of introducing another enum value in CustomElementState as RareDataBitFields has no more bits available. This patch fixes the problem by introducing a new NodeFlag::IsUnknownElement and using that to check whether JSHTMLUnknownElement should be created for a given element or not. Note that HTMLElement had a virtual function, isHTMLUnknownElement, to check this condition but invoking a virtual function proved to incur too much runtime cost. * dom/Node.h: (WebCore::Node::isUnknownElement const): Added. (WebCore::Node::isHTMLUnknownElement const): Added. (WebCore::Node::isSVGUnknownElement const): Added. (WebCore::Node::isMathMLUnknownElement const): Added. (WebCore::Node::NodeFlag): Added NodeFlag::IsUnknownElement. * dom/make_names.pl: (printWrapperFactoryCppFile): Treat the element as HTMLUnknownElement only if isUnknownElement returns true instead of isCustomElementUpgradeCandidate returning false. * html/HTMLElement.h: (WebCore::HTMLElement::isHTMLUnknownElement const): Deleted. * html/HTMLUnknownElement.h: * mathml/MathMLElement.cpp: (WebCore::MathMLElement::MathMLElement): Added ConstructionType as an argument. * mathml/MathMLElement.h: * mathml/MathMLUnknownElement.h: (WebCore::MathMLUnknownElement::MathMLUnknownElement): Set NodeFlag::IsUnknownElement. * svg/SVGElement.cpp: (WebCore::SVGElement::SVGElement): Added ConstructionType as an argument. * svg/SVGElement.h: * svg/SVGUnknownElement.h: (WebCore::SVGUnknownElement::SVGUnknownElement): Set NodeFlag::IsUnknownElement. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273935 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-04 Ryosuke Niwa "precustomized" state of custom elements can become HTMLUnknownElement https://bugs.webkit.org/show_bug.cgi?id=221652 Reviewed by Darin Adler. The bug was caused by createJSHTMLWrapper in JSHTMLElementWrapperFactory.cpp relying on !isCustomElementUpgradeCandidate() to create HTMLUnknownElement as JS wrapper of the element. This is problematic after r266269 since that change re-purposes CustomElementState::Failed on a custom element as "precustomized" state instead of introducing another enum value in CustomElementState as RareDataBitFields has no more bits available. This patch fixes the problem by introducing a new NodeFlag::IsUnknownElement and using that to check whether JSHTMLUnknownElement should be created for a given element or not. Note that HTMLElement had a virtual function, isHTMLUnknownElement, to check this condition but invoking a virtual function proved to incur too much runtime cost. * dom/Node.h: (WebCore::Node::isUnknownElement const): Added. (WebCore::Node::isHTMLUnknownElement const): Added. (WebCore::Node::isSVGUnknownElement const): Added. (WebCore::Node::isMathMLUnknownElement const): Added. (WebCore::Node::NodeFlag): Added NodeFlag::IsUnknownElement. * dom/make_names.pl: (printWrapperFactoryCppFile): Treat the element as HTMLUnknownElement only if isUnknownElement returns true instead of isCustomElementUpgradeCandidate returning false. * html/HTMLElement.h: (WebCore::HTMLElement::isHTMLUnknownElement const): Deleted. * html/HTMLUnknownElement.h: * mathml/MathMLElement.cpp: (WebCore::MathMLElement::MathMLElement): Added ConstructionType as an argument. * mathml/MathMLElement.h: * mathml/MathMLUnknownElement.h: (WebCore::MathMLUnknownElement::MathMLUnknownElement): Set NodeFlag::IsUnknownElement. * svg/SVGElement.cpp: (WebCore::SVGElement::SVGElement): Added ConstructionType as an argument. * svg/SVGElement.h: * svg/SVGUnknownElement.h: (WebCore::SVGUnknownElement::SVGUnknownElement): Set NodeFlag::IsUnknownElement. 2021-04-08 Russell Epstein Cherry-pick r273866. rdar://problem/76416143 Nulllptr crash in DeleteSelectionCommand::handleGeneralDelete() https://bugs.webkit.org/show_bug.cgi?id=222681 Reviewed by Wenson Hsieh. Skip the loop when m_downstreamEnd.isNull() or im_downstreamEnd.isOrphan() is true to avoid dereferencing a nullptr. No new tests since we don't have any reproduction for this crash, and it's not obvious how we're getting into that state. * editing/DeleteSelectionCommand.cpp: (WebCore::DeleteSelectionCommand::handleGeneralDelete): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273866 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-03 Ryosuke Niwa Nulllptr crash in DeleteSelectionCommand::handleGeneralDelete() https://bugs.webkit.org/show_bug.cgi?id=222681 Reviewed by Wenson Hsieh. Skip the loop when m_downstreamEnd.isNull() or im_downstreamEnd.isOrphan() is true to avoid dereferencing a nullptr. No new tests since we don't have any reproduction for this crash, and it's not obvious how we're getting into that state. * editing/DeleteSelectionCommand.cpp: (WebCore::DeleteSelectionCommand::handleGeneralDelete): 2021-04-08 Russell Epstein Cherry-pick r273820. rdar://problem/76412727 Report the correct document uri in the case of a ContentSecurityPolicyClient https://bugs.webkit.org/show_bug.cgi?id=222489 Reviewed by Brent Fulgham. Source/WebCore: Tests: http/tests/security/contentSecurityPolicy/report-document-uri-after-blocked-redirect.html http/tests/security/contentSecurityPolicy/report-document-uri-blob.html Previously we were setting the document URI to be the blocked URI in the case where we were using a ContentSecurityPolicyClient and didn't have access to the document URL. This patch passes the document URL to the network process when loading a resource so we can properly set the document URI in this case. * page/csp/ContentSecurityPolicy.cpp: (WebCore::shouldReportProtocolOnly): (WebCore::ContentSecurityPolicy::deprecatedURLForReporting const): (WebCore::ContentSecurityPolicy::reportViolation const): Follow spec guidelines https://www.w3.org/TR/CSP2/#violation-reports and set the document URI to be the URI's scheme if it is a globally unique identifier. In the case where we are using a client and don't have the document URL, we should at least strip the blocked URL before reporting to align with the spec. * page/csp/ContentSecurityPolicy.h: (WebCore::ContentSecurityPolicy::setDocumentURL): Source/WebKit: Pass the document URL from the Network Process when we schedule a load in case we need to report a CSP violation in NetworkLoadChecker. * NetworkProcess/NetworkLoadChecker.cpp: (WebKit::NetworkLoadChecker::NetworkLoadChecker): (WebKit::NetworkLoadChecker::contentSecurityPolicy): The regular toString() method sets file:// URLs to null. We should use toRawString() so we can report the scheme if the source origin is a local file, as per the W3C spec. * NetworkProcess/NetworkLoadChecker.h: * NetworkProcess/NetworkResourceLoadParameters.cpp: (WebKit::NetworkResourceLoadParameters::encode const): (WebKit::NetworkResourceLoadParameters::decode): * NetworkProcess/NetworkResourceLoadParameters.h: * NetworkProcess/NetworkResourceLoader.cpp: * NetworkProcess/PingLoad.cpp: (WebKit::PingLoad::PingLoad): * WebProcess/Network/WebLoaderStrategy.cpp: (WebKit::WebLoaderStrategy::scheduleLoadFromNetworkProcess): Tools: Rename OverrideContentSecurityPolicy.mm to ContentSecurityPolicy.mm so we can use it for more general purpose CSP testing. Add a test for document-uri reporting for file:, data: and about: protocols. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKitCocoa/ContentSecurityPolicy.mm: Renamed from Tools/TestWebKitAPI/Tests/WebKitCocoa/OverrideContentSecurityPolicy.mm. (TEST): * TestWebKitAPI/Tests/WebKitCocoa/csp-document-uri-report.html: Added. LayoutTests: Layout test coverage for redirects using a ContentSecurityPolicyClient and blob files. * http/tests/security/contentSecurityPolicy/report-document-uri-blob-expected.txt: Added. * http/tests/security/contentSecurityPolicy/report-document-uri-blob.html: Added. * http/tests/security/contentSecurityPolicy/report-document-uri-after-blocked-redirect-expected.txt: Added. * http/tests/security/contentSecurityPolicy/report-document-uri-after-blocked-redirect.html: Added. * platform/mac-wk1/http/tests/security/contentSecurityPolicy/report-document-uri-after-blocked-redirect-expected.txt: Added. * platform/win/http/tests/security/contentSecurityPolicy/report-document-uri-after-blocked-redirect-expected.txt: Added. * platform/win/TestExpectations: Blob URLs timeout on win. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273820 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-03 Kate Cheney Report the correct document uri in the case of a ContentSecurityPolicyClient https://bugs.webkit.org/show_bug.cgi?id=222489 Reviewed by Brent Fulgham. Tests: http/tests/security/contentSecurityPolicy/report-document-uri-after-blocked-redirect.html http/tests/security/contentSecurityPolicy/report-document-uri-blob.html Previously we were setting the document URI to be the blocked URI in the case where we were using a ContentSecurityPolicyClient and didn't have access to the document URL. This patch passes the document URL to the network process when loading a resource so we can properly set the document URI in this case. * page/csp/ContentSecurityPolicy.cpp: (WebCore::shouldReportProtocolOnly): (WebCore::ContentSecurityPolicy::deprecatedURLForReporting const): (WebCore::ContentSecurityPolicy::reportViolation const): Follow spec guidelines https://www.w3.org/TR/CSP2/#violation-reports and set the document URI to be the URI's scheme if it is a globally unique identifier. In the case where we are using a client and don't have the document URL, we should at least strip the blocked URL before reporting to align with the spec. * page/csp/ContentSecurityPolicy.h: (WebCore::ContentSecurityPolicy::setDocumentURL): 2021-04-08 Russell Epstein Cherry-pick r273752. rdar://problem/76416035 Crash under KeyframeEffect::setTarget() https://bugs.webkit.org/show_bug.cgi?id=222591 Reviewed by David Kilzer. The Styleable returned by targetStyleable() holds a reference to the Element that at this point is m_target (assuming it's non-null). However, once we set the new value for m_target, if the only reference to the original target was held by this KeyframeEffect, then that element will be deallocated and by the time we call didChangeTargetStyleable() it will be gone. To address, we create a RefPtr in the scope of KeyframeEffect::setTarget() protecting the Styleable's element while didChangeTargetStyleable() is called. * animation/KeyframeEffect.cpp: (WebCore::KeyframeEffect::setTarget): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273752 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-02 Antoine Quint Crash under KeyframeEffect::setTarget() https://bugs.webkit.org/show_bug.cgi?id=222591 Reviewed by David Kilzer. The Styleable returned by targetStyleable() holds a reference to the Element that at this point is m_target (assuming it's non-null). However, once we set the new value for m_target, if the only reference to the original target was held by this KeyframeEffect, then that element will be deallocated and by the time we call didChangeTargetStyleable() it will be gone. To address, we create a RefPtr in the scope of KeyframeEffect::setTarget() protecting the Styleable's element while didChangeTargetStyleable() is called. * animation/KeyframeEffect.cpp: (WebCore::KeyframeEffect::setTarget): 2021-04-08 Russell Epstein Cherry-pick r273505. rdar://problem/76374627 Streamline ImageData size calculations and handle out-of-memory https://bugs.webkit.org/show_bug.cgi?id=222340 Reviewed by Geoff Garen. * html/ImageData.cpp: (WebCore::ImageData::dataSize): Added (WebCore::ImageData::create): Use the dataSize function consistently to compute the size of the byteArray needed. In the JavaScript-exposed create function, use tryCreateUninitialized and throw an exception if it fails. Removed an unnecessary assertion that simply repeats something covered by an if statement just above it. (WebCore::ImageData::ImageSize): Removed the overload that only takes an IntSize and allocates a Uint8ClampedArray, moving that into the create function instead. * html/ImageData.h: Added dataSize, removed a constructor overload. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273505 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-23 Darin Adler Streamline ImageData size calculations and handle out-of-memory https://bugs.webkit.org/show_bug.cgi?id=222340 Reviewed by Geoff Garen. * html/ImageData.cpp: (WebCore::ImageData::dataSize): Added (WebCore::ImageData::create): Use the dataSize function consistently to compute the size of the byteArray needed. In the JavaScript-exposed create function, use tryCreateUninitialized and throw an exception if it fails. Removed an unnecessary assertion that simply repeats something covered by an if statement just above it. (WebCore::ImageData::ImageSize): Removed the overload that only takes an IntSize and allocates a Uint8ClampedArray, moving that into the create function instead. * html/ImageData.h: Added dataSize, removed a constructor overload. 2021-04-08 Russell Epstein Cherry-pick r273468. rdar://problem/76374398 Crash in CompositeEditCommand::breakOutOfEmptyMailBlockquotedParagraph() https://bugs.webkit.org/show_bug.cgi?id=222339 Patch by Julian Gonzalez on 2021-02-24 Reviewed by Ryosuke Niwa. Make a copy of Ref when inserting before highest blockquote node. * editing/CompositeEditCommand.cpp: (WebCore::CompositeEditCommand::breakOutOfEmptyMailBlockquotedParagraph): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273468 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-24 Julian Gonzalez Crash in CompositeEditCommand::breakOutOfEmptyMailBlockquotedParagraph() https://bugs.webkit.org/show_bug.cgi?id=222339 Reviewed by Ryosuke Niwa. Make a copy of Ref when inserting before highest blockquote node. * editing/CompositeEditCommand.cpp: (WebCore::CompositeEditCommand::breakOutOfEmptyMailBlockquotedParagraph): 2021-04-08 Russell Epstein Cherry-pick r273300. rdar://problem/76375521 Handle Page::didFinishLoadingImageForElement asynchronously https://bugs.webkit.org/show_bug.cgi?id=221390 Reviewed by Antti Koivisto. Use EventLoop instead of RunLoop::main() to be thread safe in iOS WebKit1. * page/Page.cpp: (WebCore::Page::didFinishLoadingImageForElement): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273300 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-23 Ryosuke Niwa Handle Page::didFinishLoadingImageForElement asynchronously https://bugs.webkit.org/show_bug.cgi?id=221390 Reviewed by Antti Koivisto. Use EventLoop instead of RunLoop::main() to be thread safe in iOS WebKit1. * page/Page.cpp: (WebCore::Page::didFinishLoadingImageForElement): 2021-04-08 Russell Epstein Cherry-pick r273231. rdar://problem/76375521 Handle Page::didFinishLoadingImageForElement asynchronously https://bugs.webkit.org/show_bug.cgi?id=221390 Patch by Carlos Garcia Campos on 2021-02-22 Reviewed by Alex Christensen. When called synchronously from RenderImage::notifyFinished() it's not possible to update the layout because scripts are not allowed at that point. * page/Page.cpp: (WebCore::Page::didFinishLoadingImageForElement): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273231 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-22 Carlos Garcia Campos Handle Page::didFinishLoadingImageForElement asynchronously https://bugs.webkit.org/show_bug.cgi?id=221390 Reviewed by Alex Christensen. When called synchronously from RenderImage::notifyFinished() it's not possible to update the layout because scripts are not allowed at that point. * page/Page.cpp: (WebCore::Page::didFinishLoadingImageForElement): 2021-04-08 Russell Epstein Cherry-pick r272900. rdar://problem/76411260 Teardown shadow root renderers on hostChildElementDidChange https://bugs.webkit.org/show_bug.cgi?id=221386 Patch by Carlos Garcia Campos on 2021-02-16 Reviewed by Antti Koivisto. Source/WebCore: When details element has a display contents style, the default summary renderer is not cleared when a new summary element is added. This causes that both summary elements are rendered at the same time, instead of the active one. The crash happens when the details element is removed from the document, because the default summary element still has a valid renderer on destroy. * dom/SlotAssignment.h: (WebCore::ShadowRoot::hostChildElementDidChange): LayoutTests: * tables/table-col-indent-crash-expected.txt: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272900 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-16 Carlos Garcia Campos Teardown shadow root renderers on hostChildElementDidChange https://bugs.webkit.org/show_bug.cgi?id=221386 Reviewed by Antti Koivisto. When details element has a display contents style, the default summary renderer is not cleared when a new summary element is added. This causes that both summary elements are rendered at the same time, instead of the active one. The crash happens when the details element is removed from the document, because the default summary element still has a valid renderer on destroy. * dom/SlotAssignment.h: (WebCore::ShadowRoot::hostChildElementDidChange): 2021-04-08 Russell Epstein Cherry-pick r272843. rdar://problem/76374775 Don't update form control elements validity status if they are detached from the document. https://bugs.webkit.org/show_bug.cgi?id=220390 Reviewed by Ryosuke Niwa. When a radio button input element is removed from a form (either because it's moved or because the form is deleted) then it's also removed from its current RadioButtonGroup. The latter removal might require the update of the input validity status. In case of validity status changes, then we have to walk up the ancestor chain in order to update the style for pseudo classes such as :valid :invalid. That node traversal should not be done in case of being detached from the main document because our ancestors might have been deleted before. Apart from that we're replacing the HashSet of raw pointers to descendants in HTMLFieldSetElement by a WeakHashSet which is safer. * html/HTMLFieldSetElement.cpp: (WebCore::HTMLFieldSetElement::matchesValidPseudoClass const): (WebCore::HTMLFieldSetElement::matchesInvalidPseudoClass const): (WebCore::HTMLFieldSetElement::addInvalidDescendant): (WebCore::HTMLFieldSetElement::removeInvalidDescendant): * html/HTMLFieldSetElement.h: * html/HTMLFormControlElement.cpp: (WebCore::HTMLFormControlElement::updateValidity(): Early return in case of isConnected(). git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272843 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-12 Sergio Villar Senin Don't update form control elements validity status if they are detached from the document. https://bugs.webkit.org/show_bug.cgi?id=220390 Reviewed by Ryosuke Niwa. When a radio button input element is removed from a form (either because it's moved or because the form is deleted) then it's also removed from its current RadioButtonGroup. The latter removal might require the update of the input validity status. In case of validity status changes, then we have to walk up the ancestor chain in order to update the style for pseudo classes such as :valid :invalid. That node traversal should not be done in case of being detached from the main document because our ancestors might have been deleted before. Apart from that we're replacing the HashSet of raw pointers to descendants in HTMLFieldSetElement by a WeakHashSet which is safer. * html/HTMLFieldSetElement.cpp: (WebCore::HTMLFieldSetElement::matchesValidPseudoClass const): (WebCore::HTMLFieldSetElement::matchesInvalidPseudoClass const): (WebCore::HTMLFieldSetElement::addInvalidDescendant): (WebCore::HTMLFieldSetElement::removeInvalidDescendant): * html/HTMLFieldSetElement.h: * html/HTMLFormControlElement.cpp: (WebCore::HTMLFormControlElement::updateValidity(): Early return in case of isConnected(). 2021-04-08 Russell Epstein Cherry-pick r271514. rdar://problem/76375033 Use event loop to set title https://bugs.webkit.org/show_bug.cgi?id=218496 Patch by Rob Buis on 2021-01-15 Reviewed by Ryosuke Niwa. Source/WebCore: Use event loop to set title to avoid calling WebFrameLoaderClient within HTMLTitleElement::insertedIntoAncestor. * dom/Document.cpp: (WebCore::Document::updateTitle): * dom/Document.h: Tools: Adapt unit tests to wait for title change tasks to be processed. * TestWebKitAPI/Tests/WebKit/PageLoadState.cpp: (TestWebKitAPI::didChangeTitle): (TestWebKitAPI::TEST): * TestWebKitAPI/Tests/WebKitCocoa/UIDelegate.mm: (TEST): LayoutTests: Adapt tests to make sure pending title change tasks are processed before the test is done. * fast/dom/title-text-property-2.html: * fast/dom/title-text-property-assigning-empty-string.html: * fast/dom/title-text-property.html: * http/tests/globalhistory/history-delegate-basic-title-expected.txt: * http/tests/globalhistory/history-delegate-basic-title.html: * http/tests/loading/basic-auth-load-URL-with-consecutive-slashes-expected.txt: * http/tests/loading/basic-auth-load-URL-with-consecutive-slashes.html: * http/tests/loading/redirect-with-no-location-crash-expected.txt: * http/tests/loading/redirect-with-no-location-crash.html: * platform/mac-wk2/TestExpectations: * platform/win/http/tests/loading/basic-auth-load-URL-with-consecutive-slashes-expected.txt: Copied from LayoutTests/http/tests/loading/basic-auth-load-URL-with-consecutive-slashes-expected.txt. * platform/wk2/http/tests/loading/basic-auth-load-URL-with-consecutive-slashes-expected.txt: * platform/wk2/http/tests/loading/redirect-with-no-location-crash-expected.txt: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271514 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-01-15 Rob Buis Use event loop to set title https://bugs.webkit.org/show_bug.cgi?id=218496 Reviewed by Ryosuke Niwa. Use event loop to set title to avoid calling WebFrameLoaderClient within HTMLTitleElement::insertedIntoAncestor. * dom/Document.cpp: (WebCore::Document::updateTitle): * dom/Document.h: 2021-04-08 Russell Epstein Cherry-pick r271404. rdar://problem/76413093 Safari Networking high % CPU when Caches/WebKit/ServiceWorkers folder not writable https://bugs.webkit.org/show_bug.cgi?id=220220 Reviewed by Chris Dumez. In case writing changes in the service worker database fails, we retry once. If it fails, we give up and will only retry writing when new changes happen. Manually tested. * workers/service/server/RegistrationDatabase.cpp: (WebCore::RegistrationDatabase::pushChanges): (WebCore::RegistrationDatabase::schedulePushChanges): * workers/service/server/RegistrationDatabase.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271404 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-01-12 Youenn Fablet Safari Networking high % CPU when Caches/WebKit/ServiceWorkers folder not writable https://bugs.webkit.org/show_bug.cgi?id=220220 Reviewed by Chris Dumez. In case writing changes in the service worker database fails, we retry once. If it fails, we give up and will only retry writing when new changes happen. Manually tested. * workers/service/server/RegistrationDatabase.cpp: (WebCore::RegistrationDatabase::pushChanges): (WebCore::RegistrationDatabase::schedulePushChanges): * workers/service/server/RegistrationDatabase.h: 2021-03-22 Russell Epstein Cherry-pick r274846. rdar://problem/75711124 Use JSValueInWrappedObject to keep the JSObject alive for QuickTimePluginReplacement https://bugs.webkit.org/show_bug.cgi?id=223561 Reviewed by Geoffrey Garen. This patch replaces QuickTimePluginReplacement's m_scriptObject member variable by JSValueInWrappedObject in HTMLPlugInElement and hooks it up with the slot visitor. Also use WeakPtr instead of a raw pointer for the back reference to the plugin element in QuickTimePluginReplacement and YouTubePluginReplacement. * Modules/plugins/PluginReplacement.h: (WebCore::PluginReplacement::InstallResult): Added; a boolean indicating the installation had succeeded and the script object for QuickTimePluginReplacement. (WebCore::PluginReplacement::scriptObject): Deleted. * Modules/plugins/QuickTimePluginReplacement.h: * Modules/plugins/QuickTimePluginReplacement.mm: (WebCore::QuickTimePluginReplacement::QuickTimePluginReplacement): Deployed WeakPtr. (WebCore::QuickTimePluginReplacement::~QuickTimePluginReplacement): Removed the superflous de-initialization of the member variables. (WebCore::QuickTimePluginReplacement::installReplacement): Now returns JSValue instead of storing it in m_scriptObject. * Modules/plugins/YouTubePluginReplacement.cpp: (WebCore::YouTubePluginReplacement::YouTubePluginReplacement): Deployed WeakPtr. (WebCore::YouTubePluginReplacement::installReplacement): * Modules/plugins/YouTubePluginReplacement.h: * bindings/scripts/CodeGeneratorJS.pm: (InstanceNeedsVisitChildren): Generate visitChildren when an IDL has Plugin attribute. (GenerateImplementation): Visit the newly added JSValueInWrappedObject. * html/HTMLPlugInElement.cpp: (WebCore::HTMLPlugInElement::didAddUserAgentShadowRoot): Store the script object returned by QuickTimePluginReplacement::installReplacement in the newly added member variable. (WebCore::HTMLPlugInElement::scriptObjectForPluginReplacement): Updated. * html/HTMLPlugInElement.h: (WebCore::HTMLPlugInElement::pluginReplacementScriptObject): Added. Used by visitChildren. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274846 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-22 Ryosuke Niwa Use JSValueInWrappedObject to keep the JSObject alive for QuickTimePluginReplacement https://bugs.webkit.org/show_bug.cgi?id=223561 Reviewed by Geoffrey Garen. This patch replaces QuickTimePluginReplacement's m_scriptObject member variable by JSValueInWrappedObject in HTMLPlugInElement and hooks it up with the slot visitor. Also use WeakPtr instead of a raw pointer for the back reference to the plugin element in QuickTimePluginReplacement and YouTubePluginReplacement. * Modules/plugins/PluginReplacement.h: (WebCore::PluginReplacement::InstallResult): Added; a boolean indicating the installation had succeeded and the script object for QuickTimePluginReplacement. (WebCore::PluginReplacement::scriptObject): Deleted. * Modules/plugins/QuickTimePluginReplacement.h: * Modules/plugins/QuickTimePluginReplacement.mm: (WebCore::QuickTimePluginReplacement::QuickTimePluginReplacement): Deployed WeakPtr. (WebCore::QuickTimePluginReplacement::~QuickTimePluginReplacement): Removed the superflous de-initialization of the member variables. (WebCore::QuickTimePluginReplacement::installReplacement): Now returns JSValue instead of storing it in m_scriptObject. * Modules/plugins/YouTubePluginReplacement.cpp: (WebCore::YouTubePluginReplacement::YouTubePluginReplacement): Deployed WeakPtr. (WebCore::YouTubePluginReplacement::installReplacement): * Modules/plugins/YouTubePluginReplacement.h: * bindings/scripts/CodeGeneratorJS.pm: (InstanceNeedsVisitChildren): Generate visitChildren when an IDL has Plugin attribute. (GenerateImplementation): Visit the newly added JSValueInWrappedObject. * html/HTMLPlugInElement.cpp: (WebCore::HTMLPlugInElement::didAddUserAgentShadowRoot): Store the script object returned by QuickTimePluginReplacement::installReplacement in the newly added member variable. (WebCore::HTMLPlugInElement::scriptObjectForPluginReplacement): Updated. * html/HTMLPlugInElement.h: (WebCore::HTMLPlugInElement::pluginReplacementScriptObject): Added. Used by visitChildren. 2021-03-01 Alan Coon Cherry-pick r273656. rdar://problem/74883325 REGRESSION(r272004): transform transition with delay doesn't behave correctly https://bugs.webkit.org/show_bug.cgi?id=222545 Reviewed by Dean Jackson. Source/WebCore: To support accelerated animations of individual transform properties, we introduced the notion of non-interpolating animations to apply the underlying value for a given property before applying the actual animations for this property with additivity set to true. These non-interpolating animations were meant to last between the time at which animations were committed and the effective start of the first animation for that property, accounting for any delay. However, we neglected to handle the case where that first animation had a fill mode that would make it fill backwards, such as CSS Transitions. In that situation, the animation would have its first keyframe applied on top of the underlying value, effectively applying the underlying value twice with additivity. We now only add these non-interpolating animations if the first animation has a delay and does not fill backwards. Test: webanimations/transform-transition-with-delay-on-forced-layer-with-transform.html * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::updateAnimations): LayoutTests: Add a new test where an element with a non-identity transform starts a transform transition with a long delay. Prior to this patch, this test failed because, while in the delay phase, the transition would mean the underlying transform was applied twice: once by the non-interpolating animation generated for the underlying "transform" value, and once by the first keyframe of the transition since it fills backwards. * webanimations/transform-transition-with-delay-on-forced-layer-with-transform-expected.html: Added. * webanimations/transform-transition-with-delay-on-forced-layer-with-transform.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273656 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-01 Antoine Quint REGRESSION(r272004): transform transition with delay doesn't behave correctly https://bugs.webkit.org/show_bug.cgi?id=222545 Reviewed by Dean Jackson. To support accelerated animations of individual transform properties, we introduced the notion of non-interpolating animations to apply the underlying value for a given property before applying the actual animations for this property with additivity set to true. These non-interpolating animations were meant to last between the time at which animations were committed and the effective start of the first animation for that property, accounting for any delay. However, we neglected to handle the case where that first animation had a fill mode that would make it fill backwards, such as CSS Transitions. In that situation, the animation would have its first keyframe applied on top of the underlying value, effectively applying the underlying value twice with additivity. We now only add these non-interpolating animations if the first animation has a delay and does not fill backwards. Test: webanimations/transform-transition-with-delay-on-forced-layer-with-transform.html * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::updateAnimations): 2021-03-24 Russell Epstein Cherry-pick r273868. rdar://problem/75764823 Crash in removeSymbolElementsFromSubtree() https://bugs.webkit.org/show_bug.cgi?id=222397 Patch by Julian Gonzalez on 2021-03-03 Reviewed by Ryosuke Niwa. Skip children in removeSymbolElementsFromSubtree(), so that we don't see nodes that have been removed in disassociateAndRemoveClones. Thanks to Darin Adler for the initial version of this patch and Ryosuke Niwa for refinements. * svg/SVGUseElement.cpp: (WebCore::removeSymbolElementsFromSubtree): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273868 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-03 Julian Gonzalez Crash in removeSymbolElementsFromSubtree() https://bugs.webkit.org/show_bug.cgi?id=222397 Reviewed by Ryosuke Niwa. Skip children in removeSymbolElementsFromSubtree(), so that we don't see nodes that have been removed in disassociateAndRemoveClones. Thanks to Darin Adler for the initial version of this patch and Ryosuke Niwa for refinements. * svg/SVGUseElement.cpp: (WebCore::removeSymbolElementsFromSubtree): 2021-03-22 Russell Epstein Cherry-pick r274846. rdar://problem/75706515 Use JSValueInWrappedObject to keep the JSObject alive for QuickTimePluginReplacement https://bugs.webkit.org/show_bug.cgi?id=223561 Reviewed by Geoffrey Garen. This patch replaces QuickTimePluginReplacement's m_scriptObject member variable by JSValueInWrappedObject in HTMLPlugInElement and hooks it up with the slot visitor. Also use WeakPtr instead of a raw pointer for the back reference to the plugin element in QuickTimePluginReplacement and YouTubePluginReplacement. * Modules/plugins/PluginReplacement.h: (WebCore::PluginReplacement::InstallResult): Added; a boolean indicating the installation had succeeded and the script object for QuickTimePluginReplacement. (WebCore::PluginReplacement::scriptObject): Deleted. * Modules/plugins/QuickTimePluginReplacement.h: * Modules/plugins/QuickTimePluginReplacement.mm: (WebCore::QuickTimePluginReplacement::QuickTimePluginReplacement): Deployed WeakPtr. (WebCore::QuickTimePluginReplacement::~QuickTimePluginReplacement): Removed the superflous de-initialization of the member variables. (WebCore::QuickTimePluginReplacement::installReplacement): Now returns JSValue instead of storing it in m_scriptObject. * Modules/plugins/YouTubePluginReplacement.cpp: (WebCore::YouTubePluginReplacement::YouTubePluginReplacement): Deployed WeakPtr. (WebCore::YouTubePluginReplacement::installReplacement): * Modules/plugins/YouTubePluginReplacement.h: * bindings/scripts/CodeGeneratorJS.pm: (InstanceNeedsVisitChildren): Generate visitChildren when an IDL has Plugin attribute. (GenerateImplementation): Visit the newly added JSValueInWrappedObject. * html/HTMLPlugInElement.cpp: (WebCore::HTMLPlugInElement::didAddUserAgentShadowRoot): Store the script object returned by QuickTimePluginReplacement::installReplacement in the newly added member variable. (WebCore::HTMLPlugInElement::scriptObjectForPluginReplacement): Updated. * html/HTMLPlugInElement.h: (WebCore::HTMLPlugInElement::pluginReplacementScriptObject): Added. Used by visitChildren. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274846 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-22 Ryosuke Niwa Use JSValueInWrappedObject to keep the JSObject alive for QuickTimePluginReplacement https://bugs.webkit.org/show_bug.cgi?id=223561 Reviewed by Geoffrey Garen. This patch replaces QuickTimePluginReplacement's m_scriptObject member variable by JSValueInWrappedObject in HTMLPlugInElement and hooks it up with the slot visitor. Also use WeakPtr instead of a raw pointer for the back reference to the plugin element in QuickTimePluginReplacement and YouTubePluginReplacement. * Modules/plugins/PluginReplacement.h: (WebCore::PluginReplacement::InstallResult): Added; a boolean indicating the installation had succeeded and the script object for QuickTimePluginReplacement. (WebCore::PluginReplacement::scriptObject): Deleted. * Modules/plugins/QuickTimePluginReplacement.h: * Modules/plugins/QuickTimePluginReplacement.mm: (WebCore::QuickTimePluginReplacement::QuickTimePluginReplacement): Deployed WeakPtr. (WebCore::QuickTimePluginReplacement::~QuickTimePluginReplacement): Removed the superflous de-initialization of the member variables. (WebCore::QuickTimePluginReplacement::installReplacement): Now returns JSValue instead of storing it in m_scriptObject. * Modules/plugins/YouTubePluginReplacement.cpp: (WebCore::YouTubePluginReplacement::YouTubePluginReplacement): Deployed WeakPtr. (WebCore::YouTubePluginReplacement::installReplacement): * Modules/plugins/YouTubePluginReplacement.h: * bindings/scripts/CodeGeneratorJS.pm: (InstanceNeedsVisitChildren): Generate visitChildren when an IDL has Plugin attribute. (GenerateImplementation): Visit the newly added JSValueInWrappedObject. * html/HTMLPlugInElement.cpp: (WebCore::HTMLPlugInElement::didAddUserAgentShadowRoot): Store the script object returned by QuickTimePluginReplacement::installReplacement in the newly added member variable. (WebCore::HTMLPlugInElement::scriptObjectForPluginReplacement): Updated. * html/HTMLPlugInElement.h: (WebCore::HTMLPlugInElement::pluginReplacementScriptObject): Added. Used by visitChildren. 2021-03-01 Alan Coon Cherry-pick r273656. rdar://problem/74883395 REGRESSION(r272004): transform transition with delay doesn't behave correctly https://bugs.webkit.org/show_bug.cgi?id=222545 Reviewed by Dean Jackson. Source/WebCore: To support accelerated animations of individual transform properties, we introduced the notion of non-interpolating animations to apply the underlying value for a given property before applying the actual animations for this property with additivity set to true. These non-interpolating animations were meant to last between the time at which animations were committed and the effective start of the first animation for that property, accounting for any delay. However, we neglected to handle the case where that first animation had a fill mode that would make it fill backwards, such as CSS Transitions. In that situation, the animation would have its first keyframe applied on top of the underlying value, effectively applying the underlying value twice with additivity. We now only add these non-interpolating animations if the first animation has a delay and does not fill backwards. Test: webanimations/transform-transition-with-delay-on-forced-layer-with-transform.html * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::updateAnimations): LayoutTests: Add a new test where an element with a non-identity transform starts a transform transition with a long delay. Prior to this patch, this test failed because, while in the delay phase, the transition would mean the underlying transform was applied twice: once by the non-interpolating animation generated for the underlying "transform" value, and once by the first keyframe of the transition since it fills backwards. * webanimations/transform-transition-with-delay-on-forced-layer-with-transform-expected.html: Added. * webanimations/transform-transition-with-delay-on-forced-layer-with-transform.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273656 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-01 Antoine Quint REGRESSION(r272004): transform transition with delay doesn't behave correctly https://bugs.webkit.org/show_bug.cgi?id=222545 Reviewed by Dean Jackson. To support accelerated animations of individual transform properties, we introduced the notion of non-interpolating animations to apply the underlying value for a given property before applying the actual animations for this property with additivity set to true. These non-interpolating animations were meant to last between the time at which animations were committed and the effective start of the first animation for that property, accounting for any delay. However, we neglected to handle the case where that first animation had a fill mode that would make it fill backwards, such as CSS Transitions. In that situation, the animation would have its first keyframe applied on top of the underlying value, effectively applying the underlying value twice with additivity. We now only add these non-interpolating animations if the first animation has a delay and does not fill backwards. Test: webanimations/transform-transition-with-delay-on-forced-layer-with-transform.html * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::updateAnimations): 2021-03-30 Alan Coon Cherry-pick r275214. rdar://problem/76022033 [LFC][Integration] Elements that overflow inline-blocks are not hit tested correctly https://bugs.webkit.org/show_bug.cgi?id=223932 rdar://75888718 Reviewed by Zalan Bujtas. Source/WebCore: If an inline block has overflowing children (for example due to negative margin) we may fail to hit test them. Test: fast/inline-block/hit-test-negative-margin-child.html * layout/integration/LayoutIntegrationLineLayout.cpp: (WebCore::LayoutIntegration::LineLayout::hitTest): Always descend into inline blocks even if their run didn't hit. LayoutTests: * fast/inline-block/hit-test-negative-margin-child-expected.txt: Added. * fast/inline-block/hit-test-negative-margin-child.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@275214 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-30 Antti Koivisto [LFC][Integration] Elements that overflow inline-blocks are not hit tested correctly https://bugs.webkit.org/show_bug.cgi?id=223932 rdar://75888718 Reviewed by Zalan Bujtas. If an inline block has overflowing children (for example due to negative margin) we may fail to hit test them. Test: fast/inline-block/hit-test-negative-margin-child.html * layout/integration/LayoutIntegrationLineLayout.cpp: (WebCore::LayoutIntegration::LineLayout::hitTest): Always descend into inline blocks even if their run didn't hit. 2021-03-23 Russell Epstein Cherry-pick r271385. rdar://problem/75751024 [WinCairo] Unreviewed build fix for r271353 https://bugs.webkit.org/show_bug.cgi?id=220407 > CrossOriginAccessControl.cpp(225): error C3861: 'isInNetworkProcess': identifier not found * platform/RuntimeApplicationChecks.h: (WebCore::isInWebProcess): (WebCore::isInGPUProcess): (WebCore::isInNetworkProcess): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271385 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-01-11 Fujii Hironori [WinCairo] Unreviewed build fix for r271353 https://bugs.webkit.org/show_bug.cgi?id=220407 > CrossOriginAccessControl.cpp(225): error C3861: 'isInNetworkProcess': identifier not found * platform/RuntimeApplicationChecks.h: (WebCore::isInWebProcess): (WebCore::isInGPUProcess): (WebCore::isInNetworkProcess): 2021-03-17 Alan Coon Cherry-pick r274573. rdar://problem/75538214 Degraded ScriptProcessorNode performance/quality for (14.0.3+ and iOS 14.4.1+) https://bugs.webkit.org/show_bug.cgi?id=223380 Reviewed by Geoffrey Garen. By extending the scope of the lock in ScriptProcessorNode::process(), r273542 essentially disabled double-buffering and thus negatively impacted rendering quality. To address the issue, we now have 2 locks, one per rendering buffer (since we're using double buffering) and only grab the lock we require when interacting with the buffers for this index. This maintains thread-safety while re-enabling double buffering. * Modules/webaudio/ScriptProcessorNode.cpp: (WebCore::ScriptProcessorNode::createInputBufferForJS const): Avoid duplicate call to topologyMatches() since copyTo() already calls it internally and returns false when !topologyMatches(). (WebCore::ScriptProcessorNode::process): * Modules/webaudio/ScriptProcessorNode.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274573 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-17 Chris Dumez Degraded ScriptProcessorNode performance/quality for (14.0.3+ and iOS 14.4.1+) https://bugs.webkit.org/show_bug.cgi?id=223380 Reviewed by Geoffrey Garen. By extending the scope of the lock in ScriptProcessorNode::process(), r273542 essentially disabled double-buffering and thus negatively impacted rendering quality. To address the issue, we now have 2 locks, one per rendering buffer (since we're using double buffering) and only grab the lock we require when interacting with the buffers for this index. This maintains thread-safety while re-enabling double buffering. * Modules/webaudio/ScriptProcessorNode.cpp: (WebCore::ScriptProcessorNode::createInputBufferForJS const): Avoid duplicate call to topologyMatches() since copyTo() already calls it internally and returns false when !topologyMatches(). (WebCore::ScriptProcessorNode::process): * Modules/webaudio/ScriptProcessorNode.h: 2021-03-10 Russell Epstein Cherry-pick r274203. rdar://problem/75273198 Release assertion failures under Editor::scanSelectionForTelephoneNumbers https://bugs.webkit.org/show_bug.cgi?id=223016 Reviewed by Ryosuke Niwa. No new tests; speculative fix for a non-reproducible crash, which theoretically has been avoided in a second way on trunk. * editing/Editor.cpp: (WebCore::extendSelection): (WebCore::Editor::scanSelectionForTelephoneNumbers): In r272777, Ryosuke discovered a case where FrameSelection::isRange() can be true, but firstRange() is an invalid range; in testing, forcing this to be the case reproduces the crash as reported. While that change may have fixed the root cause of this crash, we don't know that we've found all of the ways that one can get a orphaned selection *into* FrameSelection, and want a less risky workaround for this crash, so we'll also fix it in scanSelectionForTelephoneNumbers, by null-checking the result of FrameSelection::firstRange(). Also null-check the result of extendSelection(), since I cannot prove for sure that a valid range cannot become invalid in this method. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274203 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-10 Tim Horton Release assertion failures under Editor::scanSelectionForTelephoneNumbers https://bugs.webkit.org/show_bug.cgi?id=223016 Reviewed by Ryosuke Niwa. No new tests; speculative fix for a non-reproducible crash, which theoretically has been avoided in a second way on trunk. * editing/Editor.cpp: (WebCore::extendSelection): (WebCore::Editor::scanSelectionForTelephoneNumbers): In r272777, Ryosuke discovered a case where FrameSelection::isRange() can be true, but firstRange() is an invalid range; in testing, forcing this to be the case reproduces the crash as reported. While that change may have fixed the root cause of this crash, we don't know that we've found all of the ways that one can get a orphaned selection *into* FrameSelection, and want a less risky workaround for this crash, so we'll also fix it in scanSelectionForTelephoneNumbers, by null-checking the result of FrameSelection::firstRange(). Also null-check the result of extendSelection(), since I cannot prove for sure that a valid range cannot become invalid in this method. 2021-03-04 Alan Coon Cherry-pick r273901. rdar://problem/75058990 window proxy of detached iframe doesn't respect updates to global values https://bugs.webkit.org/show_bug.cgi?id=206445 Reviewed by Chris Dumez. Source/WebCore: According to the html spec the frame should only be needing for COOP access violation reporting, which we don't support. This patch removes our old behavior of blocking stores to windows that have been detached. I also removed some stale caching code from getOwnPropertySlotByIndex since it's only accessed once now. * bindings/js/JSDOMWindowCustom.cpp: (WebCore::JSDOMWindow::getOwnPropertySlotByIndex): (WebCore::JSDOMWindow::doPutPropertySecurityCheck): (WebCore::JSDOMWindow::put): (WebCore::JSDOMWindow::putByIndex): LayoutTests: * fast/frames/iframe-detached-window-still-writable-eval-expected.txt: Added. * fast/frames/iframe-detached-window-still-writable-eval.html: Added. * fast/frames/iframe-detached-window-still-writable-expected.txt: Added. * fast/frames/iframe-detached-window-still-writable.html: Added. * http/tests/dom/cross-origin-detached-window-properties-expected.txt: * http/tests/dom/cross-origin-detached-window-properties.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273901 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-04 Keith Miller window proxy of detached iframe doesn't respect updates to global values https://bugs.webkit.org/show_bug.cgi?id=206445 Reviewed by Chris Dumez. According to the html spec the frame should only be needing for COOP access violation reporting, which we don't support. This patch removes our old behavior of blocking stores to windows that have been detached. I also removed some stale caching code from getOwnPropertySlotByIndex since it's only accessed once now. * bindings/js/JSDOMWindowCustom.cpp: (WebCore::JSDOMWindow::getOwnPropertySlotByIndex): (WebCore::JSDOMWindow::doPutPropertySecurityCheck): (WebCore::JSDOMWindow::put): (WebCore::JSDOMWindow::putByIndex): 2021-03-04 Alan Coon Cherry-pick r273842. rdar://problem/75049285 Crash under SubresourceLoader::notifyDone() https://bugs.webkit.org/show_bug.cgi?id=222683 Reviewed by Geoffrey Garen. We were crashing doing a null-dereference of m_documentLoader under SubresourceLoader::notifyDone(). This adds null checks for m_documentLoader similarly to what is already done elsewhere in ResourceLoader. No new tests, I do not know how to reproduce this. * loader/SubresourceLoader.cpp: (WebCore::SubresourceLoader::notifyDone): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273842 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-03 Chris Dumez Crash under SubresourceLoader::notifyDone() https://bugs.webkit.org/show_bug.cgi?id=222683 Reviewed by Geoffrey Garen. We were crashing doing a null-dereference of m_documentLoader under SubresourceLoader::notifyDone(). This adds null checks for m_documentLoader similarly to what is already done elsewhere in ResourceLoader. No new tests, I do not know how to reproduce this. * loader/SubresourceLoader.cpp: (WebCore::SubresourceLoader::notifyDone): 2021-03-03 Ruben Turcios Cherry-pick r273764. rdar://problem/74992878 The layout of SVGImage should force the layout for its clients https://bugs.webkit.org/show_bug.cgi?id=221253 Reviewed by Simon Fraser. Source/WebCore: Unlike the bitmap image, the intrinsic size of SVGImage can only be known after running its layout. Because SVGImage can be used by multiple clients, CachedImage maintains an SVGImageCache which maps a client to an SVGImageForContainer. SVGImageForContainer is just a wrapper of SVGImage with the intrinsic size of the client. Because we may set an entry for the renderer in SVGImageCache early before running a layout for SVGImage and because the renderer intrinsic size depends on the intrinsic size of SVGImage, SVGImageForContainer may have an empty intrinsic size. So basically it is a race condition: knowing the intrinsic size of the SVGImage client depends on the intrinsic size of SVGImage itself. And the intrinsic size of SVGImageForContainer depends on the intrinsic size of the client. This may lead to not rendering the clients because their sizes are empty. To fix this issue we need to force calculateBackgroundImageGeometry() once we finish the layout of the SVGImage which happens after receiving all its data and calling RenderBox::imageChanged(). Test: fast/css/background-svg-image-loading.html * loader/cache/CachedImage.cpp: (WebCore::CachedImage::finishLoading): * rendering/RenderBox.cpp: (WebCore::RenderBox::repaintLayerRectsForImage): LayoutTests: * fast/css/background-svg-image-loading-expected.html: Added. * fast/css/background-svg-image-loading.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273764 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-02 Said Abou-Hallawa The layout of SVGImage should force the layout for its clients https://bugs.webkit.org/show_bug.cgi?id=221253 Reviewed by Simon Fraser. Unlike the bitmap image, the intrinsic size of SVGImage can only be known after running its layout. Because SVGImage can be used by multiple clients, CachedImage maintains an SVGImageCache which maps a client to an SVGImageForContainer. SVGImageForContainer is just a wrapper of SVGImage with the intrinsic size of the client. Because we may set an entry for the renderer in SVGImageCache early before running a layout for SVGImage and because the renderer intrinsic size depends on the intrinsic size of SVGImage, SVGImageForContainer may have an empty intrinsic size. So basically it is a race condition: knowing the intrinsic size of the SVGImage client depends on the intrinsic size of SVGImage itself. And the intrinsic size of SVGImageForContainer depends on the intrinsic size of the client. This may lead to not rendering the clients because their sizes are empty. To fix this issue we need to force calculateBackgroundImageGeometry() once we finish the layout of the SVGImage which happens after receiving all its data and calling RenderBox::imageChanged(). Test: fast/css/background-svg-image-loading.html * loader/cache/CachedImage.cpp: (WebCore::CachedImage::finishLoading): * rendering/RenderBox.cpp: (WebCore::RenderBox::repaintLayerRectsForImage): 2021-03-02 Alan Coon Apply patch. rdar://problem/74944301 2021-03-02 Ryosuke Niwa Merge r272331. Optimize PointerCaptureController::elementWasRemoved() https://bugs.webkit.org/show_bug.cgi?id=221316 Reviewed by Ryosuke Niwa. Speedometer profiles show HashTable iteration code under PointerCaptureController::elementWasRemoved() because we always add a hash entry for the mouse pointer. Optimize away by setting a flag that's only true if any element is referenced by pointer capture. * page/PointerCaptureController.cpp: (WebCore::PointerCaptureController::pointerCaptureElement const): (WebCore::PointerCaptureController::setPointerCapture): (WebCore::PointerCaptureController::releasePointerCapture): (WebCore::PointerCaptureController::hasPointerCapture): (WebCore::PointerCaptureController::pointerLockWasApplied): (WebCore::PointerCaptureController::elementWasRemoved): (WebCore::PointerCaptureController::reset): (WebCore::PointerCaptureController::updateHaveAnyCapturingElement): (WebCore::PointerCaptureController::touchWithIdentifierWasRemoved): (WebCore::PointerCaptureController::hasCancelledPointerEventForIdentifier const): (WebCore::PointerCaptureController::preventsCompatibilityMouseEventsForIdentifier const): (WebCore::PointerCaptureController::pointerCaptureElement): Deleted. (WebCore::PointerCaptureController::hasCancelledPointerEventForIdentifier): Deleted. (WebCore::PointerCaptureController::preventsCompatibilityMouseEventsForIdentifier): Deleted. * page/PointerCaptureController.h: 2021-02-03 Simon Fraser Optimize PointerCaptureController::elementWasRemoved() https://bugs.webkit.org/show_bug.cgi?id=221316 Reviewed by Ryosuke Niwa. Speedometer profiles show HashTable iteration code under PointerCaptureController::elementWasRemoved() because we always add a hash entry for the mouse pointer. Optimize away by setting a flag that's only true if any element is referenced by pointer capture. * page/PointerCaptureController.cpp: (WebCore::PointerCaptureController::pointerCaptureElement const): (WebCore::PointerCaptureController::setPointerCapture): (WebCore::PointerCaptureController::releasePointerCapture): (WebCore::PointerCaptureController::hasPointerCapture): (WebCore::PointerCaptureController::pointerLockWasApplied): (WebCore::PointerCaptureController::elementWasRemoved): (WebCore::PointerCaptureController::reset): (WebCore::PointerCaptureController::updateHaveAnyCapturingElement): (WebCore::PointerCaptureController::touchWithIdentifierWasRemoved): (WebCore::PointerCaptureController::hasCancelledPointerEventForIdentifier const): (WebCore::PointerCaptureController::preventsCompatibilityMouseEventsForIdentifier const): (WebCore::PointerCaptureController::pointerCaptureElement): Deleted. (WebCore::PointerCaptureController::hasCancelledPointerEventForIdentifier): Deleted. (WebCore::PointerCaptureController::preventsCompatibilityMouseEventsForIdentifier): Deleted. * page/PointerCaptureController.h: 2021-03-01 Ryosuke Niwa Merge r272299. Avoid a virtual function call in HTMLFormControlElement::isDisabledOrReadOnly() https://bugs.webkit.org/show_bug.cgi?id=221319 Reviewed by Wenson Hsieh. Avoid calling isDisabledFormControl() which is a virtual function on Element. HTMLFormControlElement is the only class in its hierarchy that implements this, so we can just copy its implementation. * html/HTMLFormControlElement.h: (WebCore::HTMLFormControlElement::isDisabledOrReadOnly const): 2021-02-02 Simon Fraser Avoid a virtual function call in HTMLFormControlElement::isDisabledOrReadOnly() https://bugs.webkit.org/show_bug.cgi?id=221319 Reviewed by Wenson Hsieh. Avoid calling isDisabledFormControl() which is a virtual function on Element. HTMLFormControlElement is the only class in its hierarchy that implements this, so we can just copy its implementation. * html/HTMLFormControlElement.h: (WebCore::HTMLFormControlElement::isDisabledOrReadOnly const): 2021-03-01 Ryosuke Niwa Merge r272298. Avoid a virtual function call in HTMLInputElement::value() https://bugs.webkit.org/show_bug.cgi?id=221318 Reviewed by Wenson Hsieh. Only file upload controls override getTypeSpecificValue(), so to avoid a virtual function call, check the type first via canHaveTypeSpecificValue(). * html/HTMLInputElement.cpp: (WebCore::HTMLInputElement::value const): * html/InputType.h: (WebCore::InputType::canHaveTypeSpecificValue const): 2021-02-02 Simon Fraser Avoid a virtual function call in HTMLInputElement::value() https://bugs.webkit.org/show_bug.cgi?id=221318 Reviewed by Wenson Hsieh. Only file upload controls override getTypeSpecificValue(), so to avoid a virtual function call, check the type first via canHaveTypeSpecificValue(). * html/HTMLInputElement.cpp: (WebCore::HTMLInputElement::value const): * html/InputType.h: (WebCore::InputType::canHaveTypeSpecificValue const): 2021-03-01 Ryosuke Niwa Merge r272180. Devirtualize InputType::supportsValidation() https://bugs.webkit.org/show_bug.cgi?id=221216 Reviewed by Yusuke Suzuki. InputType::supportsValidation() can just check the type. Use an OptionSet<> of exclusions for clarity. * html/ButtonInputType.cpp: (WebCore::ButtonInputType::supportsValidation const): Deleted. * html/ButtonInputType.h: * html/HiddenInputType.cpp: (WebCore::HiddenInputType::supportsValidation const): Deleted. * html/HiddenInputType.h: * html/ImageInputType.cpp: (WebCore::ImageInputType::supportsValidation const): Deleted. * html/ImageInputType.h: * html/InputType.cpp: (WebCore::InputType::supportsValidation const): Deleted. * html/InputType.h: (WebCore::InputType::supportsValidation const): * html/ResetInputType.cpp: (WebCore::ResetInputType::supportsValidation const): Deleted. * html/ResetInputType.h: 2021-02-01 Simon Fraser Devirtualize InputType::supportsValidation() https://bugs.webkit.org/show_bug.cgi?id=221216 Reviewed by Yusuke Suzuki. InputType::supportsValidation() can just check the type. Use an OptionSet<> of exclusions for clarity. * html/ButtonInputType.cpp: (WebCore::ButtonInputType::supportsValidation const): Deleted. * html/ButtonInputType.h: * html/HiddenInputType.cpp: (WebCore::HiddenInputType::supportsValidation const): Deleted. * html/HiddenInputType.h: * html/ImageInputType.cpp: (WebCore::ImageInputType::supportsValidation const): Deleted. * html/ImageInputType.h: * html/InputType.cpp: (WebCore::InputType::supportsValidation const): Deleted. * html/InputType.h: (WebCore::InputType::supportsValidation const): * html/ResetInputType.cpp: (WebCore::ResetInputType::supportsValidation const): Deleted. * html/ResetInputType.h: 2021-03-01 Ryosuke Niwa Merge r272097. Devirtualize some functions on InputType https://bugs.webkit.org/show_bug.cgi?id=221121 Reviewed by Yusuke Suzuki. Virtual functions on InputType show up in Speedometer profiles. We can make many of these virtual functions non-virtual by just switching on the input type. * dom/Element.cpp: * html/BaseCheckableInputType.cpp: (WebCore::BaseCheckableInputType::isCheckable): Deleted. * html/BaseCheckableInputType.h: * html/BaseTextInputType.cpp: (WebCore::BaseTextInputType::isTextType const): Deleted. * html/BaseTextInputType.h: * html/ButtonInputType.cpp: (WebCore::ButtonInputType::isTextButton const): Deleted. * html/ButtonInputType.h: * html/CheckboxInputType.cpp: (WebCore::CheckboxInputType::isCheckbox const): Deleted. * html/CheckboxInputType.h: * html/ColorInputType.cpp: (WebCore::ColorInputType::isColorControl const): Deleted. * html/ColorInputType.h: * html/DateInputType.cpp: (WebCore::DateInputType::isDateField const): Deleted. * html/DateInputType.h: * html/DateTimeLocalInputType.cpp: (WebCore::DateTimeLocalInputType::isDateTimeLocalField const): Deleted. * html/DateTimeLocalInputType.h: * html/EmailInputType.cpp: (WebCore::EmailInputType::isEmailField const): Deleted. * html/EmailInputType.h: * html/FileInputType.cpp: (WebCore::FileInputType::isFileUpload const): Deleted. * html/FileInputType.h: * html/FormAssociatedElement.h: * html/HTMLFormControlElement.h: * html/HiddenInputType.cpp: (WebCore::HiddenInputType::isHiddenType const): Deleted. * html/HiddenInputType.h: * html/ImageInputType.cpp: (WebCore::ImageInputType::isImageButton const): Deleted. (WebCore::ImageInputType::isEnumeratable): Deleted. * html/ImageInputType.h: * html/InputType.cpp: (WebCore::InputType::isTextType const): (WebCore::InputType::isTextField const): (WebCore::InputType::isTextButton const): (WebCore::InputType::isInteractiveContent const): (WebCore::InputType::supportLabels const): (WebCore::InputType::isEnumeratable): (WebCore::InputType::isCheckable): (WebCore::InputType::isRangeControl const): Deleted. (WebCore::InputType::isRadioButton const): Deleted. (WebCore::InputType::isSearchField const): Deleted. (WebCore::InputType::isHiddenType const): Deleted. (WebCore::InputType::isPasswordField const): Deleted. (WebCore::InputType::isCheckbox const): Deleted. (WebCore::InputType::isEmailField const): Deleted. (WebCore::InputType::isFileUpload const): Deleted. (WebCore::InputType::isImageButton const): Deleted. (WebCore::InputType::isNumberField const): Deleted. (WebCore::InputType::isSubmitButton const): Deleted. (WebCore::InputType::isTelephoneField const): Deleted. (WebCore::InputType::isURLField const): Deleted. (WebCore::InputType::isDateField const): Deleted. (WebCore::InputType::isDateTimeField const): Deleted. (WebCore::InputType::isDateTimeLocalField const): Deleted. (WebCore::InputType::isMonthField const): Deleted. (WebCore::InputType::isTimeField const): Deleted. (WebCore::InputType::isWeekField const): Deleted. (WebCore::InputType::isColorControl const): Deleted. * html/InputType.h: (WebCore::InputType::isCheckbox const): (WebCore::InputType::isColorControl const): (WebCore::InputType::isDateField const): (WebCore::InputType::isDateTimeField const): (WebCore::InputType::isDateTimeLocalField const): (WebCore::InputType::isEmailField const): (WebCore::InputType::isFileUpload const): (WebCore::InputType::isHiddenType const): (WebCore::InputType::isImageButton const): (WebCore::InputType::isMonthField const): (WebCore::InputType::isNumberField const): (WebCore::InputType::isPasswordField const): (WebCore::InputType::isRadioButton const): (WebCore::InputType::isRangeControl const): (WebCore::InputType::isSearchField const): (WebCore::InputType::isSubmitButton const): (WebCore::InputType::isTelephoneField const): (WebCore::InputType::isTimeField const): (WebCore::InputType::isURLField const): (WebCore::InputType::isWeekField const): * html/MonthInputType.cpp: (WebCore::MonthInputType::isMonthField const): Deleted. * html/MonthInputType.h: * html/NumberInputType.cpp: (WebCore::NumberInputType::isNumberField const): Deleted. * html/NumberInputType.h: * html/PasswordInputType.cpp: (WebCore::PasswordInputType::isPasswordField const): Deleted. * html/PasswordInputType.h: * html/RadioInputType.cpp: (WebCore::RadioInputType::isRadioButton const): Deleted. * html/RadioInputType.h: * html/RangeInputType.cpp: (WebCore::RangeInputType::isRangeControl const): Deleted. * html/RangeInputType.h: * html/ResetInputType.cpp: (WebCore::ResetInputType::isTextButton const): Deleted. * html/ResetInputType.h: * html/SearchInputType.cpp: (WebCore::SearchInputType::isSearchField const): Deleted. * html/SearchInputType.h: * html/SubmitInputType.cpp: (WebCore::SubmitInputType::isSubmitButton const): Deleted. (WebCore::SubmitInputType::isTextButton const): Deleted. * html/SubmitInputType.h: * html/TelephoneInputType.cpp: (WebCore::TelephoneInputType::isTelephoneField const): Deleted. * html/TelephoneInputType.h: * html/TextFieldInputType.cpp: (WebCore::TextFieldInputType::isTextField const): Deleted. * html/TextFieldInputType.h: * html/TimeInputType.cpp: (WebCore::TimeInputType::isTimeField const): Deleted. * html/TimeInputType.h: * html/URLInputType.cpp: (WebCore::URLInputType::isURLField const): Deleted. * html/URLInputType.h: * html/WeekInputType.cpp: (WebCore::WeekInputType::isWeekField const): Deleted. * html/WeekInputType.h: 2021-01-29 Simon Fraser Devirtualize some functions on InputType https://bugs.webkit.org/show_bug.cgi?id=221121 Reviewed by Yusuke Suzuki. Virtual functions on InputType show up in Speedometer profiles. We can make many of these virtual functions non-virtual by just switching on the input type. * dom/Element.cpp: * html/BaseCheckableInputType.cpp: (WebCore::BaseCheckableInputType::isCheckable): Deleted. * html/BaseCheckableInputType.h: * html/BaseTextInputType.cpp: (WebCore::BaseTextInputType::isTextType const): Deleted. * html/BaseTextInputType.h: * html/ButtonInputType.cpp: (WebCore::ButtonInputType::isTextButton const): Deleted. * html/ButtonInputType.h: * html/CheckboxInputType.cpp: (WebCore::CheckboxInputType::isCheckbox const): Deleted. * html/CheckboxInputType.h: * html/ColorInputType.cpp: (WebCore::ColorInputType::isColorControl const): Deleted. * html/ColorInputType.h: * html/DateInputType.cpp: (WebCore::DateInputType::isDateField const): Deleted. * html/DateInputType.h: * html/DateTimeLocalInputType.cpp: (WebCore::DateTimeLocalInputType::isDateTimeLocalField const): Deleted. * html/DateTimeLocalInputType.h: * html/EmailInputType.cpp: (WebCore::EmailInputType::isEmailField const): Deleted. * html/EmailInputType.h: * html/FileInputType.cpp: (WebCore::FileInputType::isFileUpload const): Deleted. * html/FileInputType.h: * html/FormAssociatedElement.h: * html/HTMLFormControlElement.h: * html/HiddenInputType.cpp: (WebCore::HiddenInputType::isHiddenType const): Deleted. * html/HiddenInputType.h: * html/ImageInputType.cpp: (WebCore::ImageInputType::isImageButton const): Deleted. (WebCore::ImageInputType::isEnumeratable): Deleted. * html/ImageInputType.h: * html/InputType.cpp: (WebCore::InputType::isTextType const): (WebCore::InputType::isTextField const): (WebCore::InputType::isTextButton const): (WebCore::InputType::isInteractiveContent const): (WebCore::InputType::supportLabels const): (WebCore::InputType::isEnumeratable): (WebCore::InputType::isCheckable): (WebCore::InputType::isRangeControl const): Deleted. (WebCore::InputType::isRadioButton const): Deleted. (WebCore::InputType::isSearchField const): Deleted. (WebCore::InputType::isHiddenType const): Deleted. (WebCore::InputType::isPasswordField const): Deleted. (WebCore::InputType::isCheckbox const): Deleted. (WebCore::InputType::isEmailField const): Deleted. (WebCore::InputType::isFileUpload const): Deleted. (WebCore::InputType::isImageButton const): Deleted. (WebCore::InputType::isNumberField const): Deleted. (WebCore::InputType::isSubmitButton const): Deleted. (WebCore::InputType::isTelephoneField const): Deleted. (WebCore::InputType::isURLField const): Deleted. (WebCore::InputType::isDateField const): Deleted. (WebCore::InputType::isDateTimeField const): Deleted. (WebCore::InputType::isDateTimeLocalField const): Deleted. (WebCore::InputType::isMonthField const): Deleted. (WebCore::InputType::isTimeField const): Deleted. (WebCore::InputType::isWeekField const): Deleted. (WebCore::InputType::isColorControl const): Deleted. * html/InputType.h: (WebCore::InputType::isCheckbox const): (WebCore::InputType::isColorControl const): (WebCore::InputType::isDateField const): (WebCore::InputType::isDateTimeField const): (WebCore::InputType::isDateTimeLocalField const): (WebCore::InputType::isEmailField const): (WebCore::InputType::isFileUpload const): (WebCore::InputType::isHiddenType const): (WebCore::InputType::isImageButton const): (WebCore::InputType::isMonthField const): (WebCore::InputType::isNumberField const): (WebCore::InputType::isPasswordField const): (WebCore::InputType::isRadioButton const): (WebCore::InputType::isRangeControl const): (WebCore::InputType::isSearchField const): (WebCore::InputType::isSubmitButton const): (WebCore::InputType::isTelephoneField const): (WebCore::InputType::isTimeField const): (WebCore::InputType::isURLField const): (WebCore::InputType::isWeekField const): * html/MonthInputType.cpp: (WebCore::MonthInputType::isMonthField const): Deleted. * html/MonthInputType.h: * html/NumberInputType.cpp: (WebCore::NumberInputType::isNumberField const): Deleted. * html/NumberInputType.h: * html/PasswordInputType.cpp: (WebCore::PasswordInputType::isPasswordField const): Deleted. * html/PasswordInputType.h: * html/RadioInputType.cpp: (WebCore::RadioInputType::isRadioButton const): Deleted. * html/RadioInputType.h: * html/RangeInputType.cpp: (WebCore::RangeInputType::isRangeControl const): Deleted. * html/RangeInputType.h: * html/ResetInputType.cpp: (WebCore::ResetInputType::isTextButton const): Deleted. * html/ResetInputType.h: * html/SearchInputType.cpp: (WebCore::SearchInputType::isSearchField const): Deleted. * html/SearchInputType.h: * html/SubmitInputType.cpp: (WebCore::SubmitInputType::isSubmitButton const): Deleted. (WebCore::SubmitInputType::isTextButton const): Deleted. * html/SubmitInputType.h: * html/TelephoneInputType.cpp: (WebCore::TelephoneInputType::isTelephoneField const): Deleted. * html/TelephoneInputType.h: * html/TextFieldInputType.cpp: (WebCore::TextFieldInputType::isTextField const): Deleted. * html/TextFieldInputType.h: * html/TimeInputType.cpp: (WebCore::TimeInputType::isTimeField const): Deleted. * html/TimeInputType.h: * html/URLInputType.cpp: (WebCore::URLInputType::isURLField const): Deleted. * html/URLInputType.h: * html/WeekInputType.cpp: (WebCore::WeekInputType::isWeekField const): Deleted. * html/WeekInputType.h: 2021-03-01 Alan Coon Cherry-pick r273564. rdar://problem/74886917 [Cocoa] Register VP9 decoders when PlatformMediaSessionManager is created https://bugs.webkit.org/show_bug.cgi?id=222473 Reviewed by Eric Carlson. Source/WebCore: Currently, VP9 decoders are registered when a Web page is created in the WebContent process. Instead, VP9 decoders can be registered when PlatformMediaSessionManager is created, which should be a slight performance improvement, since calls into media frameworks will then not be made unconditionally when creating a Web page, but delayed until required. No new tests, covered by existing tests. * platform/audio/PlatformMediaSessionManager.cpp: (WebCore::PlatformMediaSessionManager::setShouldEnableVP9Decoder): (WebCore::PlatformMediaSessionManager::shouldEnableVP9Decoder): (WebCore::PlatformMediaSessionManager::setShouldEnableVP8Decoder): (WebCore::PlatformMediaSessionManager::shouldEnableVP8Decoder): (WebCore::PlatformMediaSessionManager::setShouldEnableVP9SWDecoder): (WebCore::PlatformMediaSessionManager::shouldEnableVP9SWDecoder): * platform/audio/PlatformMediaSessionManager.h: * platform/audio/cocoa/MediaSessionManagerCocoa.mm: (WebCore::MediaSessionManagerCocoa::MediaSessionManagerCocoa): Source/WebKit: Currently, VP9 decoders are registered when a Web page is created in the WebContent process. Instead, VP9 decoders can be registered when PlatformMediaSessionManager is created, which should be a slight performance improvement, since calls into media frameworks will then not be made unconditionally when creating a Web page, but delayed until required. * WebProcess/WebPage/WebPage.cpp: (WebKit::m_lastNavigationWasAppBound): * WebProcess/WebProcess.cpp: (WebKit::WebProcess::enableVP9Decoder): Deleted. (WebKit::WebProcess::enableVP8SWDecoder): Deleted. (WebKit::WebProcess::enableVP9SWDecoder): Deleted. * WebProcess/WebProcess.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273564 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-26 Per Arne [Cocoa] Register VP9 decoders when PlatformMediaSessionManager is created https://bugs.webkit.org/show_bug.cgi?id=222473 Reviewed by Eric Carlson. Currently, VP9 decoders are registered when a Web page is created in the WebContent process. Instead, VP9 decoders can be registered when PlatformMediaSessionManager is created, which should be a slight performance improvement, since calls into media frameworks will then not be made unconditionally when creating a Web page, but delayed until required. No new tests, covered by existing tests. * platform/audio/PlatformMediaSessionManager.cpp: (WebCore::PlatformMediaSessionManager::setShouldEnableVP9Decoder): (WebCore::PlatformMediaSessionManager::shouldEnableVP9Decoder): (WebCore::PlatformMediaSessionManager::setShouldEnableVP8Decoder): (WebCore::PlatformMediaSessionManager::shouldEnableVP8Decoder): (WebCore::PlatformMediaSessionManager::setShouldEnableVP9SWDecoder): (WebCore::PlatformMediaSessionManager::shouldEnableVP9SWDecoder): * platform/audio/PlatformMediaSessionManager.h: * platform/audio/cocoa/MediaSessionManagerCocoa.mm: (WebCore::MediaSessionManagerCocoa::MediaSessionManagerCocoa): 2021-03-01 Alan Coon Cherry-pick r273656. rdar://problem/74883377 REGRESSION(r272004): transform transition with delay doesn't behave correctly https://bugs.webkit.org/show_bug.cgi?id=222545 Reviewed by Dean Jackson. Source/WebCore: To support accelerated animations of individual transform properties, we introduced the notion of non-interpolating animations to apply the underlying value for a given property before applying the actual animations for this property with additivity set to true. These non-interpolating animations were meant to last between the time at which animations were committed and the effective start of the first animation for that property, accounting for any delay. However, we neglected to handle the case where that first animation had a fill mode that would make it fill backwards, such as CSS Transitions. In that situation, the animation would have its first keyframe applied on top of the underlying value, effectively applying the underlying value twice with additivity. We now only add these non-interpolating animations if the first animation has a delay and does not fill backwards. Test: webanimations/transform-transition-with-delay-on-forced-layer-with-transform.html * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::updateAnimations): LayoutTests: Add a new test where an element with a non-identity transform starts a transform transition with a long delay. Prior to this patch, this test failed because, while in the delay phase, the transition would mean the underlying transform was applied twice: once by the non-interpolating animation generated for the underlying "transform" value, and once by the first keyframe of the transition since it fills backwards. * webanimations/transform-transition-with-delay-on-forced-layer-with-transform-expected.html: Added. * webanimations/transform-transition-with-delay-on-forced-layer-with-transform.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273656 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-01 Antoine Quint REGRESSION(r272004): transform transition with delay doesn't behave correctly https://bugs.webkit.org/show_bug.cgi?id=222545 Reviewed by Dean Jackson. To support accelerated animations of individual transform properties, we introduced the notion of non-interpolating animations to apply the underlying value for a given property before applying the actual animations for this property with additivity set to true. These non-interpolating animations were meant to last between the time at which animations were committed and the effective start of the first animation for that property, accounting for any delay. However, we neglected to handle the case where that first animation had a fill mode that would make it fill backwards, such as CSS Transitions. In that situation, the animation would have its first keyframe applied on top of the underlying value, effectively applying the underlying value twice with additivity. We now only add these non-interpolating animations if the first animation has a delay and does not fill backwards. Test: webanimations/transform-transition-with-delay-on-forced-layer-with-transform.html * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::updateAnimations): 2021-03-01 Kocsen Chung Cherry-pick r273583. rdar://problem/74881429 Add AXTextMarkerRangeForNSRange attribute so that Mac clients can access this functionality. https://bugs.webkit.org/show_bug.cgi?id=222477 Source/WebCore: Reviewed by Chris Fleizach. This is a follow up to: https://bugs.webkit.org/show_bug.cgi?id=222154. As Chris Fleizach pointed out in the above review, it is necessary to add a handler in accessibilityAttributeValue:forParameter: for a new AX attribute in order for clients to access this functionality. * accessibility/mac/WebAccessibilityObjectWrapperMac.mm: (-[WebAccessibilityObjectWrapper accessibilityAttributeValue:forParameter:]): (-[WebAccessibilityObjectWrapper textMarkerRangeForNSRange:]): Deleted. Tools: Reviewed by Chris Fleizach. * WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm: (WTR::AccessibilityUIElement::textMarkerRangeForRange): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273583 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-26 Andres Gonzalez Add AXTextMarkerRangeForNSRange attribute so that Mac clients can access this functionality. https://bugs.webkit.org/show_bug.cgi?id=222477 Reviewed by Chris Fleizach. This is a follow up to: https://bugs.webkit.org/show_bug.cgi?id=222154. As Chris Fleizach pointed out in the above review, it is necessary to add a handler in accessibilityAttributeValue:forParameter: for a new AX attribute in order for clients to access this functionality. * accessibility/mac/WebAccessibilityObjectWrapperMac.mm: (-[WebAccessibilityObjectWrapper accessibilityAttributeValue:forParameter:]): (-[WebAccessibilityObjectWrapper textMarkerRangeForNSRange:]): Deleted. 2021-03-01 Kocsen Chung Cherry-pick r273227. rdar://problem/74880937 Add [WebAccessibilityObjectWrapper textMarkerRangeForNSRange] to allow clients to efficiently get a TextMarkerRange from an NSRange. https://bugs.webkit.org/show_bug.cgi?id=222154 Reviewed by Chris Fleizach and Darin Adler. Source/WebCore: Test: accessibility/mac/textmarker-range-for-range.html Clients like VoiceOver often need the ability to convert a text range into an accessibility TextMarkerRange. This patch adds [WebAccessibilityObjectWrapper textMarkerRangeForNSRange] to allow clients to efficiently perform this conversion. This is the Mac implementation, iOS implementation is pending. * accessibility/AccessibilityObject.h: (WebCore::AccessibilityObject::allowsTextRanges const): * accessibility/AccessibilityObjectInterface.h: * accessibility/isolatedtree/AXIsolatedObject.h: * accessibility/isolatedtree/mac/AXIsolatedObjectMac.mm: (WebCore::AXIsolatedObject::textMarkerRangeForNSRange const): * accessibility/mac/AccessibilityObjectMac.mm: (WebCore::AccessibilityObject::textMarkerRangeForNSRange const): * accessibility/mac/WebAccessibilityObjectWrapperMac.mm: (-[WebAccessibilityObjectWrapper textMarkerRangeForNSRange:]): (-[WebAccessibilityObjectWrapper accessibilityAttributeValue:forParameter:]): * editing/Editing.cpp: (WebCore::visiblePositionForIndexUsingCharacterIterator): Only advance the CharacterIterator if not atEnd yet. Tools: * WebKitTestRunner/InjectedBundle/AccessibilityUIElement.cpp: (WTR::AccessibilityUIElement::textMarkerRangeForRange): * WebKitTestRunner/InjectedBundle/AccessibilityUIElement.h: * WebKitTestRunner/InjectedBundle/Bindings/AccessibilityUIElement.idl: * WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm: (WTR::AccessibilityUIElement::textMarkerRangeForRange): LayoutTests: * accessibility/mac/textmarker-range-for-range-expected.txt: Added. * accessibility/mac/textmarker-range-for-range.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273227 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-21 Andres Gonzalez Add [WebAccessibilityObjectWrapper textMarkerRangeForNSRange] to allow clients to efficiently get a TextMarkerRange from an NSRange. https://bugs.webkit.org/show_bug.cgi?id=222154 Reviewed by Chris Fleizach and Darin Adler. Test: accessibility/mac/textmarker-range-for-range.html Clients like VoiceOver often need the ability to convert a text range into an accessibility TextMarkerRange. This patch adds [WebAccessibilityObjectWrapper textMarkerRangeForNSRange] to allow clients to efficiently perform this conversion. This is the Mac implementation, iOS implementation is pending. * accessibility/AccessibilityObject.h: (WebCore::AccessibilityObject::allowsTextRanges const): * accessibility/AccessibilityObjectInterface.h: * accessibility/isolatedtree/AXIsolatedObject.h: * accessibility/isolatedtree/mac/AXIsolatedObjectMac.mm: (WebCore::AXIsolatedObject::textMarkerRangeForNSRange const): * accessibility/mac/AccessibilityObjectMac.mm: (WebCore::AccessibilityObject::textMarkerRangeForNSRange const): * accessibility/mac/WebAccessibilityObjectWrapperMac.mm: (-[WebAccessibilityObjectWrapper textMarkerRangeForNSRange:]): (-[WebAccessibilityObjectWrapper accessibilityAttributeValue:forParameter:]): * editing/Editing.cpp: (WebCore::visiblePositionForIndexUsingCharacterIterator): Only advance the CharacterIterator if not atEnd yet. 2021-03-30 Ruben Turcios Cherry-pick r275214. rdar://problem/76032705 [LFC][Integration] Elements that overflow inline-blocks are not hit tested correctly https://bugs.webkit.org/show_bug.cgi?id=223932 rdar://75888718 Reviewed by Zalan Bujtas. Source/WebCore: If an inline block has overflowing children (for example due to negative margin) we may fail to hit test them. Test: fast/inline-block/hit-test-negative-margin-child.html * layout/integration/LayoutIntegrationLineLayout.cpp: (WebCore::LayoutIntegration::LineLayout::hitTest): Always descend into inline blocks even if their run didn't hit. LayoutTests: * fast/inline-block/hit-test-negative-margin-child-expected.txt: Added. * fast/inline-block/hit-test-negative-margin-child.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@275214 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-30 Antti Koivisto [LFC][Integration] Elements that overflow inline-blocks are not hit tested correctly https://bugs.webkit.org/show_bug.cgi?id=223932 rdar://75888718 Reviewed by Zalan Bujtas. If an inline block has overflowing children (for example due to negative margin) we may fail to hit test them. Test: fast/inline-block/hit-test-negative-margin-child.html * layout/integration/LayoutIntegrationLineLayout.cpp: (WebCore::LayoutIntegration::LineLayout::hitTest): Always descend into inline blocks even if their run didn't hit. 2021-03-22 Russell Epstein Cherry-pick r274846. rdar://problem/75706510 Use JSValueInWrappedObject to keep the JSObject alive for QuickTimePluginReplacement https://bugs.webkit.org/show_bug.cgi?id=223561 Reviewed by Geoffrey Garen. This patch replaces QuickTimePluginReplacement's m_scriptObject member variable by JSValueInWrappedObject in HTMLPlugInElement and hooks it up with the slot visitor. Also use WeakPtr instead of a raw pointer for the back reference to the plugin element in QuickTimePluginReplacement and YouTubePluginReplacement. * Modules/plugins/PluginReplacement.h: (WebCore::PluginReplacement::InstallResult): Added; a boolean indicating the installation had succeeded and the script object for QuickTimePluginReplacement. (WebCore::PluginReplacement::scriptObject): Deleted. * Modules/plugins/QuickTimePluginReplacement.h: * Modules/plugins/QuickTimePluginReplacement.mm: (WebCore::QuickTimePluginReplacement::QuickTimePluginReplacement): Deployed WeakPtr. (WebCore::QuickTimePluginReplacement::~QuickTimePluginReplacement): Removed the superflous de-initialization of the member variables. (WebCore::QuickTimePluginReplacement::installReplacement): Now returns JSValue instead of storing it in m_scriptObject. * Modules/plugins/YouTubePluginReplacement.cpp: (WebCore::YouTubePluginReplacement::YouTubePluginReplacement): Deployed WeakPtr. (WebCore::YouTubePluginReplacement::installReplacement): * Modules/plugins/YouTubePluginReplacement.h: * bindings/scripts/CodeGeneratorJS.pm: (InstanceNeedsVisitChildren): Generate visitChildren when an IDL has Plugin attribute. (GenerateImplementation): Visit the newly added JSValueInWrappedObject. * html/HTMLPlugInElement.cpp: (WebCore::HTMLPlugInElement::didAddUserAgentShadowRoot): Store the script object returned by QuickTimePluginReplacement::installReplacement in the newly added member variable. (WebCore::HTMLPlugInElement::scriptObjectForPluginReplacement): Updated. * html/HTMLPlugInElement.h: (WebCore::HTMLPlugInElement::pluginReplacementScriptObject): Added. Used by visitChildren. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274846 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-22 Ryosuke Niwa Use JSValueInWrappedObject to keep the JSObject alive for QuickTimePluginReplacement https://bugs.webkit.org/show_bug.cgi?id=223561 Reviewed by Geoffrey Garen. This patch replaces QuickTimePluginReplacement's m_scriptObject member variable by JSValueInWrappedObject in HTMLPlugInElement and hooks it up with the slot visitor. Also use WeakPtr instead of a raw pointer for the back reference to the plugin element in QuickTimePluginReplacement and YouTubePluginReplacement. * Modules/plugins/PluginReplacement.h: (WebCore::PluginReplacement::InstallResult): Added; a boolean indicating the installation had succeeded and the script object for QuickTimePluginReplacement. (WebCore::PluginReplacement::scriptObject): Deleted. * Modules/plugins/QuickTimePluginReplacement.h: * Modules/plugins/QuickTimePluginReplacement.mm: (WebCore::QuickTimePluginReplacement::QuickTimePluginReplacement): Deployed WeakPtr. (WebCore::QuickTimePluginReplacement::~QuickTimePluginReplacement): Removed the superflous de-initialization of the member variables. (WebCore::QuickTimePluginReplacement::installReplacement): Now returns JSValue instead of storing it in m_scriptObject. * Modules/plugins/YouTubePluginReplacement.cpp: (WebCore::YouTubePluginReplacement::YouTubePluginReplacement): Deployed WeakPtr. (WebCore::YouTubePluginReplacement::installReplacement): * Modules/plugins/YouTubePluginReplacement.h: * bindings/scripts/CodeGeneratorJS.pm: (InstanceNeedsVisitChildren): Generate visitChildren when an IDL has Plugin attribute. (GenerateImplementation): Visit the newly added JSValueInWrappedObject. * html/HTMLPlugInElement.cpp: (WebCore::HTMLPlugInElement::didAddUserAgentShadowRoot): Store the script object returned by QuickTimePluginReplacement::installReplacement in the newly added member variable. (WebCore::HTMLPlugInElement::scriptObjectForPluginReplacement): Updated. * html/HTMLPlugInElement.h: (WebCore::HTMLPlugInElement::pluginReplacementScriptObject): Added. Used by visitChildren. 2021-03-22 Russell Epstein Cherry-pick r274796. rdar://problem/75712824 [iOS] Composition text is not initially highlighted when typing in text fields using Pinyin keyboard https://bugs.webkit.org/show_bug.cgi?id=223563 Reviewed by Antti Koivisto. Source/WebCore: When enabling line layout integration, composition highlights on iOS don't appear when typing an input string using the Pinyin keyboard for the first time. This is because the text renderer for the inserted composition text does not contain inline text boxes when painting the composition text on iOS, so the marked text painting codepath is never triggered. On macOS, this isn't an issue because the process of setting the composition changes the selection, which then changes the highlight state of the `RenderText`, which subsequently calls into `ensureLineBoxes()`. However, since selections are drawn using UIKit in the UI process on iOS, we don't end up ensuring that inline text boxes are constructed for the inserted text. To address this, we follow macOS behavior by ensuring line box construction on the rendered composition text when setting the composition. Test: editing/input/composition-underline-in-search-field.html * editing/Editor.cpp: (WebCore::Editor::setComposition): LayoutTests: Add a test to verify that marked text underlines show up in search fields. * editing/input/composition-underline-in-search-field-expected-mismatch.html: Added. * editing/input/composition-underline-in-search-field.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274796 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-22 Wenson Hsieh [iOS] Composition text is not initially highlighted when typing in text fields using Pinyin keyboard https://bugs.webkit.org/show_bug.cgi?id=223563 Reviewed by Antti Koivisto. When enabling line layout integration, composition highlights on iOS don't appear when typing an input string using the Pinyin keyboard for the first time. This is because the text renderer for the inserted composition text does not contain inline text boxes when painting the composition text on iOS, so the marked text painting codepath is never triggered. On macOS, this isn't an issue because the process of setting the composition changes the selection, which then changes the highlight state of the `RenderText`, which subsequently calls into `ensureLineBoxes()`. However, since selections are drawn using UIKit in the UI process on iOS, we don't end up ensuring that inline text boxes are constructed for the inserted text. To address this, we follow macOS behavior by ensuring line box construction on the rendered composition text when setting the composition. Test: editing/input/composition-underline-in-search-field.html * editing/Editor.cpp: (WebCore::Editor::setComposition): 2021-03-17 Ruben Turcios Cherry-pick r274573. rdar://problem/75538213 Degraded ScriptProcessorNode performance/quality for (14.0.3+ and iOS 14.4.1+) https://bugs.webkit.org/show_bug.cgi?id=223380 Reviewed by Geoffrey Garen. By extending the scope of the lock in ScriptProcessorNode::process(), r273542 essentially disabled double-buffering and thus negatively impacted rendering quality. To address the issue, we now have 2 locks, one per rendering buffer (since we're using double buffering) and only grab the lock we require when interacting with the buffers for this index. This maintains thread-safety while re-enabling double buffering. * Modules/webaudio/ScriptProcessorNode.cpp: (WebCore::ScriptProcessorNode::createInputBufferForJS const): Avoid duplicate call to topologyMatches() since copyTo() already calls it internally and returns false when !topologyMatches(). (WebCore::ScriptProcessorNode::process): * Modules/webaudio/ScriptProcessorNode.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@274573 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-17 Chris Dumez Degraded ScriptProcessorNode performance/quality for (14.0.3+ and iOS 14.4.1+) https://bugs.webkit.org/show_bug.cgi?id=223380 Reviewed by Geoffrey Garen. By extending the scope of the lock in ScriptProcessorNode::process(), r273542 essentially disabled double-buffering and thus negatively impacted rendering quality. To address the issue, we now have 2 locks, one per rendering buffer (since we're using double buffering) and only grab the lock we require when interacting with the buffers for this index. This maintains thread-safety while re-enabling double buffering. * Modules/webaudio/ScriptProcessorNode.cpp: (WebCore::ScriptProcessorNode::createInputBufferForJS const): Avoid duplicate call to topologyMatches() since copyTo() already calls it internally and returns false when !topologyMatches(). (WebCore::ScriptProcessorNode::process): * Modules/webaudio/ScriptProcessorNode.h: 2021-03-08 Russell Epstein Cherry-pick r273894. rdar://problem/75178487 AVAudioSessionCaptureDeviceManager::retrieveAudioSessionCaptureDevices is unnecessarily creating a NSArray twice https://bugs.webkit.org/show_bug.cgi?id=222732 Reviewed by Eric Carlson. Before the patch, [m_audioSession availableInputs] was called twice. This creates two NSArray which is not create from a memory standpoint. There is also the risk that the two NSArrays have two different size, in which case Vector::uncheckedAppend would fail. Cannot be easily tested, no observable change expected. * platform/mediastream/ios/AVAudioSessionCaptureDeviceManager.mm: (WebCore::AVAudioSessionCaptureDeviceManager::retrieveAudioSessionCaptureDevices const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273894 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-04 Youenn Fablet AVAudioSessionCaptureDeviceManager::retrieveAudioSessionCaptureDevices is unnecessarily creating a NSArray twice https://bugs.webkit.org/show_bug.cgi?id=222732 Reviewed by Eric Carlson. Before the patch, [m_audioSession availableInputs] was called twice. This creates two NSArray which is not create from a memory standpoint. There is also the risk that the two NSArrays have two different size, in which case Vector::uncheckedAppend would fail. Cannot be easily tested, no observable change expected. * platform/mediastream/ios/AVAudioSessionCaptureDeviceManager.mm: (WebCore::AVAudioSessionCaptureDeviceManager::retrieveAudioSessionCaptureDevices const): 2021-03-04 Alan Coon Cherry-pick r273901. rdar://problem/75058982 window proxy of detached iframe doesn't respect updates to global values https://bugs.webkit.org/show_bug.cgi?id=206445 Reviewed by Chris Dumez. Source/WebCore: According to the html spec the frame should only be needing for COOP access violation reporting, which we don't support. This patch removes our old behavior of blocking stores to windows that have been detached. I also removed some stale caching code from getOwnPropertySlotByIndex since it's only accessed once now. * bindings/js/JSDOMWindowCustom.cpp: (WebCore::JSDOMWindow::getOwnPropertySlotByIndex): (WebCore::JSDOMWindow::doPutPropertySecurityCheck): (WebCore::JSDOMWindow::put): (WebCore::JSDOMWindow::putByIndex): LayoutTests: * fast/frames/iframe-detached-window-still-writable-eval-expected.txt: Added. * fast/frames/iframe-detached-window-still-writable-eval.html: Added. * fast/frames/iframe-detached-window-still-writable-expected.txt: Added. * fast/frames/iframe-detached-window-still-writable.html: Added. * http/tests/dom/cross-origin-detached-window-properties-expected.txt: * http/tests/dom/cross-origin-detached-window-properties.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273901 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-04 Keith Miller window proxy of detached iframe doesn't respect updates to global values https://bugs.webkit.org/show_bug.cgi?id=206445 Reviewed by Chris Dumez. According to the html spec the frame should only be needing for COOP access violation reporting, which we don't support. This patch removes our old behavior of blocking stores to windows that have been detached. I also removed some stale caching code from getOwnPropertySlotByIndex since it's only accessed once now. * bindings/js/JSDOMWindowCustom.cpp: (WebCore::JSDOMWindow::getOwnPropertySlotByIndex): (WebCore::JSDOMWindow::doPutPropertySecurityCheck): (WebCore::JSDOMWindow::put): (WebCore::JSDOMWindow::putByIndex): 2021-03-04 Alan Coon Cherry-pick r273842. rdar://problem/75049263 Crash under SubresourceLoader::notifyDone() https://bugs.webkit.org/show_bug.cgi?id=222683 Reviewed by Geoffrey Garen. We were crashing doing a null-dereference of m_documentLoader under SubresourceLoader::notifyDone(). This adds null checks for m_documentLoader similarly to what is already done elsewhere in ResourceLoader. No new tests, I do not know how to reproduce this. * loader/SubresourceLoader.cpp: (WebCore::SubresourceLoader::notifyDone): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273842 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-03 Chris Dumez Crash under SubresourceLoader::notifyDone() https://bugs.webkit.org/show_bug.cgi?id=222683 Reviewed by Geoffrey Garen. We were crashing doing a null-dereference of m_documentLoader under SubresourceLoader::notifyDone(). This adds null checks for m_documentLoader similarly to what is already done elsewhere in ResourceLoader. No new tests, I do not know how to reproduce this. * loader/SubresourceLoader.cpp: (WebCore::SubresourceLoader::notifyDone): 2021-03-02 Russell Epstein Apply patch. rdar://problem/74944257 2021-03-02 Ryosuke Niwa Merge r272331. Optimize PointerCaptureController::elementWasRemoved() https://bugs.webkit.org/show_bug.cgi?id=221316 Reviewed by Ryosuke Niwa. Speedometer profiles show HashTable iteration code under PointerCaptureController::elementWasRemoved() because we always add a hash entry for the mouse pointer. Optimize away by setting a flag that's only true if any element is referenced by pointer capture. * page/PointerCaptureController.cpp: (WebCore::PointerCaptureController::pointerCaptureElement const): (WebCore::PointerCaptureController::setPointerCapture): (WebCore::PointerCaptureController::releasePointerCapture): (WebCore::PointerCaptureController::hasPointerCapture): (WebCore::PointerCaptureController::pointerLockWasApplied): (WebCore::PointerCaptureController::elementWasRemoved): (WebCore::PointerCaptureController::reset): (WebCore::PointerCaptureController::updateHaveAnyCapturingElement): (WebCore::PointerCaptureController::touchWithIdentifierWasRemoved): (WebCore::PointerCaptureController::hasCancelledPointerEventForIdentifier const): (WebCore::PointerCaptureController::preventsCompatibilityMouseEventsForIdentifier const): (WebCore::PointerCaptureController::pointerCaptureElement): Deleted. (WebCore::PointerCaptureController::hasCancelledPointerEventForIdentifier): Deleted. (WebCore::PointerCaptureController::preventsCompatibilityMouseEventsForIdentifier): Deleted. * page/PointerCaptureController.h: 2021-02-03 Simon Fraser Optimize PointerCaptureController::elementWasRemoved() https://bugs.webkit.org/show_bug.cgi?id=221316 Reviewed by Ryosuke Niwa. Speedometer profiles show HashTable iteration code under PointerCaptureController::elementWasRemoved() because we always add a hash entry for the mouse pointer. Optimize away by setting a flag that's only true if any element is referenced by pointer capture. * page/PointerCaptureController.cpp: (WebCore::PointerCaptureController::pointerCaptureElement const): (WebCore::PointerCaptureController::setPointerCapture): (WebCore::PointerCaptureController::releasePointerCapture): (WebCore::PointerCaptureController::hasPointerCapture): (WebCore::PointerCaptureController::pointerLockWasApplied): (WebCore::PointerCaptureController::elementWasRemoved): (WebCore::PointerCaptureController::reset): (WebCore::PointerCaptureController::updateHaveAnyCapturingElement): (WebCore::PointerCaptureController::touchWithIdentifierWasRemoved): (WebCore::PointerCaptureController::hasCancelledPointerEventForIdentifier const): (WebCore::PointerCaptureController::preventsCompatibilityMouseEventsForIdentifier const): (WebCore::PointerCaptureController::pointerCaptureElement): Deleted. (WebCore::PointerCaptureController::hasCancelledPointerEventForIdentifier): Deleted. (WebCore::PointerCaptureController::preventsCompatibilityMouseEventsForIdentifier): Deleted. * page/PointerCaptureController.h: 2021-03-01 Ryosuke Niwa Merge r272299. Avoid a virtual function call in HTMLFormControlElement::isDisabledOrReadOnly() https://bugs.webkit.org/show_bug.cgi?id=221319 Reviewed by Wenson Hsieh. Avoid calling isDisabledFormControl() which is a virtual function on Element. HTMLFormControlElement is the only class in its hierarchy that implements this, so we can just copy its implementation. * html/HTMLFormControlElement.h: (WebCore::HTMLFormControlElement::isDisabledOrReadOnly const): 2021-02-02 Simon Fraser Avoid a virtual function call in HTMLFormControlElement::isDisabledOrReadOnly() https://bugs.webkit.org/show_bug.cgi?id=221319 Reviewed by Wenson Hsieh. Avoid calling isDisabledFormControl() which is a virtual function on Element. HTMLFormControlElement is the only class in its hierarchy that implements this, so we can just copy its implementation. * html/HTMLFormControlElement.h: (WebCore::HTMLFormControlElement::isDisabledOrReadOnly const): 2021-03-01 Ryosuke Niwa Merge r272298. Avoid a virtual function call in HTMLInputElement::value() https://bugs.webkit.org/show_bug.cgi?id=221318 Reviewed by Wenson Hsieh. Only file upload controls override getTypeSpecificValue(), so to avoid a virtual function call, check the type first via canHaveTypeSpecificValue(). * html/HTMLInputElement.cpp: (WebCore::HTMLInputElement::value const): * html/InputType.h: (WebCore::InputType::canHaveTypeSpecificValue const): 2021-02-02 Simon Fraser Avoid a virtual function call in HTMLInputElement::value() https://bugs.webkit.org/show_bug.cgi?id=221318 Reviewed by Wenson Hsieh. Only file upload controls override getTypeSpecificValue(), so to avoid a virtual function call, check the type first via canHaveTypeSpecificValue(). * html/HTMLInputElement.cpp: (WebCore::HTMLInputElement::value const): * html/InputType.h: (WebCore::InputType::canHaveTypeSpecificValue const): 2021-03-01 Ryosuke Niwa Merge r272180. Devirtualize InputType::supportsValidation() https://bugs.webkit.org/show_bug.cgi?id=221216 Reviewed by Yusuke Suzuki. InputType::supportsValidation() can just check the type. Use an OptionSet<> of exclusions for clarity. * html/ButtonInputType.cpp: (WebCore::ButtonInputType::supportsValidation const): Deleted. * html/ButtonInputType.h: * html/HiddenInputType.cpp: (WebCore::HiddenInputType::supportsValidation const): Deleted. * html/HiddenInputType.h: * html/ImageInputType.cpp: (WebCore::ImageInputType::supportsValidation const): Deleted. * html/ImageInputType.h: * html/InputType.cpp: (WebCore::InputType::supportsValidation const): Deleted. * html/InputType.h: (WebCore::InputType::supportsValidation const): * html/ResetInputType.cpp: (WebCore::ResetInputType::supportsValidation const): Deleted. * html/ResetInputType.h: 2021-02-01 Simon Fraser Devirtualize InputType::supportsValidation() https://bugs.webkit.org/show_bug.cgi?id=221216 Reviewed by Yusuke Suzuki. InputType::supportsValidation() can just check the type. Use an OptionSet<> of exclusions for clarity. * html/ButtonInputType.cpp: (WebCore::ButtonInputType::supportsValidation const): Deleted. * html/ButtonInputType.h: * html/HiddenInputType.cpp: (WebCore::HiddenInputType::supportsValidation const): Deleted. * html/HiddenInputType.h: * html/ImageInputType.cpp: (WebCore::ImageInputType::supportsValidation const): Deleted. * html/ImageInputType.h: * html/InputType.cpp: (WebCore::InputType::supportsValidation const): Deleted. * html/InputType.h: (WebCore::InputType::supportsValidation const): * html/ResetInputType.cpp: (WebCore::ResetInputType::supportsValidation const): Deleted. * html/ResetInputType.h: 2021-03-01 Ryosuke Niwa Merge r272097. Devirtualize some functions on InputType https://bugs.webkit.org/show_bug.cgi?id=221121 Reviewed by Yusuke Suzuki. Virtual functions on InputType show up in Speedometer profiles. We can make many of these virtual functions non-virtual by just switching on the input type. * dom/Element.cpp: * html/BaseCheckableInputType.cpp: (WebCore::BaseCheckableInputType::isCheckable): Deleted. * html/BaseCheckableInputType.h: * html/BaseTextInputType.cpp: (WebCore::BaseTextInputType::isTextType const): Deleted. * html/BaseTextInputType.h: * html/ButtonInputType.cpp: (WebCore::ButtonInputType::isTextButton const): Deleted. * html/ButtonInputType.h: * html/CheckboxInputType.cpp: (WebCore::CheckboxInputType::isCheckbox const): Deleted. * html/CheckboxInputType.h: * html/ColorInputType.cpp: (WebCore::ColorInputType::isColorControl const): Deleted. * html/ColorInputType.h: * html/DateInputType.cpp: (WebCore::DateInputType::isDateField const): Deleted. * html/DateInputType.h: * html/DateTimeLocalInputType.cpp: (WebCore::DateTimeLocalInputType::isDateTimeLocalField const): Deleted. * html/DateTimeLocalInputType.h: * html/EmailInputType.cpp: (WebCore::EmailInputType::isEmailField const): Deleted. * html/EmailInputType.h: * html/FileInputType.cpp: (WebCore::FileInputType::isFileUpload const): Deleted. * html/FileInputType.h: * html/FormAssociatedElement.h: * html/HTMLFormControlElement.h: * html/HiddenInputType.cpp: (WebCore::HiddenInputType::isHiddenType const): Deleted. * html/HiddenInputType.h: * html/ImageInputType.cpp: (WebCore::ImageInputType::isImageButton const): Deleted. (WebCore::ImageInputType::isEnumeratable): Deleted. * html/ImageInputType.h: * html/InputType.cpp: (WebCore::InputType::isTextType const): (WebCore::InputType::isTextField const): (WebCore::InputType::isTextButton const): (WebCore::InputType::isInteractiveContent const): (WebCore::InputType::supportLabels const): (WebCore::InputType::isEnumeratable): (WebCore::InputType::isCheckable): (WebCore::InputType::isRangeControl const): Deleted. (WebCore::InputType::isRadioButton const): Deleted. (WebCore::InputType::isSearchField const): Deleted. (WebCore::InputType::isHiddenType const): Deleted. (WebCore::InputType::isPasswordField const): Deleted. (WebCore::InputType::isCheckbox const): Deleted. (WebCore::InputType::isEmailField const): Deleted. (WebCore::InputType::isFileUpload const): Deleted. (WebCore::InputType::isImageButton const): Deleted. (WebCore::InputType::isNumberField const): Deleted. (WebCore::InputType::isSubmitButton const): Deleted. (WebCore::InputType::isTelephoneField const): Deleted. (WebCore::InputType::isURLField const): Deleted. (WebCore::InputType::isDateField const): Deleted. (WebCore::InputType::isDateTimeField const): Deleted. (WebCore::InputType::isDateTimeLocalField const): Deleted. (WebCore::InputType::isMonthField const): Deleted. (WebCore::InputType::isTimeField const): Deleted. (WebCore::InputType::isWeekField const): Deleted. (WebCore::InputType::isColorControl const): Deleted. * html/InputType.h: (WebCore::InputType::isCheckbox const): (WebCore::InputType::isColorControl const): (WebCore::InputType::isDateField const): (WebCore::InputType::isDateTimeField const): (WebCore::InputType::isDateTimeLocalField const): (WebCore::InputType::isEmailField const): (WebCore::InputType::isFileUpload const): (WebCore::InputType::isHiddenType const): (WebCore::InputType::isImageButton const): (WebCore::InputType::isMonthField const): (WebCore::InputType::isNumberField const): (WebCore::InputType::isPasswordField const): (WebCore::InputType::isRadioButton const): (WebCore::InputType::isRangeControl const): (WebCore::InputType::isSearchField const): (WebCore::InputType::isSubmitButton const): (WebCore::InputType::isTelephoneField const): (WebCore::InputType::isTimeField const): (WebCore::InputType::isURLField const): (WebCore::InputType::isWeekField const): * html/MonthInputType.cpp: (WebCore::MonthInputType::isMonthField const): Deleted. * html/MonthInputType.h: * html/NumberInputType.cpp: (WebCore::NumberInputType::isNumberField const): Deleted. * html/NumberInputType.h: * html/PasswordInputType.cpp: (WebCore::PasswordInputType::isPasswordField const): Deleted. * html/PasswordInputType.h: * html/RadioInputType.cpp: (WebCore::RadioInputType::isRadioButton const): Deleted. * html/RadioInputType.h: * html/RangeInputType.cpp: (WebCore::RangeInputType::isRangeControl const): Deleted. * html/RangeInputType.h: * html/ResetInputType.cpp: (WebCore::ResetInputType::isTextButton const): Deleted. * html/ResetInputType.h: * html/SearchInputType.cpp: (WebCore::SearchInputType::isSearchField const): Deleted. * html/SearchInputType.h: * html/SubmitInputType.cpp: (WebCore::SubmitInputType::isSubmitButton const): Deleted. (WebCore::SubmitInputType::isTextButton const): Deleted. * html/SubmitInputType.h: * html/TelephoneInputType.cpp: (WebCore::TelephoneInputType::isTelephoneField const): Deleted. * html/TelephoneInputType.h: * html/TextFieldInputType.cpp: (WebCore::TextFieldInputType::isTextField const): Deleted. * html/TextFieldInputType.h: * html/TimeInputType.cpp: (WebCore::TimeInputType::isTimeField const): Deleted. * html/TimeInputType.h: * html/URLInputType.cpp: (WebCore::URLInputType::isURLField const): Deleted. * html/URLInputType.h: * html/WeekInputType.cpp: (WebCore::WeekInputType::isWeekField const): Deleted. * html/WeekInputType.h: 2021-01-29 Simon Fraser Devirtualize some functions on InputType https://bugs.webkit.org/show_bug.cgi?id=221121 Reviewed by Yusuke Suzuki. Virtual functions on InputType show up in Speedometer profiles. We can make many of these virtual functions non-virtual by just switching on the input type. * dom/Element.cpp: * html/BaseCheckableInputType.cpp: (WebCore::BaseCheckableInputType::isCheckable): Deleted. * html/BaseCheckableInputType.h: * html/BaseTextInputType.cpp: (WebCore::BaseTextInputType::isTextType const): Deleted. * html/BaseTextInputType.h: * html/ButtonInputType.cpp: (WebCore::ButtonInputType::isTextButton const): Deleted. * html/ButtonInputType.h: * html/CheckboxInputType.cpp: (WebCore::CheckboxInputType::isCheckbox const): Deleted. * html/CheckboxInputType.h: * html/ColorInputType.cpp: (WebCore::ColorInputType::isColorControl const): Deleted. * html/ColorInputType.h: * html/DateInputType.cpp: (WebCore::DateInputType::isDateField const): Deleted. * html/DateInputType.h: * html/DateTimeLocalInputType.cpp: (WebCore::DateTimeLocalInputType::isDateTimeLocalField const): Deleted. * html/DateTimeLocalInputType.h: * html/EmailInputType.cpp: (WebCore::EmailInputType::isEmailField const): Deleted. * html/EmailInputType.h: * html/FileInputType.cpp: (WebCore::FileInputType::isFileUpload const): Deleted. * html/FileInputType.h: * html/FormAssociatedElement.h: * html/HTMLFormControlElement.h: * html/HiddenInputType.cpp: (WebCore::HiddenInputType::isHiddenType const): Deleted. * html/HiddenInputType.h: * html/ImageInputType.cpp: (WebCore::ImageInputType::isImageButton const): Deleted. (WebCore::ImageInputType::isEnumeratable): Deleted. * html/ImageInputType.h: * html/InputType.cpp: (WebCore::InputType::isTextType const): (WebCore::InputType::isTextField const): (WebCore::InputType::isTextButton const): (WebCore::InputType::isInteractiveContent const): (WebCore::InputType::supportLabels const): (WebCore::InputType::isEnumeratable): (WebCore::InputType::isCheckable): (WebCore::InputType::isRangeControl const): Deleted. (WebCore::InputType::isRadioButton const): Deleted. (WebCore::InputType::isSearchField const): Deleted. (WebCore::InputType::isHiddenType const): Deleted. (WebCore::InputType::isPasswordField const): Deleted. (WebCore::InputType::isCheckbox const): Deleted. (WebCore::InputType::isEmailField const): Deleted. (WebCore::InputType::isFileUpload const): Deleted. (WebCore::InputType::isImageButton const): Deleted. (WebCore::InputType::isNumberField const): Deleted. (WebCore::InputType::isSubmitButton const): Deleted. (WebCore::InputType::isTelephoneField const): Deleted. (WebCore::InputType::isURLField const): Deleted. (WebCore::InputType::isDateField const): Deleted. (WebCore::InputType::isDateTimeField const): Deleted. (WebCore::InputType::isDateTimeLocalField const): Deleted. (WebCore::InputType::isMonthField const): Deleted. (WebCore::InputType::isTimeField const): Deleted. (WebCore::InputType::isWeekField const): Deleted. (WebCore::InputType::isColorControl const): Deleted. * html/InputType.h: (WebCore::InputType::isCheckbox const): (WebCore::InputType::isColorControl const): (WebCore::InputType::isDateField const): (WebCore::InputType::isDateTimeField const): (WebCore::InputType::isDateTimeLocalField const): (WebCore::InputType::isEmailField const): (WebCore::InputType::isFileUpload const): (WebCore::InputType::isHiddenType const): (WebCore::InputType::isImageButton const): (WebCore::InputType::isMonthField const): (WebCore::InputType::isNumberField const): (WebCore::InputType::isPasswordField const): (WebCore::InputType::isRadioButton const): (WebCore::InputType::isRangeControl const): (WebCore::InputType::isSearchField const): (WebCore::InputType::isSubmitButton const): (WebCore::InputType::isTelephoneField const): (WebCore::InputType::isTimeField const): (WebCore::InputType::isURLField const): (WebCore::InputType::isWeekField const): * html/MonthInputType.cpp: (WebCore::MonthInputType::isMonthField const): Deleted. * html/MonthInputType.h: * html/NumberInputType.cpp: (WebCore::NumberInputType::isNumberField const): Deleted. * html/NumberInputType.h: * html/PasswordInputType.cpp: (WebCore::PasswordInputType::isPasswordField const): Deleted. * html/PasswordInputType.h: * html/RadioInputType.cpp: (WebCore::RadioInputType::isRadioButton const): Deleted. * html/RadioInputType.h: * html/RangeInputType.cpp: (WebCore::RangeInputType::isRangeControl const): Deleted. * html/RangeInputType.h: * html/ResetInputType.cpp: (WebCore::ResetInputType::isTextButton const): Deleted. * html/ResetInputType.h: * html/SearchInputType.cpp: (WebCore::SearchInputType::isSearchField const): Deleted. * html/SearchInputType.h: * html/SubmitInputType.cpp: (WebCore::SubmitInputType::isSubmitButton const): Deleted. (WebCore::SubmitInputType::isTextButton const): Deleted. * html/SubmitInputType.h: * html/TelephoneInputType.cpp: (WebCore::TelephoneInputType::isTelephoneField const): Deleted. * html/TelephoneInputType.h: * html/TextFieldInputType.cpp: (WebCore::TextFieldInputType::isTextField const): Deleted. * html/TextFieldInputType.h: * html/TimeInputType.cpp: (WebCore::TimeInputType::isTimeField const): Deleted. * html/TimeInputType.h: * html/URLInputType.cpp: (WebCore::URLInputType::isURLField const): Deleted. * html/URLInputType.h: * html/WeekInputType.cpp: (WebCore::WeekInputType::isWeekField const): Deleted. * html/WeekInputType.h: 2021-03-02 Alan Coon Cherry-pick r273656. rdar://problem/74883345 REGRESSION(r272004): transform transition with delay doesn't behave correctly https://bugs.webkit.org/show_bug.cgi?id=222545 Reviewed by Dean Jackson. Source/WebCore: To support accelerated animations of individual transform properties, we introduced the notion of non-interpolating animations to apply the underlying value for a given property before applying the actual animations for this property with additivity set to true. These non-interpolating animations were meant to last between the time at which animations were committed and the effective start of the first animation for that property, accounting for any delay. However, we neglected to handle the case where that first animation had a fill mode that would make it fill backwards, such as CSS Transitions. In that situation, the animation would have its first keyframe applied on top of the underlying value, effectively applying the underlying value twice with additivity. We now only add these non-interpolating animations if the first animation has a delay and does not fill backwards. Test: webanimations/transform-transition-with-delay-on-forced-layer-with-transform.html * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::updateAnimations): LayoutTests: Add a new test where an element with a non-identity transform starts a transform transition with a long delay. Prior to this patch, this test failed because, while in the delay phase, the transition would mean the underlying transform was applied twice: once by the non-interpolating animation generated for the underlying "transform" value, and once by the first keyframe of the transition since it fills backwards. * webanimations/transform-transition-with-delay-on-forced-layer-with-transform-expected.html: Added. * webanimations/transform-transition-with-delay-on-forced-layer-with-transform.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273656 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-03-01 Antoine Quint REGRESSION(r272004): transform transition with delay doesn't behave correctly https://bugs.webkit.org/show_bug.cgi?id=222545 Reviewed by Dean Jackson. To support accelerated animations of individual transform properties, we introduced the notion of non-interpolating animations to apply the underlying value for a given property before applying the actual animations for this property with additivity set to true. These non-interpolating animations were meant to last between the time at which animations were committed and the effective start of the first animation for that property, accounting for any delay. However, we neglected to handle the case where that first animation had a fill mode that would make it fill backwards, such as CSS Transitions. In that situation, the animation would have its first keyframe applied on top of the underlying value, effectively applying the underlying value twice with additivity. We now only add these non-interpolating animations if the first animation has a delay and does not fill backwards. Test: webanimations/transform-transition-with-delay-on-forced-layer-with-transform.html * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::updateAnimations): 2021-03-01 Alan Coon Cherry-pick r273564. rdar://problem/74886738 [Cocoa] Register VP9 decoders when PlatformMediaSessionManager is created https://bugs.webkit.org/show_bug.cgi?id=222473 Reviewed by Eric Carlson. Source/WebCore: Currently, VP9 decoders are registered when a Web page is created in the WebContent process. Instead, VP9 decoders can be registered when PlatformMediaSessionManager is created, which should be a slight performance improvement, since calls into media frameworks will then not be made unconditionally when creating a Web page, but delayed until required. No new tests, covered by existing tests. * platform/audio/PlatformMediaSessionManager.cpp: (WebCore::PlatformMediaSessionManager::setShouldEnableVP9Decoder): (WebCore::PlatformMediaSessionManager::shouldEnableVP9Decoder): (WebCore::PlatformMediaSessionManager::setShouldEnableVP8Decoder): (WebCore::PlatformMediaSessionManager::shouldEnableVP8Decoder): (WebCore::PlatformMediaSessionManager::setShouldEnableVP9SWDecoder): (WebCore::PlatformMediaSessionManager::shouldEnableVP9SWDecoder): * platform/audio/PlatformMediaSessionManager.h: * platform/audio/cocoa/MediaSessionManagerCocoa.mm: (WebCore::MediaSessionManagerCocoa::MediaSessionManagerCocoa): Source/WebKit: Currently, VP9 decoders are registered when a Web page is created in the WebContent process. Instead, VP9 decoders can be registered when PlatformMediaSessionManager is created, which should be a slight performance improvement, since calls into media frameworks will then not be made unconditionally when creating a Web page, but delayed until required. * WebProcess/WebPage/WebPage.cpp: (WebKit::m_lastNavigationWasAppBound): * WebProcess/WebProcess.cpp: (WebKit::WebProcess::enableVP9Decoder): Deleted. (WebKit::WebProcess::enableVP8SWDecoder): Deleted. (WebKit::WebProcess::enableVP9SWDecoder): Deleted. * WebProcess/WebProcess.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273564 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-26 Per Arne [Cocoa] Register VP9 decoders when PlatformMediaSessionManager is created https://bugs.webkit.org/show_bug.cgi?id=222473 Reviewed by Eric Carlson. Currently, VP9 decoders are registered when a Web page is created in the WebContent process. Instead, VP9 decoders can be registered when PlatformMediaSessionManager is created, which should be a slight performance improvement, since calls into media frameworks will then not be made unconditionally when creating a Web page, but delayed until required. No new tests, covered by existing tests. * platform/audio/PlatformMediaSessionManager.cpp: (WebCore::PlatformMediaSessionManager::setShouldEnableVP9Decoder): (WebCore::PlatformMediaSessionManager::shouldEnableVP9Decoder): (WebCore::PlatformMediaSessionManager::setShouldEnableVP8Decoder): (WebCore::PlatformMediaSessionManager::shouldEnableVP8Decoder): (WebCore::PlatformMediaSessionManager::setShouldEnableVP9SWDecoder): (WebCore::PlatformMediaSessionManager::shouldEnableVP9SWDecoder): * platform/audio/PlatformMediaSessionManager.h: * platform/audio/cocoa/MediaSessionManagerCocoa.mm: (WebCore::MediaSessionManagerCocoa::MediaSessionManagerCocoa): 2021-02-26 Alan Coon Cherry-pick r273558. rdar://problem/74800042 Unreviewed, address post-landing review feedback for r273542. Update a comment and fix a check that was reversed. * Modules/webaudio/ScriptProcessorNode.cpp: (WebCore::ScriptProcessorNode::createOutputBufferForJS const): (WebCore::ScriptProcessorNode::process): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273558 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-26 Chris Dumez Unreviewed, address post-landing review feedback for r273542. Update a comment and fix a check that was reversed. * Modules/webaudio/ScriptProcessorNode.cpp: (WebCore::ScriptProcessorNode::createOutputBufferForJS const): (WebCore::ScriptProcessorNode::process): 2021-02-26 Alan Coon Cherry-pick r273542. rdar://problem/74800042 Fix threading issue in ScriptProcessorNode::process() https://bugs.webkit.org/show_bug.cgi?id=222447 Reviewed by Jer Noble. It was possible for the audio thread (in ScriptProcessorNode::process()) and the main thread (via ScriptProcessorNode::fireProcessEvent()) to access the same m_inputBuffers / m_outputBuffers concurrently, causing crashes. The m_processLock was supposed to avoid this. However, the scope of the locking in ScriptProcessorNode::process() was insufficient to protect us. ScriptProcessorNode::process() now grabs the lock very early, before interacting with any buffers and we make sure not to modify the buffers when we are unable to grab the lock. Also, to make sure that the m_inputBuffers / m_outputBuffers are modified by the main thread only during the scope of the fireProcessEvent() function (during which we hold the processLock), we no longer pass our internal buffers to the JS process event handler. Instead, we pass new buffers to JS and memcpy to and from them. While this is less efficient, this is actually required because the script could store the buffers it is given and modify them outside the scope of the process event handler. * Modules/webaudio/AudioBuffer.cpp: (WebCore::AudioBuffer::AudioBuffer): (WebCore::AudioBuffer::topologyMatches const): (WebCore::AudioBuffer::copyTo const): (WebCore::AudioBuffer::clone const): * Modules/webaudio/AudioBuffer.h: * Modules/webaudio/ScriptProcessorNode.cpp: (WebCore::ScriptProcessorNode::createInputBufferForJS const): (WebCore::ScriptProcessorNode::createOutputBufferForJS const): (WebCore::ScriptProcessorNode::process): (WebCore::ScriptProcessorNode::fireProcessEvent): * Modules/webaudio/ScriptProcessorNode.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273542 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-25 Chris Dumez Fix threading issue in ScriptProcessorNode::process() https://bugs.webkit.org/show_bug.cgi?id=222447 Reviewed by Jer Noble. It was possible for the audio thread (in ScriptProcessorNode::process()) and the main thread (via ScriptProcessorNode::fireProcessEvent()) to access the same m_inputBuffers / m_outputBuffers concurrently, causing crashes. The m_processLock was supposed to avoid this. However, the scope of the locking in ScriptProcessorNode::process() was insufficient to protect us. ScriptProcessorNode::process() now grabs the lock very early, before interacting with any buffers and we make sure not to modify the buffers when we are unable to grab the lock. Also, to make sure that the m_inputBuffers / m_outputBuffers are modified by the main thread only during the scope of the fireProcessEvent() function (during which we hold the processLock), we no longer pass our internal buffers to the JS process event handler. Instead, we pass new buffers to JS and memcpy to and from them. While this is less efficient, this is actually required because the script could store the buffers it is given and modify them outside the scope of the process event handler. * Modules/webaudio/AudioBuffer.cpp: (WebCore::AudioBuffer::AudioBuffer): (WebCore::AudioBuffer::topologyMatches const): (WebCore::AudioBuffer::copyTo const): (WebCore::AudioBuffer::clone const): * Modules/webaudio/AudioBuffer.h: * Modules/webaudio/ScriptProcessorNode.cpp: (WebCore::ScriptProcessorNode::createInputBufferForJS const): (WebCore::ScriptProcessorNode::createOutputBufferForJS const): (WebCore::ScriptProcessorNode::process): (WebCore::ScriptProcessorNode::fireProcessEvent): * Modules/webaudio/ScriptProcessorNode.h: 2021-02-26 Alan Coon Cherry-pick r273512. rdar://problem/74799698 REGRESSION(r269957): Empty font names passed to canvas2d cause all text routines to crash https://bugs.webkit.org/show_bug.cgi?id=222402 Reviewed by Darin Adler and Chris Lord. Source/WebCore: It looks like it was simply an oversight from that patch. If the font name is empty, CanvasRenderingContext2D::setFont() will set the font object to one that doesn't have its internal FontCascadeFonts pointer set. Tests: fast/text/canvas-font-resolution-2.html fast/text/canvas-font-resolution.html * html/canvas/CanvasRenderingContext2D.cpp: (WebCore::CanvasRenderingContext2D::setFont): * html/canvas/CanvasRenderingContext2DBase.h: (WebCore::CanvasRenderingContext2DBase::FontProxy::isPopulated const): * style/StyleResolveForFontRaw.cpp: (WebCore::Style::resolveForFontRaw): LayoutTests: * fast/text/canvas-font-resolution-2-expected.html: Added. * fast/text/canvas-font-resolution-2.html: Added. * fast/text/canvas-font-resolution-expected.txt: Added. * fast/text/canvas-font-resolution.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273512 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-25 Myles C. Maxfield REGRESSION(r269957): Empty font names passed to canvas2d cause all text routines to crash https://bugs.webkit.org/show_bug.cgi?id=222402 Reviewed by Darin Adler and Chris Lord. It looks like it was simply an oversight from that patch. If the font name is empty, CanvasRenderingContext2D::setFont() will set the font object to one that doesn't have its internal FontCascadeFonts pointer set. Tests: fast/text/canvas-font-resolution-2.html fast/text/canvas-font-resolution.html * html/canvas/CanvasRenderingContext2D.cpp: (WebCore::CanvasRenderingContext2D::setFont): * html/canvas/CanvasRenderingContext2DBase.h: (WebCore::CanvasRenderingContext2DBase::FontProxy::isPopulated const): * style/StyleResolveForFontRaw.cpp: (WebCore::Style::resolveForFontRaw): 2021-02-26 Alan Coon Cherry-pick r273498. rdar://problem/74800989 [iOS] Crash when playing Dolby Atmos audio tracks with AVAudioTimePitchAlgorithmTimeDomain https://bugs.webkit.org/show_bug.cgi?id=222420 Reviewed by Eric Carlson. CoreAudio throws an assertion when using the TimeDomain pitch-correction algorithm on tracks with > 2 channels. To work around this assertion for now, only set the pitch-correction algorithm when the playbackRate is set to a non 0 or 1 value. * platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm: (WebCore::audioTimePitchAlgorithmForMediaPlayerPitchCorrectionAlgorithm): (WebCore::MediaPlayerPrivateAVFoundationObjC::createAVPlayerItem): (WebCore::MediaPlayerPrivateAVFoundationObjC::setPlayerRate): (WebCore::MediaPlayerPrivateAVFoundationObjC::setPreservesPitch): (WebCore::MediaPlayerPrivateAVFoundationObjC::setPitchCorrectionAlgorithm): (WebCore::MediaPlayerPrivateAVFoundationObjC::playerItemStatusDidChange): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273498 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-25 Jer Noble [iOS] Crash when playing Dolby Atmos audio tracks with AVAudioTimePitchAlgorithmTimeDomain https://bugs.webkit.org/show_bug.cgi?id=222420 Reviewed by Eric Carlson. CoreAudio throws an assertion when using the TimeDomain pitch-correction algorithm on tracks with > 2 channels. To work around this assertion for now, only set the pitch-correction algorithm when the playbackRate is set to a non 0 or 1 value. * platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm: (WebCore::audioTimePitchAlgorithmForMediaPlayerPitchCorrectionAlgorithm): (WebCore::MediaPlayerPrivateAVFoundationObjC::createAVPlayerItem): (WebCore::MediaPlayerPrivateAVFoundationObjC::setPlayerRate): (WebCore::MediaPlayerPrivateAVFoundationObjC::setPreservesPitch): (WebCore::MediaPlayerPrivateAVFoundationObjC::setPitchCorrectionAlgorithm): (WebCore::MediaPlayerPrivateAVFoundationObjC::playerItemStatusDidChange): 2021-02-26 Alan Coon Cherry-pick r273539. rdar://problem/74798808 Emoji sequences with constituents in the UBLOCK_SYMBOLS_AND_PICTOGRAPHS_EXTENDED_A Unicode block don't get combined properly https://bugs.webkit.org/show_bug.cgi?id=222438 Reviewed by Zalan Bujtas. Source/WebCore: Just add UBLOCK_SYMBOLS_AND_PICTOGRAPHS_EXTENDED_A to the list. We have to do some workarounds because not all versions of ICU include this value. Luckily, these workarounds are compile-time-only, because we we're only using this value to compare to a value produced by ICU (not a value we pass into ICU). Test: fast/text/mending-heart.html * platform/text/CharacterProperties.h: (WebCore::isEmojiGroupCandidate): LayoutTests: * fast/text/mending-heart-expected.txt: Added. * fast/text/mending-heart.html: Added. * platform/ios/TestExpectations: * platform/mac/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273539 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-25 Myles C. Maxfield Emoji sequences with constituents in the UBLOCK_SYMBOLS_AND_PICTOGRAPHS_EXTENDED_A Unicode block don't get combined properly https://bugs.webkit.org/show_bug.cgi?id=222438 Reviewed by Zalan Bujtas. Just add UBLOCK_SYMBOLS_AND_PICTOGRAPHS_EXTENDED_A to the list. We have to do some workarounds because not all versions of ICU include this value. Luckily, these workarounds are compile-time-only, because we we're only using this value to compare to a value produced by ICU (not a value we pass into ICU). Test: fast/text/mending-heart.html * platform/text/CharacterProperties.h: (WebCore::isEmojiGroupCandidate): 2021-02-25 Russell Epstein Cherry-pick r273442. rdar://problem/74753214 Regression(r269481) Kugou Music: Can not leave "MV" category after selecting it https://bugs.webkit.org/show_bug.cgi?id=222380 Reviewed by Geoffrey Garen. The new behavior in r269481 aligns us with the specification and with Blink so I am adding a linked-on-after to maintain pre-r269481 behavior until Apps get rebuilt against the new SDK. * html/HTMLDocument.cpp: (WebCore::HTMLDocument::supportedPropertyNames const): * page/Quirks.cpp: (WebCore::Quirks::shouldOmitHTMLDocumentSupportedPropertyNames): * page/Quirks.h: * platform/cocoa/VersionChecks.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273442 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-24 Chris Dumez Regression(r269481) Kugou Music: Can not leave "MV" category after selecting it https://bugs.webkit.org/show_bug.cgi?id=222380 Reviewed by Geoffrey Garen. The new behavior in r269481 aligns us with the specification and with Blink so I am adding a linked-on-after to maintain pre-r269481 behavior until Apps get rebuilt against the new SDK. * html/HTMLDocument.cpp: (WebCore::HTMLDocument::supportedPropertyNames const): * page/Quirks.cpp: (WebCore::Quirks::shouldOmitHTMLDocumentSupportedPropertyNames): * page/Quirks.h: * platform/cocoa/VersionChecks.h: 2021-02-25 Russell Epstein Cherry-pick r273501. rdar://problem/74760623 [Cocoa] Files from webmfiles.org do not play through MSE https://bugs.webkit.org/show_bug.cgi?id=222403 Reviewed by Eric Carlson. Source/WebCore: Test: media/media-source/media-source-webm-vp8-malformed-header.html As per RFC 6386, each VP8 frame begins with a three-byte (minimum) frame header, with extra bytes if that preamble indicates that the frame is a keyframe. Files from webmfiles.org (and others) have valid frame headers for keyframes, but invalid or no header for interframes; these interframes' headers, when parsed, erroneously report they are keyframes, and thus the optional extra bytes are parsed, fail parsing, and generate an error. Rather than drop frames when parsing fails, just assume the frame is an interframe, and proceed normally. * platform/graphics/cocoa/SourceBufferParserWebM.cpp: (WebCore::SourceBufferParserWebM::VideoTrackData::consumeFrameData): LayoutTests: * platform/mac-bigsur/media/media-source/content/test-vp8-malformed-header-manifest.json: Added. * platform/mac-bigsur/media/media-source/content/test-vp8-malformed-header.webm: Added. * platform/mac-bigsur/media/media-source/media-source-webm-vp8-malformed-header-expected.txt: Added. * platform/mac-bigsur/media/media-source/media-source-webm-vp8-malformed-header.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273501 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-25 Jer Noble [Cocoa] Files from webmfiles.org do not play through MSE https://bugs.webkit.org/show_bug.cgi?id=222403 Reviewed by Eric Carlson. Test: media/media-source/media-source-webm-vp8-malformed-header.html As per RFC 6386, each VP8 frame begins with a three-byte (minimum) frame header, with extra bytes if that preamble indicates that the frame is a keyframe. Files from webmfiles.org (and others) have valid frame headers for keyframes, but invalid or no header for interframes; these interframes' headers, when parsed, erroneously report they are keyframes, and thus the optional extra bytes are parsed, fail parsing, and generate an error. Rather than drop frames when parsing fails, just assume the frame is an interframe, and proceed normally. * platform/graphics/cocoa/SourceBufferParserWebM.cpp: (WebCore::SourceBufferParserWebM::VideoTrackData::consumeFrameData): 2021-02-25 Russell Epstein Cherry-pick r273499. rdar://problem/74766327 Avoid setting page muted state if unchanged https://bugs.webkit.org/show_bug.cgi?id=222395 Reviewed by Brent Fulgham. Return early in Page::setMuted if muted state did not change. No new tests, covered by existing tests. * page/Page.cpp: (WebCore::Page::setMuted): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273499 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-25 Per Arne Vollan Avoid setting page muted state if unchanged https://bugs.webkit.org/show_bug.cgi?id=222395 Reviewed by Brent Fulgham. Return early in Page::setMuted if muted state did not change. No new tests, covered by existing tests. * page/Page.cpp: (WebCore::Page::setMuted): 2021-02-25 Russell Epstein Cherry-pick r273477. rdar://problem/74766196 Avoid heap allocation for EventContexts https://bugs.webkit.org/show_bug.cgi?id=222095 Reviewed by Simon Fraser. This patch merges all subclasses of EventContext into itself to avoid heap allocation for each EventContext in EventPath::m_path. It also merges Node::handleLocalEvents into EventContext's handleLocalEvents to avoid the extra virtual function call. No new tests since there should be no observable behavioral differences. * dom/EventContext.cpp: (WebCore::EventContext::EventContext): Moved to the header to be inlined. (WebCore::EventContext::handleLocalEvents const): Merged handleLocalEvents of HTMLFormElement and Node. Moved the code to handle related target and touch targets from MouseOrFocusEventContext and TouchEventContext as they have been merged into this class. Also special case dispatching an event on window to preserve the behavior of WindowEventContext. (WebCore::EventContext::initializeTouchLists): Added. Creates TouchList objects. (WebCore::EventContext::isUnreachableNode const): Moved from the header. (WebCore::EventContext::isMouseOrFocusEventContext const): Deleted. (WebCore::EventContext::isTouchEventContext const): Deleted. (WebCore::MouseOrFocusEventContext::MouseOrFocusEventContext): Deleted. (WebCore::MouseOrFocusEventContext::handleLocalEvents const): Deleted. (WebCore::MouseOrFocusEventContext::isMouseOrFocusEventContext const): Deleted. (WebCore::TouchEventContext::TouchEventContext): Deleted. (WebCore::TouchEventContext::handleLocalEvents const): Deleted. (WebCore::TouchEventContext::isTouchEventContext const): Deleted. (WebCore::TouchEventContext::checkReachability const): Deleted. Merged into handleLocalEvents. * dom/EventContext.h: (WebCore::EventContext::isMouseOrFocusEventContext const): Now simply checks m_type. (WebCore::EventContext::isTouchEventContext const): Ditto. (WebCore::EventContext::isWindowContext const): Ditto. (WebCore::EventContext::relatedTarget const): Moved from MouseOrFocusEventContext. (WebCore::EventContext::setRelatedTarget): Ditto. (WebCore::EventContext::touchList): Moved from TouchEventContext. (WebCore::m_contextNodeIsFormElement): Added. Caching this state here instead of checking it at every event context during dispatching in EventContext::handleLocalEvents seems to be important to get a speed up in Intel processors. Apple silicons don't seem to be affected by this. (WebCore::m_type): Added. (WebCore::MouseOrFocusEventContext): Deleted. (WebCore::MouseOrFocusEventContext::relatedTarget const): Deleted. (WebCore::TouchEventContext): Deleted. (WebCore::EventContext::EventContext): Moved from cpp file to be inlined here. (WebCore::EventContext::isUnreachableNode const): Moved into cpp as this is only used for asserting shadow DOM related conditions. (WebCore::EventContext::touchList): Renamed from TouchEventContext::touchList. (isType): Deleted. * dom/EventDispatcher.cpp: (WebCore::EventDispatcher::dispatchEvent): Deleted the variant that takes a vector of elements since it's not used anywhere. * dom/EventDispatcher.h: * dom/EventPath.cpp: (WebCore::WindowEventContext): Deleted. (WebCore::EventPath::EventPath): Avoid calling setRelatedTarget if related target is not a node or the path is empty. These were early return conditions in setRelatedTarget before this patch. (WebCore::EventPath::buildPath): Always create EventContext. Dramatically simplifies the code. (WebCore::EventPath::setRelatedTarget): Moved the early exit to EventPath::EventPath. (WebCore::EventPath::retargetTouch): (WebCore::EventPath::retargetTouchList): (WebCore::EventPath::retargetTouchLists): (WebCore::EventPath::EventPath): Deleted the variant which takes a vector of elements as it's not used anywhere. * dom/EventPath.h: (WebCore::EventPath::contextAt const): (WebCore::EventPath::contextAt): (WebCore::EventPath::m_path): Now allocates EventContext in place. The size of the inline buffer has been reduced to 16 entries for EventContext from 32 entries for std::unique_ptr since the former is considerably larger than the latter. * dom/Node.cpp: (WebCore::Node::handleLocalEvents): Deleted. Merged into EventContext::handleLocalEvents. * dom/Node.h: * html/HTMLFormElement.cpp: (WebCore::HTMLFormElement::handleLocalEvents): Ditto. * html/HTMLFormElement.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273477 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-25 Ryosuke Niwa Avoid heap allocation for EventContexts https://bugs.webkit.org/show_bug.cgi?id=222095 Reviewed by Simon Fraser. This patch merges all subclasses of EventContext into itself to avoid heap allocation for each EventContext in EventPath::m_path. It also merges Node::handleLocalEvents into EventContext's handleLocalEvents to avoid the extra virtual function call. No new tests since there should be no observable behavioral differences. * dom/EventContext.cpp: (WebCore::EventContext::EventContext): Moved to the header to be inlined. (WebCore::EventContext::handleLocalEvents const): Merged handleLocalEvents of HTMLFormElement and Node. Moved the code to handle related target and touch targets from MouseOrFocusEventContext and TouchEventContext as they have been merged into this class. Also special case dispatching an event on window to preserve the behavior of WindowEventContext. (WebCore::EventContext::initializeTouchLists): Added. Creates TouchList objects. (WebCore::EventContext::isUnreachableNode const): Moved from the header. (WebCore::EventContext::isMouseOrFocusEventContext const): Deleted. (WebCore::EventContext::isTouchEventContext const): Deleted. (WebCore::MouseOrFocusEventContext::MouseOrFocusEventContext): Deleted. (WebCore::MouseOrFocusEventContext::handleLocalEvents const): Deleted. (WebCore::MouseOrFocusEventContext::isMouseOrFocusEventContext const): Deleted. (WebCore::TouchEventContext::TouchEventContext): Deleted. (WebCore::TouchEventContext::handleLocalEvents const): Deleted. (WebCore::TouchEventContext::isTouchEventContext const): Deleted. (WebCore::TouchEventContext::checkReachability const): Deleted. Merged into handleLocalEvents. * dom/EventContext.h: (WebCore::EventContext::isMouseOrFocusEventContext const): Now simply checks m_type. (WebCore::EventContext::isTouchEventContext const): Ditto. (WebCore::EventContext::isWindowContext const): Ditto. (WebCore::EventContext::relatedTarget const): Moved from MouseOrFocusEventContext. (WebCore::EventContext::setRelatedTarget): Ditto. (WebCore::EventContext::touchList): Moved from TouchEventContext. (WebCore::m_contextNodeIsFormElement): Added. Caching this state here instead of checking it at every event context during dispatching in EventContext::handleLocalEvents seems to be important to get a speed up in Intel processors. Apple silicons don't seem to be affected by this. (WebCore::m_type): Added. (WebCore::MouseOrFocusEventContext): Deleted. (WebCore::MouseOrFocusEventContext::relatedTarget const): Deleted. (WebCore::TouchEventContext): Deleted. (WebCore::EventContext::EventContext): Moved from cpp file to be inlined here. (WebCore::EventContext::isUnreachableNode const): Moved into cpp as this is only used for asserting shadow DOM related conditions. (WebCore::EventContext::touchList): Renamed from TouchEventContext::touchList. (isType): Deleted. * dom/EventDispatcher.cpp: (WebCore::EventDispatcher::dispatchEvent): Deleted the variant that takes a vector of elements since it's not used anywhere. * dom/EventDispatcher.h: * dom/EventPath.cpp: (WebCore::WindowEventContext): Deleted. (WebCore::EventPath::EventPath): Avoid calling setRelatedTarget if related target is not a node or the path is empty. These were early return conditions in setRelatedTarget before this patch. (WebCore::EventPath::buildPath): Always create EventContext. Dramatically simplifies the code. (WebCore::EventPath::setRelatedTarget): Moved the early exit to EventPath::EventPath. (WebCore::EventPath::retargetTouch): (WebCore::EventPath::retargetTouchList): (WebCore::EventPath::retargetTouchLists): (WebCore::EventPath::EventPath): Deleted the variant which takes a vector of elements as it's not used anywhere. * dom/EventPath.h: (WebCore::EventPath::contextAt const): (WebCore::EventPath::contextAt): (WebCore::EventPath::m_path): Now allocates EventContext in place. The size of the inline buffer has been reduced to 16 entries for EventContext from 32 entries for std::unique_ptr since the former is considerably larger than the latter. * dom/Node.cpp: (WebCore::Node::handleLocalEvents): Deleted. Merged into EventContext::handleLocalEvents. * dom/Node.h: * html/HTMLFormElement.cpp: (WebCore::HTMLFormElement::handleLocalEvents): Ditto. * html/HTMLFormElement.h: 2021-02-25 Russell Epstein Cherry-pick r273438. rdar://problem/74753272 Regression(r268700) postMessage changes prototype of basic types https://bugs.webkit.org/show_bug.cgi?id=222228 Reviewed by Geoffrey Garen. Source/WebCore: r268700 updated ScriptExecutionContext::globalObject() to call: `WebCore::globalObject(mainThreadNormalWorld(), downcast(*this).page())` instead of `frame ? frame->script().globalObject(mainThreadNormalWorld()) : nullptr` This was not right for subframes because globalObject() gets the globalObject from the page's main frame instead of the document's frame. This patch gets rid of the error-prone WebCore::globalObject() taking in a Page* and replaces it with one taking in a Frame* to avoid such issues in the future. Test: fast/dom/Window/postMessage-Object-prototype.html * bindings/js/ScriptState.cpp: (WebCore::globalObject): * bindings/js/ScriptState.h: * dom/ScriptExecutionContext.cpp: (WebCore::ScriptExecutionContext::globalObject): * inspector/InspectorFrontendHost.cpp: (WebCore::InspectorFrontendHost::addSelfToGlobalObjectInWorld): (WebCore::InspectorFrontendHost::showContextMenu): LayoutTests: Add layout test coverage. * fast/dom/Window/postMessage-Object-prototype-expected.txt: Added. * fast/dom/Window/postMessage-Object-prototype.html: Added. * fast/dom/Window/resources/postMessage-Object-prototype-frame.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273438 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-24 Chris Dumez Regression(r268700) postMessage changes prototype of basic types https://bugs.webkit.org/show_bug.cgi?id=222228 Reviewed by Geoffrey Garen. r268700 updated ScriptExecutionContext::globalObject() to call: `WebCore::globalObject(mainThreadNormalWorld(), downcast(*this).page())` instead of `frame ? frame->script().globalObject(mainThreadNormalWorld()) : nullptr` This was not right for subframes because globalObject() gets the globalObject from the page's main frame instead of the document's frame. This patch gets rid of the error-prone WebCore::globalObject() taking in a Page* and replaces it with one taking in a Frame* to avoid such issues in the future. Test: fast/dom/Window/postMessage-Object-prototype.html * bindings/js/ScriptState.cpp: (WebCore::globalObject): * bindings/js/ScriptState.h: * dom/ScriptExecutionContext.cpp: (WebCore::ScriptExecutionContext::globalObject): * inspector/InspectorFrontendHost.cpp: (WebCore::InspectorFrontendHost::addSelfToGlobalObjectInWorld): (WebCore::InspectorFrontendHost::showContextMenu): 2021-02-25 Russell Epstein Cherry-pick r273415. rdar://problem/74763807 Move PostResolutionCallbackDisabler to resolveComputedStyle https://bugs.webkit.org/show_bug.cgi?id=222350 Reviewed by Ryosuke Niwa. It can be constructed and deleted repeatedly in styleForElementIgnoringPendingStylesheets when resolveComputedStyle calls it in a loop. * dom/Document.cpp: (WebCore::Document::styleForElementIgnoringPendingStylesheets): * dom/Element.cpp: (WebCore::Element::resolveComputedStyle): (WebCore::Element::resolvePseudoElementStyle): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273415 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-24 Antti Koivisto Move PostResolutionCallbackDisabler to resolveComputedStyle https://bugs.webkit.org/show_bug.cgi?id=222350 Reviewed by Ryosuke Niwa. It can be constructed and deleted repeatedly in styleForElementIgnoringPendingStylesheets when resolveComputedStyle calls it in a loop. * dom/Document.cpp: (WebCore::Document::styleForElementIgnoringPendingStylesheets): * dom/Element.cpp: (WebCore::Element::resolveComputedStyle): (WebCore::Element::resolvePseudoElementStyle): 2021-02-25 Russell Epstein Cherry-pick r273385. rdar://problem/74753323 Runtime-disabled CSS features still appear enabled via CSS.supports() https://bugs.webkit.org/show_bug.cgi?id=222280 rdar://74595641 Reviewed by Sam Weinig. Source/WebCore: When parsing CSS.supports() for a runtime-disabled property, we'd successfully parse a CSS-wide keyword like "inherit" and report that the property is supported. We need to explicitly check for runtime-disabled properties. Tests: css3/color-filters/color-filter-exposed-if-disabled.html fast/css/scroll-behavior-exposed-if-disabled.html * css/parser/CSSParserImpl.cpp: (WebCore::CSSParserImpl::isPropertyRuntimeDisabled const): (WebCore::CSSParserImpl::consumeDeclaration): * css/parser/CSSParserImpl.h: LayoutTests: * css3/color-filters/color-filter-exposed-if-disabled-expected.txt: Added. Fails tracked in webkit.org/b/217626 * css3/color-filters/color-filter-exposed-if-disabled.html: Added. * fast/css/overscroll-behavior-invalidate-if-disabled-expected.txt: * fast/css/overscroll-behavior-invalidate-if-disabled.html: * fast/css/scroll-behavior-exposed-if-disabled-expected.txt: Added. * fast/css/scroll-behavior-exposed-if-disabled.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273385 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-24 Simon Fraser Runtime-disabled CSS features still appear enabled via CSS.supports() https://bugs.webkit.org/show_bug.cgi?id=222280 rdar://74595641 Reviewed by Sam Weinig. When parsing CSS.supports() for a runtime-disabled property, we'd successfully parse a CSS-wide keyword like "inherit" and report that the property is supported. We need to explicitly check for runtime-disabled properties. Tests: css3/color-filters/color-filter-exposed-if-disabled.html fast/css/scroll-behavior-exposed-if-disabled.html * css/parser/CSSParserImpl.cpp: (WebCore::CSSParserImpl::isPropertyRuntimeDisabled const): (WebCore::CSSParserImpl::consumeDeclaration): * css/parser/CSSParserImpl.h: 2021-02-25 Russell Epstein Cherry-pick r273314. rdar://problem/74753323 aspect-ratio shows in computed style when disabled https://bugs.webkit.org/show_bug.cgi?id=222286 Patch by Rob Buis on 2021-02-23 Reviewed by Simon Fraser. Source/WebCore: Make aspect-ratio invisible from style when disabled. Test: fast/css/aspect-ratio-invalidate-if-disabled.html * css/CSSComputedStyleDeclaration.cpp: (WebCore::ComputedStyleExtractor::valueForPropertyInStyle): * css/CSSProperties.json: Tools: Add support for disabling aspect-ratio in wk1. * DumpRenderTree/TestOptions.cpp: (WTR::TestOptions::defaults): LayoutTests: Add test. * fast/css/aspect-ratio-invalidate-if-disabled-expected.txt: Added. * fast/css/aspect-ratio-invalidate-if-disabled.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273314 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-23 Rob Buis aspect-ratio shows in computed style when disabled https://bugs.webkit.org/show_bug.cgi?id=222286 Reviewed by Simon Fraser. Make aspect-ratio invisible from style when disabled. Test: fast/css/aspect-ratio-invalidate-if-disabled.html * css/CSSComputedStyleDeclaration.cpp: (WebCore::ComputedStyleExtractor::valueForPropertyInStyle): * css/CSSProperties.json: 2021-01-25 Chris Dumez Unreviewed, add missing header includes to address build issues. * Modules/webauthn/AuthenticationExtensionsClientOutputs.h: 2021-02-25 Alan Coon Cherry-pick r272039. rdar://problem/74451201 [GPUP][MSE] A video element does not fire “canplaythrough” event if SourceBuffer.abort() is called https://bugs.webkit.org/show_bug.cgi?id=220964 Reviewed by Jer Noble. Source/WebCore: This patch removes `initializationSegmentIsHandledSemaphore` from both `SourceBufferParserAVFObjC` and `SourceBufferParserWebM`, and implements a media sample cache mechanism in `SourceBufferPrivateAVFObjC` to ensure that "Coded Frame Processing" steps execute after `SourceBufferPrivate` has handled the initialization segment and enabled video/audio tracks. Without the cache mechanism, some media samples following the initialization segment may be dropped when we run `SourceBufferPrivateAVFObjC` in the GPU process, and the media element won't fire "canplaythrough" event because it cannot change its ready state to a value greater than HAVE_METADATA. This patch also implements the mechanism to make sure `SourceBufferPrivateAVFObjC::appendCompleted()` runs after all media samples have gone through the "Coded Frame Processing" steps, so that the source buffer object will fire "update" and "updateend" event after the parser has completedly parsed the appended buffer. * platform/graphics/avfoundation/objc/SourceBufferParserAVFObjC.h: * platform/graphics/avfoundation/objc/SourceBufferParserAVFObjC.mm: (WebCore::SourceBufferParserAVFObjC::SourceBufferParserAVFObjC): (WebCore::SourceBufferParserAVFObjC::~SourceBufferParserAVFObjC): (WebCore::SourceBufferParserAVFObjC::appendData): Add a parameter "CompletionHandler" to notify the caller that the parser has parsed the whole buffer. (WebCore::SourceBufferParserAVFObjC::flushPendingMediaData): (WebCore::SourceBufferParserAVFObjC::resetParserState): (WebCore::SourceBufferParserAVFObjC::invalidate): (WebCore::SourceBufferParserAVFObjC::didParseStreamDataAsAsset): * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.h: * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm: (WebCore::SourceBufferPrivateAVFObjC::SourceBufferPrivateAVFObjC): (WebCore::SourceBufferPrivateAVFObjC::~SourceBufferPrivateAVFObjC): (WebCore::SourceBufferPrivateAVFObjC::didParseInitializationData): After `SourceBufferPrivateClient` has done the configuration with the initialization segment, we need to push the cached media samples (if any) to `SourceBufferPrivate` to run the "Coded Frame Processing" steps. And we need to call "appendCompleted()" if there is a pending callback. (WebCore::SourceBufferPrivateAVFObjC::didProvideMediaDataForTrackId): `SourceBufferPrivateAVFObjC` needs to cache the media sample if the initialization segment has not been processed by `SourceBufferPrivateClient` yet. (WebCore::SourceBufferPrivateAVFObjC::append): We need to postpone the "appendCompleted()" callback if there are cached media samples. (WebCore::SourceBufferPrivateAVFObjC::appendCompleted): (WebCore::SourceBufferPrivateAVFObjC::abort): (WebCore::SourceBufferPrivateAVFObjC::setVideoLayer): (WebCore::SourceBufferPrivateAVFObjC::didProvideMediaDataForTrackID): Deleted. * platform/graphics/cocoa/SourceBufferParser.h: * platform/graphics/cocoa/SourceBufferParserWebM.cpp: (WebCore::SourceBufferParserWebM::SourceBufferParserWebM): (WebCore::SourceBufferParserWebM::~SourceBufferParserWebM): (WebCore::SourceBufferParserWebM::appendData): (WebCore::SourceBufferParserWebM::flushPendingMediaData): (WebCore::SourceBufferParserWebM::resetParserState): (WebCore::SourceBufferParserWebM::invalidate): (WebCore::SourceBufferParserWebM::OnClusterBegin): * platform/graphics/cocoa/SourceBufferParserWebM.h: Source/WebKit: * Shared/mac/MediaFormatReader/MediaFormatReader.cpp: (WebKit::MediaFormatReader::parseByteSource): LayoutTests: * gpu-process/TestExpectations: * media/media-source/media-source-webm-append-buffer-after-abort-expected.txt: Added. * media/media-source/media-source-webm-append-buffer-after-abort.html: Added. * platform/mac/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272039 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-01-28 Peng Liu [GPUP][MSE] A video element does not fire “canplaythrough” event if SourceBuffer.abort() is called https://bugs.webkit.org/show_bug.cgi?id=220964 Reviewed by Jer Noble. This patch removes `initializationSegmentIsHandledSemaphore` from both `SourceBufferParserAVFObjC` and `SourceBufferParserWebM`, and implements a media sample cache mechanism in `SourceBufferPrivateAVFObjC` to ensure that "Coded Frame Processing" steps execute after `SourceBufferPrivate` has handled the initialization segment and enabled video/audio tracks. Without the cache mechanism, some media samples following the initialization segment may be dropped when we run `SourceBufferPrivateAVFObjC` in the GPU process, and the media element won't fire "canplaythrough" event because it cannot change its ready state to a value greater than HAVE_METADATA. This patch also implements the mechanism to make sure `SourceBufferPrivateAVFObjC::appendCompleted()` runs after all media samples have gone through the "Coded Frame Processing" steps, so that the source buffer object will fire "update" and "updateend" event after the parser has completedly parsed the appended buffer. * platform/graphics/avfoundation/objc/SourceBufferParserAVFObjC.h: * platform/graphics/avfoundation/objc/SourceBufferParserAVFObjC.mm: (WebCore::SourceBufferParserAVFObjC::SourceBufferParserAVFObjC): (WebCore::SourceBufferParserAVFObjC::~SourceBufferParserAVFObjC): (WebCore::SourceBufferParserAVFObjC::appendData): Add a parameter "CompletionHandler" to notify the caller that the parser has parsed the whole buffer. (WebCore::SourceBufferParserAVFObjC::flushPendingMediaData): (WebCore::SourceBufferParserAVFObjC::resetParserState): (WebCore::SourceBufferParserAVFObjC::invalidate): (WebCore::SourceBufferParserAVFObjC::didParseStreamDataAsAsset): * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.h: * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm: (WebCore::SourceBufferPrivateAVFObjC::SourceBufferPrivateAVFObjC): (WebCore::SourceBufferPrivateAVFObjC::~SourceBufferPrivateAVFObjC): (WebCore::SourceBufferPrivateAVFObjC::didParseInitializationData): After `SourceBufferPrivateClient` has done the configuration with the initialization segment, we need to push the cached media samples (if any) to `SourceBufferPrivate` to run the "Coded Frame Processing" steps. And we need to call "appendCompleted()" if there is a pending callback. (WebCore::SourceBufferPrivateAVFObjC::didProvideMediaDataForTrackId): `SourceBufferPrivateAVFObjC` needs to cache the media sample if the initialization segment has not been processed by `SourceBufferPrivateClient` yet. (WebCore::SourceBufferPrivateAVFObjC::append): We need to postpone the "appendCompleted()" callback if there are cached media samples. (WebCore::SourceBufferPrivateAVFObjC::appendCompleted): (WebCore::SourceBufferPrivateAVFObjC::abort): (WebCore::SourceBufferPrivateAVFObjC::setVideoLayer): (WebCore::SourceBufferPrivateAVFObjC::didProvideMediaDataForTrackID): Deleted. * platform/graphics/cocoa/SourceBufferParser.h: * platform/graphics/cocoa/SourceBufferParserWebM.cpp: (WebCore::SourceBufferParserWebM::SourceBufferParserWebM): (WebCore::SourceBufferParserWebM::~SourceBufferParserWebM): (WebCore::SourceBufferParserWebM::appendData): (WebCore::SourceBufferParserWebM::flushPendingMediaData): (WebCore::SourceBufferParserWebM::resetParserState): (WebCore::SourceBufferParserWebM::invalidate): (WebCore::SourceBufferParserWebM::OnClusterBegin): * platform/graphics/cocoa/SourceBufferParserWebM.h: 2021-02-24 Russell Epstein Cherry-pick r272906. rdar://problem/74410175 [LFC][Integration] Pass child inline block scroll overflow to parent https://bugs.webkit.org/show_bug.cgi?id=221958 rdar://74050874 Reviewed by Zalan Bujtas. Source/WebCore: Integrated LFC fails to pass through overflow from nested inline blocks. Test: fast/overflow/inline-block-scroll-overflow.html * layout/integration/LayoutIntegrationInlineContentBuilder.cpp: (WebCore::LayoutIntegration::InlineContentBuilder::InlineContentBuilder): (WebCore::LayoutIntegration::InlineContentBuilder::createDisplayLines const): Find the associated RenderBox and collect overflow from it. * layout/integration/LayoutIntegrationInlineContentBuilder.h: * layout/integration/LayoutIntegrationLineLayout.cpp: (WebCore::LayoutIntegration::LineLayout::constructContent): LayoutTests: * fast/overflow/inline-block-scroll-overflow-expected.html: Added. * fast/overflow/inline-block-scroll-overflow.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272906 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-16 Antti Koivisto [LFC][Integration] Pass child inline block scroll overflow to parent https://bugs.webkit.org/show_bug.cgi?id=221958 rdar://74050874 Reviewed by Zalan Bujtas. Integrated LFC fails to pass through overflow from nested inline blocks. Test: fast/overflow/inline-block-scroll-overflow.html * layout/integration/LayoutIntegrationInlineContentBuilder.cpp: (WebCore::LayoutIntegration::InlineContentBuilder::InlineContentBuilder): (WebCore::LayoutIntegration::InlineContentBuilder::createDisplayLines const): Find the associated RenderBox and collect overflow from it. * layout/integration/LayoutIntegrationInlineContentBuilder.h: * layout/integration/LayoutIntegrationLineLayout.cpp: (WebCore::LayoutIntegration::LineLayout::constructContent): 2021-02-24 Russell Epstein Cherry-pick r272977. rdar://problem/74500812 REGRESSION (r266695): Unable to scroll the menu in 北京114预约挂号 official account - WeChat https://bugs.webkit.org/show_bug.cgi?id=221948 Reviewed by Simon Fraser. r266695 caused this to regress, but it actually is a progression, because all browsers agree that this content, as it exists in the app, doesn't scroll. So, we don't want to revert the change itself, because it's a good change, but we also want to make sure that WeChat continues to work. So, we can temporarily quirk one particular element in the WeChat app, until the the content can be fixed (). Because this is a WeChat-specific quirk, it is untestable. I tested manually. * page/Quirks.cpp: (WebCore::Quirks::needsWeChatScrollingQuirk const): * page/Quirks.h: * platform/RuntimeApplicationChecks.h: * platform/cocoa/RuntimeApplicationChecksCocoa.mm: (WebCore::IOSApplication::isWechat): * platform/cocoa/VersionChecks.h: * style/StyleAdjuster.cpp: (WebCore::Style::Adjuster::adjustForSiteSpecificQuirks const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272977 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-16 Myles C. Maxfield REGRESSION (r266695): Unable to scroll the menu in 北京114预约挂号 official account - WeChat https://bugs.webkit.org/show_bug.cgi?id=221948 Reviewed by Simon Fraser. r266695 caused this to regress, but it actually is a progression, because all browsers agree that this content, as it exists in the app, doesn't scroll. So, we don't want to revert the change itself, because it's a good change, but we also want to make sure that WeChat continues to work. So, we can temporarily quirk one particular element in the WeChat app, until the the content can be fixed (). Because this is a WeChat-specific quirk, it is untestable. I tested manually. * page/Quirks.cpp: (WebCore::Quirks::needsWeChatScrollingQuirk const): * page/Quirks.h: * platform/RuntimeApplicationChecks.h: * platform/cocoa/RuntimeApplicationChecksCocoa.mm: (WebCore::IOSApplication::isWechat): * platform/cocoa/VersionChecks.h: * style/StyleAdjuster.cpp: (WebCore::Style::Adjuster::adjustForSiteSpecificQuirks const): 2021-02-24 Russell Epstein Cherry-pick r272911. rdar://problem/74501076 MediaRecorder.stop() does not work correctly when recording has been paused. https://bugs.webkit.org/show_bug.cgi?id=221916 Reviewed by Eric Carlson. LayoutTests/imported/w3c: * web-platform-tests/mediacapture-record/MediaRecorder-pause-resume-expected.txt: * web-platform-tests/mediacapture-record/MediaRecorder-pause-resume.html: Source/WebCore: Proceed with stop steps in case of paused state, and not only in case of recording state. Covered by added WPT test. * Modules/mediarecorder/MediaRecorder.cpp: (WebCore::MediaRecorder::stopRecordingInternal): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272911 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-16 Youenn Fablet MediaRecorder.stop() does not work correctly when recording has been paused. https://bugs.webkit.org/show_bug.cgi?id=221916 Reviewed by Eric Carlson. Proceed with stop steps in case of paused state, and not only in case of recording state. Covered by added WPT test. * Modules/mediarecorder/MediaRecorder.cpp: (WebCore::MediaRecorder::stopRecordingInternal): 2021-02-24 Russell Epstein Cherry-pick r272544. rdar://problem/74409562 [Cocoa] Encrypted media segments should generate a parser error if no encrypted media handler is present. https://bugs.webkit.org/show_bug.cgi?id=221496 Reviewed by Eric Carlson. The WebM format reader does not support encrypted media parsing, so the parser must generate an error rather than continuing to parse encrypted media data. * platform/graphics/cocoa/SourceBufferParserWebM.cpp: (WebCore::SourceBufferParserWebM::OnElementEnd): (WebCore::SourceBufferParserWebM::OnTrackEntry): * platform/graphics/cocoa/SourceBufferParserWebM.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272544 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-08 Jer Noble [Cocoa] Encrypted media segments should generate a parser error if no encrypted media handler is present. https://bugs.webkit.org/show_bug.cgi?id=221496 Reviewed by Eric Carlson. The WebM format reader does not support encrypted media parsing, so the parser must generate an error rather than continuing to parse encrypted media data. * platform/graphics/cocoa/SourceBufferParserWebM.cpp: (WebCore::SourceBufferParserWebM::OnElementEnd): (WebCore::SourceBufferParserWebM::OnTrackEntry): * platform/graphics/cocoa/SourceBufferParserWebM.h: 2021-02-24 Russell Epstein Cherry-pick r272359. rdar://problem/74451201 [MSE] Move the call to didParseInitializationDataCallback() from the beginning of a cluster to the end of "tracks" element https://bugs.webkit.org/show_bug.cgi?id=221120 Reviewed by Daniel Bates. Source/WebCore: This patch updates the WebM parser regarding the timing to call didParseInitializationDataCallback() based on a discussion with Jer. Based on the spec, https://w3c.github.io/mse-byte-stream-format-webm/#webm-init-segments, "The user agent MUST accept and ignore any elements other than an EBML Header or a Cluster that occur before, in between, or after the Segment Information and Tracks elements." So the parser should have collected all required information of the initialization segment when it finishes parsing the "Tracks" element. Tests: media/media-source/media-source-webm.html * platform/graphics/cocoa/SourceBufferParserWebM.cpp: (WebCore::SourceBufferParserWebM::OnElementEnd): (WebCore::SourceBufferParserWebM::OnClusterBegin): LayoutTests: * media/media-source/media-source-webm-expected.txt: * media/media-source/media-source-webm.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272359 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-03 Peng Liu [MSE] Move the call to didParseInitializationDataCallback() from the beginning of a cluster to the end of "tracks" element https://bugs.webkit.org/show_bug.cgi?id=221120 Reviewed by Daniel Bates. This patch updates the WebM parser regarding the timing to call didParseInitializationDataCallback() based on a discussion with Jer. Based on the spec, https://w3c.github.io/mse-byte-stream-format-webm/#webm-init-segments, "The user agent MUST accept and ignore any elements other than an EBML Header or a Cluster that occur before, in between, or after the Segment Information and Tracks elements." So the parser should have collected all required information of the initialization segment when it finishes parsing the "Tracks" element. Tests: media/media-source/media-source-webm.html * platform/graphics/cocoa/SourceBufferParserWebM.cpp: (WebCore::SourceBufferParserWebM::OnElementEnd): (WebCore::SourceBufferParserWebM::OnClusterBegin): 2021-02-23 Alan Coon Cherry-pick r273264. rdar://problem/74622873 REGRESSION (r266695): twitch.tv: when in fullscreen, WebKit continually does 350ms layouts. Firefox and Chrome do not https://bugs.webkit.org/show_bug.cgi?id=222202 Reviewed by Simon Fraser. PerformanceTests: New performance test for nested column flexboxes with percentage heights. * Layout/nested-column-flexboxes-relative-height.html: Added. Source/WebCore: The problem was that we were doing the initial layout for the children of the flex container twice in those cases where the child inline axis was not the main axis (for example with column flex containers in horizontal writing modes). Refactored the code (specially the way we clear overriding sizes) so that we only do it once. This saves tons of layouts in pages with nested column flexboxes with relative heights. No new tests as there is no change in functionality, we're removing duplicate extra layouts. We're however adding a new performance test for column flexboxes with percentage heights. With this patch we go from 3.5 layout/s to 145 layout/s which is ~4000% better. Inspired by Blink's crrev.com/c/1614058 by . * rendering/RenderFlexibleBox.cpp: (WebCore::RenderFlexibleBox::computeInnerFlexBaseSizeForChild): Do not unconditionally clear overriding sizes. Also removed relayoutChildren which is now unused. Do not layout the item, that should have been done in computeInnerFlexBaseSizeForChild() before. Added ASSERTs to verify that child's intrinsic main size was cached as a consequence of the previous layout. (WebCore::RenderFlexibleBox::constructFlexItem): Do not pass relayoutChildren to computeInnerFlexBaseSizeForChild. Also no need to update it after laying out the child. * rendering/RenderFlexibleBox.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273264 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-22 Sergio Villar Senin REGRESSION (r266695): twitch.tv: when in fullscreen, WebKit continually does 350ms layouts. Firefox and Chrome do not https://bugs.webkit.org/show_bug.cgi?id=222202 Reviewed by Simon Fraser. The problem was that we were doing the initial layout for the children of the flex container twice in those cases where the child inline axis was not the main axis (for example with column flex containers in horizontal writing modes). Refactored the code (specially the way we clear overriding sizes) so that we only do it once. This saves tons of layouts in pages with nested column flexboxes with relative heights. No new tests as there is no change in functionality, we're removing duplicate extra layouts. We're however adding a new performance test for column flexboxes with percentage heights. With this patch we go from 3.5 layout/s to 145 layout/s which is ~4000% better. Inspired by Blink's crrev.com/c/1614058 by . * rendering/RenderFlexibleBox.cpp: (WebCore::RenderFlexibleBox::computeInnerFlexBaseSizeForChild): Do not unconditionally clear overriding sizes. Also removed relayoutChildren which is now unused. Do not layout the item, that should have been done in computeInnerFlexBaseSizeForChild() before. Added ASSERTs to verify that child's intrinsic main size was cached as a consequence of the previous layout. (WebCore::RenderFlexibleBox::constructFlexItem): Do not pass relayoutChildren to computeInnerFlexBaseSizeForChild. Also no need to update it after laying out the child. * rendering/RenderFlexibleBox.h: 2021-02-23 Alan Coon Cherry-pick r273220. rdar://problem/74623537 [Paint Timing] Return early from contentful paint check when no contentful pixels/characters at all https://bugs.webkit.org/show_bug.cgi?id=222245 Reviewed by Simon Fraser. Bail from recursive contenful-paint check if there are no pixels/text characters in the entire document. Covered by existing tests, an optimization only. * dom/Document.cpp: (WebCore::Document::enqueuePaintTimingEntryIfNeeded): * page/FrameView.cpp: (WebCore::FrameView::hasContenfulDescendants const): * page/FrameView.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273220 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-21 Noam Rosenthal [Paint Timing] Return early from contentful paint check when no contentful pixels/characters at all https://bugs.webkit.org/show_bug.cgi?id=222245 Reviewed by Simon Fraser. Bail from recursive contenful-paint check if there are no pixels/text characters in the entire document. Covered by existing tests, an optimization only. * dom/Document.cpp: (WebCore::Document::enqueuePaintTimingEntryIfNeeded): * page/FrameView.cpp: (WebCore::FrameView::hasContenfulDescendants const): * page/FrameView.h: 2021-02-23 Alan Coon Cherry-pick r273158. rdar://problem/74623451 Allow to use BigInt as key identifier https://bugs.webkit.org/show_bug.cgi?id=222165 Reviewed by Darin Adler. Source/WebCore: Allow to pass a BigInt as key id so as to use all of SFrame key ID 8 bytes. A RangeError is thrown if BigInt is more than 64 bits. Update the implementation to use a Vector instead of a map to keep the keys. This allows to also use 0 and 2^64-1 values that HashMap reserves for its personal use. Covered by updated test. * Modules/mediastream/RTCRtpSFrameTransform.idl: * Modules/mediastream/RTCRtpSFrameTransformer.cpp: (WebCore::RTCRtpSFrameTransformer::setEncryptionKey): (WebCore::RTCRtpSFrameTransformer::updateEncryptionKey): (WebCore::RTCRtpSFrameTransformer::decryptFrame): * Modules/mediastream/RTCRtpSFrameTransformer.h: * Sources.txt: * WebCore.xcodeproj/project.pbxproj: * bindings/js/JSRTCRtpSFrameTransformCustom.cpp: Added. (WebCore::JSRTCRtpSFrameTransform::setEncryptionKey): LayoutTests: * webrtc/sframe-keys-expected.txt: * webrtc/sframe-keys.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273158 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-19 Youenn Fablet Allow to use BigInt as key identifier https://bugs.webkit.org/show_bug.cgi?id=222165 Reviewed by Darin Adler. Allow to pass a BigInt as key id so as to use all of SFrame key ID 8 bytes. A RangeError is thrown if BigInt is more than 64 bits. Update the implementation to use a Vector instead of a map to keep the keys. This allows to also use 0 and 2^64-1 values that HashMap reserves for its personal use. Covered by updated test. * Modules/mediastream/RTCRtpSFrameTransform.idl: * Modules/mediastream/RTCRtpSFrameTransformer.cpp: (WebCore::RTCRtpSFrameTransformer::setEncryptionKey): (WebCore::RTCRtpSFrameTransformer::updateEncryptionKey): (WebCore::RTCRtpSFrameTransformer::decryptFrame): * Modules/mediastream/RTCRtpSFrameTransformer.h: * Sources.txt: * WebCore.xcodeproj/project.pbxproj: * bindings/js/JSRTCRtpSFrameTransformCustom.cpp: Added. (WebCore::JSRTCRtpSFrameTransform::setEncryptionKey): 2021-02-23 Alan Coon Cherry-pick r273129. rdar://problem/74623422 Scrolling on https://www.apple.com/ipad-air/ can jitter on certain sections https://bugs.webkit.org/show_bug.cgi?id=222136 rdar://71881767 Reviewed by Zalan Bujtas. Source/WebCore: On macOS computers with 16MB of memory, https://www.apple.com/ipad-air/ can trigger the "conservative" compositing mode where RenderLayerCompositor tries to reduce the number of composited layers. On this particular page, a "will-change: transform" element with an overflow:hidden ancestor triggers some bad compositing bounds geometry computation (webkit.org/b/222092, webkit.org/b/222124) which has the end result of changing the composited bounds of the "position:sticky" layer on every scroll. This results in layer contents temporarily appearing stretched or in the wrong place (webkit.org/b/222132). For now, do a conservative fix to avoid this problem, which is to continue to allow "will-change: transform" to trigger compositing on macOS in conservative mode. This actually reduces memory use on this page, because webkit.org/b/222092 was triggering excessively large backing store. Tested by compositing/layer-creation/compositing-policy.html * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::requiresCompositingForWillChange const): LayoutTests: * platform/mac/compositing/layer-creation/compositing-policy-expected.txt: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273129 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-18 Simon Fraser Scrolling on https://www.apple.com/ipad-air/ can jitter on certain sections https://bugs.webkit.org/show_bug.cgi?id=222136 rdar://71881767 Reviewed by Zalan Bujtas. On macOS computers with 16MB of memory, https://www.apple.com/ipad-air/ can trigger the "conservative" compositing mode where RenderLayerCompositor tries to reduce the number of composited layers. On this particular page, a "will-change: transform" element with an overflow:hidden ancestor triggers some bad compositing bounds geometry computation (webkit.org/b/222092, webkit.org/b/222124) which has the end result of changing the composited bounds of the "position:sticky" layer on every scroll. This results in layer contents temporarily appearing stretched or in the wrong place (webkit.org/b/222132). For now, do a conservative fix to avoid this problem, which is to continue to allow "will-change: transform" to trigger compositing on macOS in conservative mode. This actually reduces memory use on this page, because webkit.org/b/222092 was triggering excessively large backing store. Tested by compositing/layer-creation/compositing-policy.html * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::requiresCompositingForWillChange const): 2021-02-23 Alan Coon Cherry-pick r272358. rdar://problem/74622890 Avoid an ancestor walk in HTMLFormControlElement::computeWillValidate() https://bugs.webkit.org/show_bug.cgi?id=221357 Reviewed by Ryosuke Niwa. HTMLFormControlElement::computeWillValidate() does an ancestor DOM walk to look for enclosing data list elements, but these are fairly uncommon so we can avoid this work if we know the Document has none. * dom/Document.h: (WebCore::Document::hasDataListElements const): (WebCore::Document::incrementDataListElementCount): (WebCore::Document::decrementDataListElementCount): * dom/Element.cpp: (WebCore::Element::removedFromAncestor): Avoid fetching the page twice. * html/HTMLDataListElement.cpp: (WebCore::HTMLDataListElement::HTMLDataListElement): (WebCore::HTMLDataListElement::~HTMLDataListElement): (WebCore::HTMLDataListElement::didMoveToNewDocument): * html/HTMLDataListElement.h: * html/HTMLFormControlElement.cpp: (WebCore::HTMLFormControlElement::computeWillValidate const): * page/PointerLockController.cpp: (WebCore::PointerLockController::elementWasRemoved): Renamed for consistency. (WebCore::PointerLockController::elementRemoved): Deleted. * page/PointerLockController.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272358 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-03 Simon Fraser Avoid an ancestor walk in HTMLFormControlElement::computeWillValidate() https://bugs.webkit.org/show_bug.cgi?id=221357 Reviewed by Ryosuke Niwa. HTMLFormControlElement::computeWillValidate() does an ancestor DOM walk to look for enclosing data list elements, but these are fairly uncommon so we can avoid this work if we know the Document has none. * dom/Document.h: (WebCore::Document::hasDataListElements const): (WebCore::Document::incrementDataListElementCount): (WebCore::Document::decrementDataListElementCount): * dom/Element.cpp: (WebCore::Element::removedFromAncestor): Avoid fetching the page twice. * html/HTMLDataListElement.cpp: (WebCore::HTMLDataListElement::HTMLDataListElement): (WebCore::HTMLDataListElement::~HTMLDataListElement): (WebCore::HTMLDataListElement::didMoveToNewDocument): * html/HTMLDataListElement.h: * html/HTMLFormControlElement.cpp: (WebCore::HTMLFormControlElement::computeWillValidate const): * page/PointerLockController.cpp: (WebCore::PointerLockController::elementWasRemoved): Renamed for consistency. (WebCore::PointerLockController::elementRemoved): Deleted. * page/PointerLockController.h: 2021-02-23 Alan Coon Cherry-pick r272354. rdar://problem/74622963 Avoid frequent calls to HTMLFormControlElement::updateValidity() when constructing form control elements https://bugs.webkit.org/show_bug.cgi?id=221320 Reviewed by Geoffrey Garen. HTMLFormControlElement::updateValidity() can get called multiple times inside HTMLInputElement::parserDidSetAttributes(), so add a simple delaying scope so that validity is only updated once at the end. * html/HTMLFormControlElement.cpp: (WebCore::HTMLFormControlElement::endDelayingUpdateValidity): (WebCore::HTMLFormControlElement::computeWillValidate const): (WebCore::HTMLFormControlElement::updateValidity): * html/HTMLFormControlElement.h: (WebCore::HTMLFormControlElement::startDelayingUpdateValidity): (WebCore::DelayedUpdateValidityScope::DelayedUpdateValidityScope): (WebCore::DelayedUpdateValidityScope::~DelayedUpdateValidityScope): * html/HTMLInputElement.cpp: (WebCore::HTMLInputElement::parserDidSetAttributes): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272354 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-03 Simon Fraser Avoid frequent calls to HTMLFormControlElement::updateValidity() when constructing form control elements https://bugs.webkit.org/show_bug.cgi?id=221320 Reviewed by Geoffrey Garen. HTMLFormControlElement::updateValidity() can get called multiple times inside HTMLInputElement::parserDidSetAttributes(), so add a simple delaying scope so that validity is only updated once at the end. * html/HTMLFormControlElement.cpp: (WebCore::HTMLFormControlElement::endDelayingUpdateValidity): (WebCore::HTMLFormControlElement::computeWillValidate const): (WebCore::HTMLFormControlElement::updateValidity): * html/HTMLFormControlElement.h: (WebCore::HTMLFormControlElement::startDelayingUpdateValidity): (WebCore::DelayedUpdateValidityScope::DelayedUpdateValidityScope): (WebCore::DelayedUpdateValidityScope::~DelayedUpdateValidityScope): * html/HTMLInputElement.cpp: (WebCore::HTMLInputElement::parserDidSetAttributes): 2021-02-17 Ruben Turcios Cherry-pick r272626. rdar://problem/74410222 Descendants of row and column headers should expose the aria-sort attribute. https://bugs.webkit.org/show_bug.cgi?id=221590 Reviewed by Chris Fleizach. Source/WebCore: Tests: accessibility/aria-sort.html accessibility/ios-simulator/aria-sort-ios.html Walk up the accessibility hierarchy to check for an inherited aria-sort attribute present in a row or column header ancestor. * accessibility/AccessibilityObject.cpp: (WebCore::AccessibilityObject::sortDirection const): LayoutTests: Expanded this test to include the case where the header contains a child element that must also expose the aria-sort attribute inherited from its parent. * accessibility/aria-sort-expected.txt: * accessibility/aria-sort.html: * accessibility/ios-simulator/aria-sort-ios-expected.txt: * accessibility/ios-simulator/aria-sort-ios.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272626 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-09 Andres Gonzalez Descendants of row and column headers should expose the aria-sort attribute. https://bugs.webkit.org/show_bug.cgi?id=221590 Reviewed by Chris Fleizach. Tests: accessibility/aria-sort.html accessibility/ios-simulator/aria-sort-ios.html Walk up the accessibility hierarchy to check for an inherited aria-sort attribute present in a row or column header ancestor. * accessibility/AccessibilityObject.cpp: (WebCore::AccessibilityObject::sortDirection const): 2021-02-17 Ruben Turcios Cherry-pick r272165. rdar://problem/74032536 Use user media permission prompt for speech recognition https://bugs.webkit.org/show_bug.cgi?id=221082 rdar://problem/73372499 Patch by Sihui Liu on 2021-02-01 Reviewed by Youenn Fablet. Source/WebCore: Add frame identifier to SpeechRecognitionRequest as it is needed for checking user media permission. Updated existing tests for changed behavior. * Modules/speech/SpeechRecognition.cpp: (WebCore::SpeechRecognition::startRecognition): * Modules/speech/SpeechRecognitionConnection.h: * Modules/speech/SpeechRecognitionRequest.h: (WebCore::SpeechRecognitionRequest::frameIdentifier const): * Modules/speech/SpeechRecognitionRequestInfo.h: (WebCore::SpeechRecognitionRequestInfo::encode const): (WebCore::SpeechRecognitionRequestInfo::decode): * page/DummySpeechRecognitionProvider.h: Source/WebKit: Make SpeechRecognitionPermissionManager ask UserMediaPermissionRequestManagerProxy for user permission on microphone. * UIProcess/SpeechRecognitionPermissionManager.cpp: (WebKit::SpeechRecognitionPermissionManager::request): (WebKit::SpeechRecognitionPermissionManager::startProcessingRequest): (WebKit::SpeechRecognitionPermissionManager::requestUserPermission): * UIProcess/SpeechRecognitionPermissionManager.h: * UIProcess/SpeechRecognitionPermissionRequest.h: (WebKit::SpeechRecognitionPermissionRequest::create): (WebKit::SpeechRecognitionPermissionRequest::frameIdentifier const): (WebKit::SpeechRecognitionPermissionRequest::SpeechRecognitionPermissionRequest): * UIProcess/SpeechRecognitionServer.cpp: (WebKit::SpeechRecognitionServer::start): (WebKit::SpeechRecognitionServer::requestPermissionForRequest): * UIProcess/SpeechRecognitionServer.h: * UIProcess/SpeechRecognitionServer.messages.in: * UIProcess/UserMediaPermissionRequestManagerProxy.cpp: (WebKit::UserMediaPermissionRequestManagerProxy::denyRequest): (WebKit::UserMediaPermissionRequestManagerProxy::grantRequest): (WebKit::UserMediaPermissionRequestManagerProxy::checkUserMediaPermissionForSpeechRecognition): * UIProcess/UserMediaPermissionRequestManagerProxy.h: * UIProcess/UserMediaPermissionRequestProxy.cpp: (WebKit::UserMediaPermissionRequestProxy::UserMediaPermissionRequestProxy): * UIProcess/UserMediaPermissionRequestProxy.h: (WebKit::UserMediaPermissionRequestProxy::create): (WebKit::UserMediaPermissionRequestProxy::decisionCompletionHandler): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::requestSpeechRecognitionPermission): (WebKit::WebPageProxy::requestUserMediaPermissionForSpeechRecognition): * UIProcess/WebPageProxy.h: * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::createSpeechRecognitionServer): * WebProcess/WebCoreSupport/WebSpeechRecognitionConnection.cpp: (WebKit::WebSpeechRecognitionConnection::start): * WebProcess/WebCoreSupport/WebSpeechRecognitionConnection.h: Tools: * TestWebKitAPI/Tests/WebKitCocoa/SpeechRecognition.mm: (-[SpeechRecognitionUIDelegate _webView:requestMediaCaptureAuthorization:decisionHandler:]): LayoutTests: * fast/speechrecognition/permission-error.html: * fast/speechrecognition/start-recognition-in-removed-iframe-expected.txt: * fast/speechrecognition/start-recognition-in-removed-iframe.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272165 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-01 Sihui Liu Use user media permission prompt for speech recognition https://bugs.webkit.org/show_bug.cgi?id=221082 rdar://problem/73372499 Reviewed by Youenn Fablet. Add frame identifier to SpeechRecognitionRequest as it is needed for checking user media permission. Updated existing tests for changed behavior. * Modules/speech/SpeechRecognition.cpp: (WebCore::SpeechRecognition::startRecognition): * Modules/speech/SpeechRecognitionConnection.h: * Modules/speech/SpeechRecognitionRequest.h: (WebCore::SpeechRecognitionRequest::frameIdentifier const): * Modules/speech/SpeechRecognitionRequestInfo.h: (WebCore::SpeechRecognitionRequestInfo::encode const): (WebCore::SpeechRecognitionRequestInfo::decode): * page/DummySpeechRecognitionProvider.h: 2021-02-17 Ruben Turcios Cherry-pick r271636. rdar://problem/74452635 Update media state for active speech recognition as it uses audio capture https://bugs.webkit.org/show_bug.cgi?id=220667 Patch by Sihui Liu on 2021-01-19 Reviewed by Youenn Fablet. Source/WebCore: To make sure the media capture state is correctly sent to client. API test: WebKit2.SpeechRecognitionMediaCaptureStateChange * Modules/speech/SpeechRecognition.cpp: (WebCore::SpeechRecognition::startRecognition): (WebCore::SpeechRecognition::stop): (WebCore::SpeechRecognition::didStartCapturingAudio): (WebCore::SpeechRecognition::didStopCapturingAudio): * Modules/speech/SpeechRecognition.h: * Modules/speech/SpeechRecognitionConnection.h: * dom/Document.cpp: (WebCore::Document::setActiveSpeechRecognition): (WebCore::Document::updateIsPlayingMedia): * dom/Document.h: * page/DummySpeechRecognitionProvider.h: Source/WebKit: * WebProcess/WebCoreSupport/WebSpeechRecognitionConnection.cpp: (WebKit::WebSpeechRecognitionConnection::unregisterClient): * WebProcess/WebCoreSupport/WebSpeechRecognitionConnection.h: Tools: * TestWebKitAPI/Tests/WebKitCocoa/SpeechRecognition.mm: (-[SpeechRecognitionUIDelegate _webView:mediaCaptureStateDidChange:]): (TestWebKitAPI::TEST): (-[SpeechRecognitionPermissionUIDelegate _webView:requestSpeechRecognitionPermissionForOrigin:decisionHandler:]): Deleted. (-[SpeechRecognitionPermissionUIDelegate _webView:requestMediaCaptureAuthorization:decisionHandler:]): Deleted. (-[SpeechRecognitionPermissionUIDelegate _webView:checkUserMediaPermissionForURL:mainFrameURL:frameIdentifier:decisionHandler:]): Deleted. (-[SpeechRecognitionPermissionUIDelegate webView:createWebViewWithConfiguration:forNavigationAction:windowFeatures:]): Deleted. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271636 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-01-19 Sihui Liu Update media state for active speech recognition as it uses audio capture https://bugs.webkit.org/show_bug.cgi?id=220667 Reviewed by Youenn Fablet. To make sure the media capture state is correctly sent to client. API test: WebKit2.SpeechRecognitionMediaCaptureStateChange * Modules/speech/SpeechRecognition.cpp: (WebCore::SpeechRecognition::startRecognition): (WebCore::SpeechRecognition::stop): (WebCore::SpeechRecognition::didStartCapturingAudio): (WebCore::SpeechRecognition::didStopCapturingAudio): * Modules/speech/SpeechRecognition.h: * Modules/speech/SpeechRecognitionConnection.h: * dom/Document.cpp: (WebCore::Document::setActiveSpeechRecognition): (WebCore::Document::updateIsPlayingMedia): * dom/Document.h: * page/DummySpeechRecognitionProvider.h: 2021-02-17 Ruben Turcios Cherry-pick r272490. rdar://problem/74409784 Add support for aria-sort change notifications. https://bugs.webkit.org/show_bug.cgi?id=221495 Reviewed by Chris Fleizach. Source/WebCore: Test: accessibility/aria-sort-changed-notification.html This patch adds support for aria-sort changes. Some code cleanup by using the notificationPlatformName helper function. * accessibility/AXLogger.cpp: (WebCore::operator<<): Logging of the new notification. * accessibility/AXObjectCache.cpp: Handles the aria-sort change notification. Updates the isolated tree. (WebCore::AXObjectCache::handleAttributeChange): (WebCore::AXObjectCache::updateIsolatedTree): * accessibility/AXObjectCache.h: * accessibility/ios/AXObjectCacheIOS.mm: (WebCore::AXObjectCache::notificationPlatformName): Helper to map AXCore notifications to platform notifications. (WebCore::AXObjectCache::postPlatformNotification): Handles the AXSortDirectionChanged notification. Some code cleanup using the notificationPlatformName helper. * accessibility/ios/WebAccessibilityObjectWrapperIOS.h: * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper postNotification:]): To be overridden by system AX bundles. (-[WebAccessibilityObjectWrapper accessibilitySortDirection]): Only ascending and descending sort directions are relevant for clients. * accessibility/isolatedtree/AXIsolatedTree.cpp: (WebCore::AXIsolatedTree::updateNodeProperty): Updates the SortDirection property. * accessibility/mac/AXObjectCacheMac.mm: (WebCore::AXObjectCache::postPlatformNotification): Handles the AXSortDirectionChanged notification. Tools: * WebKitTestRunner/InjectedBundle/AccessibilityUIElement.cpp: (WTR::AccessibilityUIElement::sortDirection const): * WebKitTestRunner/InjectedBundle/AccessibilityUIElement.h: * WebKitTestRunner/InjectedBundle/Bindings/AccessibilityUIElement.idl: * WebKitTestRunner/InjectedBundle/ios/AccessibilityUIElementIOS.mm: (WTR::AccessibilityUIElement::sortDirection const): * WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm: (WTR::AccessibilityUIElement::currentStateValue const): (WTR::AccessibilityUIElement::sortDirection const): LayoutTests: * accessibility/aria-sort-changed-notification-expected.txt: Added. * accessibility/aria-sort-changed-notification.html: Added. * accessibility/aria-sort-expected.txt: * accessibility/aria-sort.html: Calls sortDirection property on the JS accessible element instead of retrieving the aria-sort attribute. This matches more accurately what an actual client would do. Changed the expected file accordingly. * accessibility/ios-simulator/aria-sort-ios-expected.txt: * accessibility/ios-simulator/aria-sort-ios.html: Same as in the Mac test above. * platform/ios/TestExpectations: Added the new test to be run on the ios-simulator. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272490 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-08 Andres Gonzalez Add support for aria-sort change notifications. https://bugs.webkit.org/show_bug.cgi?id=221495 Reviewed by Chris Fleizach. Test: accessibility/aria-sort-changed-notification.html This patch adds support for aria-sort changes. Some code cleanup by using the notificationPlatformName helper function. * accessibility/AXLogger.cpp: (WebCore::operator<<): Logging of the new notification. * accessibility/AXObjectCache.cpp: Handles the aria-sort change notification. Updates the isolated tree. (WebCore::AXObjectCache::handleAttributeChange): (WebCore::AXObjectCache::updateIsolatedTree): * accessibility/AXObjectCache.h: * accessibility/ios/AXObjectCacheIOS.mm: (WebCore::AXObjectCache::notificationPlatformName): Helper to map AXCore notifications to platform notifications. (WebCore::AXObjectCache::postPlatformNotification): Handles the AXSortDirectionChanged notification. Some code cleanup using the notificationPlatformName helper. * accessibility/ios/WebAccessibilityObjectWrapperIOS.h: * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper postNotification:]): To be overridden by system AX bundles. (-[WebAccessibilityObjectWrapper accessibilitySortDirection]): Only ascending and descending sort directions are relevant for clients. * accessibility/isolatedtree/AXIsolatedTree.cpp: (WebCore::AXIsolatedTree::updateNodeProperty): Updates the SortDirection property. * accessibility/mac/AXObjectCacheMac.mm: (WebCore::AXObjectCache::postPlatformNotification): Handles the AXSortDirectionChanged notification. 2021-02-17 Ruben Turcios Cherry-pick r272067. rdar://problem/74444347 Support for aria-current state changed notifications. https://bugs.webkit.org/show_bug.cgi?id=221074 Reviewed by Chris Fleizach. Source/WebCore: Test: accessibility/aria-current-state-changed-notification.html Added handling of the AXCurrentStateChanged notification for Mac and iOS ports. This notification is fired when the aria-current attribute changes. Handling of this notification is required to properly update the accessibility properties of the target object and convey them to assistive technology clients. * accessibility/AXLogger.cpp: (WebCore::operator<<): Renamed notification anumerand. * accessibility/AXObjectCache.cpp: (WebCore::AXObjectCache::handleAttributeChange): * accessibility/AXObjectCache.h: * accessibility/atk/AXObjectCacheAtk.cpp: (WebCore::AXObjectCache::postPlatformNotification): * accessibility/ios/AXObjectCacheIOS.mm: (WebCore::AXObjectCache::postPlatformNotification): * accessibility/ios/WebAccessibilityObjectWrapperIOS.h: * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper accessibilityDOMIdentifier]): (-[WebAccessibilityObjectWrapper postCurrentStateChangedNotification]): (-[WebAccessibilityObjectWrapper accessibilityCurrentState]): (-[WebAccessibilityObjectWrapper accessibilityARIACurrentStatus]): Renamed to accessibilityCurrentState. * accessibility/mac/AXObjectCacheMac.mm: (WebCore::AXObjectCache::postPlatformNotification): Tools: Added AccessibilityUIElement::domIdentifier and currentStateValue used in LayoutTests/accessibility/aria-current-state-changed-notification.html. * WebKitTestRunner/InjectedBundle/AccessibilityUIElement.cpp: (WTR::AccessibilityUIElement::domIdentifier const): Non-Cocoa implementation. (WTR::AccessibilityUIElement::currentStateValue const): Non-Cocoa implementation. * WebKitTestRunner/InjectedBundle/AccessibilityUIElement.h: * WebKitTestRunner/InjectedBundle/Bindings/AccessibilityUIElement.idl: * WebKitTestRunner/InjectedBundle/ios/AccessibilityUIElementIOS.mm: (WTR::AccessibilityUIElement::domIdentifier const): (WTR::AccessibilityUIElement::stringAttributeValue): (WTR::AccessibilityUIElement::currentStateValue const): * WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm: (WTR::AccessibilityUIElement::domIdentifier const): (WTR::AccessibilityUIElement::currentStateValue const): LayoutTests: * accessibility/aria-current-state-changed-notification-expected.txt: Added. * accessibility/aria-current-state-changed-notification.html: Added. * accessibility/aria-current.html: Use AccessibilityUIElement::currentStateValue for consistency and to match closely how actual clients will invoke this functionality. * platform/gtk/TestExpectations: * platform/ios-wk1/TestExpectations: * platform/ios/TestExpectations: * platform/mac-wk1/TestExpectations: * platform/win/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272067 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-01-29 Andres Gonzalez Support for aria-current state changed notifications. https://bugs.webkit.org/show_bug.cgi?id=221074 Reviewed by Chris Fleizach. Test: accessibility/aria-current-state-changed-notification.html Added handling of the AXCurrentStateChanged notification for Mac and iOS ports. This notification is fired when the aria-current attribute changes. Handling of this notification is required to properly update the accessibility properties of the target object and convey them to assistive technology clients. * accessibility/AXLogger.cpp: (WebCore::operator<<): Renamed notification anumerand. * accessibility/AXObjectCache.cpp: (WebCore::AXObjectCache::handleAttributeChange): * accessibility/AXObjectCache.h: * accessibility/atk/AXObjectCacheAtk.cpp: (WebCore::AXObjectCache::postPlatformNotification): * accessibility/ios/AXObjectCacheIOS.mm: (WebCore::AXObjectCache::postPlatformNotification): * accessibility/ios/WebAccessibilityObjectWrapperIOS.h: * accessibility/ios/WebAccessibilityObjectWrapperIOS.mm: (-[WebAccessibilityObjectWrapper accessibilityDOMIdentifier]): (-[WebAccessibilityObjectWrapper postCurrentStateChangedNotification]): (-[WebAccessibilityObjectWrapper accessibilityCurrentState]): (-[WebAccessibilityObjectWrapper accessibilityARIACurrentStatus]): Renamed to accessibilityCurrentState. * accessibility/mac/AXObjectCacheMac.mm: (WebCore::AXObjectCache::postPlatformNotification): 2021-02-17 Ruben Turcios Cherry-pick r272755. rdar://problem/74409916 Unreviewed, reverting r270578. https://bugs.webkit.org/show_bug.cgi?id=221110 Caused incorrect image layout inside a flexbox container. LayoutTests/imported/w3c: * web-platform-tests/css/css-flexbox/flex-aspect-ratio-img-row-013-expected.txt: * web-platform-tests/css/css-flexbox/image-as-flexitem-size-003-expected.txt: * web-platform-tests/css/css-flexbox/image-as-flexitem-size-003v-expected.txt: * web-platform-tests/css/css-flexbox/image-as-flexitem-size-004-expected.txt: * web-platform-tests/css/css-flexbox/image-as-flexitem-size-004v-expected.txt: Source/WebCore: * rendering/RenderFlexibleBox.cpp: (WebCore::RenderFlexibleBox::computeMainSizeFromAspectRatioUsing const): (WebCore::RenderFlexibleBox::childCrossSizeIsDefinite const): LayoutTests: * TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272755 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-11 Said Abou-Hallawa Unreviewed, reverting r270578. https://bugs.webkit.org/show_bug.cgi?id=221110 Caused incorrect image layout inside a flexbox container. * rendering/RenderFlexibleBox.cpp: (WebCore::RenderFlexibleBox::computeMainSizeFromAspectRatioUsing const): (WebCore::RenderFlexibleBox::childCrossSizeIsDefinite const): 2021-02-23 Alan Coon Cherry-pick r272678. rdar://problem/74410058 WebCore::createBusFromInMemoryAudioFile() may crash under ExtAudioFileRead() https://bugs.webkit.org/show_bug.cgi?id=221642 Reviewed by Geoffrey Garen. The crash seems to indicate we are passing an AudioBufferList to ExtAudioFileRead() that contains a null buffer. It is not obvious how this is happening but I have made the following changes: 1. createAudioBufferList() / destroyAudioListBuffer() implementation is now shared on both macOS and iOS. The implementation now uses fastCalloc and returns null in case of failure to allocate. 2. createAudioBufferList() was renamed to tryCreateAudioBufferList() to make it clear it can return null. All call sites now properly deal with tryCreateAudioBufferList() potentially return null 3. Add a new validateAudioBufferList() function which makes sure that the AudioBufferList we are about to pass to ExtAudioFileRead() does not contain any null buffer. In case of validation failure, we log an error, generate a simulated crash log and early return gracefully instead of crashing later on. 4. Added more assertions to help catch bugs. * SourcesCocoa.txt: * WebCore.xcodeproj/project.pbxproj: * platform/audio/cocoa/AudioFileReaderCocoa.cpp: Added. (WebCore::tryCreateAudioBufferList): (WebCore::destroyAudioBufferList): (WebCore::validateAudioBufferList): * platform/audio/cocoa/AudioFileReaderCocoa.h: Added. * platform/audio/ios/AudioFileReaderIOS.cpp: (WebCore::AudioFileReader::createBus): (WebCore::createAudioBufferList): Deleted. (WebCore::destroyAudioBufferList): Deleted. * platform/audio/mac/AudioFileReaderMac.cpp: (WebCore::AudioFileReader::createBus): (WebCore::createAudioBufferList): Deleted. (WebCore::destroyAudioBufferList): Deleted. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272678 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-10 Chris Dumez WebCore::createBusFromInMemoryAudioFile() may crash under ExtAudioFileRead() https://bugs.webkit.org/show_bug.cgi?id=221642 Reviewed by Geoffrey Garen. The crash seems to indicate we are passing an AudioBufferList to ExtAudioFileRead() that contains a null buffer. It is not obvious how this is happening but I have made the following changes: 1. createAudioBufferList() / destroyAudioListBuffer() implementation is now shared on both macOS and iOS. The implementation now uses fastCalloc and returns null in case of failure to allocate. 2. createAudioBufferList() was renamed to tryCreateAudioBufferList() to make it clear it can return null. All call sites now properly deal with tryCreateAudioBufferList() potentially return null 3. Add a new validateAudioBufferList() function which makes sure that the AudioBufferList we are about to pass to ExtAudioFileRead() does not contain any null buffer. In case of validation failure, we log an error, generate a simulated crash log and early return gracefully instead of crashing later on. 4. Added more assertions to help catch bugs. * SourcesCocoa.txt: * WebCore.xcodeproj/project.pbxproj: * platform/audio/cocoa/AudioFileReaderCocoa.cpp: Added. (WebCore::tryCreateAudioBufferList): (WebCore::destroyAudioBufferList): (WebCore::validateAudioBufferList): * platform/audio/cocoa/AudioFileReaderCocoa.h: Added. * platform/audio/ios/AudioFileReaderIOS.cpp: (WebCore::AudioFileReader::createBus): (WebCore::createAudioBufferList): Deleted. (WebCore::destroyAudioBufferList): Deleted. * platform/audio/mac/AudioFileReaderMac.cpp: (WebCore::AudioFileReader::createBus): (WebCore::createAudioBufferList): Deleted. (WebCore::destroyAudioBufferList): Deleted. 2021-02-17 Ruben Turcios Cherry-pick r272504. rdar://problem/74409474 NetworkRTCSocketCocoa extractDataMessages should not read too much data https://bugs.webkit.org/show_bug.cgi?id=221544 Reviewed by Eric Carlson. Source/WebCore: Move STUN/TURN message parsing to its own file routine so that we can add API test. Code is taken from Source/WebKit/NetworkProcess/webrtc/NetworkRTCSocketCocoa.mm. Fix the test verifying we can actually read a message given its expected length. Covered by API test. * Headers.cmake: * Modules/mediastream/STUNMessageParsing.cpp: Added. (WebCore::isStunMessage): (WebCore::getSTUNOrTURNMessageLengths): (WebCore::extractSTUNOrTURNMessages): (WebCore::extractDataMessages): (WebCore::extractMessages): * Modules/mediastream/STUNMessageParsing.h: Added. * Sources.txt: * WebCore.xcodeproj/project.pbxproj: Source/WebKit: * NetworkProcess/webrtc/NetworkRTCSocketCocoa.mm: Make use of WebCore method. Tools: * TestWebKitAPI/Tests/WebCore/STUNMessageParsingTest.cpp: Added. (TestWebKitAPI::TEST): * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272504 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-08 Youenn Fablet NetworkRTCSocketCocoa extractDataMessages should not read too much data https://bugs.webkit.org/show_bug.cgi?id=221544 Reviewed by Eric Carlson. Move STUN/TURN message parsing to its own file routine so that we can add API test. Code is taken from Source/WebKit/NetworkProcess/webrtc/NetworkRTCSocketCocoa.mm. Fix the test verifying we can actually read a message given its expected length. Covered by API test. * Headers.cmake: * Modules/mediastream/STUNMessageParsing.cpp: Added. (WebCore::isStunMessage): (WebCore::getSTUNOrTURNMessageLengths): (WebCore::extractSTUNOrTURNMessages): (WebCore::extractDataMessages): (WebCore::extractMessages): * Modules/mediastream/STUNMessageParsing.h: Added. * Sources.txt: * WebCore.xcodeproj/project.pbxproj: 2021-02-19 Alan Coon Cherry-pick r273069. rdar://problem/74500798 Backgrounding a page that is playing and capturing audio will stop audio playing https://bugs.webkit.org/show_bug.cgi?id=222032 Reviewed by Eric Carlson. When a page gets backgrounded while capturing, it will continue doing capture, as can be seen with the red status bar. In that case, for video conferencing, it makes sense that audio being played continues playing, at least for MediaStreamTrack. The red status bar is an indication that the call is continuing. Also, for MediaStreamTrack, audio and video content are not buffered: they are played or discarded. The media player, whenever not visible, will stop processing video but will continue processing audio if not interrupted. This makes it working for websites using video elements for both audio and video, which is more common than websites using video elements for video and audio elements for audio. Manually tested. * html/HTMLMediaElement.cpp: (WebCore::HTMLMediaElement::shouldOverrideBackgroundPlaybackRestriction const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273069 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-18 Youenn Fablet Backgrounding a page that is playing and capturing audio will stop audio playing https://bugs.webkit.org/show_bug.cgi?id=222032 Reviewed by Eric Carlson. When a page gets backgrounded while capturing, it will continue doing capture, as can be seen with the red status bar. In that case, for video conferencing, it makes sense that audio being played continues playing, at least for MediaStreamTrack. The red status bar is an indication that the call is continuing. Also, for MediaStreamTrack, audio and video content are not buffered: they are played or discarded. The media player, whenever not visible, will stop processing video but will continue processing audio if not interrupted. This makes it working for websites using video elements for both audio and video, which is more common than websites using video elements for video and audio elements for audio. Manually tested. * html/HTMLMediaElement.cpp: (WebCore::HTMLMediaElement::shouldOverrideBackgroundPlaybackRestriction const): 2021-02-19 Alan Coon Cherry-pick r273003. rdar://problem/74500696 Animated keyframe style needs to go through full style adjuster https://bugs.webkit.org/show_bug.cgi?id=222036 rdar://72421747 Reviewed by Zalan Bujtas. Source/WebCore: We can create unadjusted styles via keyframe animations and those may cause problems in rendering. Test: fast/animation/animation-position-crash.html * style/StyleAdjuster.cpp: (WebCore::Style::Adjuster::adjustAnimatedStyle): Make this a member function and invoke Adjuster::adjust. Simplify the z-index adjustment since it is mostly handled by adjust. * style/StyleAdjuster.h: * style/StyleTreeResolver.cpp: Always use style adjuster for keyframe animation. (WebCore::Style::TreeResolver::createAnimatedElementUpdate): LayoutTests: * fast/animation/animation-position-crash-expected.html: Added. * fast/animation/animation-position-crash.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@273003 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-17 Antti Koivisto Animated keyframe style needs to go through full style adjuster https://bugs.webkit.org/show_bug.cgi?id=222036 rdar://72421747 Reviewed by Zalan Bujtas. We can create unadjusted styles via keyframe animations and those may cause problems in rendering. Test: fast/animation/animation-position-crash.html * style/StyleAdjuster.cpp: (WebCore::Style::Adjuster::adjustAnimatedStyle): Make this a member function and invoke Adjuster::adjust. Simplify the z-index adjustment since it is mostly handled by adjust. * style/StyleAdjuster.h: * style/StyleTreeResolver.cpp: Always use style adjuster for keyframe animation. (WebCore::Style::TreeResolver::createAnimatedElementUpdate): 2021-02-19 Alan Coon Cherry-pick r272931. rdar://problem/74500616 RenderElement::containingBlockForAbsolutePosition may call RenderObject::containingBlock recursively https://bugs.webkit.org/show_bug.cgi?id=221976 Reviewed by Simon Fraser. When a RenderInline happens to be absolute positioned (this is a highly incorrect state, see webkit.org/b/221994), containingBlockForAbsolutePosition() calls containingBlock() with |this| and in return containingBlock() calls back on containingBlockForAbsolutePosition() with the same renderer. This patch ensures that we always call containingBlock() from containingBlockForAbsolutePosition() with an ancestor -mostly with the parent(). * rendering/RenderElement.cpp: (WebCore::RenderElement::containingBlockForAbsolutePosition const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272931 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-16 Zalan Bujtas RenderElement::containingBlockForAbsolutePosition may call RenderObject::containingBlock recursively https://bugs.webkit.org/show_bug.cgi?id=221976 Reviewed by Simon Fraser. When a RenderInline happens to be absolute positioned (this is a highly incorrect state, see webkit.org/b/221994), containingBlockForAbsolutePosition() calls containingBlock() with |this| and in return containingBlock() calls back on containingBlockForAbsolutePosition() with the same renderer. This patch ensures that we always call containingBlock() from containingBlockForAbsolutePosition() with an ancestor -mostly with the parent(). * rendering/RenderElement.cpp: (WebCore::RenderElement::containingBlockForAbsolutePosition const): 2021-02-19 Alan Coon Cherry-pick r272927. rdar://problem/74500651 REGRESSION(r271515): ::marker fired at wrong time https://bugs.webkit.org/show_bug.cgi?id=221961 Reviewed by Dean Jackson. Source/WebCore: Restore the order in which we generate CSS Animations for pseudo-elements as it was prior to r271515. * style/StyleTreeResolver.cpp: (WebCore::Style::TreeResolver::resolveElement): LayoutTests: Remove flakiness for this test since it didn't allow us to spot the regression introduced by r271515. * TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272927 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-16 Antoine Quint REGRESSION(r271515): ::marker fired at wrong time https://bugs.webkit.org/show_bug.cgi?id=221961 Reviewed by Dean Jackson. Restore the order in which we generate CSS Animations for pseudo-elements as it was prior to r271515. * style/StyleTreeResolver.cpp: (WebCore::Style::TreeResolver::resolveElement): 2021-02-19 Alan Coon Cherry-pick r272913. rdar://problem/74500965 AVAudioSessionCaptureDeviceManager should disable its audio session in a background thread https://bugs.webkit.org/show_bug.cgi?id=221949 Reviewed by Eric Carlson. Manually tested. * platform/mediastream/ios/AVAudioSessionCaptureDeviceManager.mm: (WebCore::AVAudioSessionCaptureDeviceManager::disableAllDevicesQuery): Hop to a background thread before disabling the audio session. Abort if audio session is no longer marked as unneeded. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272913 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-16 Youenn Fablet AVAudioSessionCaptureDeviceManager should disable its audio session in a background thread https://bugs.webkit.org/show_bug.cgi?id=221949 Reviewed by Eric Carlson. Manually tested. * platform/mediastream/ios/AVAudioSessionCaptureDeviceManager.mm: (WebCore::AVAudioSessionCaptureDeviceManager::disableAllDevicesQuery): Hop to a background thread before disabling the audio session. Abort if audio session is no longer marked as unneeded. 2021-02-19 Alan Coon Cherry-pick r272379. rdar://problem/74500599 Supplementary code points (U+10000 - U+10FFFF) are not shaped correctly in the fast text codepath https://bugs.webkit.org/show_bug.cgi?id=221356 Reviewed by Zalan Bujtas. Source/WebCore: Supplementary code points are represented in UTF-16 as two adjacent (surrogate) code units. When we map code points to glyphs, we were originally mapping these two code units to a single glyph. However, shaping routines require that the number of code units and glyphs be equal, by injecting a 0 glyph for the trailing surrogate. Luckily, we don't actually have to delete these extra 0 glyphs, because the shaping engine will do that for us. Test: fast/text/multi-code-unit-simple-path.html * platform/graphics/WidthIterator.cpp: (WebCore::WidthIterator::advanceInternal): LayoutTests: * fast/text/multi-code-unit-simple-path-expected-mismatch.html: Added. * fast/text/multi-code-unit-simple-path.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272379 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-04 Myles C. Maxfield Supplementary code points (U+10000 - U+10FFFF) are not shaped correctly in the fast text codepath https://bugs.webkit.org/show_bug.cgi?id=221356 Reviewed by Zalan Bujtas. Supplementary code points are represented in UTF-16 as two adjacent (surrogate) code units. When we map code points to glyphs, we were originally mapping these two code units to a single glyph. However, shaping routines require that the number of code units and glyphs be equal, by injecting a 0 glyph for the trailing surrogate. Luckily, we don't actually have to delete these extra 0 glyphs, because the shaping engine will do that for us. Test: fast/text/multi-code-unit-simple-path.html * platform/graphics/WidthIterator.cpp: (WebCore::WidthIterator::advanceInternal): 2021-02-17 Alan Coon Cherry-pick r272345. rdar://problem/74195248 [WebAuthn] Allow one user gesture free prompt for each navigation https://bugs.webkit.org/show_bug.cgi?id=220897 Reviewed by Brent Fulgham. Source/WebCore: * Modules/webauthn/AuthenticatorCoordinator.cpp: (WebCore::AuthenticatorCoordinator::resetUserGestureRequirement): * Modules/webauthn/AuthenticatorCoordinator.h: * Modules/webauthn/AuthenticatorCoordinatorClient.h: * page/Quirks.cpp: * page/Quirks.cpp.h: * replay/UserInputBridge.cpp: (WebCore::UserInputBridge::loadRequest): (WebCore::UserInputBridge::reloadFrame): Adds the ability to reset the user gesture requirement flag for user initiated reloads and quirks. Source/WebKit: This is a quirk that only allows certain websites. Covered by existing tests. * UIProcess/WebAuthentication/AuthenticatorManager.cpp: (WebKit::AuthenticatorManager::filterTransports const): (WebKit::AuthenticatorManager::runPanel): (WebKit::AuthenticatorManager::runPresenter): Cancel the whole WebAuthn operation if no user gesture is indicated. * WebProcess/WebAuthentication/WebAuthenticatorCoordinator.cpp: (WebKit::WebAuthenticatorCoordinator::makeCredential): (WebKit::WebAuthenticatorCoordinator::getAssertion): * WebProcess/WebAuthentication/WebAuthenticatorCoordinator.h: Set a boolean to indicate a free coupon for each navigation. Tools: * TestWebKitAPI/Tests/WebKitCocoa/_WKWebAuthenticationPanel.mm: (TestWebKitAPI::TEST): LayoutTests: * http/wpt/webauthn/ctap-hid-failure.https-expected.txt: * http/wpt/webauthn/ctap-hid-success.https-expected.txt: * http/wpt/webauthn/ctap-nfc-failure.https-expected.txt: * http/wpt/webauthn/idl.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-hid-silent.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-hid.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-local-silent.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-local.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-nfc.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-u2f-silent.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-u2f.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-success-hid.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-success-local.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-success-nfc.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-success-u2f.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-hid-silent.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-hid.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-local-silent.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-local.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-nfc.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-u2f-silent.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-u2f.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-success-hid.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-success-local.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-success-nfc.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-success-u2f.https-expected.txt: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272345 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-03 Jiewen Tan [WebAuthn] Allow one user gesture free prompt for each navigation https://bugs.webkit.org/show_bug.cgi?id=220897 Reviewed by Brent Fulgham. * Modules/webauthn/AuthenticatorCoordinator.cpp: (WebCore::AuthenticatorCoordinator::resetUserGestureRequirement): * Modules/webauthn/AuthenticatorCoordinator.h: * Modules/webauthn/AuthenticatorCoordinatorClient.h: * page/Quirks.cpp: * page/Quirks.cpp.h: * replay/UserInputBridge.cpp: (WebCore::UserInputBridge::loadRequest): (WebCore::UserInputBridge::reloadFrame): Adds the ability to reset the user gesture requirement flag for user initiated reloads and quirks. 2021-02-16 Ruben Turcios Cherry-pick r272880. rdar://problem/74409363 Crash under WorkerThreadableLoader::MainThreadBridge::notifyIsDone() https://bugs.webkit.org/show_bug.cgi?id=221906 Reviewed by Alex Christensen. * loader/DocumentThreadableLoader.cpp: (WebCore::DocumentThreadableLoader::computeIsDone): r267227 added this function and this was the first case where the DocumentThreadableLoader would do an async operation and ref itself during the operation. I believe this was the source of the crash as this could cause DocumentThreadableLoader to outlive its client. When DocumentThreadableLoader::notifyIsDone() would get called later on, m_client may be bad. To maintain pre-r267227 behavior, we now capture a WeakPtr to |this| instead of a Ref<>, so that we don't unnecessarily extend the lifetime of the DocumentThreadableLoader. * loader/DocumentThreadableLoader.h: (WebCore::DocumentThreadableLoader::clearClient): Add new clearClient() function to DocumentThreadableLoader so that the client can clear the raw pointer the DocumentThreadableLoader holds to it before getting destroyed. I wanted to use WeakPtr but this did not work out due to multithreading. * loader/WorkerThreadableLoader.cpp: (WebCore::WorkerThreadableLoader::MainThreadBridge::destroy): Before destroying itself, WorkerThreadableLoader::MainThreadBridge now clears the raw pointer to it that DocumentThreadableLoader holds. This is important since DocumentThreadableLoader is RefCounted and its lifetime may get extended past the MainThreadBridge. * loader/WorkerThreadableLoader.h: Use tighter typing for clarity. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272880 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-15 Chris Dumez Crash under WorkerThreadableLoader::MainThreadBridge::notifyIsDone() https://bugs.webkit.org/show_bug.cgi?id=221906 Reviewed by Alex Christensen. * loader/DocumentThreadableLoader.cpp: (WebCore::DocumentThreadableLoader::computeIsDone): r267227 added this function and this was the first case where the DocumentThreadableLoader would do an async operation and ref itself during the operation. I believe this was the source of the crash as this could cause DocumentThreadableLoader to outlive its client. When DocumentThreadableLoader::notifyIsDone() would get called later on, m_client may be bad. To maintain pre-r267227 behavior, we now capture a WeakPtr to |this| instead of a Ref<>, so that we don't unnecessarily extend the lifetime of the DocumentThreadableLoader. * loader/DocumentThreadableLoader.h: (WebCore::DocumentThreadableLoader::clearClient): Add new clearClient() function to DocumentThreadableLoader so that the client can clear the raw pointer the DocumentThreadableLoader holds to it before getting destroyed. I wanted to use WeakPtr but this did not work out due to multithreading. * loader/WorkerThreadableLoader.cpp: (WebCore::WorkerThreadableLoader::MainThreadBridge::destroy): Before destroying itself, WorkerThreadableLoader::MainThreadBridge now clears the raw pointer to it that DocumentThreadableLoader holds. This is important since DocumentThreadableLoader is RefCounted and its lifetime may get extended past the MainThreadBridge. * loader/WorkerThreadableLoader.h: Use tighter typing for clarity. 2021-02-16 Ruben Turcios Cherry-pick r272856. rdar://problem/74410114 [LFC][IFC] Do not re-measure wrapped content https://bugs.webkit.org/show_bug.cgi?id=221874 Reviewed by Antti Koivisto. This patch addresses the performance issue with extremely long content when the content gets re-measured many time while performing line breaking. When a certain text content does not fit the line we can 1. keep it on the current line and let it overflow or 2. wrap the entire content to the next line or 3. split it somewhere in the middle. In case of 2 and 3 this overflowing content turns into the leading content on the subsequent line. Now due to ligature (#3) and position dependent glyph sizing(#2) we need to remeasure this leading content again. However with unreasonably long content and relatively small horizontal constraint, this could lead to repeated, continuous text measuring. In this patch we turn the overflow width into the leading width so that we measure the long text content only once. (FIXME: This should be turned into a generic "use the overflow content as-is when turning it into leading content") * layout/inlineformatting/InlineFormattingContext.cpp: (WebCore::Layout::InlineFormattingContext::lineLayout): * layout/inlineformatting/InlineLineBuilder.cpp: (WebCore::Layout::LineBuilder::layoutInlineContent): (WebCore::Layout::LineBuilder::computedIntrinsicWidth): (WebCore::Layout::LineBuilder::placeInlineContent): (WebCore::Layout::LineBuilder::candidateContentForLine): (WebCore::Layout::LineBuilder::handleInlineContent): * layout/inlineformatting/InlineLineBuilder.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272856 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-15 Zalan Bujtas [LFC][IFC] Do not re-measure wrapped content https://bugs.webkit.org/show_bug.cgi?id=221874 Reviewed by Antti Koivisto. This patch addresses the performance issue with extremely long content when the content gets re-measured many time while performing line breaking. When a certain text content does not fit the line we can 1. keep it on the current line and let it overflow or 2. wrap the entire content to the next line or 3. split it somewhere in the middle. In case of 2 and 3 this overflowing content turns into the leading content on the subsequent line. Now due to ligature (#3) and position dependent glyph sizing(#2) we need to remeasure this leading content again. However with unreasonably long content and relatively small horizontal constraint, this could lead to repeated, continuous text measuring. In this patch we turn the overflow width into the leading width so that we measure the long text content only once. (FIXME: This should be turned into a generic "use the overflow content as-is when turning it into leading content") * layout/inlineformatting/InlineFormattingContext.cpp: (WebCore::Layout::InlineFormattingContext::lineLayout): * layout/inlineformatting/InlineLineBuilder.cpp: (WebCore::Layout::LineBuilder::layoutInlineContent): (WebCore::Layout::LineBuilder::computedIntrinsicWidth): (WebCore::Layout::LineBuilder::placeInlineContent): (WebCore::Layout::LineBuilder::candidateContentForLine): (WebCore::Layout::LineBuilder::handleInlineContent): * layout/inlineformatting/InlineLineBuilder.h: 2021-02-16 Ruben Turcios Cherry-pick r272841. rdar://problem/74409856 [iOS] MobileSafari crashes at WebCore: WebCore::VideoFullscreenInterfaceAVKit::doEnterFullscreen https://bugs.webkit.org/show_bug.cgi?id=221863 Patch by Jean-Yves Avenard on 2021-02-14 Reviewed by Darin Adler. On iPad, it's possible for AVKit to fail due to racing requests to exit full screen and enter full screen. The enterFullscreenHandler would attempt to immediately re-enter full screen. For now we bail-out early to avoid the crash. In a follow-up patch we will ensure that the condition to enter fullscreen while there's a pending operation to exit fullscreen can't occur. No new tests, can't reproduce. Analysis has been entirely theoretical. * platform/ios/VideoFullscreenInterfaceAVKit.mm: (VideoFullscreenInterfaceAVKit::enterFullscreenHandler): Exit early if error returned. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272841 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-14 Jean-Yves Avenard [iOS] MobileSafari crashes at WebCore: WebCore::VideoFullscreenInterfaceAVKit::doEnterFullscreen https://bugs.webkit.org/show_bug.cgi?id=221863 Reviewed by Darin Adler. On iPad, it's possible for AVKit to fail due to racing requests to exit full screen and enter full screen. The enterFullscreenHandler would attempt to immediately re-enter full screen. For now we bail-out early to avoid the crash. In a follow-up patch we will ensure that the condition to enter fullscreen while there's a pending operation to exit fullscreen can't occur. No new tests, can't reproduce. Analysis has been entirely theoretical. * platform/ios/VideoFullscreenInterfaceAVKit.mm: (VideoFullscreenInterfaceAVKit::enterFullscreenHandler): Exit early if error returned. 2021-02-16 Ruben Turcios Cherry-pick r272829. rdar://problem/74409245 [Mac] Sound does not play on YouTube after switching back to foreground https://bugs.webkit.org/show_bug.cgi?id=221858 Reviewed by Eric Carlson. Source/WebCore: Test: platform/mac/media/unmute-after-loading.html Remove a stray, unnecessary reset of a cached muted state which kept mute state from being changed the first time after loading. * platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm: (WebCore::MediaPlayerPrivateAVFoundationObjC::createAVPlayer): * testing/Internals.cpp: (WebCore::Internals::privatePlayerMuted): * testing/Internals.h: * testing/Internals.idl: * testing/Internals.mm: (WebCore::Internals::privatePlayerMuted): LayoutTests: * platform/mac/media/unmute-after-loading-expected.txt: Added. * platform/mac/media/unmute-after-loading.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272829 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-12 Jer Noble [Mac] Sound does not play on YouTube after switching back to foreground https://bugs.webkit.org/show_bug.cgi?id=221858 Reviewed by Eric Carlson. Test: platform/mac/media/unmute-after-loading.html Remove a stray, unnecessary reset of a cached muted state which kept mute state from being changed the first time after loading. * platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm: (WebCore::MediaPlayerPrivateAVFoundationObjC::createAVPlayer): * testing/Internals.cpp: (WebCore::Internals::privatePlayerMuted): * testing/Internals.h: * testing/Internals.idl: * testing/Internals.mm: (WebCore::Internals::privatePlayerMuted): 2021-02-16 Ruben Turcios Cherry-pick r272777. rdar://problem/74410399 Nullopt crash in DOMSelection::getRangeAt https://bugs.webkit.org/show_bug.cgi?id=221786 Reviewed by Darin Adler. No new tests since we don't have any way to reproduce this crash. * page/DOMSelection.cpp: (WebCore::DOMSelection::getRangeAt): Added a nullopt check with an assertion. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272777 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-12 Ryosuke Niwa Nullopt crash in DOMSelection::getRangeAt https://bugs.webkit.org/show_bug.cgi?id=221786 Reviewed by Darin Adler. No new tests since we don't have any way to reproduce this crash. * page/DOMSelection.cpp: (WebCore::DOMSelection::getRangeAt): Added a nullopt check with an assertion. 2021-02-16 Ruben Turcios Cherry-pick r272703. rdar://problem/74409698 Reduce the overhead of DocumentFragment in innerHTML & outerHTML https://bugs.webkit.org/show_bug.cgi?id=221535 Reviewed by Geoffrey Garen. Source/WebCore: This patch reduces the overhead of using DocumentFragment in innerHTMl and outerHTML setters by 1. Cache DocumentFragment used for innerHTML and outerHTML. 2. Adding a fast path to removeAllChildrenWithScriptAssertion when removing child nodes from (1) immediately before appending it to the new parent. This is safe for now since no DOM nodes or API store information about its root node or parent node when it's DocumentFragment, and and there are no node flags to be updated or invalidated since we're removing already-disconnected nodes to which no script ever had access up until this point. We release-assert these conditions before going into the fast path. No new tests since there should be no observable behavior change. * dom/ContainerNode.cpp: (WebCore::ContainerNode::removeAllChildrenWithScriptAssertion): Added a fast path. See above. * dom/Document.cpp: (WebCore::Document::commonTeardown): Clear m_documentFragmentForInnerOuterHTML as it would keep the ownewr document (this Document) alive otherwise. (WebCore::Document::documentFragmentForInnerOuterHTML): Added. Lazily create a DocumentFragment used to parse the fragment for innerHTML and outerHTML setters. Remove any child nodes left in the document fragment in the case the last call to replaceChildrenWithFragment took a fast path for a single text node, which case we don't remove any child nodes from DocumentFragment. * dom/Document.h: * dom/DocumentFragment.h: (WebCore::DocumentFragment::setIsDocumentFragmentForInnerOuterHTML): Added. * dom/Node.h: (WebCore::Node::isDocumentFragmentForInnerOuterHTML const): Added. * editing/markup.cpp: (WebCore::createFragmentForMarkup): Extracted from createFragmentForInnerOuterHTML to share code between createFragmentForInnerOuterHTML and createContextualFragment. (WebCore::createFragmentForInnerOuterHTML): Reuse the fragment in createFragmentForMarkup. (WebCore::createContextualFragment): Don't reuse the fragment in createFragmentForMarkup as this function is used by Range::createContextualFragment which exposes the document fragment to arbitrary author scripts. (WebCore::hasOneChild): Deleted since we now have Node::hasOneChild. (WebCore::hasOneTextChild): Use Node::hasOneChild. (WebCore::replaceChildrenWithFragment): Added assertions to make sure we don't have any child nodes left after replacing the children. Source/WTF: Added a helper function for writing assertions. * wtf/WeakPtr.h: (WTF::WeakPtrFactory::isInitialized const): Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272703 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-10 Ryosuke Niwa Reduce the overhead of DocumentFragment in innerHTML & outerHTML https://bugs.webkit.org/show_bug.cgi?id=221535 Reviewed by Geoffrey Garen. This patch reduces the overhead of using DocumentFragment in innerHTMl and outerHTML setters by 1. Cache DocumentFragment used for innerHTML and outerHTML. 2. Adding a fast path to removeAllChildrenWithScriptAssertion when removing child nodes from (1) immediately before appending it to the new parent. This is safe for now since no DOM nodes or API store information about its root node or parent node when it's DocumentFragment, and and there are no node flags to be updated or invalidated since we're removing already-disconnected nodes to which no script ever had access up until this point. We release-assert these conditions before going into the fast path. No new tests since there should be no observable behavior change. * dom/ContainerNode.cpp: (WebCore::ContainerNode::removeAllChildrenWithScriptAssertion): Added a fast path. See above. * dom/Document.cpp: (WebCore::Document::commonTeardown): Clear m_documentFragmentForInnerOuterHTML as it would keep the ownewr document (this Document) alive otherwise. (WebCore::Document::documentFragmentForInnerOuterHTML): Added. Lazily create a DocumentFragment used to parse the fragment for innerHTML and outerHTML setters. Remove any child nodes left in the document fragment in the case the last call to replaceChildrenWithFragment took a fast path for a single text node, which case we don't remove any child nodes from DocumentFragment. * dom/Document.h: * dom/DocumentFragment.h: (WebCore::DocumentFragment::setIsDocumentFragmentForInnerOuterHTML): Added. * dom/Node.h: (WebCore::Node::isDocumentFragmentForInnerOuterHTML const): Added. * editing/markup.cpp: (WebCore::createFragmentForMarkup): Extracted from createFragmentForInnerOuterHTML to share code between createFragmentForInnerOuterHTML and createContextualFragment. (WebCore::createFragmentForInnerOuterHTML): Reuse the fragment in createFragmentForMarkup. (WebCore::createContextualFragment): Don't reuse the fragment in createFragmentForMarkup as this function is used by Range::createContextualFragment which exposes the document fragment to arbitrary author scripts. (WebCore::hasOneChild): Deleted since we now have Node::hasOneChild. (WebCore::hasOneTextChild): Use Node::hasOneChild. (WebCore::replaceChildrenWithFragment): Added assertions to make sure we don't have any child nodes left after replacing the children. 2021-02-16 Ruben Turcios Cherry-pick r272633. rdar://problem/74410421 REGRESSION: (r272458): [BigSur Debug] ASSERTION FAILED: m_haveAddedMediaUsageManagerSession in WebCore::MediaElementSession::updateMediaUsageIfChanged() https://bugs.webkit.org/show_bug.cgi?id=221634 Reviewed by Ryosuke Niwa. No new tests, this fixes an assertion in an existing test. * html/MediaElementSession.cpp: (WebCore::MediaElementSession::MediaElementSession): (WebCore::MediaElementSession::addMediaUsageManagerSessionIfNecessary): (WebCore::MediaElementSession::inActiveDocumentChanged): (WebCore::MediaElementSession::updateMediaUsageIfChanged): (WebCore::MediaElementSession::addedMediaUsageManagerSessionIfNecessary): Deleted. * html/MediaElementSession.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272633 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-09 Eric Carlson REGRESSION: (r272458): [BigSur Debug] ASSERTION FAILED: m_haveAddedMediaUsageManagerSession in WebCore::MediaElementSession::updateMediaUsageIfChanged() https://bugs.webkit.org/show_bug.cgi?id=221634 Reviewed by Ryosuke Niwa. No new tests, this fixes an assertion in an existing test. * html/MediaElementSession.cpp: (WebCore::MediaElementSession::MediaElementSession): (WebCore::MediaElementSession::addMediaUsageManagerSessionIfNecessary): (WebCore::MediaElementSession::inActiveDocumentChanged): (WebCore::MediaElementSession::updateMediaUsageIfChanged): (WebCore::MediaElementSession::addedMediaUsageManagerSessionIfNecessary): Deleted. * html/MediaElementSession.h: 2021-02-16 Ruben Turcios Cherry-pick r272622. rdar://problem/74410599 Reduce the overhead of HTMLDocumentParser in innerHTML setter https://bugs.webkit.org/show_bug.cgi?id=221596 Reviewed by Simon Fraser. This patch reduces the overhead of HTMLDocumentParser for innerHTML. This appears to be ~0.5% Speedometer progression. No new tests since there should be no observable behavior differences. * dom/ScriptableDocumentParser.h: (WebCore::ScriptableDocumentParser:isWaitingForScripts): Removed since this abstract virtual function is only used in HTMLDocumentParser. * html/FTPDirectoryDocument.cpp: (WebCore::FTPDirectoryDocument::isWaitingForScripts): Removed. There are no scripts in ftp directory document but there is no need to override it here. * html/parser/HTMLDocumentParser.cpp: (WebCore::HTMLDocumentParser::pumpTokenizer): Exit early when we're parsing a fragment to avoid accessing the scheduler, preloader, and document loader for various things since they're all irrelevant for fragment parsing. (WebCore::HTMLDocumentParser::isWaitingForScripts const): Return false immediately when parsing a document fragment as a fast path. * html/parser/HTMLDocumentParser.h: * xml/parser/XMLDocumentParser.cpp: (WebCore::XMLDocumentParser::isWaitingForScripts const): Removed. Unused. * xml/parser/XMLDocumentParser.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272622 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-09 Ryosuke Niwa Reduce the overhead of HTMLDocumentParser in innerHTML setter https://bugs.webkit.org/show_bug.cgi?id=221596 Reviewed by Simon Fraser. This patch reduces the overhead of HTMLDocumentParser for innerHTML. This appears to be ~0.5% Speedometer progression. No new tests since there should be no observable behavior differences. * dom/ScriptableDocumentParser.h: (WebCore::ScriptableDocumentParser:isWaitingForScripts): Removed since this abstract virtual function is only used in HTMLDocumentParser. * html/FTPDirectoryDocument.cpp: (WebCore::FTPDirectoryDocument::isWaitingForScripts): Removed. There are no scripts in ftp directory document but there is no need to override it here. * html/parser/HTMLDocumentParser.cpp: (WebCore::HTMLDocumentParser::pumpTokenizer): Exit early when we're parsing a fragment to avoid accessing the scheduler, preloader, and document loader for various things since they're all irrelevant for fragment parsing. (WebCore::HTMLDocumentParser::isWaitingForScripts const): Return false immediately when parsing a document fragment as a fast path. * html/parser/HTMLDocumentParser.h: * xml/parser/XMLDocumentParser.cpp: (WebCore::XMLDocumentParser::isWaitingForScripts const): Removed. Unused. * xml/parser/XMLDocumentParser.h: 2021-02-16 Ruben Turcios Cherry-pick r272602. rdar://problem/74409444 [LFC][IFC] Disable BIDI processing for modern line layout https://bugs.webkit.org/show_bug.cgi?id=221615 Reviewed by Sam Weinig. This was added in preparation for BIDI content support but we are not there yet. Let's just disable it for now. * layout/integration/LayoutIntegrationInlineContentBuilder.cpp: (WebCore::LayoutIntegration::InlineContentBuilder::createDisplayLineRuns const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272602 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-09 Zalan Bujtas [LFC][IFC] Disable BIDI processing for modern line layout https://bugs.webkit.org/show_bug.cgi?id=221615 Reviewed by Sam Weinig. This was added in preparation for BIDI content support but we are not there yet. Let's just disable it for now. * layout/integration/LayoutIntegrationInlineContentBuilder.cpp: (WebCore::LayoutIntegration::InlineContentBuilder::createDisplayLineRuns const): 2021-02-16 Ruben Turcios Cherry-pick r272583. rdar://problem/74409637 MediaStream-backed video elements should not compute the mediaType based on track muted states https://bugs.webkit.org/show_bug.cgi?id=221601 Reviewed by Eric Carlson. Source/WebCore: In case of entering background, two things happen: - video elements get paused - local video capture track gets muted When entering foreground: - video element should resume but did not as the local video track was muted and video element was considered as an audio element. - local video capture track gets unmuted but this is too late. To fix this, compute hasVideo/hasAudio based on available tracks, no matter their active state. Test: fast/mediastream/MediaStream-video-element-enter-background.html * platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.mm: (WebCore::MediaPlayerPrivateMediaStreamAVFObjC::hasVideo const): (WebCore::MediaPlayerPrivateMediaStreamAVFObjC::hasAudio const): LayoutTests: * fast/mediastream/MediaStream-video-element-enter-background-expected.txt: Added. * fast/mediastream/MediaStream-video-element-enter-background.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272583 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-09 Youenn Fablet MediaStream-backed video elements should not compute the mediaType based on track muted states https://bugs.webkit.org/show_bug.cgi?id=221601 Reviewed by Eric Carlson. In case of entering background, two things happen: - video elements get paused - local video capture track gets muted When entering foreground: - video element should resume but did not as the local video track was muted and video element was considered as an audio element. - local video capture track gets unmuted but this is too late. To fix this, compute hasVideo/hasAudio based on available tracks, no matter their active state. Test: fast/mediastream/MediaStream-video-element-enter-background.html * platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.mm: (WebCore::MediaPlayerPrivateMediaStreamAVFObjC::hasVideo const): (WebCore::MediaPlayerPrivateMediaStreamAVFObjC::hasAudio const): 2021-02-16 Ruben Turcios Cherry-pick r272567. rdar://problem/74410033 REGRESSION (r269458): yahoo.com social / comments bar shows as transparent when scrolling page https://bugs.webkit.org/show_bug.cgi?id=221582 Source/WebCore: Reviewed by Tim Horton. Fix some copypasta in r269458 that resulted in scrolling state fixed nodes failing to get the right dirty bits after attach, resulting bad viewport constraint data. Test: scrollingcoordinator/fixed-node-reattach.html * page/scrolling/ScrollingStateFixedNode.cpp: (WebCore::ScrollingStateFixedNode::applicableProperties const): LayoutTests: Reviewed by Tim Horton. * scrollingcoordinator/fixed-node-reattach-expected.html: Added. * scrollingcoordinator/fixed-node-reattach.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272567 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-08 Simon Fraser REGRESSION (r269458): yahoo.com social / comments bar shows as transparent when scrolling page https://bugs.webkit.org/show_bug.cgi?id=221582 Reviewed by Tim Horton. Fix some copypasta in r269458 that resulted in scrolling state fixed nodes failing to get the right dirty bits after attach, resulting bad viewport constraint data. Test: scrollingcoordinator/fixed-node-reattach.html * page/scrolling/ScrollingStateFixedNode.cpp: (WebCore::ScrollingStateFixedNode::applicableProperties const): 2021-02-16 Ruben Turcios Cherry-pick r272550. rdar://problem/74409264 Make the UserContentController for ServiceWorker pages be non-optional. and https://bugs.webkit.org/show_bug.cgi?id=221503 Reviewed by Alex Christensen. Source/WebCore: * loader/EmptyClients.cpp: (WebCore::pageConfigurationWithEmptyClients): * page/Page.cpp: (WebCore::Page::Page): * page/PageConfiguration.cpp: (WebCore::PageConfiguration::PageConfiguration): * page/PageConfiguration.h: Source/WebKit: Normal Pages always have a UserContentProvider, even if they just create an empty default one. Same should be true for ServiceWorkers. * Shared/ServiceWorkerInitializationData.cpp: (WebKit::ServiceWorkerInitializationData::decode): * Shared/ServiceWorkerInitializationData.h: * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::userContentControllerIdentifierForServiceWorkers): (WebKit::WebProcessPool::createWebPage): * UIProcess/WebProcessPool.h: * UIProcess/WebProcessProxy.cpp: (WebKit::WebProcessProxy::enableServiceWorkers): * UIProcess/WebProcessProxy.h: * WebProcess/Storage/WebSWContextManagerConnection.cpp: (WebKit::m_userContentController): (WebKit::m_userAgent): Deleted. * WebProcess/Storage/WebSWContextManagerConnection.h: * WebProcess/WebPage/WebPage.cpp: (WebKit::m_limitsNavigationsToAppBoundDomains): Source/WebKitLegacy/mac: * WebView/WebView.mm: (-[WebView _commonInitializationWithFrameName:groupName:]): Source/WebKitLegacy/win: * WebView.cpp: (WebView::initWithFrame): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272550 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-08 Brady Eidson Make the UserContentController for ServiceWorker pages be non-optional. and https://bugs.webkit.org/show_bug.cgi?id=221503 Reviewed by Alex Christensen. * loader/EmptyClients.cpp: (WebCore::pageConfigurationWithEmptyClients): * page/Page.cpp: (WebCore::Page::Page): * page/PageConfiguration.cpp: (WebCore::PageConfiguration::PageConfiguration): * page/PageConfiguration.h: 2021-02-16 Ruben Turcios Cherry-pick r272495. rdar://problem/74409320 [macOS] Return key binding for date inputs conflicts with return to submit form https://bugs.webkit.org/show_bug.cgi?id=221532 Reviewed by Wenson Hsieh. Source/WebCore: Currently, pressing the return key within a focused date input presents the calendar view, rather than submitting an associated form. This is a usability issue for keyboard users, and is different from the behavior in Chrome. This patch matches the behavior in Chrome, and makes it so that a return keypress submits an associated form. However, since the return key is now reserved for form submission, we need a new key to present the calendar view for the date input. Chrome and Firefox use the space key for this functionality, so this patch matches that behavior. Note that r267281 updated date inputs to focus the next editable component when pressing the space key. This behavior is now removed in favor of presenting the calendar. Other separator keys, and arrow keys, can still be used to focus the next editable component. Tests: fast/forms/date/date-editable-components/date-picker-show-on-space-keypress.html fast/forms/date/date-editable-components/form-submit-on-return-keypress.html * html/BaseDateAndTimeInputType.cpp: (WebCore::BaseDateAndTimeInputType::handleKeypressEvent): Date and time inputs are BaseClickableWithKeyInputTypes. This gives them activation behavior on return and space keypresses, similar to button and color inputs. However, since date/time inputs are closer to textfields, than buttons, we elide activation behavior on a return keypress, allowing the event to submit an associated form. Activation behavior on a space keypress is supported by going through the existing code path. * html/shadow/DateTimeFieldElement.cpp: (WebCore::DateTimeFieldElement::defaultKeyboardEventHandler): Remove "Space" from the list of separator keys that focus the next editable component. LayoutTests: Added tests to verify that pressing the space key in a focused date input presents a calendar view, and pressing the enter key in a focused date input submits a form. Rebaselined existing tests to account for the fact that the space key no longer focuses the next editable component within a date input. * fast/forms/date/date-editable-components/date-editable-components-keyboard-events-expected.txt: * fast/forms/date/date-editable-components/date-editable-components-keyboard-events.html: * fast/forms/date/date-editable-components/date-picker-show-on-space-keypress-expected.txt: Added. * fast/forms/date/date-editable-components/date-picker-show-on-space-keypress.html: Added. * fast/forms/date/date-editable-components/form-submit-on-return-keypress-expected.txt: Added. * fast/forms/date/date-editable-components/form-submit-on-return-keypress.html: Added. * fast/forms/datetimelocal/datetimelocal-editable-components/datetimelocal-editable-components-keyboard-events-expected.txt: * fast/forms/datetimelocal/datetimelocal-editable-components/datetimelocal-editable-components-keyboard-events.html: * fast/forms/month/month-editable-components/month-editable-components-keyboard-events-expected.txt: * fast/forms/month/month-editable-components/month-editable-components-keyboard-events.html: * fast/forms/time/time-editable-components/time-editable-components-keyboard-events-expected.txt: * fast/forms/time/time-editable-components/time-editable-components-keyboard-events.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272495 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-08 Aditya Keerthi [macOS] Return key binding for date inputs conflicts with return to submit form https://bugs.webkit.org/show_bug.cgi?id=221532 Reviewed by Wenson Hsieh. Currently, pressing the return key within a focused date input presents the calendar view, rather than submitting an associated form. This is a usability issue for keyboard users, and is different from the behavior in Chrome. This patch matches the behavior in Chrome, and makes it so that a return keypress submits an associated form. However, since the return key is now reserved for form submission, we need a new key to present the calendar view for the date input. Chrome and Firefox use the space key for this functionality, so this patch matches that behavior. Note that r267281 updated date inputs to focus the next editable component when pressing the space key. This behavior is now removed in favor of presenting the calendar. Other separator keys, and arrow keys, can still be used to focus the next editable component. Tests: fast/forms/date/date-editable-components/date-picker-show-on-space-keypress.html fast/forms/date/date-editable-components/form-submit-on-return-keypress.html * html/BaseDateAndTimeInputType.cpp: (WebCore::BaseDateAndTimeInputType::handleKeypressEvent): Date and time inputs are BaseClickableWithKeyInputTypes. This gives them activation behavior on return and space keypresses, similar to button and color inputs. However, since date/time inputs are closer to textfields, than buttons, we elide activation behavior on a return keypress, allowing the event to submit an associated form. Activation behavior on a space keypress is supported by going through the existing code path. * html/shadow/DateTimeFieldElement.cpp: (WebCore::DateTimeFieldElement::defaultKeyboardEventHandler): Remove "Space" from the list of separator keys that focus the next editable component. 2021-02-16 Ruben Turcios Cherry-pick r272488. rdar://problem/74410510 Perform layout before running Editor::findString https://bugs.webkit.org/show_bug.cgi?id=220384 Patch by Frédéric Wang on 2021-02-08 Reviewed by Ryosuke Niwa. This ensures that the layout is up-to-date before performing any search. Also disable any post-resolution that could cause more changes to happen. * editing/Editor.cpp: (WebCore::Editor::findString): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272488 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-08 Frédéric Wang Perform layout before running Editor::findString https://bugs.webkit.org/show_bug.cgi?id=220384 Reviewed by Ryosuke Niwa. This ensures that the layout is up-to-date before performing any search. Also disable any post-resolution that could cause more changes to happen. * editing/Editor.cpp: (WebCore::Editor::findString): 2021-02-16 Ruben Turcios Cherry-pick r272483. rdar://problem/74409975 Nullptr crash in editingIgnoresContent via InsertParagraphSeparatorCommand::doApply https://bugs.webkit.org/show_bug.cgi?id=220349 Patch by Carlos Garcia Campos on 2021-02-08 Reviewed by Ryosuke Niwa. Add an early return to InsertParagraphSeparatorCommand::doApply if insert position is null. * editing/CompositeEditCommand.cpp: (WebCore::CompositeEditCommand::insertNodeBefore): Return early if a InsertNodeBeforeCommand can't be created. * editing/InsertParagraphSeparatorCommand.cpp: (WebCore::InsertParagraphSeparatorCommand::doApply): Abort the insertion if the insert position is null. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272483 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-08 Carlos Garcia Campos Nullptr crash in editingIgnoresContent via InsertParagraphSeparatorCommand::doApply https://bugs.webkit.org/show_bug.cgi?id=220349 Reviewed by Ryosuke Niwa. Add an early return to InsertParagraphSeparatorCommand::doApply if insert position is null. * editing/CompositeEditCommand.cpp: (WebCore::CompositeEditCommand::insertNodeBefore): Return early if a InsertNodeBeforeCommand can't be created. * editing/InsertParagraphSeparatorCommand.cpp: (WebCore::InsertParagraphSeparatorCommand::doApply): Abort the insertion if the insert position is null. 2021-02-16 Ruben Turcios Cherry-pick r272439. rdar://problem/74409122 [Cocoa] CRASH in MediaPlayerPrivateMediaSourceAVFObjC::removeAudioRenderer() https://bugs.webkit.org/show_bug.cgi?id=221490 Reviewed by Eric Carlson. Add null-checks to every use of player() in SourceBufferPrivateAVFObjC. * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.h: * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm: (WebCore::SourceBufferPrivateAVFObjC::didParseInitializationData): (WebCore::SourceBufferPrivateAVFObjC::willProvideContentKeyRequestInitializationDataForTrackID): (WebCore::SourceBufferPrivateAVFObjC::didProvideContentKeyRequestInitializationDataForTrackID): (WebCore::SourceBufferPrivateAVFObjC::appendCompleted): (WebCore::SourceBufferPrivateAVFObjC::destroyParser): (WebCore::SourceBufferPrivateAVFObjC::destroyRenderers): (WebCore::SourceBufferPrivateAVFObjC::readyState const): (WebCore::SourceBufferPrivateAVFObjC::setReadyState): (WebCore::SourceBufferPrivateAVFObjC::trackDidChangeEnabled): (WebCore::SourceBufferPrivateAVFObjC::flushVideo): (WebCore::SourceBufferPrivateAVFObjC::enqueueSample): (WebCore::SourceBufferPrivateAVFObjC::bufferWasConsumed): (WebCore::SourceBufferPrivateAVFObjC::setDecompressionSession): (WebCore::SourceBufferPrivateAVFObjC::player const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272439 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-05 Jer Noble [Cocoa] CRASH in MediaPlayerPrivateMediaSourceAVFObjC::removeAudioRenderer() https://bugs.webkit.org/show_bug.cgi?id=221490 Reviewed by Eric Carlson. Add null-checks to every use of player() in SourceBufferPrivateAVFObjC. * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.h: * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm: (WebCore::SourceBufferPrivateAVFObjC::didParseInitializationData): (WebCore::SourceBufferPrivateAVFObjC::willProvideContentKeyRequestInitializationDataForTrackID): (WebCore::SourceBufferPrivateAVFObjC::didProvideContentKeyRequestInitializationDataForTrackID): (WebCore::SourceBufferPrivateAVFObjC::appendCompleted): (WebCore::SourceBufferPrivateAVFObjC::destroyParser): (WebCore::SourceBufferPrivateAVFObjC::destroyRenderers): (WebCore::SourceBufferPrivateAVFObjC::readyState const): (WebCore::SourceBufferPrivateAVFObjC::setReadyState): (WebCore::SourceBufferPrivateAVFObjC::trackDidChangeEnabled): (WebCore::SourceBufferPrivateAVFObjC::flushVideo): (WebCore::SourceBufferPrivateAVFObjC::enqueueSample): (WebCore::SourceBufferPrivateAVFObjC::bufferWasConsumed): (WebCore::SourceBufferPrivateAVFObjC::setDecompressionSession): (WebCore::SourceBufferPrivateAVFObjC::player const): 2021-02-16 Ruben Turcios Cherry-pick r272435. rdar://problem/74410448 [LFC][Integration] Hit testing broken for descendants of pointer-events:none boxes https://bugs.webkit.org/show_bug.cgi?id=221460 Reviewed by Zalan Bujtas. Source/WebCore: Descendants of pointer-events:none boxes may still be hittestable if they override the value. LFC integration hit testing code didn't take this into account. Test: fast/events/hittest-pointer-event-none-descendants.html * layout/integration/LayoutIntegrationLineLayout.cpp: (WebCore::LayoutIntegration::LineLayout::hitTest): Replaced and inline-block boxes do the visibility/pointer-events test themselves. This code just needs to take care of text boxes. LayoutTests: * fast/events/hittest-pointer-event-none-descendants-expected.html: Added. * fast/events/hittest-pointer-event-none-descendants.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272435 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-05 Antti Koivisto [LFC][Integration] Hit testing broken for descendants of pointer-events:none boxes https://bugs.webkit.org/show_bug.cgi?id=221460 Reviewed by Zalan Bujtas. Descendants of pointer-events:none boxes may still be hittestable if they override the value. LFC integration hit testing code didn't take this into account. Test: fast/events/hittest-pointer-event-none-descendants.html * layout/integration/LayoutIntegrationLineLayout.cpp: (WebCore::LayoutIntegration::LineLayout::hitTest): Replaced and inline-block boxes do the visibility/pointer-events test themselves. This code just needs to take care of text boxes. 2021-02-16 Ruben Turcios Cherry-pick r272394. rdar://problem/74409285 Avoid creating JS wrapper on a removed node when the subtree is not observable https://bugs.webkit.org/show_bug.cgi?id=221243 Reviewed by Geoffrey Garen. Prior to this patch, WebKit forced the creation the JS wrapper on the root DOM node of a removed subtree to avoid script observable deletion of nodes. This is necessary because DOM nodes are reference counted in the C++ side, and while a DOM node keeps its child nodes alive, it won't keep its parent node alive to avoid reference cycles (leaks). If we didn't force the creation of the JS wrapper and the root node of the removed subtree didn't have any external reference to it in C++ side, we would happily delete it and all its descendant nodes above any subtree with a JS wrapper or an external C++ reference. While this turned out to be an effective strategy for implementing DOM nodes' GC semantics correctly, it has a significant runtime and memory cost - the latter is because we don't collect the JS wrappers of DOM nodes once they're created until they're ready to be destructed. This patch introduces a new optimization to avoid creating these JS wrappers when the removed subtree won't be observable by scripts in the future. The current heuristic is to check if the removed node has any external reference to it (i.e. refCount() > 0 excluding any reference counting that happens within our algorithm). This is sufficient because a given node should not be observable at a later time unless it has an external reference to it. This is ~0.5% progression on Speedometer-2.0 on MacBookAir7,2. To do this, we take advantage of the fact notifyChildNodeRemoved already traverses each removed subtree, and check if any of them has a reference count greater than 1 (greater than 1 because notifyChildNodeRemoved itself increments node's reference count before calling itself on child nodes). Note that we exclude the root node of the removed subtree as these JS wrapper creation is only needed to keep the root node alive. If the root node is already kept alive by some external reference to it, there is no need to keep it alive again by creating a JS wrapper on it. No new tests since existing tests such as fast/dom/gc-3.html covers it. * dom/ContainerNode.cpp: (WebCore::ContainerNode::removeAllChildrenWithScriptAssertion): Call willCreatePossiblyOrphanedTreeByRemoval if the removed subtree contains an observable node. (WebCore::ContainerNode::removeNodeWithScriptAssertion): Ditto. (WebCore::ContainerNode::removeSelfOrChildNodesForInsertion): Renamed from collectChildrenAndRemoveFromOldParent. Avoid collecting the removed nodes in this function in addition to removeAllChildrenWithScriptAssertion. (WebCore::ContainerNode::insertBefore): (WebCore::ContainerNode::replaceChild): (WebCore::ContainerNode::appendChildWithoutPreInsertionValidityCheck): (WebCore::dispatchChildRemovalEvents): Don't call willCreatePossiblyOrphanedTreeByRemoval here. * dom/ContainerNode.h: * dom/ContainerNodeAlgorithms.cpp: (WebCore::observabilityOfRemovedNode): Added. Checks the observability of a node excluding the root node of the removed subtree since it needs a special case in removeAllChildrenWithScriptAssertion. As notifyNodeRemovedFromDocument and notifyNodeRemovedFromTree ref's each child node before recursing on itself, we check refCount() > 1 here. (WebCore::updateObservability): Added. A helper function to update RemovedSubtreeObservability. (WebCore::notifyNodeRemovedFromDocument): Now returns RemovedSubtreeObservability, (WebCore::notifyNodeRemovedFromTree): Ditto. (WebCore::notifyChildNodeRemoved): Ditto. * dom/ContainerNodeAlgorithms.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272394 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-04 Ryosuke Niwa Avoid creating JS wrapper on a removed node when the subtree is not observable https://bugs.webkit.org/show_bug.cgi?id=221243 Reviewed by Geoffrey Garen. Prior to this patch, WebKit forced the creation the JS wrapper on the root DOM node of a removed subtree to avoid script observable deletion of nodes. This is necessary because DOM nodes are reference counted in the C++ side, and while a DOM node keeps its child nodes alive, it won't keep its parent node alive to avoid reference cycles (leaks). If we didn't force the creation of the JS wrapper and the root node of the removed subtree didn't have any external reference to it in C++ side, we would happily delete it and all its descendant nodes above any subtree with a JS wrapper or an external C++ reference. While this turned out to be an effective strategy for implementing DOM nodes' GC semantics correctly, it has a significant runtime and memory cost - the latter is because we don't collect the JS wrappers of DOM nodes once they're created until they're ready to be destructed. This patch introduces a new optimization to avoid creating these JS wrappers when the removed subtree won't be observable by scripts in the future. The current heuristic is to check if the removed node has any external reference to it (i.e. refCount() > 0 excluding any reference counting that happens within our algorithm). This is sufficient because a given node should not be observable at a later time unless it has an external reference to it. This is ~0.5% progression on Speedometer-2.0 on MacBookAir7,2. To do this, we take advantage of the fact notifyChildNodeRemoved already traverses each removed subtree, and check if any of them has a reference count greater than 1 (greater than 1 because notifyChildNodeRemoved itself increments node's reference count before calling itself on child nodes). Note that we exclude the root node of the removed subtree as these JS wrapper creation is only needed to keep the root node alive. If the root node is already kept alive by some external reference to it, there is no need to keep it alive again by creating a JS wrapper on it. No new tests since existing tests such as fast/dom/gc-3.html covers it. * dom/ContainerNode.cpp: (WebCore::ContainerNode::removeAllChildrenWithScriptAssertion): Call willCreatePossiblyOrphanedTreeByRemoval if the removed subtree contains an observable node. (WebCore::ContainerNode::removeNodeWithScriptAssertion): Ditto. (WebCore::ContainerNode::removeSelfOrChildNodesForInsertion): Renamed from collectChildrenAndRemoveFromOldParent. Avoid collecting the removed nodes in this function in addition to removeAllChildrenWithScriptAssertion. (WebCore::ContainerNode::insertBefore): (WebCore::ContainerNode::replaceChild): (WebCore::ContainerNode::appendChildWithoutPreInsertionValidityCheck): (WebCore::dispatchChildRemovalEvents): Don't call willCreatePossiblyOrphanedTreeByRemoval here. * dom/ContainerNode.h: * dom/ContainerNodeAlgorithms.cpp: (WebCore::observabilityOfRemovedNode): Added. Checks the observability of a node excluding the root node of the removed subtree since it needs a special case in removeAllChildrenWithScriptAssertion. As notifyNodeRemovedFromDocument and notifyNodeRemovedFromTree ref's each child node before recursing on itself, we check refCount() > 1 here. (WebCore::updateObservability): Added. A helper function to update RemovedSubtreeObservability. (WebCore::notifyNodeRemovedFromDocument): Now returns RemovedSubtreeObservability, (WebCore::notifyNodeRemovedFromTree): Ditto. (WebCore::notifyChildNodeRemoved): Ditto. * dom/ContainerNodeAlgorithms.h: 2021-02-16 Ruben Turcios Cherry-pick r272390. rdar://problem/74409535 AX: expose focusable elements even if element or ancestor has aria-hidden=true https://bugs.webkit.org/show_bug.cgi?id=220534 Reviewed by Zalan Bujtas. Source/WebCore: ARIA states that if an item is focused, then it should override aria-hidden status. https://github.com/w3c/aria/pull/1387/files Test: accessibility/focusable-inside-hidden.html * accessibility/AXObjectCache.cpp: (WebCore::isNodeAriaVisible): * accessibility/AccessibilityObject.cpp: (WebCore::AccessibilityObject::isAXHidden const): (WebCore::AccessibilityObject::setIsIgnoredFromParentDataForChild): LayoutTests: * accessibility/focusable-inside-hidden-expected.txt: Added. * accessibility/focusable-inside-hidden.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272390 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-04 Chris Fleizach AX: expose focusable elements even if element or ancestor has aria-hidden=true https://bugs.webkit.org/show_bug.cgi?id=220534 Reviewed by Zalan Bujtas. ARIA states that if an item is focused, then it should override aria-hidden status. https://github.com/w3c/aria/pull/1387/files Test: accessibility/focusable-inside-hidden.html * accessibility/AXObjectCache.cpp: (WebCore::isNodeAriaVisible): * accessibility/AccessibilityObject.cpp: (WebCore::AccessibilityObject::isAXHidden const): (WebCore::AccessibilityObject::setIsIgnoredFromParentDataForChild): 2021-02-10 Alan Coon Revert r272541. rdar://problem/74208306 2021-02-08 Russell Epstein Cherry-pick r272345. rdar://problem/74032500 [WebAuthn] Allow one user gesture free prompt for each navigation https://bugs.webkit.org/show_bug.cgi?id=220897 Reviewed by Brent Fulgham. Source/WebCore: * Modules/webauthn/AuthenticatorCoordinator.cpp: (WebCore::AuthenticatorCoordinator::resetUserGestureRequirement): * Modules/webauthn/AuthenticatorCoordinator.h: * Modules/webauthn/AuthenticatorCoordinatorClient.h: * page/Quirks.cpp: * page/Quirks.cpp.h: * replay/UserInputBridge.cpp: (WebCore::UserInputBridge::loadRequest): (WebCore::UserInputBridge::reloadFrame): Adds the ability to reset the user gesture requirement flag for user initiated reloads and quirks. Source/WebKit: This is a quirk that only allows certain websites. Covered by existing tests. * UIProcess/WebAuthentication/AuthenticatorManager.cpp: (WebKit::AuthenticatorManager::filterTransports const): (WebKit::AuthenticatorManager::runPanel): (WebKit::AuthenticatorManager::runPresenter): Cancel the whole WebAuthn operation if no user gesture is indicated. * WebProcess/WebAuthentication/WebAuthenticatorCoordinator.cpp: (WebKit::WebAuthenticatorCoordinator::makeCredential): (WebKit::WebAuthenticatorCoordinator::getAssertion): * WebProcess/WebAuthentication/WebAuthenticatorCoordinator.h: Set a boolean to indicate a free coupon for each navigation. Tools: * TestWebKitAPI/Tests/WebKitCocoa/_WKWebAuthenticationPanel.mm: (TestWebKitAPI::TEST): LayoutTests: * http/wpt/webauthn/ctap-hid-failure.https-expected.txt: * http/wpt/webauthn/ctap-hid-success.https-expected.txt: * http/wpt/webauthn/ctap-nfc-failure.https-expected.txt: * http/wpt/webauthn/idl.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-hid-silent.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-hid.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-local-silent.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-local.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-nfc.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-u2f-silent.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure-u2f.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-failure.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-success-hid.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-success-local.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-success-nfc.https-expected.txt: * http/wpt/webauthn/public-key-credential-create-success-u2f.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-hid-silent.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-hid.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-local-silent.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-local.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-nfc.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-u2f-silent.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure-u2f.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-failure.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-success-hid.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-success-local.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-success-nfc.https-expected.txt: * http/wpt/webauthn/public-key-credential-get-success-u2f.https-expected.txt: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272345 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-03 Jiewen Tan [WebAuthn] Allow one user gesture free prompt for each navigation https://bugs.webkit.org/show_bug.cgi?id=220897 Reviewed by Brent Fulgham. * Modules/webauthn/AuthenticatorCoordinator.cpp: (WebCore::AuthenticatorCoordinator::resetUserGestureRequirement): * Modules/webauthn/AuthenticatorCoordinator.h: * Modules/webauthn/AuthenticatorCoordinatorClient.h: * page/Quirks.cpp: * page/Quirks.cpp.h: * replay/UserInputBridge.cpp: (WebCore::UserInputBridge::loadRequest): (WebCore::UserInputBridge::reloadFrame): Adds the ability to reset the user gesture requirement flag for user initiated reloads and quirks. 2021-02-08 Russell Epstein Cherry-pick r272422. rdar://problem/74033021 Make sure click attribution is processed in case of redirected kept alive loads https://bugs.webkit.org/show_bug.cgi?id=221453 Reviewed by John Wilander. Source/WebCore: Test: http/tests/privateClickMeasurement/attribution-conversion-through-fetch-keepalive.html * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::addSubresourceLoader): Update assertion to cope with keep alive fetches which are similar to beacon/ping loads. Source/WebKit: * NetworkProcess/NetworkResourceLoader.cpp: (WebKit::NetworkResourceLoader::continueWillSendRedirectedRequest): Move the click attribution processing before kept alive check. LayoutTests: * http/tests/privateClickMeasurement/attribution-conversion-through-fetch-keepalive-expected.txt: Added. * http/tests/privateClickMeasurement/attribution-conversion-through-fetch-keepalive.html: Added. * http/tests/privateClickMeasurement/resources/redirectToConversion.php: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272422 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-05 Youenn Fablet Make sure click attribution is processed in case of redirected kept alive loads https://bugs.webkit.org/show_bug.cgi?id=221453 Reviewed by John Wilander. Test: http/tests/privateClickMeasurement/attribution-conversion-through-fetch-keepalive.html * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::addSubresourceLoader): Update assertion to cope with keep alive fetches which are similar to beacon/ping loads. 2021-02-08 Russell Epstein Cherry-pick r272368. rdar://problem/74032667 [macOS] Selecting a date on datetime-local inputs unexpectedly adds second and millisecond fields https://bugs.webkit.org/show_bug.cgi?id=221350 Reviewed by Devin Rousso. Source/WebCore: Currently, when setting the value of a datetime-local input using the picker, the length of the current value of the input is used to determine whether or not to return a value with second/millisecond precision. This is approach is incorrect, since the value could be empty, while the step attribute can specify second/millisecond precision. To fix, ensure the DateTimeChooserParameters knows whether the input has second and millisecond fields. That information can then be used by the UIProcess to return a correctly formatted value to the WebProcess. Test: fast/forms/datetimelocal/datetimelocal-editable-components/datetimelocal-choose-value-from-picker.html * html/BaseDateAndTimeInputType.cpp: (WebCore::BaseDateAndTimeInputType::handleDOMActivateEvent): (WebCore::BaseDateAndTimeInputType::didChangeValueFromControl): (WebCore::BaseDateAndTimeInputType::setupDateTimeChooserParameters): Moved this method from HTMLInputElement to the input type, since it is specific to date/time input types, and to leverage the existing shouldHaveSecondField and shouldHaveMillisecondField methods when building the DateTimeChooserParameters. * html/BaseDateAndTimeInputType.h: * html/HTMLInputElement.cpp: * html/HTMLInputElement.h: * platform/DateTimeChooserParameters.h: Added hasSecondField and hasMillisecondField members, so that the UIProcess knows whether or not to return a string that contains seconds/milliseconds. (WebCore::DateTimeChooserParameters::encode const): (WebCore::DateTimeChooserParameters::decode): Source/WebKit: * UIProcess/mac/WebDateTimePickerMac.mm: (-[WKDateTimePicker updatePicker:]): (-[WKDateTimePicker dateFormatStringForType:]): Do not use the length of the value to determine whether or seconds and milliseconds should be present, since the value can be empty. Instead, use the new information in DateTimeChooserParameters, matching the visual appearance of the input. Tools: Added a method to UIScriptController to simulate selecting a date using the presented date picker. * TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl: * TestRunnerShared/UIScriptContext/UIScriptController.h: (WTR::UIScriptController::chooseDateTimePickerValue): * WebKitTestRunner/mac/UIScriptControllerMac.h: * WebKitTestRunner/mac/UIScriptControllerMac.mm: (WTR::UIScriptControllerMac::chooseDateTimePickerValue): LayoutTests: Added a test to to verify that the presence of seconds and milliseconds in the value of a datetime-local input after selecting a date using the picker matches the configuration. * fast/forms/datetimelocal/datetimelocal-editable-components/datetimelocal-choose-value-from-picker-expected.txt: Added. * fast/forms/datetimelocal/datetimelocal-editable-components/datetimelocal-choose-value-from-picker.html: Added. * resources/ui-helper.js: (window.UIHelper.chooseDateTimePickerValue): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272368 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-04 Aditya Keerthi [macOS] Selecting a date on datetime-local inputs unexpectedly adds second and millisecond fields https://bugs.webkit.org/show_bug.cgi?id=221350 Reviewed by Devin Rousso. Currently, when setting the value of a datetime-local input using the picker, the length of the current value of the input is used to determine whether or not to return a value with second/millisecond precision. This is approach is incorrect, since the value could be empty, while the step attribute can specify second/millisecond precision. To fix, ensure the DateTimeChooserParameters knows whether the input has second and millisecond fields. That information can then be used by the UIProcess to return a correctly formatted value to the WebProcess. Test: fast/forms/datetimelocal/datetimelocal-editable-components/datetimelocal-choose-value-from-picker.html * html/BaseDateAndTimeInputType.cpp: (WebCore::BaseDateAndTimeInputType::handleDOMActivateEvent): (WebCore::BaseDateAndTimeInputType::didChangeValueFromControl): (WebCore::BaseDateAndTimeInputType::setupDateTimeChooserParameters): Moved this method from HTMLInputElement to the input type, since it is specific to date/time input types, and to leverage the existing shouldHaveSecondField and shouldHaveMillisecondField methods when building the DateTimeChooserParameters. * html/BaseDateAndTimeInputType.h: * html/HTMLInputElement.cpp: * html/HTMLInputElement.h: * platform/DateTimeChooserParameters.h: Added hasSecondField and hasMillisecondField members, so that the UIProcess knows whether or not to return a string that contains seconds/milliseconds. (WebCore::DateTimeChooserParameters::encode const): (WebCore::DateTimeChooserParameters::decode): 2021-02-08 Russell Epstein Cherry-pick r272353. rdar://problem/74105476 [Cocoa] WebM audio goes out-of-sync or stops playing after a seek https://bugs.webkit.org/show_bug.cgi?id=221354 Reviewed by Eric Carlson. Source/WebCore: Add a new flag to MediaSample indicating whether the sample has any information about whether it is an sync-sample or not, and expose that through a new method hasSyncInfo(). Drive-by Fix: Force all video samples to contain a sample attachments dictionary, whether or not the sample is sync. Drive-by Fix #2: SampleMap does an equality comparison for `flags() == MediaSample::IsSync`. This breaks as soon as any sample has both `IsSync` and any other flag. Replace with a specific call to `isSync()` instead. * platform/MediaSample.h: * platform/graphics/avfoundation/objc/MediaSampleAVFObjC.mm: (WebCore::doesCMSampleBufferHaveSyncInfo): (WebCore::MediaSampleAVFObjC::flags const): * platform/graphics/cocoa/SourceBufferParserWebM.cpp: (WebCore::SourceBufferParserWebM::VideoTrackData::createSampleBuffer): Source/WebKit: The MTPluginFormatReader will attempt to determine whether an audio sample needs priming frames by querying for, among other things, its "syncInfo". Previously, we had just presumed all samples without a sample attachment dictionary were sync samples, and reported them as such from MediaSampleCursor, but this causes the format reader plugin to walk backwards all the way to the beginning of the audio track looking for priming samples. Instead, since the sample in question has no sync info (it was synthesized by MediaSample), return kCMBaseObjectError_ValueNotAvailable in this case, which causes the plugin format reader to assume all samples are both sync and do not require explicit priming frames. * Shared/mac/MediaFormatReader/MediaSampleCursor.cpp: (WebKit::MediaSampleCursor::getSampleTiming const): (WebKit::MediaSampleCursor::getSyncInfo const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272353 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-03 Jer Noble [Cocoa] WebM audio goes out-of-sync or stops playing after a seek https://bugs.webkit.org/show_bug.cgi?id=221354 Reviewed by Eric Carlson. Add a new flag to MediaSample indicating whether the sample has any information about whether it is an sync-sample or not, and expose that through a new method hasSyncInfo(). Drive-by Fix: Force all video samples to contain a sample attachments dictionary, whether or not the sample is sync. Drive-by Fix #2: SampleMap does an equality comparison for `flags() == MediaSample::IsSync`. This breaks as soon as any sample has both `IsSync` and any other flag. Replace with a specific call to `isSync()` instead. * platform/MediaSample.h: * platform/graphics/avfoundation/objc/MediaSampleAVFObjC.mm: (WebCore::doesCMSampleBufferHaveSyncInfo): (WebCore::MediaSampleAVFObjC::flags const): * platform/graphics/cocoa/SourceBufferParserWebM.cpp: (WebCore::SourceBufferParserWebM::VideoTrackData::createSampleBuffer): 2021-02-08 Russell Epstein Cherry-pick r272303. rdar://problem/74105623 Animation of "rotate" or "scale" property does not correctly account for static "translate" property https://bugs.webkit.org/show_bug.cgi?id=219894 Unreviewed build fix for Mojave. * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::updateAnimations): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272303 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-01 Antoine Quint Animation of "rotate" or "scale" property does not correctly account for static "translate" property https://bugs.webkit.org/show_bug.cgi?id=219894 Unreviewed build fix for Mojave. * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::updateAnimations): 2021-02-08 Russell Epstein Cherry-pick r272234. rdar://problem/74105068 [macOS] Force loading the HEIF reader symbols before transcoding any HEIF image https://bugs.webkit.org/show_bug.cgi?id=221191 Reviewed by Tim Horton. Source/WebCore: Transcoding the HEIF images requires loading the HEIF reader symbols which is not happening in macOS Catalina. A workaround for this bug in WebKit is to call CGImageSourceGetCount() for the CGImageSource of the HEIF image. * platform/graphics/cg/ImageUtilitiesCG.cpp: (WebCore::transcodeImage): Source/WTF: Add a HAVE macro for the fix of . * wtf/PlatformHave.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272234 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-02 Said Abou-Hallawa [macOS] Force loading the HEIF reader symbols before transcoding any HEIF image https://bugs.webkit.org/show_bug.cgi?id=221191 Reviewed by Tim Horton. Transcoding the HEIF images requires loading the HEIF reader symbols which is not happening in macOS Catalina. A workaround for this bug in WebKit is to call CGImageSourceGetCount() for the CGImageSource of the HEIF image. * platform/graphics/cg/ImageUtilitiesCG.cpp: (WebCore::transcodeImage): 2021-02-08 Russell Epstein Cherry-pick r272214. rdar://problem/74032646 Unreviewed, address post-landing review comment by Darin Adler for r272211. * platform/network/cocoa/NetworkStorageSessionCocoa.mm: (WebCore::cookiesForURL): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272214 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-02 Chris Dumez Unreviewed, address post-landing review comment by Darin Adler for r272211. * platform/network/cocoa/NetworkStorageSessionCocoa.mm: (WebCore::cookiesForURL): 2021-02-08 Russell Epstein Cherry-pick r272211. rdar://problem/74032646 Crash under NetworkStorageSession::cookiesForSession() https://bugs.webkit.org/show_bug.cgi?id=221227 Reviewed by Geoffrey Garen. Retain NSArray of cookies in NetworkStorageSession::cookiesForSession() for clearer lifetime management. This is a speculative fix for . * platform/network/NetworkStorageSession.h: * platform/network/cocoa/NetworkStorageSessionCocoa.mm: (WebCore::NetworkStorageSession::httpCookies const): (WebCore::cookiesForURL): (WebCore::NetworkStorageSession::httpCookiesForURL const): (WebCore::NetworkStorageSession::cookiesForURL const): (WebCore::NetworkStorageSession::cookiesForSession const): (WebCore::NetworkStorageSession::getRawCookies const): (WebCore::NetworkStorageSession::deleteCookie const): (WebCore::NetworkStorageSession::getHostnamesWithCookies): (WebCore::NetworkStorageSession::deleteCookiesForHostnames): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272211 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-02 Chris Dumez Crash under NetworkStorageSession::cookiesForSession() https://bugs.webkit.org/show_bug.cgi?id=221227 Reviewed by Geoffrey Garen. Retain NSArray of cookies in NetworkStorageSession::cookiesForSession() for clearer lifetime management. This is a speculative fix for . * platform/network/NetworkStorageSession.h: * platform/network/cocoa/NetworkStorageSessionCocoa.mm: (WebCore::NetworkStorageSession::httpCookies const): (WebCore::cookiesForURL): (WebCore::NetworkStorageSession::httpCookiesForURL const): (WebCore::NetworkStorageSession::cookiesForURL const): (WebCore::NetworkStorageSession::cookiesForSession const): (WebCore::NetworkStorageSession::getRawCookies const): (WebCore::NetworkStorageSession::deleteCookie const): (WebCore::NetworkStorageSession::getHostnamesWithCookies): (WebCore::NetworkStorageSession::deleteCookiesForHostnames): 2021-02-08 Russell Epstein Cherry-pick r272201. rdar://problem/74105623 Animation of "rotate" or "scale" property does not correctly account for static "translate" property https://bugs.webkit.org/show_bug.cgi?id=219894 Reviewed by Dean Jackson. Source/WebCore: The CSS transform-related properties are designed to be applied in a specific order, guaranteeing that "translate" is applied prior to both "scale" and "rotate". Since Core Animation has no concept of these individual transform-related CSS properties, we use additive Core Animation animations to apply the value of each CSS property, using non-interpolating animations set to start at the earliest time in the Core Animation timeline and lasting forever to set the value of any underlying, non-animated value. As such, in an example where an element would have a static "translate" property set as well as a "rotate" or "scale" animation, we would yield the following animations, added in this order: 1. non-interpolating animation beginning at 1s setting the identity transform (the "clean slate" animation) 2. interpolating animation beginning at a time > 1s for the "scale" or "rotate" animation 3. non-interpolating animation beginning at 1s setting the "translate" value Note that animations 2 and 3 are additive and thus added in the inverse order that we expect animations to be applied. Due to a peculiarity of Core Animation (introduced in macOS 10.15), additive animations are applied in an inverse order, hence the build-time flag CA_WHERE_ADDITIVE_TRANSFORMS_ARE_REVERSED. However, Core Animation will first sort all animations based on their begin time, only respecting the order in which animations are added when their begin time is equal. This means that in practice, our animations were applied in the order 1, 3, 2, and thus the "translate" property was applied after the "rotate" or "scale" animation. In order to address this, we now create a CAAnimationGroup for each set of animations created for a given CSS property. Each of these groups shares the same begin time, 1s, to allow for "forever" non-interpolating animations to be applied, but also to set a common base time for animations to be applied in the expected order. Tests: webanimations/relative-ordering-of-translate-and-rotate-properties-accelerated.html webanimations/relative-ordering-of-translate-and-scale-properties-accelerated.html * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::updateAnimations): * platform/graphics/ca/GraphicsLayerCA.h: (WebCore::GraphicsLayerCA::LayerPropertyAnimation::computedBeginTime const): LayoutTests: Add two new tests that ensure that translate is indeed applied before rotate and scale. * webanimations/relative-ordering-of-translate-and-rotate-properties-accelerated-expected.html: Added. * webanimations/relative-ordering-of-translate-and-rotate-properties-accelerated.html: Added. * webanimations/relative-ordering-of-translate-and-scale-properties-accelerated-expected.html: Added. * webanimations/relative-ordering-of-translate-and-scale-properties-accelerated.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272201 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-01 Antoine Quint Animation of "rotate" or "scale" property does not correctly account for static "translate" property https://bugs.webkit.org/show_bug.cgi?id=219894 Reviewed by Dean Jackson. The CSS transform-related properties are designed to be applied in a specific order, guaranteeing that "translate" is applied prior to both "scale" and "rotate". Since Core Animation has no concept of these individual transform-related CSS properties, we use additive Core Animation animations to apply the value of each CSS property, using non-interpolating animations set to start at the earliest time in the Core Animation timeline and lasting forever to set the value of any underlying, non-animated value. As such, in an example where an element would have a static "translate" property set as well as a "rotate" or "scale" animation, we would yield the following animations, added in this order: 1. non-interpolating animation beginning at 1s setting the identity transform (the "clean slate" animation) 2. interpolating animation beginning at a time > 1s for the "scale" or "rotate" animation 3. non-interpolating animation beginning at 1s setting the "translate" value Note that animations 2 and 3 are additive and thus added in the inverse order that we expect animations to be applied. Due to a peculiarity of Core Animation (introduced in macOS 10.15), additive animations are applied in an inverse order, hence the build-time flag CA_WHERE_ADDITIVE_TRANSFORMS_ARE_REVERSED. However, Core Animation will first sort all animations based on their begin time, only respecting the order in which animations are added when their begin time is equal. This means that in practice, our animations were applied in the order 1, 3, 2, and thus the "translate" property was applied after the "rotate" or "scale" animation. In order to address this, we now create a CAAnimationGroup for each set of animations created for a given CSS property. Each of these groups shares the same begin time, 1s, to allow for "forever" non-interpolating animations to be applied, but also to set a common base time for animations to be applied in the expected order. Tests: webanimations/relative-ordering-of-translate-and-rotate-properties-accelerated.html webanimations/relative-ordering-of-translate-and-scale-properties-accelerated.html * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::updateAnimations): * platform/graphics/ca/GraphicsLayerCA.h: (WebCore::GraphicsLayerCA::LayerPropertyAnimation::computedBeginTime const): 2021-02-08 Russell Epstein Cherry-pick r272188. rdar://problem/74032553 [Cocoa] Disable interstitial events on AVPlayerItem. https://bugs.webkit.org/show_bug.cgi?id=221215 Reviewed by Eric Carlson. Source/WebCore: * platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm: (WebCore::MediaPlayerPrivateAVFoundationObjC::createAVPlayerItem): Source/WebCore/PAL: * pal/spi/cocoa/AVFoundationSPI.h: Source/WTF: * wtf/PlatformHave.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@272188 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2021-02-01 Jer Noble [Cocoa] Disable interstitial events on AVPlayerItem. https://bugs.webkit.org/show_bug.cgi?id=221215 Reviewed by Eric Carlson. * platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm: (WebCore::MediaPlayerPrivateAVFoundationObjC::createAVPlayerItem): 2021-02-08 Russell Epstein Cherry-pick r272185. rdar://problem/74032429 REGRESSION (iOS 14.2): Can't play html audio with muted attribute https://bugs.webkit.org/show_bug.cgi?id=219295 Reviewed by Eric Carlson. In r266844, we added a power-saving feature that would disable the audio decoder for initially muted media elements. However, this caused an issue for .mp3 files, where the duration of the track is computed by the decoder, and not the parser. Since the goal of the power-saving feature was to reduce the CPU cost for decoding a muted audio track on a