Haiku_webkit2_gsoc2019: Bump to Webkit 608.5.12 #1

kenmays · 2021-02-24T19:32:46Z

This PR is to bump the Haiku GSOC 2019 project to the current Webkit 608 branch as of 2021-02-24.

Canonical link: https://commits.webkit.org/213666.345@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@249707 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Canonical link: https://commits.webkit.org/213666.346@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@249727 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Canonical link: https://commits.webkit.org/213666.347@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@249966 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Crash under WebCore::firstPositionInNode() https://bugs.webkit.org/show_bug.cgi?id=201764 <rdar://problem/54823754> Reviewed by Wenson Hsieh and Geoff Garen. Make sure to keep a Ref<> to the textNode when we call insertNodeAtTabSpanPosition() or insertNodeAt(). Test: editing/firstPositionInNode-crash.html * editing/InsertTextCommand.cpp: (WebCore::InsertTextCommand::positionInsideTextNode): Canonical link: https://commits.webkit.org/215410@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249854 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/213666.348@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@249968 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Line artifacts in note body after viewing note with <attachment>s https://bugs.webkit.org/show_bug.cgi?id=201474 <rdar://problem/51306108> Reviewed by Simon Fraser. Source/WebCore: Test: fast/attachment/attachment-border-should-stay-inside-attachment.html * rendering/RenderThemeIOS.mm: (WebCore::attachmentBorderPath): (WebCore::paintAttachmentBorder): Inset the border rect by half the width, so that <attachment> doesn't paint out-of-bounds. LayoutTests: * fast/attachment/attachment-border-should-stay-inside-attachment-expected.html: Added. * fast/attachment/attachment-border-should-stay-inside-attachment.html: Added. Add a test that ensures that <attachment> stays inside its bounds. Canonical link: https://commits.webkit.org/215113@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249507 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/213666.349@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@249986 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Cancelled transitions on Google image search leave content with opacity 0 sometimes https://bugs.webkit.org/show_bug.cgi?id=201482 rdar://problem/54921036 Reviewed by Tim Horton. Source/WebCore: If, in a single rendering update, we started an accelerated opacity transition, and then removed it, we'd still push the transition onto the CALayer with fillForwards and never remove it, so its effects would last forever. Fix by making GraphicsLayerCA::removeAnimation() remove animations from the uncomittedAnimations list as well. Also fix layer names in debug; if a layer's primaryLayerID changed, we'd fail to rename the CALayer, causing confusion when logging at layer dumps. Fix by adding the layer ID just before pushing the name to the platform layer. Some drive-by logging cleanup. Test: legacy-animation-engine/compositing/transitions/add-remove-transition.html * platform/graphics/GraphicsLayer.cpp: (WebCore::GraphicsLayer::debugName const): * platform/graphics/GraphicsLayer.h: * platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::setName): (WebCore::GraphicsLayerCA::debugName const): (WebCore::GraphicsLayerCA::addAnimation): (WebCore::GraphicsLayerCA::pauseAnimation): (WebCore::GraphicsLayerCA::seekAnimation): (WebCore::GraphicsLayerCA::removeAnimation): (WebCore::GraphicsLayerCA::platformCALayerAnimationStarted): (WebCore::GraphicsLayerCA::platformCALayerAnimationEnded): (WebCore::GraphicsLayerCA::updateNames): (WebCore::GraphicsLayerCA::createTransformAnimationsFromKeyframes): * platform/graphics/ca/GraphicsLayerCA.h: * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::logLayerInfo): LayoutTests: * legacy-animation-engine/compositing/transitions/add-remove-transition-expected.html: Added. * legacy-animation-engine/compositing/transitions/add-remove-transition.html: Added. Canonical link: https://commits.webkit.org/215116@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249511 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/213666.350@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@249987 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Revert to pre-r243144 scavenging behavior for macOS https://bugs.webkit.org/show_bug.cgi?id=201555 Reviewed by Saam Barati. The change in r243144 regressed internal power metrics for some Mac models. * bmalloc/Heap.cpp: (bmalloc::Heap::scavenge): (bmalloc::Heap::scavengeToHighWatermark): (bmalloc::Heap::allocateSmallChunk): (bmalloc::Heap::allocateSmallPage): (bmalloc::Heap::allocateLarge): * bmalloc/Heap.h: * bmalloc/IsoDirectory.h: * bmalloc/IsoDirectoryInlines.h: (bmalloc::passedNumPages>::takeFirstEligible): (bmalloc::passedNumPages>::scavenge): (bmalloc::passedNumPages>::scavengeToHighWatermark): * bmalloc/IsoHeapImpl.h: * bmalloc/IsoHeapImplInlines.h: (bmalloc::IsoHeapImpl<Config>::scavengeToHighWatermark): * bmalloc/LargeMap.cpp: (bmalloc::LargeMap::add): * bmalloc/LargeRange.h: (bmalloc::LargeRange::LargeRange): (bmalloc::merge): * bmalloc/Scavenger.cpp: (bmalloc::Scavenger::Scavenger): (bmalloc::Scavenger::timeSinceLastPartialScavenge): (bmalloc::Scavenger::scavenge): (bmalloc::Scavenger::partialScavenge): (bmalloc::Scavenger::threadRunLoop): * bmalloc/Scavenger.h: * bmalloc/SmallPage.h: Canonical link: https://commits.webkit.org/215259@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249670 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/213666.351@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@249988 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Tap and hold on Facebook sometimes creates a tall empty selection. https://bugs.webkit.org/show_bug.cgi?id=201618 rdar://53630145 Reviewed by Megan Gardner. Source/WebCore: API Test: SelectionTests.ByWordAtEndOfDocument * editing/VisibleUnits.cpp: (WebCore::wordRangeFromPosition): Remove special case code for the possibility of an empty paragraph and at the end of the document. This is no longer needed and was causing a large selection to be created on Facebook due to large areas of non-selectable content on the page. Tools: * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/ios/SelectionByWord.mm: Added. Canonical link: https://commits.webkit.org/215274@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249701 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/213666.352@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@249989 268f45cc-cd09-0410-ab3c-d52691b4dbfc

[iOS] We sometimes attempt to use a terminated prewarmed WebContent process https://bugs.webkit.org/show_bug.cgi?id=201614 <rdar://problem/54714507> Reviewed by Geoffrey Garen. On iOS, it is possible for our processes to get terminated (e.g. jetsammed) while the UIProcess is suspended. Upon resuming, it takes a little while for the UIProcess to get the notification that the mac connection to its child process has been severed and the UIProcess may try to use it for a load. This is especially problematic for prewarmed process because the client will end up showing a crash banner and reloading when we could have used a new process rather the prewarmed one if we had known it was dead. This patch makes 2 improvements: 1. It makes AuxiliaryProcessProxy::state() return Terminated if we still have a connection but the PID is not the PID of a running process. I also added a check in tryTakePrewarmedProcess() to not use the prewarmed process if it state() is Terminated. 2. When the UIProcess is about to get suspended, have the process pools terminate their non-critical processes (i.e. prewarmed + the ones used for PageCache). This makes WebKit friendlier with other apps on the system when suspended with regards to memory. Also, it makes it less likely useful WebContent processes will get jetsammed. * UIProcess/AuxiliaryProcessProxy.cpp: (WebKit::AuxiliaryProcessProxy::state const): (WebKit::AuxiliaryProcessProxy::isRunningProcessPID): * UIProcess/AuxiliaryProcessProxy.h: * UIProcess/Cocoa/WebProcessPoolCocoa.mm: (WebKit::WebProcessPool::applicationIsAboutToSuspend): * UIProcess/WebProcessPool.cpp: (WebKit::WebProcessPool::tryTakePrewarmedProcess): * UIProcess/WebProcessPool.h: * UIProcess/ios/ProcessAssertionIOS.mm: (-[WKProcessAssertionBackgroundTaskManager init]): (-[WKProcessAssertionBackgroundTaskManager _releaseBackgroundTask]): Canonical link: https://commits.webkit.org/215276@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249703 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/213666.353@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@249990 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Hangs on Swiss.com due to the web process being blocked on StorageAreaMap::LoadValuesIfNeeded https://bugs.webkit.org/show_bug.cgi?id=201644 <rdar://problem/54942761> Reviewed by Geoffrey Garen. Mark the StorageManagerSet::GetValues sync IPC from the WebContent process to the Network process with a UnboundedSynchronousIPCScope so that it will process critical sync IPC from the UIProcess (such as WebPage::GetPositionInformation) while waiting for a reply. * WebProcess/WebStorage/StorageAreaMap.cpp: (WebKit::StorageAreaMap::loadValuesIfNeeded): Canonical link: https://commits.webkit.org/215294@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249723 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/213666.354@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@249991 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Attempt to make this test not flakey. https://bugs.webkit.org/show_bug.cgi?id=201482 * legacy-animation-engine/compositing/transitions/add-remove-transition.html: Canonical link: https://commits.webkit.org/215303@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249734 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/213666.355@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@249992 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Nullptr crash in Page::sessionID() via WebKit::WebFrameLoaderClient::detachedFromParent2() https://bugs.webkit.org/show_bug.cgi?id=201625 Reviewed by Ryosuke Niwa. This is based on a patch from Ryosuke Niwa. Source/WebCore: Drop setHasFrameSpecificStorageAccess() in WebCore and call it from the WebKit layer instead. * dom/DocumentStorageAccess.cpp: (WebCore::DocumentStorageAccess::requestStorageAccess): (WebCore::DocumentStorageAccess::setHasFrameSpecificStorageAccess): Deleted. * dom/DocumentStorageAccess.h: * loader/EmptyFrameLoaderClient.h: * loader/FrameLoaderClient.h: Source/WebKit: The crash was caused by WebFrameLoaderClient::sessionID() calling WebPage::sessionID() without checking the nullity of WebPage::m_page which can be null. Added a null check. Because passing a wrong session to RemoveStorageAccessForFrame could result in a leak, this patch also replaces m_hasFrameSpecificStorageAccess boolean with an optioanl struct which stores session ID, frame ID, and page ID even after WebCore::Frame or WebCore::Page had been cleared or before WebFrameLoaderClient::m_frame is set. * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp: (WebKit::WebFrameLoaderClient::sessionID const): (WebKit::WebFrameLoaderClient::setHasFrameSpecificStorageAccess): (WebKit::WebFrameLoaderClient::detachedFromParent2): (WebKit::WebFrameLoaderClient::dispatchWillChangeDocument): * WebProcess/WebCoreSupport/WebFrameLoaderClient.h: * WebProcess/WebPage/WebFrame.h: (WebKit::WebFrame::frameLoaderClient const): * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::requestStorageAccess): Canonical link: https://commits.webkit.org/215315@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249748 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/213666.356@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@249993 268f45cc-cd09-0410-ab3c-d52691b4dbfc

REGRESSION (r233780): After swiping to navigate back, pinching to zoom in on webcontent snaps back to zoomed out when letting go https://bugs.webkit.org/show_bug.cgi?id=201671 <rdar://problem/50488372> Reviewed by Simon Fraser. * WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::didCommitLoad): Reset m_lastTransactionIDWithScaleChange, since it is not guaranteed to only march forward. Otherwise, we can get stuck with a very large m_lastTransactionIDWithScaleChange, and will not allow stable-state user-driven zooms until the current transactionID exceeds it. Canonical link: https://commits.webkit.org/215321@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249754 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/213666.357@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@249994 268f45cc-cd09-0410-ab3c-d52691b4dbfc

REGRESSION: Scrubbing on ted.com does not work well https://bugs.webkit.org/show_bug.cgi?id=201635 <rdar://problem/51463649> Patch by Antoine Quint <graouts@apple.com> on 2019-09-11 Reviewed by Dean Jackson. This website uses custom media controls that simply don't work well on iOS when the User-Agent string is the desktop one, so we default to the mobile UA. * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::desktopClassBrowsingRecommendedForRequest): Canonical link: https://commits.webkit.org/215324@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249757 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/213666.358@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@249995 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Prevent reentrancy FrameLoader::dispatchUnloadEvents() https://bugs.webkit.org/show_bug.cgi?id=200738 Reviewed by Brady Eidson. Reentrancy causes m_pageDismissalEventBeingDispatched to be incorrectly updated, so don't allow reentrancy. Since this prevents m_pageDismissalEventBeingDispatched from being reset inside a reentrant call, it can have the unintended effect of causing FrameLoader::stopAllLoaders to early-out when called from FrameLoader::detachFromParent while a frame's unload event handler calls document.open() on a parent frame and causes itself to become detached. Allowing a load to continue in a detached frame will lead to a crash. To prevent this, add a new argument to FrameLoader::stopAllLoaders that FrameLoader::detachFromParent can use to prevent an early-out. * loader/FrameLoader.cpp: (WebCore::FrameLoader::stopAllLoaders): (WebCore::FrameLoader::detachFromParent): (WebCore::FrameLoader::dispatchUnloadEvents): (WebCore::FrameLoader::dispatchBeforeUnloadEvent): Ensure that m_pageDismissalEventBeingDispatched is reset to its previous value, even if this is not None. * loader/FrameLoader.h: * loader/FrameLoaderTypes.h: Add a StopLoadingPolicy enum. Canonical link: https://commits.webkit.org/215329@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249762 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/213666.359@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@249996 268f45cc-cd09-0410-ab3c-d52691b4dbfc

REGRESSION (245006): can't scroll in "read more" view in Eventbrite app https://bugs.webkit.org/show_bug.cgi?id=201683 <rdar://problem/54582602> Reviewed by Simon Fraser. Source/WebCore: * platform/RuntimeApplicationChecks.h: * platform/cocoa/RuntimeApplicationChecksCocoa.mm: (WebCore::IOSApplication::isEventbrite): Source/WebKit: Content <body> has 'overflow:hidden'. * UIProcess/Cocoa/VersionChecks.h: * UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.cpp: (WebKit::RemoteScrollingCoordinatorProxy::hasScrollableMainFrame const): Fix by adding an app specific LinkedOnOrAfter quirk that always allows main frame scrolling. Canonical link: https://commits.webkit.org/215333@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249770 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/213666.360@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@249997 268f45cc-cd09-0410-ab3c-d52691b4dbfc

[Cocoa] Text indicator for an image link on the front page of apple.com looks wrong https://bugs.webkit.org/show_bug.cgi?id=201724 <rdar://problem/54622894> Reviewed by Tim Horton. Source/WebCore: When computing the bounds of the range (<a>, 0) to (<a>, 1) for a text indicator snapshot where <a> is a link with a single non-breaking whitespace character, we currently use the text rect of the single space. This leads to a confusing text indicator, as the resulting snapshot is a tiny blank square in the top left corner of the link. This problem manifests when starting a drag or showing the system context menu on iOS, or force clicking or three-finger tapping to show a preview on macOS. To address this scenario, tweak the heuristic in the case where the text indicator option TextIndicatorOptionUseBoundingRectAndPaintAllContentForComplexRanges is specified, such that we consider a range containing only text with whitespaces to be "complex"; additionally, instead of falling back to the range's bounding rect (which in this case is still tiny), fall back to the common ancestor container's bounding rect, which encompasses not only the text inside the range but also the element containing the range (in this case, the anchor element). Test: fast/text-indicator/text-indicator-empty-link.html * page/TextIndicator.cpp: (WebCore::containsOnlyWhiteSpaceText): Add a helper to determine whether a Range is comprised only of rendered text that only contains whitespace characters. (WebCore::initializeIndicator): See ChangeLog entry above for more detail. LayoutTests: Add a new layout test to exercise this scenario. * fast/text-indicator/text-indicator-empty-link-expected.txt: Added. * fast/text-indicator/text-indicator-empty-link.html: Added. Canonical link: https://commits.webkit.org/215369@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249813 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/213666.361@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@249998 268f45cc-cd09-0410-ab3c-d52691b4dbfc

REGRESSION (iOS 13): Top fixed element on apple.com flickers in size while pinching in https://bugs.webkit.org/show_bug.cgi?id=201668 rdar://problem/51934041 Reviewed by Frédéric Wang. Source/WebCore: When computing the new layout viewport rect in ScrollingTreeFrameScrollingNode, use "StickToDocumentBounds" mode, not "StickToViewportBounds", because otherwise we'll compute a layout viewport that has negative top/left offsets which causes fixed elements to jump outside the viewport. The only code that should be moving things outside the viewport (a temporary effect that happens when pinching) is the 'isBelowMinimumScale' path in WebPageProxy::computeCustomFixedPositionRect(). With this change ScrollingTreeFrameScrollingNode no longer needs m_behaviorForFixed; it can be removed later. Not currently testable, since it involves pinching in past minimum zoom and transients state. * page/scrolling/ScrollingTreeFrameScrollingNode.cpp: (WebCore::ScrollingTreeFrameScrollingNode::layoutViewportForScrollPosition const): Source/WebKit: The UI process can have transient state that pushes scrolling-tree-managed layers into custom locations while pinch-zooming. We have to apply this state both when the visible rects in the UI process change (existing code in -[WKContentView didUpdateVisibleRect:...]) and when we get new layers from the web process (added in RemoteLayerTreeDrawingAreaProxy::commitLayerTree() in this patch). Move some code into WebPageProxy to create functions that we can call from both places. For manual testing, visit a page with fixed banners, pinch in slightly, then pinch out and, while keeping your fingers down, move the contents around. * UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm: (WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree): * UIProcess/WebPageProxy.h: * UIProcess/ios/WKContentView.mm: (-[WKContentView didUpdateVisibleRect:unobscuredRect:contentInsets:unobscuredRectInScrollViewCoordinates:obscuredInsets:unobscuredSafeAreaInsets:inputViewBounds:scale:minimumScale:inStableState:isChangingObscuredInsetsInteractively:enclosedInScrollableAncestorView:]): * UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::unconstrainedLayoutViewportRect const): (WebKit::WebPageProxy::adjustLayersForLayoutViewport): Canonical link: https://commits.webkit.org/215371@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249815 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/213666.362@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@249999 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Canonical link: https://commits.webkit.org/213666.363@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@250007 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Canonical link: https://commits.webkit.org/213666.364@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@250008 268f45cc-cd09-0410-ab3c-d52691b4dbfc

[Pointer Events] The button and buttons properties are incorrect on iOS https://bugs.webkit.org/show_bug.cgi?id=199910 <rdar://problem/52778374> Reviewed by Dean Jackson. Source/WebCore: The button and buttons properties were always set to 0 on iOS. We now use the correct values such that button is always 0 except for "pointermove" where it's -1, and "buttons" is 1 as long as the pointer is in contact with the touch surface. Tests: pointerevents/ios/pointer-event-button-and-buttons-pointer-cancel.html pointerevents/ios/pointer-event-button-and-buttons.html * dom/ios/PointerEventIOS.cpp: (WebCore::buttonForType): (WebCore::buttonsForType): (WebCore::PointerEvent::PointerEvent): LayoutTests: * pointerevents/ios/pointer-event-button-and-buttons-expected.txt: Added. * pointerevents/ios/pointer-event-button-and-buttons-pointer-cancel-expected.txt: Added. * pointerevents/ios/pointer-event-button-and-buttons-pointer-cancel.html: Added. * pointerevents/ios/pointer-event-button-and-buttons.html: Added. Canonical link: https://commits.webkit.org/213793@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247573 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/213666.365@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@250010 268f45cc-cd09-0410-ab3c-d52691b4dbfc

[WebIDL] Derived dictionaries should inherit their inherited dictionaries' partials https://bugs.webkit.org/show_bug.cgi?id=201802 Reviewed by Sam Weinig. Prior to this change, a dictionary D that inherits from dictionary B would not inherit B's partial dictionaries. Fixed this by moving supplemental dependencies processing from generate-bindings.pl to CodeGenerator.pm and reusing it in GetDictionaryByType. Added new bindings tests. * bindings/scripts/CodeGenerator.pm: (new): (ProcessDocument): (ProcessSupplementalDependencies): (shouldPropertyBeExposed): (GetDictionaryByType): * bindings/scripts/generate-bindings.pl: (generateBindings): (shouldPropertyBeExposed): Deleted. * bindings/scripts/test/JS/JSTestDerivedDictionary.cpp: Added. (WebCore::convertDictionary<TestDerivedDictionary>): (WebCore::convertDictionaryToJS): * bindings/scripts/test/JS/JSTestDerivedDictionary.h: Added. * bindings/scripts/test/JS/JSTestInheritedDictionary.cpp: Added. (WebCore::convertDictionary<TestInheritedDictionary>): (WebCore::convertDictionaryToJS): * bindings/scripts/test/JS/JSTestInheritedDictionary.h: Added. * bindings/scripts/test/TestDerivedDictionary.idl: Added. * bindings/scripts/test/TestInheritedDictionary.idl: Added. * bindings/scripts/test/TestSupplemental.idl: Canonical link: https://commits.webkit.org/215442@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249888 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/213666.366@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@250011 268f45cc-cd09-0410-ab3c-d52691b4dbfc

JSObject::putInlineSlow should not ignore "__proto__" for Proxy https://bugs.webkit.org/show_bug.cgi?id=200386 <rdar://problem/53854946> Reviewed by Yusuke Suzuki. JSTests: * stress/proxy-__proto__-in-prototype-chain.js: Added. * stress/proxy-property-replace-structure-transition.js: Added. Source/JavaScriptCore: We used to ignore '__proto__' in putInlineSlow when the object in question was Proxy. There is no reason for this, and it goes against the spec. So I've removed that condition. This also has the effect that it fixes an assertion firing inside our inline caching code which dictates that for a property replace that the base value's structure must be equal to the structure when we grabbed the structure prior to the put operation. The old code caused a weird edge case where we broke this invariant. * runtime/JSObject.cpp: (JSC::JSObject::putInlineSlow): Canonical link: https://commits.webkit.org/215465@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249911 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/213666.367@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@250012 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Provide a prototype for AR QuickLook to trigger processing in the originating page https://bugs.webkit.org/show_bug.cgi?id=201371 Hopefully fix the public iOS 13 build. Source/WebCore/PAL: * pal/spi/ios/SystemPreviewSPI.h: Source/WebKit: * UIProcess/Cocoa/SystemPreviewControllerCocoa.mm: Canonical link: https://commits.webkit.org/215487@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249936 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/213666.368@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@250013 268f45cc-cd09-0410-ab3c-d52691b4dbfc

[First-letter] Use WeakPtr for the first-letter insertion point. https://bugs.webkit.org/show_bug.cgi?id=201842 <rdar://problem/51373788> Reviewed by Antti Koivisto. Source/WebCore: The about-to-be-removed first letter renderer's sibling could potentially be destroyed too as the result of the anonymous subtree collapsing logic (when the next sibling is a generated anonymous block and it is not needed anymore.) Test: fast/text/first-letter-with-columns-crash.html * rendering/updating/RenderTreeBuilderFirstLetter.cpp: (WebCore::RenderTreeBuilder::FirstLetter::updateStyle): LayoutTests: * fast/text/first-letter-with-columns-crash-expected.txt: Added. * fast/text/first-letter-with-columns-crash.html: Added. Canonical link: https://commits.webkit.org/215505@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249954 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/213666.369@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@250014 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Canonical link: https://commits.webkit.org/213666.370@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@250017 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Canonical link: https://commits.webkit.org/213666.371@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@250134 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Canonical link: https://commits.webkit.org/213666.372@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@250137 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Canonical link: https://commits.webkit.org/213666.373@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@250245 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Remove the "Show Link Previews" and "Hide Link Previews" action menus in the preview platter https://bugs.webkit.org/show_bug.cgi?id=201864 <rdar://55190038> Reviewed by Simon Fraser. Source/WebKit: * UIProcess/ios/WKActionSheetAssistant.mm: Remove the toggle action from the default values. (-[WKActionSheetAssistant defaultActionsForLinkSheet:]): * UIProcess/ios/WKContentViewInteraction.mm: No longer try to add a toggle when it isn't there. (-[WKContentView assignLegacyDataForContextMenuInteraction]): (menuWithShowLinkPreviewAction): Deleted. Tools: Test for the suggested actions. * TestWebKitAPI/Tests/WebKitCocoa/ContextMenus.mm: (-[TestContextMenuSuggestedActionsUIDelegate webView:contextMenuConfigurationForElement:completionHandler:]): (-[TestContextMenuSuggestedActionsUIDelegate webView:contextMenuWillPresentForElement:]): (TEST): Canonical link: https://commits.webkit.org/215541@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250015 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/213666.374@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@250246 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=226751 Reviewed by Simon Fraser. Source/WebCore: This patch adds the initial support for content like this: <table> <tr> <td style="width: 10%"></td><td style="width: 90%"></td> </tr> </table> Percent values work in mysterious ways in cases when the table has no fixed width. 1. The smaller the percent value is, the wider the table may become. Percent values are resolved against the cell's border box (so essentially they are resolved against their own content as opposed to the table/containing block) and the formula is slightly different. <td style="padding: 5px; width: 20%;"></td> : produces a 10px wide border box (horizontal border: 0px, padding: 10px, content: 0px). The maximum constraint is resolved to 50px (width / percent * 100) <td style="padding: 5px; width: 100%;"></td> : produces a 10px wide border box and the maximum constraint is resolved to 10px. This maximum constraint value turns into the available width for the table content and becomes the final table width. 2. With multiple rows, we pick the highest _percent_ value for each column (as opposed to the resolved values). <tr><td style="width: 20%"></td></tr> (assum same 5px padding on both sides) <tr><td style="width: 80%"></td></tr> While the second row's cell has a higher maximum constraint value (50px see #1) since we only look at the raw percent values, this content only produces a 12.5px wide table. 3. The percent values do not accumulate across columns but instead we pick the largest one to represent the entire table's max constraint width. <tr><td style="width: 60%"></td><td style="width: 40%"></td></tr> 60% resolves to 16.6px 40% resolves to 25px and we use the 25px value as the width for the entire table (and not 16.6px + 25px). 4. Since we pick the highest percent values across rows for each columns, we may end up with > 100%. In such cases we start dropping percent values for subsequent columns: <tr><td style="width: 20%;"></td><td style="width: 80%;"></td></tr> <tr><td style="width: 60%;"></td><td style="width: 10%;"></td></tr> First column width is max(20%, 60%) -> 60% Second column width is max(80%, 10%) -> 80% As we limit the accumulated percent value to 100%, the final column percent values are 60% and 40% (and not 80%). Now the 60% is resolved to 16.6px and the 40% is resolved to 25px and since we don't accumulate these values (see #3) the final table width is 25px (based on a percent value which is not even in the markup). 5. While the smaller percent values produce wider tables (see #1), during the available space distribution columns with smaller percent values get assigned less space. <tr><td style="width: 1%"></td><td style="width: 99%"></td></tr> This content produces a 1000px wide table due to the small (1%) percent value (see #1 #2 and #3). When we distribute the available space (1000px), the first cell gets only 10px (1%) while the second cell ends up with 990px (99%). (and this is the cherry on top (not included in this patch): Imagine the following scenario: 1. the accumulated column percent value > 100% (let's say 80% and 30%) 2. as we reach the 100% while walking the columns one by one (see #4), the remaining percent value becomes 0%. 3. In order to avoid division by 0, we pick a very small epsilon value to run the formula. 4. Now this very small percent value produces a large resolved value (see #2) which means <tr><td style="width: 100%"></td></tr> produces a 10px wide table <tr><td style="width: 100%"></td><td style="width: 1%"></td></tr> <- note the 1% produces a very very very wide table. ) Test: fast/layoutformattingcontext/table-with-percent-columns-only-no-content.html * layout/formattingContexts/table/TableFormattingContext.cpp: (WebCore::Layout::TableFormattingContext::computedIntrinsicWidthConstraints): (WebCore::Layout::TableFormattingContext::computedPreferredWidthForColumns): * layout/formattingContexts/table/TableGrid.h: (WebCore::Layout::TableGrid::Column::percent const): (WebCore::Layout::TableGrid::Column::setFixedWidth): (WebCore::Layout::TableGrid::Column::setPercent): * layout/formattingContexts/table/TableLayout.cpp: (WebCore::Layout::TableFormattingContext::TableLayout::distributedHorizontalSpace): LayoutTests: * fast/layoutformattingcontext/table-with-percent-columns-only-no-content-expected.html: Added. * fast/layoutformattingcontext/table-with-percent-columns-only-no-content.html: Added. Canonical link: https://commits.webkit.org/238594@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@278605 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=228047 Reviewed by Phil Pizlo. Pre-indexed addressing means that the address is the sum of the value in the 64-bit base register and an offset, and the address is then written back to the base register. And post-indexed addressing means that the address is the value in the 64-bit base register, and the sum of the address and the offset is then written back to the base register. They are relatively common for loops to iterate over an array by increasing/decreasing a pointer into the array at each iteration. With such an addressing mode, the instruction selector can merge the increment and access the array. ##################################### ## Pre-Index Address Mode For Load ## ##################################### LDR Wt, [Xn, #imm]! In B3 Reduction Strength, since we have this reduction rule: Turn this: Load(Add(address, offset1), offset = offset2) Into this: Load(address, offset = offset1 + offset2) Then, the equivalent pattern is: address = Add(base, offset) ... memory = Load(base, offset) First, we convert it to the canonical form: address = Add(base, offset) newMemory = Load(base, offset) // move the memory to just after the address ... memory = Identity(newMemory) Next, lower to Air: Move %base, %address Move (%address, prefix(offset)), %newMemory ###################################### ## Post-Index Address Mode For Load ## ###################################### LDR Wt, [Xn], #imm Then, the equivalent pattern is: memory = Load(base, 0) ... address = Add(base, offset) First, we convert it to the canonical form: newOffset = Constant newAddress = Add(base, offset) memory = Load(base, 0) // move the offset and address to just before the memory ... offset = Identity(newOffset) address = Identity(newAddress) Next, lower to Air: Move %base, %newAddress Move (%newAddress, postfix(offset)), %memory ############################# ## Pattern Match Algorithm ## ############################# To detect the pattern for prefix/postfix increment address is tricky due to the structure in B3 IR. The algorithm used in this patch is to collect the first valid values (add/load), then search for any paired value (load/add) to match all of them. In worst case, the runtime complexity is O(n^2) when n is the number of all values. After collecting two sets of candidates, we match the prefix incremental address first since it seems more beneficial to the compiler (shown in the next section). And then, go for the postfix one. ############################################## ## Test for Pre/Post-Increment Address Mode ## ############################################## Given Loop with Pre-Increment: int64_t ldr_pre(int64_t *p) { int64_t res = 0; while (res < 10) res += *++p; return res; } B3 IR: ------------------------------------------------------ BB#0: ; frequency = 1.000000 Int64 b@0 = Const64(0) Int64 b@2 = ArgumentReg(%x0) Void b@20 = Upsilon($0(b@0), ^18, WritesLocalState) Void b@21 = Upsilon(b@2, ^19, WritesLocalState) Void b@4 = Jump(Terminal) Successors: #1 BB#1: ; frequency = 1.000000 Predecessors: #0, #2 Int64 b@18 = Phi(ReadsLocalState) Int64 b@19 = Phi(ReadsLocalState) Int64 b@7 = Const64(10) Int32 b@8 = AboveEqual(b@18, $10(b@7)) Void b@9 = Branch(b@8, Terminal) Successors: Then:#3, Else:#2 BB#2: ; frequency = 1.000000 Predecessors: #1 Int64 b@10 = Const64(8) Int64 b@11 = Add(b@19, $8(b@10)) Int64 b@13 = Load(b@11, ControlDependent|Reads:Top) Int64 b@14 = Add(b@18, b@13) Void b@22 = Upsilon(b@14, ^18, WritesLocalState) Void b@23 = Upsilon(b@11, ^19, WritesLocalState) Void b@16 = Jump(Terminal) Successors: #1 BB#3: ; frequency = 1.000000 Predecessors: #1 Void b@17 = Return(b@18, Terminal) Variables: Int64 var0 Int64 var1 ------------------------------------------------------ W/O Pre-Increment Address Mode: ------------------------------------------------------ ... BB#2: ; frequency = 1.000000 Predecessors: #1 Move $8, %x3, $8(b@12) Add64 $8, %x0, %x1, b@11 Move (%x0,%x3), %x0, b@13 Add64 %x0, %x2, %x2, b@14 Move %x1, %x0, b@23 Jump b@16 Successors: #1 ... ------------------------------------------------------ W/ Pre-Increment Address Mode: ------------------------------------------------------ ... BB#2: ; frequency = 1.000000 Predecessors: #1 MoveWithIncrement64 (%x0,Pre($8)), %x2, b@13 Add64 %x2, %x1, %x1, b@14 Jump b@16 Successors: #1 ... ------------------------------------------------------ Given Loop with Post-Increment: int64_t ldr_pre(int64_t *p) { int64_t res = 0; while (res < 10) res += *p++; return res; } B3 IR: ------------------------------------------------------ BB#0: ; frequency = 1.000000 Int64 b@0 = Const64(0) Int64 b@2 = ArgumentReg(%x0) Void b@20 = Upsilon($0(b@0), ^18, WritesLocalState) Void b@21 = Upsilon(b@2, ^19, WritesLocalState) Void b@4 = Jump(Terminal) Successors: #1 BB#1: ; frequency = 1.000000 Predecessors: #0, #2 Int64 b@18 = Phi(ReadsLocalState) Int64 b@19 = Phi(ReadsLocalState) Int64 b@7 = Const64(10) Int32 b@8 = AboveEqual(b@18, $10(b@7)) Void b@9 = Branch(b@8, Terminal) Successors: Then:#3, Else:#2 BB#2: ; frequency = 1.000000 Predecessors: #1 Int64 b@10 = Load(b@19, ControlDependent|Reads:Top) Int64 b@11 = Add(b@18, b@10) Int64 b@12 = Const64(8) Int64 b@13 = Add(b@19, $8(b@12)) Void b@22 = Upsilon(b@11, ^18, WritesLocalState) Void b@23 = Upsilon(b@13, ^19, WritesLocalState) Void b@16 = Jump(Terminal) Successors: #1 BB#3: ; frequency = 1.000000 Predecessors: #1 Void b@17 = Return(b@18, Terminal) Variables: Int64 var0 Int64 var1 ------------------------------------------------------ W/O Post-Increment Address Mode: ------------------------------------------------------ ... BB#2: ; frequency = 1.000000 Predecessors: #1 Move (%x0), %x2, b@10 Add64 %x2, %x1, %x1, b@11 Add64 $8, %x0, %x0, b@13 Jump b@16 Successors: #1 ... ------------------------------------------------------ W/ Post-Increment Address Mode: ------------------------------------------------------ ... BB#2: ; frequency = 1.000000 Predecessors: #1 MoveWithIncrement64 (%x0,Post($8)), %x2, b@10 Add64 %x2, %x1, %x1, b@11 Jump b@16 Successors: #1 ... ------------------------------------------------------ * Sources.txt: * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::PreIndexAddress::PreIndexAddress): (JSC::AbstractMacroAssembler::PostIndexAddress::PostIndexAddress): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::load64): (JSC::MacroAssemblerARM64::load32): (JSC::MacroAssemblerARM64::store64): (JSC::MacroAssemblerARM64::store32): * assembler/testmasm.cpp: (JSC::testStorePrePostIndex32): (JSC::testStorePrePostIndex64): (JSC::testLoadPrePostIndex32): (JSC::testLoadPrePostIndex64): * b3/B3CanonicalizePrePostIncrements.cpp: Added. (JSC::B3::canonicalizePrePostIncrements): * b3/B3CanonicalizePrePostIncrements.h: Copied from Source/JavaScriptCore/b3/B3ValueKeyInlines.h. * b3/B3Generate.cpp: (JSC::B3::generateToAir): * b3/B3LowerToAir.cpp: * b3/B3ValueKey.h: * b3/B3ValueKeyInlines.h: (JSC::B3::ValueKey::ValueKey): * b3/air/AirArg.cpp: (JSC::B3::Air::Arg::jsHash const): (JSC::B3::Air::Arg::dump const): (WTF::printInternal): * b3/air/AirArg.h: (JSC::B3::Air::Arg::preIndex): (JSC::B3::Air::Arg::postIndex): (JSC::B3::Air::Arg::isPreIndex const): (JSC::B3::Air::Arg::isPostIndex const): (JSC::B3::Air::Arg::isMemory const): (JSC::B3::Air::Arg::base const): (JSC::B3::Air::Arg::offset const): (JSC::B3::Air::Arg::isGP const): (JSC::B3::Air::Arg::isFP const): (JSC::B3::Air::Arg::isValidPreIndexForm): (JSC::B3::Air::Arg::isValidPostIndexForm): (JSC::B3::Air::Arg::isValidForm const): (JSC::B3::Air::Arg::forEachTmpFast): (JSC::B3::Air::Arg::forEachTmp): (JSC::B3::Air::Arg::asPreIndexAddress const): (JSC::B3::Air::Arg::asPostIndexAddress const): * b3/air/AirOpcode.opcodes: * b3/air/opcode_generator.rb: * b3/testb3.h: * b3/testb3_3.cpp: (testLoadPreIndex32): (testLoadPreIndex64): (testLoadPostIndex32): (testLoadPostIndex64): (addShrTests): * jit/ExecutableAllocator.cpp: (JSC::jitWriteThunkGenerator): Canonical link: https://commits.webkit.org/240125@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280493 268f45cc-cd09-0410-ab3c-d52691b4dbfc

… be called more than once under WebCore::MediaControlsContextMenuProvider::contextMenuItemSelected https://bugs.webkit.org/show_bug.cgi?id=228725 <rdar://problem/81437221> Reviewed by Eric Carlson. The contextmenu system used by (modern) media controls are a bit wonky in that it has to support both macOS and iOS, which use wildly different mechanisms. The former has distinct methods for handling when a contextmenu item is selected vs when the menu is dismissed (at least as of r280374). The latter has a single method that handles both. Additionally, the (modern) media controls JS expects the following from `showMediaControlsContextMenu`: 1. `showMediaControlsContextMenu` will only `return true` if the contextmenu will be shown 2. the callback provided to `showMediaControlsContextMenu` will always/only be invoked when the contextmenu is dismissed (regardless of whether an item is selected) 3. if an item is selected, the logic for that will be handled by the `MediaControlsHost` This patch primarily addresses #2, but also slightly adjusts the code to fix #1. It does #1 by moving the call that saves the callback further down. On iOS, #2 already works. On macOS, it does #2 by changing from `CompletionHandler` to `Function`, allowing it to be called more than once, with the understanding that the JS callback will not be invoked more than once. This way, macOS can match the behavior of iOS by eagerly invoking the JS callback when a contextmenu item is selected without waiting for the menu to actually dismiss, while still handling the contextmenu being dismissed without an item being selected (and also not having to worry about whether the `CompletionHandler` has already been invoked). * Modules/mediacontrols/MediaControlsHost.h: * Modules/mediacontrols/MediaControlsHost.cpp: (WebCore::MediaControlsContextMenuProvider::create): (WebCore::MediaControlsContextMenuProvider::MediaControlsContextMenuProvider): (WebCore::MediaControlsContextMenuProvider::didDismissContextMenu): (WebCore::MediaControlsContextMenuProvider::contextMenuCleared): (WebCore::MediaControlsHost::showMediaControlsContextMenu): Canonical link: https://commits.webkit.org/240278@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@280676 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=232265 Patch by Mikhail R. Gadelha <mikhail@igalia.com> on 2021-11-09 Reviewed by Saam Barati. Follow-up from https://bugs.webkit.org/show_bug.cgi?id=232242, this patch includes several small code changes but the patch doesn't add/remove any feature: 1. Removed several calls to operationPutByVal*Cell* that were only used by the 32 bit code paths due to the lack of registers. These calls were replaced by the calls used by the 64 bit paths, that expect EncodedJSValues 2. Because of #1, this patch removes those methods, since no one uses them anymore. 3. Created compilePutByVal to handle all cases (similar to compileGetByVal). 4. Removed the Edge& childX from the PutByVal handling (and all methods that expected them) in favor of getting them from node when needed. 5. Unified compileContiguousPutByVal so it could be used by both 32 and 64 bit archs. 6. Removed a lot of whitespace. * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal): (JSC::DFG::SpeculativeJIT::compileDoublePutByVal): (JSC::DFG::SpeculativeJIT::compilePutByVal): (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray): Deleted. (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray): Deleted. (JSC::DFG::SpeculativeJIT::compileGetByValForObjectWithString): Deleted. (JSC::DFG::SpeculativeJIT::compileGetByValForObjectWithSymbol): Deleted. (JSC::DFG::SpeculativeJIT::compileGetPrivateName): Deleted. (JSC::DFG::SpeculativeJIT::compileGetPrivateNameByVal): Deleted. (JSC::DFG::SpeculativeJIT::compileGetPrivateNameById): Deleted. (JSC::DFG::SpeculativeJIT::compilePutByValForCellWithString): Deleted. (JSC::DFG::SpeculativeJIT::compilePutByValForCellWithSymbol): Deleted. (JSC::DFG::SpeculativeJIT::compileGetByValWithThis): Deleted. (JSC::DFG::SpeculativeJIT::compilePutPrivateName): Deleted. (JSC::DFG::SpeculativeJIT::compilePutPrivateNameById): Deleted. (JSC::DFG::SpeculativeJIT::compileCheckPrivateBrand): Deleted. (JSC::DFG::SpeculativeJIT::compileSetPrivateBrand): Deleted. (JSC::DFG::SpeculativeJIT::compileCheckTypeInfoFlags): Deleted. (JSC::DFG::SpeculativeJIT::compileParseInt): Deleted. (JSC::DFG::SpeculativeJIT::compileOverridesHasInstance): Deleted. (JSC::DFG::SpeculativeJIT::compileInstanceOfForCells): Deleted. (JSC::DFG::SpeculativeJIT::compileInstanceOf): Deleted. (JSC::DFG::SpeculativeJIT::compileValueBitNot): Deleted. (JSC::DFG::SpeculativeJIT::compileBitwiseNot): Deleted. (JSC::DFG::SpeculativeJIT::emitUntypedOrAnyBigIntBitOp): Deleted. (JSC::DFG::SpeculativeJIT::compileValueBitwiseOp): Deleted. (JSC::DFG::SpeculativeJIT::compileBitwiseOp): Deleted. (JSC::DFG::SpeculativeJIT::emitUntypedOrBigIntRightShiftBitOp): Deleted. (JSC::DFG::SpeculativeJIT::compileValueLShiftOp): Deleted. (JSC::DFG::SpeculativeJIT::compileValueBitRShift): Deleted. (JSC::DFG::SpeculativeJIT::compileShiftOp): Deleted. (JSC::DFG::SpeculativeJIT::compileValueAdd): Deleted. (JSC::DFG::SpeculativeJIT::compileValueSub): Deleted. (JSC::DFG::SpeculativeJIT::compileMathIC): Deleted. (JSC::DFG::SpeculativeJIT::compileInstanceOfCustom): Deleted. (JSC::DFG::SpeculativeJIT::compileIsCellWithType): Deleted. (JSC::DFG::SpeculativeJIT::compileIsTypedArrayView): Deleted. (JSC::DFG::SpeculativeJIT::compileToObjectOrCallObjectConstructor): Deleted. (JSC::DFG::SpeculativeJIT::compileArithAdd): Deleted. (JSC::DFG::SpeculativeJIT::compileArithAbs): Deleted. (JSC::DFG::SpeculativeJIT::compileArithClz32): Deleted. (JSC::DFG::SpeculativeJIT::compileArithDoubleUnaryOp): Deleted. (JSC::DFG::SpeculativeJIT::compileArithSub): Deleted. (JSC::DFG::SpeculativeJIT::compileIncOrDec): Deleted. (JSC::DFG::SpeculativeJIT::compileValueNegate): Deleted. (JSC::DFG::SpeculativeJIT::compileArithNegate): Deleted. (JSC::DFG::SpeculativeJIT::compileValueMul): Deleted. (JSC::DFG::SpeculativeJIT::compileArithMul): Deleted. (JSC::DFG::SpeculativeJIT::compileValueDiv): Deleted. (JSC::DFG::SpeculativeJIT::compileArithDiv): Deleted. (JSC::DFG::SpeculativeJIT::compileArithFRound): Deleted. (JSC::DFG::SpeculativeJIT::compileValueMod): Deleted. (JSC::DFG::SpeculativeJIT::compileArithMod): Deleted. (JSC::DFG::SpeculativeJIT::compileArithRounding): Deleted. (JSC::DFG::SpeculativeJIT::compileArithUnary): Deleted. (JSC::DFG::SpeculativeJIT::compileArithSqrt): Deleted. (JSC::DFG::SpeculativeJIT::compileArithMinMax): Deleted. (JSC::DFG::compileArithPowIntegerFastPath): Deleted. (JSC::DFG::SpeculativeJIT::compileValuePow): Deleted. (JSC::DFG::SpeculativeJIT::compileArithPow): Deleted. (JSC::DFG::SpeculativeJIT::compare): Deleted. (JSC::DFG::SpeculativeJIT::compileCompareUnsigned): Deleted. (JSC::DFG::SpeculativeJIT::compileStrictEq): Deleted. (JSC::DFG::SpeculativeJIT::compileBooleanCompare): Deleted. (JSC::DFG::SpeculativeJIT::compileInt32Compare): Deleted. (JSC::DFG::SpeculativeJIT::compileDoubleCompare): Deleted. (JSC::DFG::SpeculativeJIT::compileObjectEquality): Deleted. (JSC::DFG::SpeculativeJIT::compileSymbolEquality): Deleted. (JSC::DFG::SpeculativeJIT::compilePeepHoleSymbolEquality): Deleted. (JSC::DFG::SpeculativeJIT::emitBitwiseJSValueEquality): Deleted. (JSC::DFG::SpeculativeJIT::emitBranchOnBitwiseJSValueEquality): Deleted. (JSC::DFG::SpeculativeJIT::compileNotDoubleNeitherDoubleNorHeapBigIntNorStringStrictEquality): Deleted. (JSC::DFG::SpeculativeJIT::compilePeepHoleNotDoubleNeitherDoubleNorHeapBigIntNorStringStrictEquality): Deleted. (JSC::DFG::SpeculativeJIT::compileStringEquality): Deleted. (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality): Deleted. (JSC::DFG::SpeculativeJIT::compileStringIdentEquality): Deleted. (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality): Deleted. (JSC::DFG::SpeculativeJIT::compileStringCompare): Deleted. (JSC::DFG::SpeculativeJIT::compileStringIdentCompare): Deleted. (JSC::DFG::SpeculativeJIT::compileSameValue): Deleted. (JSC::DFG::SpeculativeJIT::compileToBooleanString): Deleted. (JSC::DFG::SpeculativeJIT::compileToBooleanStringOrOther): Deleted. (JSC::DFG::SpeculativeJIT::emitStringBranch): Deleted. (JSC::DFG::SpeculativeJIT::emitStringOrOtherBranch): Deleted. (JSC::DFG::SpeculativeJIT::compileConstantStoragePointer): Deleted. (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage): Deleted. (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): Deleted. (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset): Deleted. (JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments): Deleted. (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments): Deleted. (JSC::DFG::SpeculativeJIT::compileGetScope): Deleted. (JSC::DFG::SpeculativeJIT::compileSkipScope): Deleted. (JSC::DFG::SpeculativeJIT::compileGetGlobalObject): Deleted. (JSC::DFG::SpeculativeJIT::compileGetGlobalThis): Deleted. (JSC::DFG::SpeculativeJIT::canBeRope): Deleted. (JSC::DFG::SpeculativeJIT::compileGetArrayLength): Deleted. (JSC::DFG::SpeculativeJIT::compileCheckIdent): Deleted. (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon): Deleted. (JSC::DFG::SpeculativeJIT::compileNewFunction): Deleted. (JSC::DFG::SpeculativeJIT::compileSetFunctionName): Deleted. (JSC::DFG::SpeculativeJIT::compileVarargsLength): Deleted. (JSC::DFG::SpeculativeJIT::compileLoadVarargs): Deleted. (JSC::DFG::SpeculativeJIT::compileForwardVarargs): Deleted. (JSC::DFG::SpeculativeJIT::compileCreateActivation): Deleted. (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments): Deleted. (JSC::DFG::SpeculativeJIT::compileGetFromArguments): Deleted. (JSC::DFG::SpeculativeJIT::compilePutToArguments): Deleted. (JSC::DFG::SpeculativeJIT::compileGetArgument): Deleted. (JSC::DFG::SpeculativeJIT::compileCreateScopedArguments): Deleted. (JSC::DFG::SpeculativeJIT::compileCreateClonedArguments): Deleted. (JSC::DFG::SpeculativeJIT::compileCreateArgumentsButterfly): Deleted. (JSC::DFG::SpeculativeJIT::compileCreateRest): Deleted. (JSC::DFG::SpeculativeJIT::compileSpread): Deleted. (JSC::DFG::SpeculativeJIT::compileNewArray): Deleted. (JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread): Deleted. (JSC::DFG::SpeculativeJIT::compileGetRestLength): Deleted. (JSC::DFG::SpeculativeJIT::emitPopulateSliceIndex): Deleted. (JSC::DFG::SpeculativeJIT::compileArraySlice): Deleted. (JSC::DFG::SpeculativeJIT::compileArrayIndexOf): Deleted. (JSC::DFG::SpeculativeJIT::compileArrayPush): Deleted. (JSC::DFG::SpeculativeJIT::compileNotifyWrite): Deleted. (JSC::DFG::SpeculativeJIT::compileIsObject): Deleted. (JSC::DFG::SpeculativeJIT::compileTypeOfIsObject): Deleted. (JSC::DFG::SpeculativeJIT::compileIsCallable): Deleted. (JSC::DFG::SpeculativeJIT::compileIsConstructor): Deleted. (JSC::DFG::SpeculativeJIT::compileTypeOf): Deleted. (JSC::DFG::SpeculativeJIT::emitStructureCheck): Deleted. (JSC::DFG::SpeculativeJIT::compileCheckIsConstant): Deleted. (JSC::DFG::SpeculativeJIT::compileCheckNotEmpty): Deleted. (JSC::DFG::SpeculativeJIT::compileCheckStructure): Deleted. (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage): Deleted. (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage): Deleted. (JSC::DFG::SpeculativeJIT::compileNukeStructureAndSetButterfly): Deleted. (JSC::DFG::SpeculativeJIT::compileGetButterfly): Deleted. (JSC::DFG::allocateTemporaryRegistersForSnippet): Deleted. (JSC::DFG::SpeculativeJIT::compileCallDOM): Deleted. (JSC::DFG::SpeculativeJIT::compileCallDOMGetter): Deleted. (JSC::DFG::SpeculativeJIT::compileCheckJSCast): Deleted. (JSC::DFG::SpeculativeJIT::temporaryRegisterForPutByVal): Deleted. (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOrStringValueOf): Deleted. (JSC::DFG::getExecutable): Deleted. (JSC::DFG::SpeculativeJIT::compileFunctionToString): Deleted. (JSC::DFG::SpeculativeJIT::compileNumberToStringWithValidRadixConstant): Deleted. (JSC::DFG::SpeculativeJIT::compileNumberToStringWithRadix): Deleted. (JSC::DFG::SpeculativeJIT::compileNewStringObject): Deleted. (JSC::DFG::SpeculativeJIT::compileNewSymbol): Deleted. (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize): Deleted. (JSC::DFG::SpeculativeJIT::emitNewTypedArrayWithSizeInRegister): Deleted. (JSC::DFG::SpeculativeJIT::compileNewRegexp): Deleted. (JSC::DFG::SpeculativeJIT::speculateCellTypeWithoutTypeFiltering): Deleted. (JSC::DFG::SpeculativeJIT::speculateCellType): Deleted. (JSC::DFG::SpeculativeJIT::speculateInt32): Deleted. (JSC::DFG::SpeculativeJIT::speculateNumber): Deleted. (JSC::DFG::SpeculativeJIT::speculateRealNumber): Deleted. (JSC::DFG::SpeculativeJIT::speculateDoubleRepReal): Deleted. (JSC::DFG::SpeculativeJIT::speculateBoolean): Deleted. (JSC::DFG::SpeculativeJIT::speculateCell): Deleted. (JSC::DFG::SpeculativeJIT::speculateCellOrOther): Deleted. (JSC::DFG::SpeculativeJIT::speculateObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateFunction): Deleted. (JSC::DFG::SpeculativeJIT::speculateFinalObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateRegExpObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateArray): Deleted. (JSC::DFG::SpeculativeJIT::speculateProxyObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateDerivedArray): Deleted. (JSC::DFG::SpeculativeJIT::speculatePromiseObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateDateObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateMapObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateSetObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateWeakMapObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateWeakSetObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateDataViewObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateObjectOrOther): Deleted. (JSC::DFG::SpeculativeJIT::speculateString): Deleted. (JSC::DFG::SpeculativeJIT::speculateStringOrOther): Deleted. (JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage): Deleted. (JSC::DFG::SpeculativeJIT::speculateStringIdent): Deleted. (JSC::DFG::SpeculativeJIT::speculateStringObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateStringOrStringObject): Deleted. (JSC::DFG::SpeculativeJIT::speculateNotStringVar): Deleted. (JSC::DFG::SpeculativeJIT::speculateNotSymbol): Deleted. (JSC::DFG::SpeculativeJIT::speculateSymbol): Deleted. (JSC::DFG::SpeculativeJIT::speculateHeapBigInt): Deleted. (JSC::DFG::SpeculativeJIT::speculateNotCell): Deleted. (JSC::DFG::SpeculativeJIT::speculateNotCellNorBigInt): Deleted. (JSC::DFG::SpeculativeJIT::speculateNotDouble): Deleted. (JSC::DFG::SpeculativeJIT::speculateNeitherDoubleNorHeapBigInt): Deleted. (JSC::DFG::SpeculativeJIT::speculateNeitherDoubleNorHeapBigIntNorString): Deleted. (JSC::DFG::SpeculativeJIT::speculateOther): Deleted. (JSC::DFG::SpeculativeJIT::speculateMisc): Deleted. (JSC::DFG::SpeculativeJIT::speculate): Deleted. (JSC::DFG::SpeculativeJIT::emitSwitchIntJump): Deleted. (JSC::DFG::SpeculativeJIT::emitSwitchImm): Deleted. (JSC::DFG::SpeculativeJIT::emitSwitchCharStringJump): Deleted. (JSC::DFG::SpeculativeJIT::emitSwitchChar): Deleted. (JSC::DFG::SpeculativeJIT::emitBinarySwitchStringRecurse): Deleted. (JSC::DFG::SpeculativeJIT::emitSwitchStringOnString): Deleted. (JSC::DFG::SpeculativeJIT::emitSwitchString): Deleted. (JSC::DFG::SpeculativeJIT::emitSwitch): Deleted. (JSC::DFG::SpeculativeJIT::addBranch): Deleted. (JSC::DFG::SpeculativeJIT::linkBranches): Deleted. (JSC::DFG::SpeculativeJIT::compileStoreBarrier): Deleted. (JSC::DFG::SpeculativeJIT::compilePutAccessorById): Deleted. (JSC::DFG::SpeculativeJIT::compilePutGetterSetterById): Deleted. (JSC::DFG::SpeculativeJIT::compileResolveScope): Deleted. (JSC::DFG::SpeculativeJIT::compileResolveScopeForHoistingFuncDeclInEval): Deleted. (JSC::DFG::SpeculativeJIT::compileGetGlobalVariable): Deleted. (JSC::DFG::SpeculativeJIT::compilePutGlobalVariable): Deleted. (JSC::DFG::SpeculativeJIT::compileGetDynamicVar): Deleted. (JSC::DFG::SpeculativeJIT::compilePutDynamicVar): Deleted. (JSC::DFG::SpeculativeJIT::compileGetClosureVar): Deleted. (JSC::DFG::SpeculativeJIT::compilePutClosureVar): Deleted. (JSC::DFG::SpeculativeJIT::compileGetInternalField): Deleted. (JSC::DFG::SpeculativeJIT::compilePutInternalField): Deleted. (JSC::DFG::SpeculativeJIT::compilePutAccessorByVal): Deleted. (JSC::DFG::SpeculativeJIT::compileGetRegExpObjectLastIndex): Deleted. (JSC::DFG::SpeculativeJIT::compileSetRegExpObjectLastIndex): Deleted. (JSC::DFG::SpeculativeJIT::compileRegExpExec): Deleted. (JSC::DFG::SpeculativeJIT::compileRegExpTest): Deleted. (JSC::DFG::SpeculativeJIT::compileStringReplace): Deleted. (JSC::DFG::SpeculativeJIT::compileRegExpExecNonGlobalOrSticky): Deleted. (JSC::DFG::SpeculativeJIT::compileRegExpMatchFastGlobal): Deleted. (JSC::DFG::SpeculativeJIT::compileRegExpMatchFast): Deleted. (JSC::DFG::SpeculativeJIT::compileLazyJSConstant): Deleted. (JSC::DFG::SpeculativeJIT::compileMaterializeNewObject): Deleted. (JSC::DFG::SpeculativeJIT::compileRecordRegExpCachedResult): Deleted. (JSC::DFG::SpeculativeJIT::compileDefineDataProperty): Deleted. (JSC::DFG::SpeculativeJIT::compileDefineAccessorProperty): Deleted. (JSC::DFG::SpeculativeJIT::emitAllocateButterfly): Deleted. (JSC::DFG::SpeculativeJIT::compileNormalizeMapKey): Deleted. (JSC::DFG::SpeculativeJIT::compileGetMapBucketHead): Deleted. (JSC::DFG::SpeculativeJIT::compileGetMapBucketNext): Deleted. (JSC::DFG::SpeculativeJIT::compileLoadKeyFromMapBucket): Deleted. (JSC::DFG::SpeculativeJIT::compileLoadValueFromMapBucket): Deleted. (JSC::DFG::SpeculativeJIT::compileExtractValueFromWeakMapGet): Deleted. (JSC::DFG::SpeculativeJIT::compileThrow): Deleted. (JSC::DFG::SpeculativeJIT::compileThrowStaticError): Deleted. (JSC::DFG::SpeculativeJIT::compileEnumeratorNextUpdateIndexAndMode): Deleted. (JSC::DFG::SpeculativeJIT::compileEnumeratorNextExtractIndex): Deleted. (JSC::DFG::SpeculativeJIT::compileEnumeratorNextExtractMode): Deleted. (JSC::DFG::SpeculativeJIT::compileEnumeratorNextUpdatePropertyName): Deleted. (JSC::DFG::SpeculativeJIT::compileEnumeratorHasProperty): Deleted. (JSC::DFG::SpeculativeJIT::compileEnumeratorInByVal): Deleted. (JSC::DFG::SpeculativeJIT::compileEnumeratorHasOwnProperty): Deleted. (JSC::DFG::SpeculativeJIT::compilePutByIdFlush): Deleted. (JSC::DFG::SpeculativeJIT::compilePutById): Deleted. (JSC::DFG::SpeculativeJIT::compilePutByIdDirect): Deleted. (JSC::DFG::SpeculativeJIT::compilePutByIdWithThis): Deleted. (JSC::DFG::SpeculativeJIT::compileGetByOffset): Deleted. (JSC::DFG::SpeculativeJIT::compilePutByOffset): Deleted. (JSC::DFG::SpeculativeJIT::compileMatchStructure): Deleted. (JSC::DFG::SpeculativeJIT::compileGetPropertyEnumerator): Deleted. (JSC::DFG::SpeculativeJIT::compileGetExecutable): Deleted. (JSC::DFG::SpeculativeJIT::compileGetGetter): Deleted. (JSC::DFG::SpeculativeJIT::compileGetSetter): Deleted. (JSC::DFG::SpeculativeJIT::compileGetCallee): Deleted. (JSC::DFG::SpeculativeJIT::compileSetCallee): Deleted. (JSC::DFG::SpeculativeJIT::compileGetArgumentCountIncludingThis): Deleted. (JSC::DFG::SpeculativeJIT::compileSetArgumentCountIncludingThis): Deleted. (JSC::DFG::SpeculativeJIT::compileStrCat): Deleted. (JSC::DFG::SpeculativeJIT::compileNewArrayBuffer): Deleted. (JSC::DFG::SpeculativeJIT::compileNewArrayWithSize): Deleted. (JSC::DFG::SpeculativeJIT::compileNewTypedArray): Deleted. (JSC::DFG::SpeculativeJIT::compileToThis): Deleted. (JSC::DFG::SpeculativeJIT::compileObjectKeysOrObjectGetOwnPropertyNames): Deleted. (JSC::DFG::SpeculativeJIT::compileObjectAssign): Deleted. (JSC::DFG::SpeculativeJIT::compileObjectCreate): Deleted. (JSC::DFG::SpeculativeJIT::compileCreateThis): Deleted. (JSC::DFG::SpeculativeJIT::compileCreatePromise): Deleted. (JSC::DFG::SpeculativeJIT::compileCreateInternalFieldObject): Deleted. (JSC::DFG::SpeculativeJIT::compileCreateGenerator): Deleted. (JSC::DFG::SpeculativeJIT::compileCreateAsyncGenerator): Deleted. (JSC::DFG::SpeculativeJIT::compileNewObject): Deleted. (JSC::DFG::SpeculativeJIT::compileNewInternalFieldObjectImpl): Deleted. (JSC::DFG::SpeculativeJIT::compileNewGenerator): Deleted. (JSC::DFG::SpeculativeJIT::compileNewAsyncGenerator): Deleted. (JSC::DFG::SpeculativeJIT::compileNewInternalFieldObject): Deleted. (JSC::DFG::SpeculativeJIT::compileToPrimitive): Deleted. (JSC::DFG::SpeculativeJIT::compileToPropertyKey): Deleted. (JSC::DFG::SpeculativeJIT::compileToNumeric): Deleted. (JSC::DFG::SpeculativeJIT::compileCallNumberConstructor): Deleted. (JSC::DFG::SpeculativeJIT::compileLogShadowChickenPrologue): Deleted. (JSC::DFG::SpeculativeJIT::compileLogShadowChickenTail): Deleted. (JSC::DFG::SpeculativeJIT::compileSetAdd): Deleted. (JSC::DFG::SpeculativeJIT::compileMapSet): Deleted. (JSC::DFG::SpeculativeJIT::compileWeakMapGet): Deleted. (JSC::DFG::SpeculativeJIT::compileWeakSetAdd): Deleted. (JSC::DFG::SpeculativeJIT::compileWeakMapSet): Deleted. (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf): Deleted. (JSC::DFG::SpeculativeJIT::compileIdentity): Deleted. (JSC::DFG::SpeculativeJIT::compileMiscStrictEq): Deleted. (JSC::DFG::SpeculativeJIT::emitInitializeButterfly): Deleted. (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize): Deleted. (JSC::DFG::SpeculativeJIT::compileHasIndexedProperty): Deleted. (JSC::DFG::SpeculativeJIT::compileExtractCatchLocal): Deleted. (JSC::DFG::SpeculativeJIT::compileClearCatchLocals): Deleted. (JSC::DFG::SpeculativeJIT::compileProfileType): Deleted. (JSC::DFG::SpeculativeJIT::cachedPutById): Deleted. (JSC::DFG::SpeculativeJIT::genericJSValueNonPeepholeCompare): Deleted. (JSC::DFG::SpeculativeJIT::genericJSValuePeepholeBranch): Deleted. (JSC::DFG::SpeculativeJIT::compileHeapBigIntEquality): Deleted. (JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted. (JSC::DFG::SpeculativeJIT::compileEnumeratorGetByVal): Deleted. * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal): Deleted. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::branchIfEmpty): (JSC::AssemblyHelpers::branchIfNotEmpty): Canonical link: https://commits.webkit.org/244047@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@285530 268f45cc-cd09-0410-ab3c-d52691b4dbfc

…ed underneath -[UIWindow dealloc] https://bugs.webkit.org/show_bug.cgi?id=237505 rdar://85563958 Reviewed by Tim Horton. Source/WebKit: It's currently possible for the web page to get permanently stuck in frozen state, due to the `BackgroundApplication` layer tree freeze reason; this occurs when the web view is unparented from the view hierarchy underneath the scope of UIWindow's `-dealloc` method. During `-[UIWindow dealloc]`, the backpointer underlying the implementation of `-[UIView window]` is set to `nil` immediately before the subclassing method hook `-willMoveToWindow:` is invoked on the view hierarchy. This means that when `-willMoveToWindow:` is invoked, `self.window` will return `nil`. This, in turn, puts `WKApplicationStateTrackingView` in a bad state because we bail early before resetting `_applicationStateTracker` in the early return below, since we (erroneously) believe that we've already been unparented from the view hierarchy, so we don't need to do anything. ``` if (!self._contentView.window || newWindow) return; ``` As a result, if the same web view is eventually moved back into another visible window, `-didMoveToWindow` bails before setting up the `_applicationStateTracker` again, since it already exists from when the previous window was still active. This means `-_applicationWillEnterForeground` is never called when the web view is reintroduced to the view hierarchy, so `LayerTreeFreezeReason::BackgroundApplication` is never lifted. To address this, we simply remove the debug assertion for `_applicationStateTracker`, and instead check whether the application state tracker exists or not for the logic of the early return. Doing so also makes the early return in `-willMoveToWindow:` consistent with the logic in one in `-didMoveToWindow`, which already consults `_applicationStateTracker`: ``` - (void)didMoveToWindow { if (!self._contentView.window || _applicationStateTracker) return; ``` Test: ApplicationStateTracking.WindowDeallocDoesNotPermanentlyFreezeLayerTree * UIProcess/ios/WKApplicationStateTrackingView.mm: (-[WKApplicationStateTrackingView willMoveToWindow:]): See above. Tools: Add an API test to exercise the bug. This API test is comprised of the following series of steps: 1. Create the web view and add it under window #1. 2. Post a "did enter background" notification. 3. Deallocate window #1 (thereby unparenting the web view in the process). 4. Post a "will enter foreground" notification. 5. Add the web view under window #2. 6. Load some HTML content and wait for a presentation update. Before the fix, this test times out because the layer tree is permanently frozen after step (3), due to the `BackgroundApplication` reason, so the presentation update in step (6) never finishes. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/ios/ApplicationStateTracking.mm: Added. (TestWebKitAPI::TEST): Canonical link: https://commits.webkit.org/248106@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@290875 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=237630 rdar://88690874 Reviewed by Jer Noble. Source/WebCore: Data cues have a start time but not an explicit duration, a data cue ends when the next data cue from the same track starts. This means we don’t know the duration of cue #1 until cue #2 is delivered, so when cue #1 is delivered it is given the end time of the media file’s duration and the actual end time is updated when cue #2 arrives. http://webkit.org/b/229924 refactored text, audio, and video tracks to not depend on HTMLMediaElement. Because InbandDataTextTrack could no longer access the HTMLMediaElement to get its duration, a duration property was added to TextTrackList that InbandDataTextTrack uses to set the duration of temporary cues. TextTrackList.duration is set when it is created and updated when the media player reports a duration change. This means that if the media file’s duration is not known when the text track list is created, and the file's duration never changes, the text track list never has a valid duration and data cues were not added to the temporary list. Fix this by updating TextTrackList.duration when a HTMLMediaElement reaches HAVE_METADATA. Test: http/tests/media/hls/track-in-band-hls-metadata-cue-duration.html * html/HTMLMediaElement.cpp: (WebCore::HTMLMediaElement::durationChanged): Update m_textTracks.duration and post the 'durationchange' event. (WebCore::HTMLMediaElement::setReadyState): Call durationChanged. (WebCore::HTMLMediaElement::mediaPlayerDurationChanged): Ditto. * html/HTMLMediaElement.h: * html/track/InbandDataTextTrack.cpp: (WebCore::InbandDataTextTrack::addDataCue): Add cues to the incomplete cue map even if the track list doesn't have duration. LayoutTests: * http/tests/media/hls/track-in-band-hls-metadata-cue-duration-expected.txt: Added. * http/tests/media/hls/track-in-band-hls-metadata-cue-duration.html: Added. Canonical link: https://commits.webkit.org/248203@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@291029 268f45cc-cd09-0410-ab3c-d52691b4dbfc

…with-relative-parent.html is a flaky image failure https://bugs.webkit.org/show_bug.cgi?id=239101 <rdar://problem/91603539> Reviewed by Antti Koivisto. Source/WebCore: 1. Out of flow boxes are laid out independently from each other as the last step of their containing block layout. 2. However their static positions are computed during regular in-flow layout (as if their positions were static). In order to do #1, we maintain a ListHashSet for the out-of-flow boxes and insert them at #2 (and we also have a corresponding HashMap<ContainingBlock, ListHasSet>). Normally this is a very simple list of descendant positioned boxes and since out-of-flow boxes don't interact with each other, their position in the list is not important. e.g. <div id=A style="position: relative"> <div> <div id=B style="position: absolute"></div> <div id=C style="position: absolute"></div> </div> </div> At in-flow layout (#2), we insert B and C to "ListHashSet of A" as we come across them in DOM order and compute their static positions. Later in the layout flow when we get to the "let's layout the out-of-flow boxes" phase (#1) we simply walk the ListHashSet and lay out B and C (but "C and B" order would also work just fine). However the ICB (RenderView) is a special containing block as it can hold different types of out-of-flow boxes (absolute and fixed) and those out-of-flow boxes may have layout dependencies. e.g. <body><div id=A class=absolute><div id=B class=fixed></div></div></body> ICB's ListHasSet has both A and B, but in this case there's (static)layout dependency between these boxes. In order to figure out the static position of B, we have to have A laid out first. In order to lay out A before B, B has to be preceded by A in ICB's ListHasSet. Now full layout always guarantees the correct order. However in case of partial layout since we don't run a full #2, the ListHasSet may end up having an unexpected order. e.g. <body><div id=A class=absolute><div id=B><div id=C class=fixed></div></div></div></body> 1. The initial (full) layout produces the following (correct) order for the ICB's ListHasSet -> AC. 2. A subsequent partial layout (e.g. triggered by A's position change) runs an in-flow layout on the <body> which (re-)appends A to the ListHasSet (CA <- incorrect order). Now at this point we assume that the in-flow layout picks up B which eventually (re-)appends C to the ListHashSet (AC <- correct order). However since B does not need layout, we just stop at <body> which leaves us with an unexpected ListHashSet. 3. As part of the ICB's out-of-flow layout, we pick C as the first box to lay out followed by A. However since C's static position depends on A's position, we end up using stale geometry when computing C's static position. This patch fixes this issue by ensuring the absolute positioned boxes always come first in the ICB's ListHasSet (note that their order is not really important -see above. What's important is that a potential (as-if-static) containing block always comes before the fixed boxes). Test: fast/block/fixed-inside-absolute-positioned.html * rendering/RenderBlock.cpp: (WebCore::PositionedDescendantsMap::addDescendant): (WebCore::RenderBlock::insertPositionedObject): LayoutTests: * fast/block/fixed-inside-absolute-positioned-expected.html: Added. * fast/block/fixed-inside-absolute-positioned.html: Added. * platform/mac-wk1/TestExpectations: Canonical link: https://commits.webkit.org/249597@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@292817 268f45cc-cd09-0410-ab3c-d52691b4dbfc

…with-relative-parent.html is a flaky image failure https://bugs.webkit.org/show_bug.cgi?id=239101 <rdar://problem/91603539> Reviewed by Antti Koivisto. Source/WebCore: 1. Out of flow boxes are laid out independently from each other as the last step of their containing block layout. 2. However their static positions are computed during regular in-flow layout (as if their positions were static). In order to do #1, we maintain a ListHashSet for the out-of-flow boxes and insert them at #2 (and we also have a corresponding HashMap<ContainingBlock, ListHasSet>). Normally this is a very simple list of descendant positioned boxes and since out-of-flow boxes don't interact with each other, their position in the list is not important. e.g. <div id=A style="position: relative"> <div> <div id=B style="position: absolute"></div> <div id=C style="position: absolute"></div> </div> </div> At in-flow layout (#2), we insert B and C to "ListHashSet of A" as we come across them in DOM order and compute their static positions. Later in the layout flow when we get to the "let's layout the out-of-flow boxes" phase (#1) we simply walk the ListHashSet and lay out B and C (but "C and B" order would also work just fine). However the ICB (RenderView) is a special containing block as it can hold different types of out-of-flow boxes (absolute and fixed) and those out-of-flow boxes may have layout dependencies. e.g. <body><div id=A class=absolute><div id=B class=fixed></div></div></body> ICB's ListHasSet has both A and B, but in this case there's (static)layout dependency between these boxes. In order to figure out the static position of B, we have to have A laid out first. In order to lay out A before B, B has to be preceded by A in ICB's ListHasSet. Now full layout always guarantees the correct order. However in case of partial layout since we don't run a full #2, the ListHasSet may end up having an unexpected order. e.g. <body><div id=A class=absolute><div id=B><div id=C class=fixed></div></div></div></body> 1. The initial (full) layout produces the following (correct) order for the ICB's ListHasSet -> AC. 2. A subsequent partial layout (e.g. triggered by A's position change) runs an in-flow layout on the <body> which (re-)appends A to the ListHasSet (CA <- incorrect order). Now at this point we assume that the in-flow layout picks up B which eventually (re-)appends C to the ListHashSet (AC <- correct order). However since B does not need layout, we just stop at <body> which leaves us with an unexpected ListHashSet. 3. As part of the ICB's out-of-flow layout, we pick C as the first box to lay out followed by A. However since C's static position depends on A's position, we end up using stale geometry when computing C's static position. This patch fixes this issue by ensuring the absolute positioned boxes always come first in the ICB's ListHasSet (note that their order is not really important -see above. What's important is that a potential (as-if-static) containing block always comes before the fixed boxes). Test: fast/block/fixed-inside-absolute-positioned.html * rendering/RenderBlock.cpp: (WebCore::PositionedDescendantsMap::addDescendant): (WebCore::RenderBlock::insertPositionedObject): LayoutTests: * fast/block/fixed-inside-absolute-positioned-expected.html: Added. * fast/block/fixed-inside-absolute-positioned.html: Added. * platform/mac-wk1/TestExpectations: Canonical link: https://commits.webkit.org/249626@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@292855 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=241856 Reviewed by Yusuke Suzuki. 1. Ruby treats numeric 0 as truthy. However, there's a test in arm64LowerMalformedLoadStoreAddresses which assumes a value of 0 would be false. As a result, we see offlineasm emit inefficient LLInt code like this: ".loc 3 821\n" "movz x16, #0 \n" // LowLevelInterpreter64.asm:821 "add x13, x3, x16 \n" "ldr x0, [x13] \n" ... instead of this: ".loc 3 821\n" "ldr x0, [x3] \n" // LowLevelInterpreter64.asm:821 This patch fixes this. 2. offlineasm's emitARM64MoveImmediate chooses to use `movn` instead of `movz` based on whether a 64-bit value is negative or not. Instead, it should be making that decision based on the number of halfwords (16-bits) in the value that is 0xffff vs 0. As a result, offlineasm emits code like this: ".loc 1 1638\n" "movn x27, #1, lsl #48 \n" // LowLevelInterpreter.asm:1638 "movk x27, #0, lsl #32 \n" "movk x27, #0, lsl #16 \n" "movk x27, #0 \n" ... instead of this: ".loc 1 1638\n" "movz x27, #65534, lsl #48 \n" // LowLevelInterpreter.asm:1638 This patch fixes this. 3. offlineasm is trivially assuming the range of immediate offsets for ldr/str instructions is [-255..4095]. However, that's only the range for byte sized load-stores. For 32-bit, the range is actually [-255..16380]. For 64-bit, the range is actually [-255..32760]. As a result, offlineasm emits code like this: ".loc 1 633\n" "movn x16, WebKit#16383 \n" // LowLevelInterpreter.asm:633 ".loc 1 1518\n" "and x3, x3, x16 \n" // LowLevelInterpreter.asm:1518 ".loc 1 1519\n" "movz x16, WebKit#16088 \n" // LowLevelInterpreter.asm:1519 "add x17, x3, x16 \n" "ldr x3, [x17] \n" ... instead of this: ".loc 1 633\n" "movn x17, WebKit#16383 \n" // LowLevelInterpreter.asm:633 ".loc 1 1518\n" "and x3, x3, x17 \n" // LowLevelInterpreter.asm:1518 ".loc 1 1519\n" "ldr x3, [x3, WebKit#16088] \n" // LowLevelInterpreter.asm:1519 This patch fixes this for 64-bit and 32-bit load-stores. 16-bit load-stores also has a wider range, but for now, it will continue to use the conservative range. This patch also introduces an `isMalformedArm64LoadAStoreAddress` so that this range check can be done consistently in all the places that checks for it. 4. offlineasm is eagerly emitting no-op arguments in instructions, e.g. "lsl #0", and adding 0. As a result, offlineasm emits code like this: ".loc 3 220\n" "movz x13, #51168, lsl #0 \n" // LowLevelInterpreter64.asm:220 "add x17, x1, x13, lsl #0 \n" "ldr w4, [x17, #0] \n" ... instead of this: ".loc 3 220\n" "movz x13, #51168 \n" // LowLevelInterpreter64.asm:220 "add x17, x1, x13 \n" "ldr w4, [x17] \n" This unnecessary arguments are actually very common throughout the emitted LLIntAssembly.h. This patch removes these unnecessary arguments, which makes the emitted LLInt code more human readable due to less clutter. This patch has passed the testapi and JSC stress tests with a Release build on an M1 Mac. I also manually verified that the emitARM64MoveImmediate code is working properly by hacking up LowLevelInterpreter64.asm to emit moves of constants of different values in the ranges, and for load-store instructions of different sizes, and visually inspecting the emitted code. * Source/JavaScriptCore/offlineasm/arm64.rb: Canonical link: https://commits.webkit.org/251771@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@295766 268f45cc-cd09-0410-ab3c-d52691b4dbfc

…ting layers https://bugs.webkit.org/show_bug.cgi?id=241874 Reviewed by Simon Fraser. addLayers stops (recursive) descending in the render tree soon after it finds a root (R) with layer. It says that if a subtree root (R) has a layer then all layers in this subtree must have already been inserted into the layer tree at an earlier time. (it simply assumes that any layer in the subtree is a child of (R), or some other layers in the subtree) <div id=container> <div id=R> <div id=child> The insertion is bottom to top; we attach 1, (child) to (R) first 2, followed by (R) to (container) addLayers assumes that when (R) is being inserted (#2), we don't have to descend into (R)'s subtree since any renderer's layer that was inserted before (at #1) must have already been parented. However toplayer/backdrop content is an exception where the parent layer may be outside of the subtree but still accessible. In such cases subsequent insertions (and the recursive nature of finding layer parents) could lead to double parenting where we try to insert the same layer into the layer tree multiple times. * Source/WebCore/rendering/RenderElement.cpp: (WebCore::addLayers): (WebCore::RenderElement::insertedIntoTree): (WebCore::RenderElement::addLayers): Deleted. * Source/WebCore/rendering/RenderElement.h: Canonical link: https://commits.webkit.org/251772@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@295767 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=242295 Reviewed by Michael Catanzaro. We need to use adoptGRef when calling g_variant_get_data_as_bytes as the return is already ref'd. See: https://github.com/GNOME/glib/blob/2.72.3/glib/gvariant-core.c#L975 Fixes: ==3126== 330 (120 direct, 210 indirect) bytes in 3 blocks are definitely lost in loss record 3,105 of 3,199 ==3126== at 0x48447ED: malloc (vg_replace_malloc.c:381) ==3126== by 0xA87B2E8: g_malloc (gmem.c:106) ==3126== by 0xA892E44: g_slice_alloc (gslice.c:1072) ==3126== by 0xA84B005: g_bytes_new_with_free_func (gbytes.c:186) ==3126== by 0xA84B067: g_bytes_new_take (gbytes.c:128) ==3126== by 0xA8B934D: g_variant_ensure_serialised (gvariant-core.c:460) ==3126== by 0xA8B958E: g_variant_get_data_as_bytes (gvariant-core.c:961) ==3126== by 0x8765214: WebCore::KeyedEncoderGlib::finishEncoding() (KeyedEncoderGlib.cpp:139) ==3126== by 0x53CF40E: WebKit::writeToDisk(std::unique_ptr<WebCore::KeyedEncoder, std::default_delete<WebCore::KeyedEncoder> >&&, WTF::String&&) (PersistencyUtils.cpp:53) ==3126== by 0x545EF8C: operator() (DeviceIdHashSaltStorage.cpp:201) ==3126== by 0x545EF8C: WTF::Detail::CallableWrapper<WebKit::DeviceIdHashSaltStorage::storeHashSaltToDisk(WebKit::DeviceIdHashSaltStorage::HashSaltForOrigin const&)::{lambda()#1}, void>::call() (Function.h:53) ==3126== by 0x6E52DE9: operator() (Function.h:82) ==3126== by 0x6E52DE9: operator() (WorkQueueGeneric.cpp:70) ==3126== by 0x6E52DE9: WTF::Detail::CallableWrapper<WTF::WorkQueueBase::dispatch(WTF::Function<void ()>&&)::{lambda()#1}, void>::call() (Function.h:53) ==3126== by 0x6DF490F: operator() (Function.h:82) ==3126== by 0x6DF490F: WTF::RunLoop::performWork() (RunLoop.cpp:133) ==3126== by 0x6E55171: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*) (RunLoopGLib.cpp:80) ==3126== by 0x6E55D61: operator() (RunLoopGLib.cpp:53) ==3126== by 0x6E55D61: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::_FUN(_GSource*, int (*)(void*), void*) (RunLoopGLib.cpp:56) ==3126== by 0xA8723AB: g_main_dispatch (gmain.c:3381) ==3126== by 0xA875839: g_main_context_dispatch (gmain.c:4099) ==3126== by 0xA8759A7: g_main_context_iterate (gmain.c:4175) ==3126== by 0xA875D41: g_main_loop_run (gmain.c:4373) ==3126== by 0x6E5613C: WTF::RunLoop::run() (RunLoopGLib.cpp:108) ==3126== by 0x6E52E14: operator() (WorkQueueGeneric.cpp:51) ==3126== by 0x6E52E14: WTF::Detail::CallableWrapper<WTF::WorkQueueBase::platformInitialize(char const*, WTF::WorkQueueBase::Type, WTF::Thread::QOS)::{lambda()#1}, void>::call() (Function.h:53) ==3126== by 0x6DF6FD7: operator() (Function.h:82) ==3126== by 0x6DF6FD7: WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) (Threading.cpp:236) ==3126== by 0x6E59A3F: WTF::wtfThreadEntryPoint(void*) (ThreadingPOSIX.cpp:242) ==3126== by 0xA9D6DC2: start_thread (pthread_create.c:442) ==3126== by 0xAA4FA0F: clone (clone.S:100) ==3126== * Source/WebCore/platform/glib/KeyedEncoderGlib.cpp: (WebCore::KeyedEncoderGlib::finishEncoding): Canonical link: https://commits.webkit.org/252100@main

…e leak https://bugs.webkit.org/show_bug.cgi?id=242576 Reviewed by Xabier Rodriguez-Calvar. Refactor ref counting for GstContext in GLVideoSinkGStreamer to prevent a resource leak. Fixes: ==196== 401 (296 direct, 105 indirect) bytes in 1 blocks are definitely lost in loss record 58,280 of 62,411 ==196== at 0x4845A83: calloc (vg_replace_malloc.c:1328) ==196== by 0x15F58780: g_malloc0 (gmem.c:136) ==196== by 0x161C8CBB: gst_structure_new_id_empty_with_size (gststructure.c:281) ==196== by 0x161C8CBB: gst_structure_new_id_empty (gststructure.c:312) ==196== by 0x161716CF: gst_context_new (gstcontext.c:178) ==196== by 0x1122BB85: requestGLContext(char const*) (GLVideoSinkGStreamer.cpp:154) ==196== by 0x1122BD12: setGLContext(_GstElement*, char const*) (GLVideoSinkGStreamer.cpp:173) ==196== by 0x1122BE39: webKitGLVideoSinkChangeState(_GstElement*, GstStateChange) (GLVideoSinkGStreamer.cpp:189) ==196== by 0x1617FA11: gst_element_change_state (gstelement.c:3083) ==196== by 0x16180154: gst_element_set_state_func (gstelement.c:3037) ==196== by 0x40651CE6: activate_sink (gstplaybin3.c:3805) ==196== by 0x40651CE6: activate_sink.constprop.0 (gstplaybin3.c:3780) ==196== by 0x40652B3E: activate_group (gstplaybin3.c:4539) ==196== by 0x40652B3E: setup_next_source (gstplaybin3.c:4801) ==196== by 0x406542A7: gst_play_bin3_change_state (gstplaybin3.c:5031) ==196== by 0x1617FA11: gst_element_change_state (gstelement.c:3083) ==196== by 0x1617FA5A: gst_element_change_state (gstelement.c:3122) ==196== by 0x16180154: gst_element_set_state_func (gstelement.c:3037) ==196== by 0x11257BC9: WebCore::MediaPlayerPrivateGStreamer::changePipelineState(GstState) (MediaPlayerPrivateGStreamer.cpp:924) ==196== by 0x11258D8B: WebCore::MediaPlayerPrivateGStreamer::commitLoad() (MediaPlayerPrivateGStreamer.cpp:1184) ==196== by 0x1125420B: WebCore::MediaPlayerPrivateGStreamer::load(WTF::String const&) (MediaPlayerPrivateGStreamer.cpp:354) ==196== by 0x112542F4: WebCore::MediaPlayerPrivateGStreamer::load(WebCore::MediaStreamPrivate&) (MediaPlayerPrivateGStreamer.cpp:370) ==196== by 0x148CF508: WebCore::MediaPlayer::loadWithNextMediaEngine(WebCore::MediaPlayerFactory const*) (MediaPlayer.cpp:646) ==196== by 0x148CED64: WebCore::MediaPlayer::load(WebCore::MediaStreamPrivate&) (MediaPlayer.cpp:549) ==196== by 0x13CF7047: WebCore::HTMLMediaElement::loadResource(WTF::URL const&, WebCore::ContentType&, WTF::String const&) (HTMLMediaElement.cpp:1599) ==196== by 0x13CF5D70: WebCore::HTMLMediaElement::selectMediaResource()::{lambda()#1}::operator()() const (HTMLMediaElement.cpp:1413) ==196== by 0x13D291BD: WTF::Detail::CallableWrapper<WebCore::HTMLMediaElement::selectMediaResource()::{lambda()#1}, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0x131C31E7: WTF::CancellableTask::operator()() (CancellableTask.h:86) ==196== by 0x13D2D2DD: WebCore::ActiveDOMObject::queueCancellableTaskKeepingObjectAlive<WebCore::HTMLMediaElement>(WebCore::HTMLMediaElement&, WebCore::TaskSource, WTF::TaskCancellationGroup&, WTF::Function<void ()>&&)::{lambda()#1}::operator()() (ActiveDOMObject.h:119) ==196== by 0x13D5C88F: WTF::Detail::CallableWrapper<WebCore::ActiveDOMObject::queueCancellableTaskKeepingObjectAlive<WebCore::HTMLMediaElement>(WebCore::HTMLMediaElement&, WebCore::TaskSource, WTF::TaskCancellationGroup&, WTF::Function<void ()>&&)::{lambda()#1}, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0x1399229B: WebCore::EventLoopFunctionDispatchTask::execute() (EventLoop.cpp:159) ==196== by 0x13987D3A: WebCore::EventLoop::run() (EventLoop.cpp:123) ==196== by 0x13ABF15D: WebCore::WindowEventLoop::didReachTimeToRun() (WindowEventLoop.cpp:121) ==196== by 0x13AD46FB: void std::__invoke_impl<void, void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>(std::__invoke_memfun_deref, void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&) (invoke.h:74) ==196== by 0x13AD4666: std::__invoke_result<void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>::type std::__invoke<void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>(void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&) (invoke.h:96) ==196== by 0x13AD45DC: void std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (functional:420) ==196== by 0x13AD456E: void std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>::operator()<, void>() (functional:503) ==196== by 0x13AD4537: WTF::Detail::CallableWrapper<std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0xE23D137: WebCore::Timer::fired() (Timer.h:135) ==196== by 0x146E59EF: WebCore::ThreadTimers::sharedTimerFiredInternal() (ThreadTimers.cpp:127) ==196== by 0x146E52E4: WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::{lambda()#1}::operator()() const (ThreadTimers.cpp:67) ==196== by 0x146E8407: WTF::Detail::CallableWrapper<WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::{lambda()#1}, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0x14698311: WebCore::MainThreadSharedTimer::fired() (MainThreadSharedTimer.cpp:83) ==196== by 0x146A2E9D: void std::__invoke_impl<void, void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>(std::__invoke_memfun_deref, void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&) (invoke.h:74) ==196== by 0x146A2E16: std::__invoke_result<void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>::type std::__invoke<void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>(void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&) (invoke.h:96) ==196== by 0x146A2D8C: void std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (functional:420) ==196== by 0x146A2D1E: void std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>::operator()<, void>() (functional:503) ==196== by 0x146A2CC7: WTF::Detail::CallableWrapper<std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0x146A2CE7: WTF::RunLoop::Timer<WebCore::MainThreadSharedTimer>::fired() (RunLoop.h:188) ==196== by 0x110196A8: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::operator()(void*) const (RunLoopGLib.cpp:177) ==196== by 0x110196E8: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::_FUN(void*) (RunLoopGLib.cpp:181) ==196== by 0x11018BFA: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::operator()(_GSource*, int (*)(void*), void*) const (RunLoopGLib.cpp:53) ==196== by 0x11018C48: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::_FUN(_GSource*, int (*)(void*), void*) (RunLoopGLib.cpp:56) ==196== by 0x15F52293: g_main_dispatch (gmain.c:3381) ==196== by 0x15F52293: g_main_context_dispatch (gmain.c:4099) ==196== by 0x15F52637: g_main_context_iterate.constprop.0 (gmain.c:4175) ==196== by 0x15F52942: g_main_loop_run (gmain.c:4373) ==196== by 0x110192B3: WTF::RunLoop::run() (RunLoopGLib.cpp:108) ==196== by 0xEFB8674: WebKit::AuxiliaryProcessMainBase<WebKit::WebProcess, true>::run(int, char**) (AuxiliaryProcessMain.h:70) ==196== by 0xEFB5D26: int WebKit::AuxiliaryProcessMain<WebKit::WebProcessMainWPE>(int, char**) (AuxiliaryProcessMain.h:96) ==196== by 0xEFB227E: WebKit::WebProcessMain(int, char**) (WebProcessMainWPE.cpp:75) ==196== by 0x109908: main (WebProcessMain.cpp:31) ==196== ==196== 403 (88 direct, 315 indirect) bytes in 1 blocks are definitely lost in loss record 58,282 of 62,411 ==196== at 0x4840899: malloc (vg_replace_malloc.c:381) ==196== by 0x15F58728: g_malloc (gmem.c:106) ==196== by 0x15F710B4: g_slice_alloc (gslice.c:1072) ==196== by 0x16171683: gst_context_new (gstcontext.c:174) ==196== by 0x1122BC0A: requestGLContext(char const*) (GLVideoSinkGStreamer.cpp:160) ==196== by 0x1122BD12: setGLContext(_GstElement*, char const*) (GLVideoSinkGStreamer.cpp:173) ==196== by 0x1122BE5D: webKitGLVideoSinkChangeState(_GstElement*, GstStateChange) (GLVideoSinkGStreamer.cpp:191) ==196== by 0x1617FA11: gst_element_change_state (gstelement.c:3083) ==196== by 0x16180154: gst_element_set_state_func (gstelement.c:3037) ==196== by 0x40651CE6: activate_sink (gstplaybin3.c:3805) ==196== by 0x40651CE6: activate_sink.constprop.0 (gstplaybin3.c:3780) ==196== by 0x40652B3E: activate_group (gstplaybin3.c:4539) ==196== by 0x40652B3E: setup_next_source (gstplaybin3.c:4801) ==196== by 0x406542A7: gst_play_bin3_change_state (gstplaybin3.c:5031) ==196== by 0x1617FA11: gst_element_change_state (gstelement.c:3083) ==196== by 0x1617FA5A: gst_element_change_state (gstelement.c:3122) ==196== by 0x16180154: gst_element_set_state_func (gstelement.c:3037) ==196== by 0x11257BC9: WebCore::MediaPlayerPrivateGStreamer::changePipelineState(GstState) (MediaPlayerPrivateGStreamer.cpp:924) ==196== by 0x11258D8B: WebCore::MediaPlayerPrivateGStreamer::commitLoad() (MediaPlayerPrivateGStreamer.cpp:1184) ==196== by 0x1125420B: WebCore::MediaPlayerPrivateGStreamer::load(WTF::String const&) (MediaPlayerPrivateGStreamer.cpp:354) ==196== by 0x112542F4: WebCore::MediaPlayerPrivateGStreamer::load(WebCore::MediaStreamPrivate&) (MediaPlayerPrivateGStreamer.cpp:370) ==196== by 0x148CF508: WebCore::MediaPlayer::loadWithNextMediaEngine(WebCore::MediaPlayerFactory const*) (MediaPlayer.cpp:646) ==196== by 0x148CED64: WebCore::MediaPlayer::load(WebCore::MediaStreamPrivate&) (MediaPlayer.cpp:549) ==196== by 0x13CF7047: WebCore::HTMLMediaElement::loadResource(WTF::URL const&, WebCore::ContentType&, WTF::String const&) (HTMLMediaElement.cpp:1599) ==196== by 0x13CF5D70: WebCore::HTMLMediaElement::selectMediaResource()::{lambda()#1}::operator()() const (HTMLMediaElement.cpp:1413) ==196== by 0x13D291BD: WTF::Detail::CallableWrapper<WebCore::HTMLMediaElement::selectMediaResource()::{lambda()#1}, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0x131C31E7: WTF::CancellableTask::operator()() (CancellableTask.h:86) ==196== by 0x13D2D2DD: WebCore::ActiveDOMObject::queueCancellableTaskKeepingObjectAlive<WebCore::HTMLMediaElement>(WebCore::HTMLMediaElement&, WebCore::TaskSource, WTF::TaskCancellationGroup&, WTF::Function<void ()>&&)::{lambda()#1}::operator()() (ActiveDOMObject.h:119) ==196== by 0x13D5C88F: WTF::Detail::CallableWrapper<WebCore::ActiveDOMObject::queueCancellableTaskKeepingObjectAlive<WebCore::HTMLMediaElement>(WebCore::HTMLMediaElement&, WebCore::TaskSource, WTF::TaskCancellationGroup&, WTF::Function<void ()>&&)::{lambda()#1}, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0x1399229B: WebCore::EventLoopFunctionDispatchTask::execute() (EventLoop.cpp:159) ==196== by 0x13987D3A: WebCore::EventLoop::run() (EventLoop.cpp:123) ==196== by 0x13ABF15D: WebCore::WindowEventLoop::didReachTimeToRun() (WindowEventLoop.cpp:121) ==196== by 0x13AD46FB: void std::__invoke_impl<void, void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>(std::__invoke_memfun_deref, void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&) (invoke.h:74) ==196== by 0x13AD4666: std::__invoke_result<void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>::type std::__invoke<void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>(void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&) (invoke.h:96) ==196== by 0x13AD45DC: void std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (functional:420) ==196== by 0x13AD456E: void std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>::operator()<, void>() (functional:503) ==196== by 0x13AD4537: WTF::Detail::CallableWrapper<std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0xE23D137: WebCore::Timer::fired() (Timer.h:135) ==196== by 0x146E59EF: WebCore::ThreadTimers::sharedTimerFiredInternal() (ThreadTimers.cpp:127) ==196== by 0x146E52E4: WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::{lambda()#1}::operator()() const (ThreadTimers.cpp:67) ==196== by 0x146E8407: WTF::Detail::CallableWrapper<WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::{lambda()#1}, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0x14698311: WebCore::MainThreadSharedTimer::fired() (MainThreadSharedTimer.cpp:83) ==196== by 0x146A2E9D: void std::__invoke_impl<void, void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>(std::__invoke_memfun_deref, void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&) (invoke.h:74) ==196== by 0x146A2E16: std::__invoke_result<void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>::type std::__invoke<void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>(void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&) (invoke.h:96) ==196== by 0x146A2D8C: void std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (functional:420) ==196== by 0x146A2D1E: void std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>::operator()<, void>() (functional:503) ==196== by 0x146A2CC7: WTF::Detail::CallableWrapper<std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>, void>::call() (Function.h:53) ==196== by 0xD99E63C: WTF::Function<void ()>::operator()() const (Function.h:82) ==196== by 0x146A2CE7: WTF::RunLoop::Timer<WebCore::MainThreadSharedTimer>::fired() (RunLoop.h:188) ==196== by 0x110196A8: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::operator()(void*) const (RunLoopGLib.cpp:177) ==196== by 0x110196E8: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::_FUN(void*) (RunLoopGLib.cpp:181) ==196== by 0x11018BFA: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::operator()(_GSource*, int (*)(void*), void*) const (RunLoopGLib.cpp:53) ==196== by 0x11018C48: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::_FUN(_GSource*, int (*)(void*), void*) (RunLoopGLib.cpp:56) ==196== by 0x15F52293: g_main_dispatch (gmain.c:3381) ==196== by 0x15F52293: g_main_context_dispatch (gmain.c:4099) ==196== by 0x15F52637: g_main_context_iterate.constprop.0 (gmain.c:4175) ==196== by 0x15F52942: g_main_loop_run (gmain.c:4373) ==196== by 0x110192B3: WTF::RunLoop::run() (RunLoopGLib.cpp:108) ==196== by 0xEFB8674: WebKit::AuxiliaryProcessMainBase<WebKit::WebProcess, true>::run(int, char**) (AuxiliaryProcessMain.h:70) ==196== by 0xEFB5D26: int WebKit::AuxiliaryProcessMain<WebKit::WebProcessMainWPE>(int, char**) (AuxiliaryProcessMain.h:96) ==196== by 0xEFB227E: WebKit::WebProcessMain(int, char**) (WebProcessMainWPE.cpp:75) ==196== by 0x109908: main (WebProcessMain.cpp:31) ==196== * Source/WebCore/platform/graphics/gstreamer/GLVideoSinkGStreamer.cpp: (requestGLContext): (setGLContext): Canonical link: https://commits.webkit.org/252340@main

…tureMapperFlags https://bugs.webkit.org/show_bug.cgi?id=242561 Reviewed by Xabier Rodriguez-Calvar. Fixes: ==195== Conditional jump or move depends on uninitialised value(s) ==195== at 0x11429778: WebCore::TextureMapperPlatformLayerBuffer::paintToTextureMapper(WebCore::TextureMapper&, WebCore::FloatRect const&, WebCore::TransformationMatrix const&, float) (TextureMapperPlatformLayerBuffer.cpp:112) ==195== by 0x11403DDD: WebCore::TextureMapperLayer::paintSelf(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:202) ==195== by 0x114042D4: WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:255) ==195== by 0x114049D4: WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:319) ==195== by 0x1140683D: WebCore::TextureMapperLayer::paintSelfChildrenReplicaFilterAndMask(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:563) ==195== by 0x11406903: WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:576) ==195== by 0x114046C9: WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:283) ==195== by 0x114049D4: WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:319) ==195== by 0x1140683D: WebCore::TextureMapperLayer::paintSelfChildrenReplicaFilterAndMask(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:563) ==195== by 0x11406903: WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:576) ==195== by 0x114046C9: WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:283) ==195== by 0x114049D4: WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:319) ==195== by 0x1140683D: WebCore::TextureMapperLayer::paintSelfChildrenReplicaFilterAndMask(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:563) ==195== by 0x11406903: WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:576) ==195== by 0x114046C9: WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:283) ==195== by 0x114049D4: WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:319) ==195== by 0x1140683D: WebCore::TextureMapperLayer::paintSelfChildrenReplicaFilterAndMask(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:563) ==195== by 0x11406903: WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:576) ==195== by 0x114046C9: WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:283) ==195== by 0x114049D4: WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:319) ==195== by 0x1140683D: WebCore::TextureMapperLayer::paintSelfChildrenReplicaFilterAndMask(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:563) ==195== by 0x11406903: WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:576) ==195== by 0x114046C9: WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:283) ==195== by 0x114049D4: WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:319) ==195== by 0x1140683D: WebCore::TextureMapperLayer::paintSelfChildrenReplicaFilterAndMask(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:563) ==195== by 0x11406903: WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:576) ==195== by 0x114046C9: WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:283) ==195== by 0x114049D4: WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:319) ==195== by 0x1140683D: WebCore::TextureMapperLayer::paintSelfChildrenReplicaFilterAndMask(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:563) ==195== by 0x11406903: WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:576) ==195== by 0x114046C9: WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:283) ==195== by 0x114049D4: WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:319) ==195== by 0x1140683D: WebCore::TextureMapperLayer::paintSelfChildrenReplicaFilterAndMask(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:563) ==195== by 0x11406903: WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions&) (TextureMapperLayer.cpp:576) ==195== by 0x11403586: WebCore::TextureMapperLayer::paint(WebCore::TextureMapper&) (TextureMapperLayer.cpp:145) ==195== by 0xE6C2F6B: WebKit::CoordinatedGraphicsScene::paintToCurrentGLContext(WebCore::TransformationMatrix const&, WebCore::FloatRect const&, unsigned int) (CoordinatedGraphicsScene.cpp:78) ==195== by 0xE6E47A2: WebKit::ThreadedCompositor::renderLayerTree() (ThreadedCompositor.cpp:240) ==195== by 0xE6E3762: WebKit::ThreadedCompositor::ThreadedCompositor(WebKit::ThreadedCompositor::Client&, WebKit::ThreadedDisplayRefreshMonitor::Client&, unsigned int, WebCore::IntSize const&, float, unsigned int)::{lambda()#1}::operator()() const (ThreadedCompositor.cpp:58) ==195== by 0xE6E83FD: WTF::Detail::CallableWrapper<WebKit::ThreadedCompositor::ThreadedCompositor(WebKit::ThreadedCompositor::Client&, WebKit::ThreadedDisplayRefreshMonitor::Client&, unsigned int, WebCore::IntSize const&, float, unsigned int)::{lambda()#1}, void>::call() (Function.h:53) ==195== by 0xD9D7F1C: WTF::Function<void ()>::operator()() const (Function.h:82) ==195== by 0xE6C660B: WebKit::CompositingRunLoop::updateTimerFired() (CompositingRunLoop.cpp:188) ==195== by 0xE6E33EF: void std::__invoke_impl<void, void (WebKit::CompositingRunLoop::*&)(), WebKit::CompositingRunLoop*&>(std::__invoke_memfun_deref, void (WebKit::CompositingRunLoop::*&)(), WebKit::CompositingRunLoop*&) (invoke.h:74) ==195== by 0xE6E3368: std::__invoke_result<void (WebKit::CompositingRunLoop::*&)(), WebKit::CompositingRunLoop*&>::type std::__invoke<void (WebKit::CompositingRunLoop::*&)(), WebKit::CompositingRunLoop*&>(void (WebKit::CompositingRunLoop::*&)(), WebKit::CompositingRunLoop*&) (invoke.h:96) ==195== by 0xE6E32DE: void std::_Bind<void (WebKit::CompositingRunLoop::*(WebKit::CompositingRunLoop*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (functional:420) ==195== by 0xE6E3270: void std::_Bind<void (WebKit::CompositingRunLoop::*(WebKit::CompositingRunLoop*))()>::operator()<, void>() (functional:503) ==195== by 0xE6E3219: WTF::Detail::CallableWrapper<std::_Bind<void (WebKit::CompositingRunLoop::*(WebKit::CompositingRunLoop*))()>, void>::call() (Function.h:53) ==195== by 0xD9D7F1C: WTF::Function<void ()>::operator()() const (Function.h:82) ==195== by 0xE6E3239: WTF::RunLoop::Timer<WebKit::CompositingRunLoop>::fired() (RunLoop.h:188) ==195== by 0x1108296A: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::operator()(void*) const (RunLoopGLib.cpp:177) ==195== by 0x110829AA: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::_FUN(void*) (RunLoopGLib.cpp:181) ==195== by 0x11081EBC: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::operator()(_GSource*, int (*)(void*), void*) const (RunLoopGLib.cpp:53) ==195== by 0x11081F0A: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::_FUN(_GSource*, int (*)(void*), void*) (RunLoopGLib.cpp:56) ==195== by 0x15FB8293: g_main_dispatch (gmain.c:3381) ==195== by 0x15FB8293: g_main_context_dispatch (gmain.c:4099) ==195== by 0x15FB8637: g_main_context_iterate.constprop.0 (gmain.c:4175) ==195== by 0x15FB8942: g_main_loop_run (gmain.c:4373) ==195== by 0x11082575: WTF::RunLoop::run() (RunLoopGLib.cpp:108) ==195== by 0xE6C5CB2: WebKit::createRunLoop()::{lambda()#1}::operator()() const (CompositingRunLoop.cpp:49) ==195== by 0xE6CADE5: WTF::Detail::CallableWrapper<WebKit::createRunLoop()::{lambda()#1}, void>::call() (Function.h:53) ==195== by 0xD9D7F1C: WTF::Function<void ()>::operator()() const (Function.h:82) ==195== by 0x10FDF034: WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) (Threading.cpp:236) ==195== by 0x1108F1BC: WTF::wtfThreadEntryPoint(void*) (ThreadingPOSIX.cpp:242) ==195== by 0x18A463B9: start_thread (pthread_create.c:481) ==195== by 0x16782952: clone (clone.S:95) ==195== Uninitialised value was created by a heap allocation ==195== at 0x4840899: malloc (vg_replace_malloc.c:381) ==195== by 0x10F92F47: WTF::fastMalloc(unsigned long) (FastMalloc.cpp:232) ==195== by 0x112E0165: WebCore::MediaPlayerPrivateGStreamer::operator new(unsigned long) (MediaPlayerPrivateGStreamer.h:128) ==195== by 0x112E5BB3: std::_MakeUniq<WebCore::MediaPlayerPrivateGStreamer>::__single_object std::make_unique<WebCore::MediaPlayerPrivateGStreamer, WebCore::MediaPlayer*&>(WebCore::MediaPlayer*&) (unique_ptr.h:962) ==195== by 0x112E24B9: decltype(auto) WTF::makeUnique<WebCore::MediaPlayerPrivateGStreamer, WebCore::MediaPlayer*&>(WebCore::MediaPlayer*&) (StdLibExtras.h:540) ==195== by 0x112E2509: WebCore::MediaPlayerFactoryGStreamer::createMediaEnginePlayer(WebCore::MediaPlayer*) const (MediaPlayerPrivateGStreamer.cpp:288) ==195== by 0x149351A3: WebCore::MediaPlayer::loadWithNextMediaEngine(WebCore::MediaPlayerFactory const*) (MediaPlayer.cpp:625) ==195== by 0x14934C7E: WebCore::MediaPlayer::load(WebCore::MediaStreamPrivate&) (MediaPlayer.cpp:549) ==195== by 0x13D5FCA5: WebCore::HTMLMediaElement::loadResource(WTF::URL const&, WebCore::ContentType&, WTF::String const&) (HTMLMediaElement.cpp:1599) ==195== by 0x13D5E9CE: WebCore::HTMLMediaElement::selectMediaResource()::{lambda()#1}::operator()() const (HTMLMediaElement.cpp:1413) ==195== by 0x13D91E1B: WTF::Detail::CallableWrapper<WebCore::HTMLMediaElement::selectMediaResource()::{lambda()#1}, void>::call() (Function.h:53) ==195== by 0xD9D7F1C: WTF::Function<void ()>::operator()() const (Function.h:82) ==195== by 0x1322C265: WTF::CancellableTask::operator()() (CancellableTask.h:86) ==195== by 0x13D95F3B: WebCore::ActiveDOMObject::queueCancellableTaskKeepingObjectAlive<WebCore::HTMLMediaElement>(WebCore::HTMLMediaElement&, WebCore::TaskSource, WTF::TaskCancellationGroup&, WTF::Function<void ()>&&)::{lambda()#1}::operator()() (ActiveDOMObject.h:119) ==195== by 0x13DC54ED: WTF::Detail::CallableWrapper<WebCore::ActiveDOMObject::queueCancellableTaskKeepingObjectAlive<WebCore::HTMLMediaElement>(WebCore::HTMLMediaElement&, WebCore::TaskSource, WTF::TaskCancellationGroup&, WTF::Function<void ()>&&)::{lambda()#1}, void>::call() (Function.h:53) ==195== by 0xD9D7F1C: WTF::Function<void ()>::operator()() const (Function.h:82) ==195== by 0x139FB2B1: WebCore::EventLoopFunctionDispatchTask::execute() (EventLoop.cpp:159) ==195== by 0x139F0D50: WebCore::EventLoop::run() (EventLoop.cpp:123) ==195== by 0x13B2815F: WebCore::WindowEventLoop::didReachTimeToRun() (WindowEventLoop.cpp:121) ==195== by 0x13B3D6FD: void std::__invoke_impl<void, void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>(std::__invoke_memfun_deref, void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&) (invoke.h:74) ==195== by 0x13B3D668: std::__invoke_result<void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>::type std::__invoke<void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&>(void (WebCore::WindowEventLoop::*&)(), WebCore::WindowEventLoop*&) (invoke.h:96) ==195== by 0x13B3D5DE: void std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (functional:420) ==195== by 0x13B3D570: void std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>::operator()<, void>() (functional:503) ==195== by 0x13B3D539: WTF::Detail::CallableWrapper<std::_Bind<void (WebCore::WindowEventLoop::*(WebCore::WindowEventLoop*))()>, void>::call() (Function.h:53) ==195== by 0xD9D7F1C: WTF::Function<void ()>::operator()() const (Function.h:82) ==195== by 0xE2769FD: WebCore::Timer::fired() (Timer.h:135) ==195== by 0x1474B909: WebCore::ThreadTimers::sharedTimerFiredInternal() (ThreadTimers.cpp:127) ==195== by 0x1474B1FE: WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::{lambda()#1}::operator()() const (ThreadTimers.cpp:67) ==195== by 0x1474E321: WTF::Detail::CallableWrapper<WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::{lambda()#1}, void>::call() (Function.h:53) ==195== by 0xD9D7F1C: WTF::Function<void ()>::operator()() const (Function.h:82) ==195== by 0x146FE25D: WebCore::MainThreadSharedTimer::fired() (MainThreadSharedTimer.cpp:83) ==195== by 0x14708DE9: void std::__invoke_impl<void, void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>(std::__invoke_memfun_deref, void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&) (invoke.h:74) ==195== by 0x14708D62: std::__invoke_result<void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>::type std::__invoke<void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>(void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&) (invoke.h:96) ==195== by 0x14708CD8: void std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (functional:420) ==195== by 0x14708C6A: void std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>::operator()<, void>() (functional:503) ==195== by 0x14708C13: WTF::Detail::CallableWrapper<std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>, void>::call() (Function.h:53) ==195== by 0xD9D7F1C: WTF::Function<void ()>::operator()() const (Function.h:82) ==195== by 0x14708C33: WTF::RunLoop::Timer<WebCore::MainThreadSharedTimer>::fired() (RunLoop.h:188) ==195== by 0x1108296A: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::operator()(void*) const (RunLoopGLib.cpp:177) ==195== by 0x110829AA: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::{lambda(void*)#1}::_FUN(void*) (RunLoopGLib.cpp:181) ==195== by 0x11081EBC: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::operator()(_GSource*, int (*)(void*), void*) const (RunLoopGLib.cpp:53) ==195== by 0x11081F0A: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::_FUN(_GSource*, int (*)(void*), void*) (RunLoopGLib.cpp:56) ==195== by 0x15FB8293: g_main_dispatch (gmain.c:3381) ==195== by 0x15FB8293: g_main_context_dispatch (gmain.c:4099) ==195== by 0x15FB8637: g_main_context_iterate.constprop.0 (gmain.c:4175) ==195== by 0x15FB8942: g_main_loop_run (gmain.c:4373) ==195== by 0x11082575: WTF::RunLoop::run() (RunLoopGLib.cpp:108) ==195== by 0xF024098: WebKit::AuxiliaryProcessMainBase<WebKit::WebProcess, true>::run(int, char**) (AuxiliaryProcessMain.h:70) ==195== by 0xF02174A: int WebKit::AuxiliaryProcessMain<WebKit::WebProcessMainWPE>(int, char**) (AuxiliaryProcessMain.h:96) ==195== by 0xF01DCA2: WebKit::WebProcessMain(int, char**) (WebProcessMainWPE.cpp:75) ==195== by 0x109918: main (WebProcessMain.cpp:31) ==195== * Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h: Canonical link: https://commits.webkit.org/252393@main

…us wrapper https://bugs.webkit.org/show_bug.cgi?id=242734 Reviewed by Antti Koivisto. When the anonymous block wrapper for an inline level child is not needed anymore (sibling block is removed or became non-inflow), we 1. detach the inline level child (and its subtree) 2. destroy the anonymous wrapper 3. re-attach the inline level child under the new parent (most likely the parent of the destroyed anonymous wrapper) We call this re-parenting activity an "internal move". Certain properties (e.g fragmentation state) are not supposed to change during this type of move (we simply stop calling some "reset" functions when RenderObject::IsInternalMove::Yes) This patch ensures that the internal move flag is set for both #1 and #3. * Source/WebCore/rendering/RenderBlockFlow.cpp: drive-by fix to ensure no ruby content gets multi-column context. (WebCore::RenderBlockFlow::willCreateColumns const): * Source/WebCore/rendering/updating/RenderTreeBuilder.cpp: (WebCore::RenderTreeBuilder::removeAnonymousWrappersForInlineChildrenIfNeeded): Make sure both detach and attach are covered with the "internal move" flag as currently only the attach is covered. It means that whatever flags we reset at detach (not an internal move) we don't set back on attach (internal move). Canonical link: https://commits.webkit.org/252456@main

https://bugs.webkit.org/show_bug.cgi?id=242517 Reviewed by Darin Adler. We need to initialize processIdentifier as it is accessed by the equality operator for GlobalWindowIdentifier. Fixes the following valgrind error: ==137== Conditional jump or move depends on uninitialised value(s) ==137== at 0x144770C4: WebCore::operator==(WebCore::GlobalWindowIdentifier const&, WebCore::GlobalWindowIdentifier const&) (GlobalWindowIdentifier.h:49) ==137== by 0x1447715D: WTF::GlobalWindowIdentifierHash::equal(WebCore::GlobalWindowIdentifier const&, WebCore::GlobalWindowIdentifier const&) (GlobalWindowIdentifier.h:85) ==137== by 0x1447ACBA: bool WTF::HashMapTranslator<WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::DefaultHash<WebCore::GlobalWindowIdentifier> >::equal<WebCore::GlobalWindowIdentifier, WebCore::GlobalWindowIdentifier>(WebCore::GlobalWindowIdentifier const&, WebCore::GlobalWindowIdentifier const&) (HashMap.h:229) ==137== by 0x1447AAEB: void WTF::HashTable<WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> >::checkKey<WTF::HashMapTranslator<WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::DefaultHash<WebCore::GlobalWindowIdentifier> >, WebCore::GlobalWindowIdentifier>(WebCore::GlobalWindowIdentifier const&) (HashTable.h:664) ==137== by 0x14479888: WTF::HashTableAddResult<WTF::HashTableIterator<WTF::HashTable<WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> >, WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> > > WTF::HashTable<WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> >::add<WTF::HashMapTranslator<WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::DefaultHash<WebCore::GlobalWindowIdentifier> >, WebCore::GlobalWindowIdentifier const&, WebCore::AbstractDOMWindow*>(WebCore::GlobalWindowIdentifier const&, WebCore::AbstractDOMWindow*&&) (HashTable.h:932) ==137== by 0x1447895D: WTF::HashTableAddResult<WTF::HashTableIterator<WTF::HashTable<WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> >, WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> > > WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::inlineAdd<WebCore::GlobalWindowIdentifier const&, WebCore::AbstractDOMWindow*>(WebCore::GlobalWindowIdentifier const&, WebCore::AbstractDOMWindow*&&) (HashMap.h:382) ==137== by 0x1447795B: WTF::HashTableAddResult<WTF::HashTableIterator<WTF::HashTable<WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> >, WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> > > WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::add<WebCore::AbstractDOMWindow*>(WebCore::GlobalWindowIdentifier const&, WebCore::AbstractDOMWindow*&&) (HashMap.h:417) ==137== by 0x144705B3: WebCore::AbstractDOMWindow::AbstractDOMWindow(WebCore::GlobalWindowIdentifier&&) (AbstractDOMWindow.cpp:48) ==137== by 0x1448AA3C: WebCore::DOMWindow::DOMWindow(WebCore::Document&) (DOMWindow.cpp:405) ==137== by 0x1392F767: WebCore::DOMWindow::create(WebCore::Document&) (DOMWindow.h:124) ==137== by 0x139026F1: WebCore::Document::createDOMWindow() (Document.cpp:5119) ==137== by 0x142DD1B7: WebCore::DocumentWriter::begin(WTF::URL const&, bool, WebCore::Document*, WebCore::ProcessQualified<WTF::UUID>)::{lambda()#1}::operator()() const (DocumentWriter.cpp:165) ==137== by 0x142E61DB: WTF::Detail::CallableWrapper<WebCore::DocumentWriter::begin(WTF::URL const&, bool, WebCore::Document*, WebCore::ProcessQualified<WTF::UUID>)::{lambda()#1}, void>::call() (Function.h:53) ==137== by 0xD9D5E94: WTF::Function<void ()>::operator()() const (Function.h:82) ==137== by 0x1431A333: WebCore::FrameLoader::clear(WTF::RefPtr<WebCore::Document, WTF::RawPtrTraits<WebCore::Document>, WTF::DefaultRefDerefTraits<WebCore::Document> >&&, bool, bool, bool, WTF::Function<void ()>&&) (FrameLoader.cpp:646) ==137== by 0x142DD5B1: WebCore::DocumentWriter::begin(WTF::URL const&, bool, WebCore::Document*, WebCore::ProcessQualified<WTF::UUID>) (DocumentWriter.cpp:168) ==137== by 0x142D05BB: WebCore::DocumentLoader::commitData(WebCore::SharedBuffer const&) (DocumentLoader.cpp:1235) ==137== by 0x142CAE8C: WebCore::DocumentLoader::finishedLoading() (DocumentLoader.cpp:493) ==137== by 0x142D44AA: WebCore::DocumentLoader::maybeLoadEmpty() (DocumentLoader.cpp:2038) ==137== by 0x142D4D93: WebCore::DocumentLoader::startLoadingMainResource() (DocumentLoader.cpp:2065) ==137== by 0x143188E2: WebCore::FrameLoader::init() (FrameLoader.cpp:351) ==137== by 0x144DB8BF: WebCore::Frame::init() (Frame.cpp:192) ==137== by 0xEFD71C5: WebKit::WebFrame::initWithCoreMainFrame(WebKit::WebPage&, WebCore::Frame&) (WebFrame.cpp:115) ==137== by 0xEF7CECD: WebKit::WebPage::WebPage(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&) (WebPage.cpp:721) ==137== by 0xEF7B307: WebKit::WebPage::create(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&) (WebPage.cpp:461) ==137== by 0xECA85C2: WebKit::WebProcess::createWebPage(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&) (WebProcess.cpp:837) ==137== by 0xDEB4991: void IPC::callMemberFunctionImpl<WebKit::WebProcess, void (WebKit::WebProcess::*)(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&), std::tuple<WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters>, 0ul, 1ul>(WebKit::WebProcess*, void (WebKit::WebProcess::*)(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&), std::tuple<WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters>&&, std::integer_sequence<unsigned long, 0ul, 1ul>) (HandleMessage.h:131) ==137== by 0xDEB1B6F: void IPC::callMemberFunction<WebKit::WebProcess, void (WebKit::WebProcess::*)(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&), std::tuple<WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters>, std::integer_sequence<unsigned long, 0ul, 1ul> >(std::tuple<WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters>&&, WebKit::WebProcess*, void (WebKit::WebProcess::*)(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&)) (HandleMessage.h:137) ==137== by 0xDEACC26: void IPC::handleMessage<Messages::WebProcess::CreateWebPage, WebKit::WebProcess, void (WebKit::WebProcess::*)(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&)>(IPC::Connection&, IPC::Decoder&, WebKit::WebProcess*, void (WebKit::WebProcess::*)(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&)) (HandleMessage.h:259) ==137== by 0xDEAA311: WebKit::WebProcess::didReceiveWebProcessMessage(IPC::Connection&, IPC::Decoder&) (WebProcessMessageReceiver.cpp:280) ==137== by 0xECA8AA3: WebKit::WebProcess::didReceiveMessage(IPC::Connection&, IPC::Decoder&) (WebProcess.cpp:916) ==137== by 0xE58AFE3: IPC::Connection::dispatchMessage(IPC::Decoder&) (Connection.cpp:1108) ==137== by 0xE58B27A: IPC::Connection::dispatchMessage(std::unique_ptr<IPC::Decoder, std::default_delete<IPC::Decoder> >) (Connection.cpp:1153) ==137== by 0xE58B821: IPC::Connection::dispatchOneIncomingMessage() (Connection.cpp:1222) ==137== by 0xE58ACF3: IPC::Connection::enqueueIncomingMessage(std::unique_ptr<IPC::Decoder, std::default_delete<IPC::Decoder> >)::{lambda()#1}::operator()() (Connection.cpp:1072) ==137== by 0xE591DD7: WTF::Detail::CallableWrapper<IPC::Connection::enqueueIncomingMessage(std::unique_ptr<IPC::Decoder, std::default_delete<IPC::Decoder> >)::{lambda()#1}, void>::call() (Function.h:53) ==137== by 0xD9D5E94: WTF::Function<void ()>::operator()() const (Function.h:82) ==137== by 0x10FD4BEE: WTF::RunLoop::performWork() (RunLoop.cpp:133) ==137== by 0x110803FD: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::operator()(void*) const (RunLoopGLib.cpp:80) ==137== by 0x11080421: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*) (RunLoopGLib.cpp:82) ==137== by 0x11080390: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::operator()(_GSource*, int (*)(void*), void*) const (RunLoopGLib.cpp:53) ==137== by 0x110803DE: WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::_FUN(_GSource*, int (*)(void*), void*) (RunLoopGLib.cpp:56) ==137== by 0x15FB4293: g_main_dispatch (gmain.c:3381) ==137== by 0x15FB4293: g_main_context_dispatch (gmain.c:4099) ==137== by 0x15FB4637: g_main_context_iterate.constprop.0 (gmain.c:4175) ==137== by 0x15FB4942: g_main_loop_run (gmain.c:4373) ==137== by 0x11080A49: WTF::RunLoop::run() (RunLoopGLib.cpp:108) ==137== by 0xF022010: WebKit::AuxiliaryProcessMainBase<WebKit::WebProcess, true>::run(int, char**) (AuxiliaryProcessMain.h:70) ==137== by 0xF01F6C2: int WebKit::AuxiliaryProcessMain<WebKit::WebProcessMainWPE>(int, char**) (AuxiliaryProcessMain.h:96) ==137== by 0xF01BC1A: WebKit::WebProcessMain(int, char**) (WebProcessMainWPE.cpp:75) ==137== by 0x109918: main (WebProcessMain.cpp:31) ==137== Uninitialised value was created by a stack allocation ==137== at 0x1447AA1A: void WTF::HashTable<WebCore::GlobalWindowIdentifier, WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*>, WTF::KeyValuePairKeyExtractor<WTF::KeyValuePair<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*> >, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::HashTraits<WebCore::GlobalWindowIdentifier> >::checkKey<WTF::HashMapTranslator<WTF::HashMap<WebCore::GlobalWindowIdentifier, WebCore::AbstractDOMWindow*, WTF::DefaultHash<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::GlobalWindowIdentifier>, WTF::HashTraits<WebCore::AbstractDOMWindow*>, WTF::HashTableTraits>::KeyValuePairTraits, WTF::DefaultHash<WebCore::GlobalWindowIdentifier> >, WebCore::GlobalWindowIdentifier>(WebCore::GlobalWindowIdentifier const&) (HashTable.h:655) ==137== * Source/WebCore/page/GlobalWindowIdentifier.h: (WTF::HashTraits<WebCore::GlobalWindowIdentifier>::constructDeletedValue): Canonical link: https://commits.webkit.org/252473@main

…ing-navigations-and-traversals/tentative/forward-to-pruned-entry.html is flaky https://bugs.webkit.org/show_bug.cgi?id=243518 <rdar://98082718> Reviewed by Geoffrey Garen. The test calls `history.forward()` which determines that the next HistoryItem is #1 and schedules a navigation to #1. The test then does a synchronous fragment navigation, which prunes the forward HistoryItem from the back/forward list. When the attempt to navigate to HistoryItem #1 in the async task, it should no longer be part of the back/forward and thus no navigation should happen. The navigation to #1 was happening in WebKit however and this was causing the test to be flaky (since the test checks on a timer to see if the navigation to #1 happened or not). WebKit was trying to deal with this by checking BackForwardController::containsItem() in ScheduledHistoryNavigation::fire() and aborting if the BackForwardController no longer contains the HistoryItem. However, in the WebKit2 implementation, the Back / Forward list lives in the UIProcess and WebBackForwardListProxy::containsItem() was failing to ask the UIProcess. Instead, it was relying on the idToHistoryItemMap() map on the WebProcess side. The issue with this is that the map only gets updated asynchronously via IPC from the UIProcess. In the context of the test, we may not have received this IPC from the UIProcess yet when the ScheduledHistoryNavigation fires since the navigation that pruned the HistoryItem was a synchronous fragment navigation. To address the issue, I updated ebBackForwardListProxy::containsItem() to ask the UIProcess instead of relying on idToHistoryItemMap(), for better reliability. * Source/WebKit/UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::backForwardListContainsItem): * Source/WebKit/UIProcess/WebPageProxy.h: * Source/WebKit/UIProcess/WebPageProxy.messages.in: * Source/WebKit/WebProcess/WebPage/WebBackForwardListProxy.cpp: (WebKit::WebBackForwardListProxy::containsItem const): Canonical link: https://commits.webkit.org/253121@main

…a rejected promise https://bugs.webkit.org/show_bug.cgi?id=247785 rdar://102325201 Reviewed by Yusuke Suzuki. Rest parameter should be caught in async function. So, running this JavaScript program should print "caught". ``` async function f(...[[]]) { } f().catch(e => print("caught")); ``` V8 (used console.log) ``` $ node input.js caught ``` GraalJS ``` $ js input.js caught ``` https://tc39.es/ecma262/#sec-async-function-definitions ... AsyncFunctionDeclaration[Yield, Await, Default] : async [no LineTerminator here] function BindingIdentifier[?Yield, ?Await] ( FormalParameters[~Yield, +Await] ) { AsyncFunctionBody } [+Default] async [no LineTerminator here] function ( FormalParameters[~Yield, +Await] ) { AsyncFunctionBody } AsyncFunctionExpression : async [no LineTerminator here] function BindingIdentifier[~Yield, +Await]opt ( FormalParameters[~Yield, +Await] ) { AsyncFunctionBody } ... According to the spec, it indicates `FormalParameters` is used for Async Function, where `FormalParameters` can be converted to `FunctionRestParameter`. https://tc39.es/ecma262/#sec-parameter-lists ... FormalParameters[Yield, Await] : [empty] FunctionRestParameter[?Yield, ?Await] FormalParameterList[?Yield, ?Await] FormalParameterList[?Yield, ?Await] , FormalParameterList[?Yield, ?Await] , FunctionRestParameter[?Yield, ?Await] ... And based on RS: EvaluateAsyncFunctionBody, it will invoke the promise.reject callback function with abrupt value ([[value]] of non-normal completion record). https://tc39.es/ecma262/#sec-runtime-semantics-evaluateasyncfunctionbody ... 2. Let declResult be Completion(FunctionDeclarationInstantiation(functionObject, argumentsList)). 3. If declResult is an abrupt completion, then a. Perform ! Call(promiseCapability.[[Reject]], undefined, « declResult.[[Value]] »). ... In that case, any non-normal results of evaluating rest parameters should be caught and passed to the reject callback function. To resolve this problem, we should allow the emitted RestParameterNode be wrapped by the catch handler for promise. However, we should remove `m_restParameter` and emit rest parameter byte code in `initializeDefaultParameterValuesAndSetupFunctionScopeStack` if we can prove that change has no side effect. In that case, we can only use one exception handler. Current fix is to add another exception handler. And move the handler byte codes to the bottom of code block in order to make other byte codes as much compact as possible. Input: ``` async function f(arg0, ...[[]]) { } f(); ``` Dumped Byte Codes: ``` ... bb#2 Predecessors: [ #1 ] [ 20] mov dst:loc9, src:<JSValue()>(const0) ... bb#3 Predecessors: [ #2 ] [ 29] get_rest_length dst:loc11, numParametersToSkip:1 ... bb#12 Predecessors: [ #8 #9 #10 ] [ 138] new_func_exp dst:loc10, scope:loc4, functionDecl:0 ... bb#13 Predecessors: [ ] [ 170] catch exception:loc10, thrownValue:loc8 [ 174] jmp targetLabel:8(->182) Successors: [ #15 ] bb#14 Predecessors: [ #7 #11 ] [ 176] catch exception:loc10, thrownValue:loc8 [ 180] jmp targetLabel:2(->182) Successors: [ #15 ] bb#15 Predecessors: [ #13 #14 ] [ 182] mov dst:loc12, src:Undefined(const1) ... Exception Handlers: 1: { start: [ 20] end: [ 29] target: [ 170] } synthesized catch 2: { start: [ 29] end: [ 138] target: [ 176] } synthesized catch ``` * JSTests/stress/catch-rest-parameter.js: Added. (throwError): (shouldThrow): (async f): (throwError.async f): (throwError.async let): (async let): (x.async f): (x): (async shouldThrow): * Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack): * Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h: Canonical link: https://commits.webkit.org/256864@main

https://bugs.webkit.org/show_bug.cgi?id=250196 rdar://98798050 Reviewed by Simon Fraser and Dean Jackson. WebKit has long accidentally depended on the combination of two somewhat unusual behavioral quirks in CGIOSurfaceContext: 1) (Source) If you make a CGImageRef from one CGIOSurfaceContext via CGIOSurfaceContextCreateImage, and mutate the original IOSurface under the hood (or in a different process) in a way that CGIOSurfaceContext does not know, CGIOSurfaceContextCreateImage will return the same CGImageRef when called later. 2) (Destination) If you make a CGImageRef from one CGIOSurfaceContext via CGIOSurfaceContextCreateImage, paint it into a different CGIOSurfaceContext, then mutate the original IOSurface, and paint the same CGImageRef again, the updated IOSurface contents will be used the second time. The second quirk has never worked with unaccelerated CoreGraphics bitmap context destinations. Instead, in the unaccelerated case, the CGImageRef acts as a snapshot of the surface at the time it was created. We've long had code to handle this, forcing CGIOSurfaceContextCreateImage to re-create the CGImageRef each time we paint it (by drawing an empty rect into the CGIOSurfaceContext), working around quirk #1 and thus bypassing quirk #2, if we're painting into an unaccelerated backing store. It turns out our CG display list backing store implementation behaves like a CG bitmap context (without quirk #2), and so currently any IOSurfaces painted into CG display list backing store from a CGImageRef created by CGIOSurfaceContextCreateImage (but not -CreateImageReference) become stale if painted multiple times. To avoid this, extend the workaround to apply to any destination context that claims that it needs the workaround, and use it whenever painting an IOSurface into anything other than a CGIOSurfaceContext. * Source/WebCore/platform/graphics/BifurcatedGraphicsContext.cpp: (WebCore::BifurcatedGraphicsContext::needsCachedNativeImageInvalidationWorkaround): * Source/WebCore/platform/graphics/BifurcatedGraphicsContext.h: Make BifurcatedGraphicsContext assume the more conservative mode of its two children. * Source/WebCore/platform/graphics/GraphicsContext.h: (WebCore::GraphicsContext::needsCachedNativeImageInvalidationWorkaround): Assume that by default, GraphicsContexts need the workaround. * Source/WebCore/platform/graphics/cg/GraphicsContextCG.cpp: (WebCore::GraphicsContextCG::needsCachedNativeImageInvalidationWorkaround): * Source/WebCore/platform/graphics/cg/GraphicsContextCG.h: GraphicsContextCG needs the workaround, except in the IOSurface->IOSurface case. * Source/WebCore/platform/graphics/cg/ImageBufferIOSurfaceBackend.cpp: (WebCore::ImageBufferIOSurfaceBackend::finalizeDrawIntoContext): Confer with the GraphicsContext about its need for the workaround instead of hardcoding the behavior here. * Source/WebKit/Shared/RemoteLayerTree/CGDisplayListImageBufferBackend.mm: CG display list graphics contexts need the workaround. Canonical link: https://commits.webkit.org/258586@main

https://bugs.webkit.org/show_bug.cgi?id=251063 rdar://104585575 Reviewed by Mark Lam and Justin Michaud. This patch enhances CallFrame::dump to support wasm frames in btjs stacktrace. The example is as follows. frame #0: 0x00000001035fca78 JavaScriptCore`JSC::functionBreakpoint(globalObject=0x000000012f410068, callFrame=0x000000016fdfa9d0) at JSDollarVM.cpp:2273:9 [opt] frame #1: 0x000000010ec44204 0x10eccc5dc frame #2: 0x000000010eccc5dc callback#Dwaxn6 [Baseline bc#50](Undefined) frame #3: 0x000000010ec4ca84 wasm-stub [WasmToJS](Wasm::Instance: 0x10d29da40) frame #4: 0x000000010ed0c060 <?>.wasm-function[1] [OMG](Wasm::Instance: 0x10d29da40) frame #5: 0x000000010ed100d0 jsToWasm#CWTx6k [FTL bc#22](Cell[JSModuleEnvironment]: 0x12f524540, Cell[WebAssemblyFunction]: 0x10d06a3a8, 1, 2, 3) frame #6: 0x000000010ec881b0 #D5ymZE [Baseline bc#733](Undefined, Cell[Generator]: 0x12f55c180, 1, Cell[Object]: 0x12f69dfc0, 0, Cell[JSLexicalEnvironment]: 0x12f52cee0) frame #7: 0x000000010ec3c008 asyncFunctionResume#A4ayYg [LLInt bc#49](Undefined, Cell[Generator]: 0x12f55c180, Cell[Object]: 0x12f69dfc0, 0) frame #8: 0x000000010ec3c008 promiseReactionJobWithoutPromise#D0yDF1 [LLInt bc#25](Undefined, Cell[Function]: 0x12f44f3c0, Cell[Object]: 0x12f69dfc0, Cell[Generator]: 0x12f55c180) frame #9: 0x000000010ec80ec0 promiseReactionJob#EdShZz [Baseline bc#74](Undefined, Undefined, Cell[Function]: 0x12f44f3c0, Cell[Object]: 0x12f69dfc0, Cell[Generator]: 0x12f55c180) frame #10: 0x000000010ec3c728 frame #11: 0x0000000103137560 JavaScriptCore`JSC::Interpreter::executeCall(JSC::JSGlobalObject*, JSC::JSObject*, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) [inlined] JSC::JITCode::execute(this=<unavailable>, vm=<unavailable>, protoCallFrame=<unavailable>) at JITCodeInlines.h:42:38 [opt] frame #12: 0x0000000103137524 JavaScriptCore`JSC::Interpreter::executeCall(this=<unavailable>, lexicalGlobalObject=<unavailable>, function=<unavailable>, callData=<unavailable>, thisValue=<unavailable>, args=<unavailable>) at Interpreter.cpp:1093:27 [opt] frame #13: 0x000000010349d6d0 JavaScriptCore`JSC::runJSMicrotask(globalObject=0x000000012f410068, identifier=(m_identifier = 81), job=JSValue @ x22, argument0=JSValue @ x26, argument1=JSValue @ x25, argument2=<unavailable>, argument3=<unavailable>) at JSMicrotask.cpp:98:9 [opt] frame #14: 0x00000001039dfc54 JavaScriptCore`JSC::VM::drainMicrotasks() (.cold.1) at VM.cpp:0:9 [opt] frame #15: 0x00000001035e58a4 JavaScriptCore`JSC::VM::drainMicrotasks() [inlined] JSC::MicrotaskQueue::dequeue(this=<unavailable>) at VM.cpp:0:9 [opt] frame #16: 0x00000001035e5894 JavaScriptCore`JSC::VM::drainMicrotasks(this=0x000000012f000000) at VM.cpp:1255:46 [opt] ... * Source/JavaScriptCore/interpreter/CallFrame.cpp: (JSC::CallFrame::dump const): Canonical link: https://commits.webkit.org/259262@main

https://bugs.webkit.org/show_bug.cgi?id=252379 <rdar://104303475> Reviewed by Antti Koivisto. While display boxes are positioned based on margin boxes, the left/right side of a display box do not include these margins. e.g. [display box #1]<- 100px margin ->[display box #2] width: 50px width: 50px margin-right: 100px; display box #1's right: 50px display box #2's left: 150px This patch makes sure when we place an out-of-flow box next to display box #1, we put it at 150px and not at 50px. * LayoutTests/fast/inline/out-of-flow-inline-with-previous-next-margin-expected.html: Added. * LayoutTests/fast/inline/out-of-flow-inline-with-previous-next-margin.html: Added. * Source/WebCore/layout/formattingContexts/inline/InlineFormattingGeometry.cpp: (WebCore::Layout::InlineFormattingGeometry::staticPositionForOutOfFlowInlineLevelBox const): Canonical link: https://commits.webkit.org/260380@main

https://bugs.webkit.org/show_bug.cgi?id=255872 rdar://108738795 Reviewed by Darin Adler. It turns out that JSON, HTTP, and XML all use the same whitespace definition, so let's make them share it. Also correct an existing comment for that function as \v is not part of isASCIIWhitespace(), but \f is. Furthermore, remove the "optimization" from these whitespace functions per a comment from Chris Dumez at WebKit#13080 (comment): > Just verified out of curiosity and llvm does generate the same code > with -O2 (tried both arm64 and x86_64): > > isXMLSpace1(char): // @isXMLSpace1(char) > mov x8, WebKit#9728 // =0x2600 > and w9, w0, #0xff > movk x8, #1, lsl #32 > cmp w9, #33 > cset w9, lo > lsr x8, x8, x0 > and w0, w9, w8 > ret > isXMLSpace2(char): // @isXMLSpace2(char) > mov x8, WebKit#9728 // =0x2600 > and w9, w0, #0xff > movk x8, #1, lsl #32 > cmp w9, #33 > cset w9, lo > lsr x8, x8, x0 > and w0, w9, w8 > ret > > Ahmad-S792 Let's simplify the code then. * Source/WTF/wtf/ASCIICType.h: (WTF::isASCIIWhitespace): (WTF::isJSONOrHTTPOrXMLWhitespace): (WTF::isJSONOrHTTPWhitespace): Deleted. * Source/WTF/wtf/JSONValues.cpp: (WTF::JSONImpl::Value::parseJSON): * Source/WTF/wtf/text/StringToIntegerConversion.h: * Source/WebCore/Modules/cache/DOMCache.cpp: (WebCore::hasResponseVaryStarHeaderValue): * Source/WebCore/Modules/cache/DOMCacheEngine.cpp: (WebCore::DOMCacheEngine::queryCacheMatch): * Source/WebCore/Modules/fetch/FetchBodyConsumer.cpp: (WebCore::parseParameters): (WebCore::parseMIMEType): (WebCore::FetchBodyConsumer::packageFormData): * Source/WebCore/Modules/fetch/FetchHeaders.cpp: (WebCore::canWriteHeader): (WebCore::appendToHeaderMap): (WebCore::FetchHeaders::set): (WebCore::FetchHeaders::filterAndFill): * Source/WebCore/mathml/MathMLPresentationElement.cpp: (WebCore::MathMLPresentationElement::parseMathMLLength): * Source/WebCore/mathml/MathMLTokenElement.cpp: (WebCore::MathMLTokenElement::convertToSingleCodePoint): * Source/WebCore/page/csp/ContentSecurityPolicyDirectiveList.cpp: (WebCore::ContentSecurityPolicyDirectiveList::parse): * Source/WebCore/platform/ReferrerPolicy.cpp: (WebCore::parseReferrerPolicy): * Source/WebCore/platform/network/DataURLDecoder.cpp: (WebCore::DataURLDecoder::DecodeTask::process): * Source/WebCore/platform/network/HTTPParsers.cpp: (WebCore::parseContentTypeOptionsHeader): (WebCore::parseClearSiteDataHeader): (WebCore::parseRange): (WebCore::parseCrossOriginResourcePolicyHeader): * Source/WebCore/platform/network/HTTPParsers.h: (WebCore::addToAccessControlAllowList): * Source/WebCore/platform/network/ParsedContentType.cpp: (WebCore::skipSpaces): (WebCore::parseToken): (WebCore::ParsedContentType::create): (WebCore::ParsedContentType::setContentType): * Source/WebCore/platform/network/ResourceResponseBase.cpp: (WebCore::ResourceResponseBase::containsInvalidHTTPHeaders const): * Source/WebCore/platform/network/TimingAllowOrigin.cpp: (WebCore::passesTimingAllowOriginCheck): * Source/WebCore/xml/XMLHttpRequest.cpp: (WebCore::XMLHttpRequest::setRequestHeader): * Source/WebCore/xml/XPathFunctions.cpp: (WebCore::XPath::FunNormalizeSpace::evaluate const): * Source/WebCore/xml/XPathParser.cpp: (WebCore::XPath::Parser::skipWS): * Source/WebCore/xml/XPathUtil.cpp: (WebCore::XPath::isXMLSpace): Deleted. * Source/WebCore/xml/XPathUtil.h: * Source/WebKit/NetworkProcess/cache/CacheStorageEngineCache.cpp: (WebKit::CacheStorage::updateVaryInformation): * Source/WebKit/NetworkProcess/soup/WebSocketTaskSoup.cpp: (WebKit::WebSocketTask::WebSocketTask): * Source/WebKit/NetworkProcess/storage/CacheStorageRecord.h: (WebKit::CacheStorageRecordInformation::updateVaryHeaders): * Source/WebKit/WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::shouldSkipDecidePolicyForResponse const): Canonical link: https://commits.webkit.org/266253@main

https://bugs.webkit.org/show_bug.cgi?id=263269 <rdar://problem/117086061> Reviewed by Ross Kirsling. The spec has at least 8 occurrences of > It is a Syntax Error if the LexicallyDeclaredNames of X contains any duplicate entries. early error rules that preclude duplicate lexical declarations. For backwards-compatibility, LexicallyDeclaredNames [1] skips top-level function declarations inside `ScriptBody : StatementList` by invoking TopLevelLexicallyDeclaredNames [2], which returns an empty list for them [3]. However, the semantics of LexicallyDeclaredNames is entirely different for `ModuleItem` (also please see note #1). The fact that top-level function declarations are lexical in module code is also evident during binding initialization [4]. This change makes top-level function declarations in module code behave like `let` rather than `var`, introducing early errors that come with it, like disallowing duplicates with `var` and `function`. Since inside declareFunction() we can't rely neither on `m_scriptMode` (which is always `Module`, even for nested functions that absolutely should not throw SyntaxError for duplicate declarations), nor on `m_parseMode` (it's already the parse mode of the declared function itself), this change introduces isModuleCode() [5], refactoring parse mode handling in Scope. Also, this patch aligns declareFunctionAsLet() with declareVariable(), called for `let` declarations, by adding `m_declaredVariables` check, which may fail only in module code. Removes now incorrect (for module code only) ASSERT that isn't particularly useful given how simple declareFunction() now is. Aligns JSC with V8 and SpiderMonkey. [1]: https://tc39.es/ecma262/#sec-static-semantics-lexicallydeclarednames [2]: https://tc39.es/ecma262/#sec-static-semantics-toplevellexicallydeclarednames [3]: https://tc39.es/ecma262/#prod-HoistableDeclaration [4]: https://tc39.es/ecma262/#sec-source-text-module-record-initialize-environment (step 24.iii) [5]: https://tc39.es/ecma262/#sec-types-of-source-code * JSTests/modules/async-function-export.js: Moved to JSTests/stress/modules-syntax-error.js. * JSTests/stress/modules-syntax-error.js: * JSTests/test262/expectations.yaml: Mark 8 tests as passing. * Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * Source/JavaScriptCore/parser/Parser.cpp: (JSC::Parser<LexerType>::Parser): (JSC::Parser<LexerType>::parseFunctionInfo): (JSC::Parser<LexerType>::parseMemberExpression): * Source/JavaScriptCore/parser/Parser.h: (JSC::Scope::setSourceParseMode): (JSC::Scope::isGlobalCode const): (JSC::Scope::isModuleCode const): (JSC::Scope::declareFunctionAsLet): (JSC::Scope::setIsGlobalCode): (JSC::Scope::setIsModuleCode): (JSC::Parser::declareFunction): (JSC::Scope::setIsGlobalCodeScope): Deleted. (JSC::Scope::isGlobalCodeScope const): Deleted. Canonical link: https://commits.webkit.org/269485@main

https://bugs.webkit.org/show_bug.cgi?id=266153 Reviewed by Antti Koivisto. This patch adds support for "ruby-align: space-around" on both bidi and non-bidi content. "ruby-align: space-around" consists of 2 adjustments at run level. - run spacing at justification opportunities (similar to text-align: justify) - content offsetting to distribute one extra justification opportunity space before/after base content In this patch we start computing the offset values at step #1 and pass them over to InlineContentBuilder where the final ruby processing happens (using visual order). InlineContentAligner takes these offset values and adjusts (aligns) the display boxes accordingly. What makes it a bit more verbose is the fact that while non-bidi base runs have the correct spacing (e.g. when annotation is wider than the base), we lose that information at visual reordering (<- we essentially have a fast path for non-bidi content, where as we build the Line for line breaking we also compute horizontal content positions) It simply means that while non-bidi content, offsetting means just moving content inside the base without pushing adjacent content/expanding enclosing inline boxes, bidi content needs both (see AdjustContentOnlyInsideRubyBase). * Source/WebCore/layout/formattingContexts/inline/InlineContentAligner.cpp: (WebCore::Layout::shiftDisplayBox): (WebCore::Layout::expandInlineBox): (WebCore::Layout::alignmentOffset): (WebCore::Layout::expandInlineBoxWithDescendants): (WebCore::Layout::shiftRubyBaseContentByAlignmentOffset): (WebCore::Layout::InlineContentAligner::applyRubyAlignSpaceAround): (WebCore::Layout::InlineContentAligner::applyRubyBaseAlignmentOffset): (WebCore::Layout::InlineContentAligner::applyRubyAlign): Deleted. * Source/WebCore/layout/formattingContexts/inline/InlineContentAligner.h: * Source/WebCore/layout/formattingContexts/inline/InlineLine.h: * Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.cpp: (WebCore::Layout::LineBuilder::layoutInlineContent): * Source/WebCore/layout/formattingContexts/inline/LineLayoutResult.h: * Source/WebCore/layout/formattingContexts/inline/TextOnlySimpleLineBuilder.cpp: (WebCore::Layout::TextOnlySimpleLineBuilder::layoutInlineContent): * Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayContentBuilder.cpp: (WebCore::Layout::InlineDisplayContentBuilder::build): (WebCore::Layout::InlineDisplayContentBuilder::processRubyContent): * Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayContentBuilder.h: * Source/WebCore/layout/formattingContexts/inline/ruby/RubyFormattingContext.cpp: (WebCore::Layout::RubyFormattingContext::applyRubyAlignOnBaseContent): (WebCore::Layout::RubyFormattingContext::applyRubyAlign): (WebCore::Layout::RubyFormattingContext::applyAlignmentOffsetList): (WebCore::Layout::applyRubyAlignOnBaseContent): Deleted. * Source/WebCore/layout/formattingContexts/inline/ruby/RubyFormattingContext.h: Canonical link: https://commits.webkit.org/271836@main

https://bugs.webkit.org/show_bug.cgi?id=268227 Reviewed by Antti Koivisto. This is in preparation for being able to run a range of content through the simple line builder (where the range has text only content e.g. <div><span>this is text content</span></div> 1. Keep track of the number of inline boxes (m_inlineBoxCount) 2. m_isTextAndForcedLineBreakOnlyContent only tracks _content_ type of inline level boxes now (excluding inline boxes, see #1) 3. and it does not track if content needs bidi reordering anymore (we already track that information in m_contentRequiresVisualReordering) 4. Add InlineContentCache::InlineItems::ContentAttributes to hold all these bits. 5. Remove dedicated set functions and pass these bit through InlineContentCache::InlineItems::set/replace. * Source/WebCore/layout/formattingContexts/inline/InlineContentCache.h: (WebCore::Layout::InlineContentCache::InlineItems::requiresVisualReordering const): (WebCore::Layout::InlineContentCache::InlineItems::hasTextAndLineBreakOnlyContent const): (WebCore::Layout::InlineContentCache::InlineItems::hasInlineBoxes const): (WebCore::Layout::InlineContentCache::InlineItems::inlineBoxCount const): (WebCore::Layout::InlineContentCache::InlineItems::set): (WebCore::Layout::InlineContentCache::InlineItems::replace): (WebCore::Layout::InlineContentCache::InlineItems::append): Deleted. (WebCore::Layout::InlineContentCache::InlineItems::clear): Deleted. (WebCore::Layout::InlineContentCache::InlineItems::setRequiresVisualReordering): Deleted. (WebCore::Layout::InlineContentCache::InlineItems::setIsNonBidiTextAndForcedLineBreakOnlyContent): Deleted. (WebCore::Layout::InlineContentCache::InlineItems::isNonBidiTextAndForcedLineBreakOnlyContent const): Deleted. * Source/WebCore/layout/formattingContexts/inline/InlineFormattingContext.cpp: (WebCore::Layout::InlineFormattingContext::layout): (WebCore::Layout::InlineFormattingContext::minimumMaximumContentSize): (WebCore::Layout::InlineFormattingContext::minimumContentSize): (WebCore::Layout::InlineFormattingContext::maximumContentSize): * Source/WebCore/layout/formattingContexts/inline/InlineItemsBuilder.cpp: (WebCore::Layout::InlineItemsBuilder::build): (WebCore::Layout::InlineItemsBuilder::traverseUntilDamaged): (WebCore::Layout::InlineItemsBuilder::collectInlineItems): (WebCore::Layout::InlineItemsBuilder::handleTextContent): (WebCore::Layout::InlineItemsBuilder::handleInlineBoxStart): (WebCore::Layout::InlineItemsBuilder::handleInlineBoxEnd): (WebCore::Layout::InlineItemsBuilder::handleInlineLevelBox): * Source/WebCore/layout/formattingContexts/inline/InlineItemsBuilder.h: * Source/WebCore/layout/formattingContexts/inline/IntrinsicWidthHandler.cpp: (WebCore::Layout::IntrinsicWidthHandler::IntrinsicWidthHandler): (WebCore::Layout::IntrinsicWidthHandler::minimumContentSize): (WebCore::Layout::IntrinsicWidthHandler::maximumContentSize): (WebCore::Layout::IntrinsicWidthHandler::computedIntrinsicWidthForConstraint): (WebCore::Layout::IntrinsicWidthHandler::simplifiedMaximumWidth): * Source/WebCore/layout/formattingContexts/inline/IntrinsicWidthHandler.h: (WebCore::Layout::IntrinsicWidthHandler::inlineItemList const): * Source/WebCore/layout/formattingContexts/inline/TextOnlySimpleLineBuilder.cpp: (WebCore::Layout::TextOnlySimpleLineBuilder::isEligibleForSimplifiedTextOnlyInlineLayout): * Source/WebCore/layout/formattingContexts/inline/TextOnlySimpleLineBuilder.h: Canonical link: https://commits.webkit.org/273632@main

https://bugs.webkit.org/show_bug.cgi?id=275019 <rdar://128067952> Reviewed by Antti Koivisto. 1. Backdrop render is always anchored to the viewport regardless of where the associated content renderer is 2. While destroying the content renderer we also remove the backdrop renderer In order to let invalidateLineLayout kick in (see RenderTreeBuilder::detachFromRenderElement) we have to make sure the content renderer is not considered as the "destroy root" of the backdrop (see #1). * LayoutTests/fast/dynamic/backdrop-remove-crash-expected.txt: Added. * LayoutTests/fast/dynamic/backdrop-remove-crash.html: Added. * Source/WebCore/rendering/updating/RenderTreeUpdater.cpp: (WebCore::RenderTreeUpdater::tearDownRenderers): Canonical link: https://commits.webkit.org/279651@main

…terpolate https://bugs.webkit.org/show_bug.cgi?id=275993 rdar://130704075 Reviewed by Matt Woodrow. We had three separate issues that would lead us to visually animate when one of the values in a given interval is a non-invertible matrix: 1. The method that determines whether it's possible to interpolate between two `transform` values would only account for `matrix()` values and not `matrix3d()`. 2. The `transform` property animation wrapper would not implement the `canInterpolate()` method and would thus always indicate that two `transform` values could be interpolated. This caused CSS Transitions to run even when the values would not a discrete interpolation. 3. Even if we correctly determined that two `transform` values should yield discrete interpolation, we would delegate an accelerated animation to Core Animation and that animation's behavior would differ an visibly interpolate. In this patch, we fill all three issues. First, we introduce a new `TransformOperations::containsNonInvertibleMatrix()` method which will check whether a `matrix()` or `matrix3d()` value that is not invertible is contained in the list of transform operations. We now use this function in `TransformOperations::shouldFallBackToDiscreteAnimation()` to address issue #1. Then, we add a `canInterpolate()` implementation to `AcceleratedTransformOperationsPropertyWrapper` which calls in the now-correct `TransformOperations::shouldFallBackToDiscreteAnimation()` to address issue #2. Finally, we add a new flag on `BlendingKeyframes` to determine whether a keyframe contains a `transform` value with a non-invertible matrix and we consult that flag in `KeyframeEffect::canBeAccelerated()` to determine whether an animation should be delegated to Core Animation, addressing issue #3. We add new WPT tests to check the correct interpolation behavior of `transform` when a non-invertible `matrix3d()` value is used, that no CSS Transition can be started with such a value, and finally that no animation is visibly run to catch the Core Animation case. * LayoutTests/imported/w3c/web-platform-tests/css/css-transforms/animation/transform-interpolation-007-expected.txt: Added. * LayoutTests/imported/w3c/web-platform-tests/css/css-transforms/animation/transform-interpolation-007.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/css-transforms/animation/transform-non-invertible-discrete-interpolation-expected.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/css-transforms/animation/transform-non-invertible-discrete-interpolation-ref.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/css-transforms/animation/transform-non-invertible-discrete-interpolation.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/css-transforms/animation/transform-non-invertible-no-transition-expected.txt: Added. * LayoutTests/imported/w3c/web-platform-tests/css/css-transforms/animation/transform-non-invertible-no-transition.html: Added. * Source/WebCore/animation/BlendingKeyframes.cpp: (WebCore::BlendingKeyframes::analyzeKeyframe): * Source/WebCore/animation/BlendingKeyframes.h: (WebCore::BlendingKeyframes::hasDiscreteTransformInterval const): * Source/WebCore/animation/CSSPropertyAnimation.cpp: * Source/WebCore/animation/KeyframeEffect.cpp: (WebCore::KeyframeEffect::canBeAccelerated const): * Source/WebCore/platform/graphics/transforms/TransformOperations.cpp: (WebCore::TransformOperations::containsNonInvertibleMatrix const): (WebCore::TransformOperations::shouldFallBackToDiscreteAnimation const): * Source/WebCore/platform/graphics/transforms/TransformOperations.h: Canonical link: https://commits.webkit.org/280466@main

…text run https://bugs.webkit.org/show_bug.cgi?id=277716 rdar://133309470 Reviewed by Matthieu Dubet. This patch implements the processing of text-autospace: ideogram-alpha only within an element. We don't yet handle element boundaries here. Although we pass SpacingState context from one ComplexTextController to another, we do that here in a limited way, only for measuring text for layout and for painting. There are other places in code which this will be necessary, for example, for handling element boundaries. 1. During the construction of ComplexTextController, we call ::adjustGlyphsAndAdvances which already iterates through glyphs and adjust spacing for other reasons. Now we process each pair of characters related to these glyphs here, adding the spacing necessary before the "current" character. For that reason, the SpacingState stores information about the previous character of a run. We also save the measured spacing in a new parallel vector m_textAutoSpaceSpacings. At this phase we can only manipulate a glyph advance, however, for adding space "before" a glyph, we need to move the glyph to the logical right, which is done later on ::advance. 2. ComplexTextController::advance is called for both layout and painting, but during painting it has access to a GlyphBuffer and it add glyphs into it. We are introducing a new GlyphBuffer::add function that also takes the glyph's origin, so we can manipulate the origin as necessary by adding the previous calculated spacing. 3. Doing #1 and #2 is already enough for painting the extra spacing between relevant characters according to their classes. Howeverm the width measured during layout would be broken because IFC splits text content into inlineTextItem(s) and measure the width of each item independently. This means that we already have to handle SpacingState passing here, otherwise we are not able to handle spacing between characters on the boundary of different InlineTextItem. * LayoutTests/imported/w3c/web-platform-tests/css/css-text/text-autospace/text-autospace-ideogram-alpha-001-expected.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/css-text/text-autospace/text-autospace-ideogram-alpha-001-ref.html: Added. * LayoutTests/imported/w3c/web-platform-tests/css/css-text/text-autospace/text-autospace-ideogram-alpha-001.html: Added. * Source/WTF/wtf/text/CharacterProperties.h: (WTF::isPunctuation): (WTF::isOpeningPunctuation): (WTF::isClosingPunctuation): (WTF::isOfScriptType): (WTF::eastAsianWidth): (WTF::isEastAsianFullWidth): (WTF::isCJKSymbolOrPunctuation): * Source/WebCore/Sources.txt: * Source/WebCore/WebCore.xcodeproj/project.pbxproj: * Source/WebCore/layout/formattingContexts/inline/InlineItemsBuilder.cpp: (WebCore::Layout::InlineItemsBuilder::computeInlineTextItemWidths): * Source/WebCore/layout/formattingContexts/inline/text/TextUtil.cpp: (WebCore::Layout::TextUtil::width): * Source/WebCore/layout/formattingContexts/inline/text/TextUtil.h: (WebCore::Layout::TextUtil::width): * Source/WebCore/platform/graphics/ComplexTextController.cpp: (WebCore::ComplexTextController::ComplexTextController): (WebCore::ComplexTextController::advance): (WebCore::ComplexTextController::adjustGlyphsAndAdvances): (WebCore::ComplexTextController::ComplexTextRun::ComplexTextRun): * Source/WebCore/platform/graphics/ComplexTextController.h: (WebCore::ComplexTextController::ComplexTextRun::textAutospaceSize const): * Source/WebCore/platform/graphics/FontCascade.cpp: (WebCore::FontCascade::width const): (WebCore::FontCascade::codePath const): * Source/WebCore/platform/graphics/GlyphBuffer.h: (WebCore::GlyphBuffer::add): * Source/WebCore/platform/graphics/TextRun.cpp: * Source/WebCore/platform/graphics/TextRun.h: * Source/WebCore/platform/graphics/WidthCache.h: (WebCore::WidthCache::add): (WebCore::WidthCache::invalidateCacheForTextSpacing): * Source/WebCore/platform/graphics/harfbuzz/ComplexTextControllerHarfBuzz.cpp: (WebCore::ComplexTextController::ComplexTextRun::ComplexTextRun): * Source/WebCore/platform/graphics/mac/ComplexTextControllerCoreText.mm: (WebCore::ComplexTextController::ComplexTextRun::ComplexTextRun): * Source/WebCore/platform/graphics/skia/ComplexTextControllerSkia.cpp: (WebCore::ComplexTextController::ComplexTextRun::ComplexTextRun): * Source/WebCore/platform/text/TextSpacing.cpp: Added. (WebCore::TextAutospace::shouldApplySpacing const): (WebCore::TextAutospace::textAutospaceSize): (WebCore::TextSpacing::isIdeograph): (WebCore::TextSpacing::isNonIdeographicNumeral): (WebCore::TextSpacing::characterClass): * Source/WebCore/platform/text/TextSpacing.h: (WebCore::TextAutospace::hasIdeographAlpha const): (WebCore::TextAutospace::hasIdeographNumeric const): Canonical link: https://commits.webkit.org/282192@main

…text run https://bugs.webkit.org/show_bug.cgi?id=277716 rdar://133309470 Reviewed by Matthieu Dubet. We are relanding this patch as its first version was reverted due to performance reasons. On the current iteration we are avoiding classifying characters when not needed (text-autospace: no-autospace). We also won't keep the parralel vector for the added spacing in such a case. Original patch description: This patch implements the processing of text-autospace: ideogram-alpha only within an element. We don't yet handle element boundaries here. Although we pass SpacingState context from one ComplexTextController to another, we do that here in a limited way, only for measuring text for layout and for painting. There are other places in code which this will be necessary, for example, for handling element boundaries. 1. During the construction of ComplexTextController, we call ::adjustGlyphsAndAdvances which already iterates through glyphs and adjust spacing for other reasons. Now we process each pair of characters related to these glyphs here, adding the spacing necessary before the "current" character. For that reason, the SpacingState stores information about the previous character of a run. We also save the measured spacing in a new parallel vector m_textAutoSpaceSpacings. At this phase we can only manipulate a glyph advance, however, for adding space "before" a glyph, we need to move the glyph to the logical right, which is done later on ::advance. 2. ComplexTextController::advance is called for both layout and painting, but during painting it has access to a GlyphBuffer and it add glyphs into it. We are introducing a new GlyphBuffer::add function that also takes the glyph's origin, so we can manipulate the origin as necessary by adding the previous calculated spacing. 3. Doing #1 and #2 is already enough for painting the extra spacing between relevant characters according to their classes. Howeverm the width measured during layout would be broken because IFC splits text content into inlineTextItem(s) and measure the width of each item independently. This means that we already have to handle SpacingState passing here, otherwise we are not able to handle spacing between characters on the boundary of different InlineTextItem. * Source/WTF/wtf/text/CharacterProperties.h: (WTF::isPunctuation): (WTF::isOpeningPunctuation): (WTF::isClosingPunctuation): (WTF::isOfScriptType): (WTF::eastAsianWidth): (WTF::isEastAsianFullWidth): (WTF::isCJKSymbolOrPunctuation): * Source/WebCore/Sources.txt: * Source/WebCore/WebCore.xcodeproj/project.pbxproj: * Source/WebCore/layout/formattingContexts/inline/InlineItemsBuilder.cpp: (WebCore::Layout::InlineItemsBuilder::computeInlineTextItemWidths): * Source/WebCore/layout/formattingContexts/inline/text/TextUtil.cpp: (WebCore::Layout::TextUtil::width): * Source/WebCore/layout/formattingContexts/inline/text/TextUtil.h: (WebCore::Layout::TextUtil::width): * Source/WebCore/platform/graphics/ComplexTextController.cpp: (WebCore::ComplexTextController::ComplexTextController): (WebCore::ComplexTextController::advance): (WebCore::ComplexTextController::adjustGlyphsAndAdvances): (WebCore::ComplexTextController::ComplexTextRun::ComplexTextRun): * Source/WebCore/platform/graphics/ComplexTextController.h: (WebCore::ComplexTextController::ComplexTextRun::textAutospaceSize const): * Source/WebCore/platform/graphics/FontCascade.cpp: (WebCore::FontCascade::width const): (WebCore::FontCascade::codePath const): * Source/WebCore/platform/graphics/GlyphBuffer.h: (WebCore::GlyphBuffer::add): * Source/WebCore/platform/graphics/TextRun.cpp: * Source/WebCore/platform/graphics/TextRun.h: * Source/WebCore/platform/graphics/WidthCache.h: (WebCore::WidthCache::add): (WebCore::WidthCache::invalidateCacheForTextSpacing): * Source/WebCore/platform/graphics/coretext/ComplexTextControllerCoreText.mm: (WebCore::ComplexTextController::ComplexTextRun::ComplexTextRun): * Source/WebCore/platform/graphics/harfbuzz/ComplexTextControllerHarfBuzz.cpp: (WebCore::ComplexTextController::ComplexTextRun::ComplexTextRun): * Source/WebCore/platform/graphics/skia/ComplexTextControllerSkia.cpp: (WebCore::ComplexTextController::ComplexTextRun::ComplexTextRun): * Source/WebCore/platform/text/TextSpacing.cpp: Added. (WebCore::TextAutospace::shouldApplySpacing const): (WebCore::TextAutospace::textAutospaceSize): (WebCore::TextSpacing::isIdeograph): (WebCore::TextSpacing::isNonIdeographicNumeral): (WebCore::TextSpacing::characterClass): * Source/WebCore/platform/text/TextSpacing.h: (WebCore::TextAutospace::hasIdeographAlpha const): (WebCore::TextAutospace::hasIdeographNumeric const): Canonical link: https://commits.webkit.org/282511@main

…r_ overflow https://bugs.webkit.org/show_bug.cgi?id=279486 Reviewed by Antti Koivisto. Let's call 1. lastHyphenPosition when we are dealing with the non-overflowing runs (this is when we can't break the overflowing part of the content and try to break runs _before_ the overflowing point). Since these runs are not overflowing, we should simply pick the last hyphenation position. 2. firstHyphenPosition when even the first hyphenation would produce overflowing content (e.g. minimum-content with computation) 3. hyphenPositionBefore when dealing with normal overflowing breaking (neither #1 nor #2) * LayoutTests/fast/inline/overflowing-content-with-hypens-expected.html: Added. * LayoutTests/fast/inline/overflowing-content-with-hypens.html: Added. * Source/WebCore/layout/formattingContexts/inline/InlineContentBreaker.cpp: (WebCore::Layout::firstTextRunIndex): (WebCore::Layout::InlineContentBreaker::processOverflowingContent const): (WebCore::Layout::limitBeforeValue): (WebCore::Layout::limitAfterValue): (WebCore::Layout::hasEnoughContentForHyphenation): (WebCore::Layout::firstHyphenPosition): (WebCore::Layout::lastHyphenPosition): (WebCore::Layout::hyphenPositionBefore): (WebCore::Layout::InlineContentBreaker::tryBreakingTextRun const): (WebCore::Layout::InlineContentBreaker::tryHyphenationAcrossOverflowingInlineTextItems const): (WebCore::Layout::hyphenPosition): Deleted. Canonical link: https://commits.webkit.org/283528@main

@0

…ter follows to the same value https://bugs.webkit.org/show_bug.cgi?id=279570 rdar://135851156 Reviewed by Keith Miller. Let's consider the following FTL graph. BB#0 @0 = NewObject() Jump #1 BB#1 PutByOffset(@0, 0, @x) Jump #2 BB#2 ... @z = ... @1 = GetByOffset(@x, 0) Branch(@1, #3, #4) BB#3 PutByOffset(@0, 0, @z) Jump #5 BB#4 PutByOffset(@0, 0, @z) Jump #5 BB#5 Jump #2 Now, we would like to eliminate @0 object allocation. And we are computing SSA for pointers of fields of the that object which gets eliminated. Consider about @x's fields' SSA. PutByOffset becomes Def and GetByOffset becomes Use. And the same field will get the same SSA variable. So we first puts Defs and compute Phis based on that. In ObjectAllocationSinking phase, we had a fast path when the both SSA variable is following to the same value. Let's see BB#5. Because BB#3 and BB#4 defines Defs, dominance frontier BB#5 will need to introduce Phi. But interestingly, both SSA variable is following to the same @z. As a result, we were not inserting Phi for this case. But this is wrong. Inserted Phi is a Def, and based on that, we will further introduce Phis with that. If we omit inserting Phi in BB#5, we will not insert Phi into BB#2 while BB#2 will merge BB#1's Def And BB#5's Phi's Def. As a result, in BB#2, we think this variable is following to BB#1's Def. But that's wrong and BB#5's Phi exists. This patch removes this fast path to fix the issue. * JSTests/stress/object-allocation-sinking-phi-insertion-for-pointers.js: Added. (Queue): (Queue.prototype.enqueue): (Queue.prototype.dequeue): (i.queue.dequeue): * Source/JavaScriptCore/dfg/DFGObjectAllocationSinkingPhase.cpp: Canonical link: https://commits.webkit.org/283558@main

rniwa and others added 30 commits September 10, 2019 05:30

Cherry-pick r249535. rdar://problem/55183140

72a5d24

Canonical link: https://commits.webkit.org/213666.345@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@249707 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Unreviewed build fix. rdar://problem/55198064

1d4e88a

Canonical link: https://commits.webkit.org/213666.346@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@249727 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Versioning.

b9e82e7

Canonical link: https://commits.webkit.org/213666.347@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@249966 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Revert r249748. rdar://problem/55240888

8843b2d

Canonical link: https://commits.webkit.org/213666.363@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@250007 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Apply patch. rdar://problem/55240888

eae5d97

Canonical link: https://commits.webkit.org/213666.364@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@250008 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Unreviewed build fix. rdar://problem/55240888

04a069d

Canonical link: https://commits.webkit.org/213666.370@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@250017 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Revert r247573. rdar://problem/55461395

6f6d49f

Canonical link: https://commits.webkit.org/213666.371@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@250134 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Revert "Revert r247573. rdar://problem/55461395"

235c9fc

Canonical link: https://commits.webkit.org/213666.372@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@250137 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Versioning.

09bfb46

Canonical link: https://commits.webkit.org/213666.373@safari-608-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-608-branch@250245 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Haiku_webkit2_gsoc2019: Bump to Webkit 608.5.12 #1

Haiku_webkit2_gsoc2019: Bump to Webkit 608.5.12 #1

kenmays commented Feb 24, 2021

Haiku_webkit2_gsoc2019: Bump to Webkit 608.5.12 #1

Haiku_webkit2_gsoc2019: Bump to Webkit 608.5.12 #1

Conversation

kenmays commented Feb 24, 2021