Upgrade to upstream WebKit 2e37adcc23b7 - #370
Conversation
https://bugs.webkit.org/show_bug.cgi?id=318669 Reviewed by Xabier Rodriguez-Calvar. This backend is un-maintained and provides incomplete WebRTC support. The WPE and GTK ports will leverage LibWebRTC from now on. Canonical link: https://commits.webkit.org/317849@main
…eBox into FlexLayoutState https://bugs.webkit.org/show_bug.cgi?id=320117 Reviewed by Antti Koivisto. The set tracking which flex items have already been laid out during the current pass was a SingleThreadWeakHashSet member on RenderFlexibleBox (m_flexItemsWithCompletedLayout) with mark/has accessors, cleared by hand at the top of layoutBlock. That is transient per-layout state -- exactly what FlexLayoutState (added in 320044) exists to hold. Move the set and its accessors onto FlexLayoutState (setFlexItemHasCompletedLayout / hasFlexItemCompletedLayout); RenderFlexibleBox and FlexFormattingContext reach it through the container's FlexLayoutState. The manual clear() is gone -- each layout engages a fresh FlexLayoutState, so the set starts empty. While in this code, tidy up the surrounding per-flex-item layout helpers. No behavior change: - Simplify layoutFlexItemWithMainSize: fold the relayout decision into one shouldMarkFlexItemForLayout lambda, inline the one-line setOverridingMainSizeForFlexItem, and drop updateFlexItemDirtyBitsBeforeLayout -- its isOutOfFlowPositioned early return was dead code, since the flex algorithm only ever iterates in-flow items. - Consolidate the stretch relayout: applyStretchedLogicalHeightToFlexItem loses its needsRelayout bool and delegates to layoutFlexItemForStretchedCrossSize (renamed from relayoutFlexItemForStretchedCrossSize); the caller handles the "already the right size, just mark it definite" case inline. - Rename FlexFormattingContext::flexLayoutState() to layoutState(), plus a couple of guard-clause / ternary simplifications (isHorizontalFlow, resetAutoMarginsAndLogicalTopInCrossAxis). * Source/WebCore/layout/formattingContexts/flex/FlexFormattingContext.cpp: (WebCore::FlexFormattingContext::computeFlexBaseAndHypotheticalMainSizes): (WebCore::FlexFormattingContext::computeFlexLines): (WebCore::FlexFormattingContext::computeMainSizeForFlexItems): (WebCore::FlexFormattingContext::layoutFlexItems): (WebCore::FlexFormattingContext::hypotheticalCrossSizeForFlexItems): (WebCore::FlexFormattingContext::handleMainAxisAlignment): (WebCore::FlexFormattingContext::computeCrossSizeForFlexItems): (WebCore::FlexFormattingContext::handleCrossAxisAlignmentForFlexItems): (WebCore::FlexFormattingContext::applyStretchAlignmentToFlexItem): (WebCore::FlexFormattingContext::applyStretchMinMaxCrossSize): (WebCore::FlexFormattingContext::layoutState const): * Source/WebCore/layout/formattingContexts/flex/FlexFormattingContext.h: * Source/WebCore/layout/formattingContexts/flex/FlexFormattingUtils.cpp: (WebCore::FlexFormattingUtils::isHorizontalFlow): * Source/WebCore/layout/formattingContexts/flex/FlexLayoutState.h: (WebCore::FlexLayoutState::setFlexItemHasCompletedLayout): (WebCore::FlexLayoutState::hasFlexItemCompletedLayout const): * Source/WebCore/rendering/RenderFlexibleBox.cpp: (WebCore::RenderFlexibleBox::layoutBlock): (WebCore::RenderFlexibleBox::computeBlockAxisContentSizeForFlexItem): (WebCore::RenderFlexibleBox::applyStretchedLogicalHeightToFlexItem): (WebCore::RenderFlexibleBox::layoutFlexItemForStretchedCrossSize): (WebCore::RenderFlexibleBox::layoutFlexItemWithMainSize): (WebCore::RenderFlexibleBox::resetAutoMarginsAndLogicalTopInCrossAxis): (WebCore::RenderFlexibleBox::setOverridingMainSizeForFlexItem): Deleted. * Source/WebCore/rendering/RenderFlexibleBox.h: Canonical link: https://commits.webkit.org/317850@main
https://bugs.webkit.org/show_bug.cgi?id=320169 rdar://problem/183104731 Reviewed by Chris Dumez. A fetch can be aborted by an AbortSignal. When AbortSignal abort steps run (in FetchResponse::addAbortSteps), we tell the FetchResponse::Loader to abort. FetchResponse::Loader will then abort the upload sink by cancelling the corresponding readablestream reader. Covered by rebased tests. * LayoutTests/imported/w3c/web-platform-tests/fetch/api/basic/request-upload.h2.any-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/fetch/api/basic/request-upload.h2.any.serviceworker-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/fetch/api/basic/request-upload.h2.any.sharedworker-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/fetch/api/basic/request-upload.h2.any.worker-expected.txt: * Source/WebCore/Modules/fetch/FetchResponse.cpp: (WebCore::FetchResponse::addAbortSteps): (WebCore::FetchResponse::createFetchResponse): (WebCore::FetchResponse::fetch): (WebCore::FetchResponse::Loader::create): (WebCore::FetchResponse::Loader::Loader): (WebCore::FetchResponse::Loader::abortUpload): * Source/WebCore/Modules/fetch/FetchResponse.h: * Source/WebCore/Modules/streams/ReadableStreamToSharedBufferSink.cpp: (WebCore::ReadableStreamToSharedBufferSink::cancel): * Source/WebCore/Modules/streams/ReadableStreamToSharedBufferSink.h: Canonical link: https://commits.webkit.org/317851@main
https://bugs.webkit.org/show_bug.cgi?id=320180 Unreviewed, update expectation of several tests following-up with enablement of libwebrtc. * LayoutTests/platform/glib/TestExpectations: * LayoutTests/platform/gtk/TestExpectations: * LayoutTests/platform/wpe/TestExpectations: Canonical link: https://commits.webkit.org/317852@main
https://bugs.webkit.org/show_bug.cgi?id=320181 Unreviewed. * LayoutTests/platform/glib/TestExpectations: * LayoutTests/platform/wpe/TestExpectations: Canonical link: https://commits.webkit.org/317853@main
https://bugs.webkit.org/show_bug.cgi?id=230612 Unreviewed test gardening. These tests were originally gardened in 316749@main for WPE, but are also failing on GTK. * WebDriverTests/TestExpectations.json: Canonical link: https://commits.webkit.org/317854@main
https://bugs.webkit.org/show_bug.cgi?id=320089 Reviewed by Nikolas Zimmermann. * .wkdev-sdk-version: Bump to v9 which among other things removed GstWebRTC-related dependencies. Canonical link: https://commits.webkit.org/317855@main
https://bugs.webkit.org/show_bug.cgi?id=320184 Unreviewed, additional round of test expectations updates after the switch to libwebrtc. * LayoutTests/platform/glib/TestExpectations: * LayoutTests/platform/gtk/TestExpectations: * LayoutTests/platform/wpe/TestExpectations: Canonical link: https://commits.webkit.org/317856@main
https://bugs.webkit.org/show_bug.cgi?id=142657 <rdar://problem/20149674> Reviewed by Yusuke Suzuki. Rather than trying to keep a manual list, leverage the pretty format of IDL to autogenerate `WI.NativeConstructorFunctionParameters` and `WI.NativePrototypeFunctionParameters`. * Source/WebCore/bindings/scripts/CodeGenerator.pm: (ProcessInterfaces): (WriteInspectorNativeFunctionParameters): Added. Modify the IDL parser to output `*.inspector-native-function-parameters.json` files containing a pretty string of the arguments for any class-level and instance-level methods. * Source/WebCore/bindings/scripts/combine-inspector-native-function-parameters.pl: Added. Combine all `*.inspector-native-function-parameters.json` into a single `InspectorNativeFunctionParameters.json`. * Source/WebInspectorUI/UserInterface/Models/NativeFunctionParameters.js: Removed. * Source/WebInspectorUI/UserInterface/Models/NativeFunctionParameters-overrides.json: Added. Pure JS APIs do not have anything like pretty formatted IDL to draw from like other web APIs. Instead, have these be handwritten in a JSON file until a solution can be found for them. This also allows for Web Inspector to override anything that is automatic if needed. * Source/WebInspectorUI/Scripts/update-NativeFunctionParameters.py: Added. Merge the `InspectorNativeFunctionParameters.json` with the overrides file and generate `NativeFunctionParameters.js`. * Source/WebInspectorUI/Scripts/copy-user-interface-resources.pl: Copy `NativeFunctionParameters.js` alongside all other resources. * Source/WebInspectorUI/UserInterface/Views/ObjectTreePropertyTreeElement.js: (WI.ObjectTreePropertyTreeElement.prototype._functionParameterString): Drive-by: also handle `Atomics`, `Intl`, and `WebAssembly` namespace objects. * Source/WebCore/CMakeLists.txt: * Source/WebCore/DerivedSources.make: * Source/WebCore/DerivedSources-output.xcfilelist: * Source/WebCore/WebCoreMacros.cmake: * Source/WebInspectorUI/CMakeLists.txt: * Source/WebInspectorUI/WebInspectorUI.xcodeproj/project.pbxproj: * Source/WebCore/bindings/scripts/test/JS/TestCallTracer.inspector-native-function-parameters.json: Added. * Source/WebCore/bindings/scripts/test/JS/TestCallbackInterface.inspector-native-function-parameters.json: Added. * Source/WebCore/bindings/scripts/test/JS/TestConditionalIncludes.inspector-native-function-parameters.json: Added. * Source/WebCore/bindings/scripts/test/JS/TestDOMJIT.inspector-native-function-parameters.json: Added. * Source/WebCore/bindings/scripts/test/JS/TestDomainSecurity.inspector-native-function-parameters.json: Added. * Source/WebCore/bindings/scripts/test/JS/TestEnabledBySetting.inspector-native-function-parameters.json: Added. * Source/WebCore/bindings/scripts/test/JS/TestEventTarget.inspector-native-function-parameters.json: Added. * Source/WebCore/bindings/scripts/test/JS/TestGlobalObject.inspector-native-function-parameters.json: Added. * Source/WebCore/bindings/scripts/test/JS/TestIndexedSetterWithIdentifier.inspector-native-function-parameters.json: Added. * Source/WebCore/bindings/scripts/test/JS/TestInterface.inspector-native-function-parameters.json: Added. * Source/WebCore/bindings/scripts/test/JS/TestLegacyOverrideBuiltIns.inspector-native-function-parameters.json: Added. * Source/WebCore/bindings/scripts/test/JS/TestNamedAndIndexedSetterWithIdentifier.inspector-native-function-parameters.json: Added. * Source/WebCore/bindings/scripts/test/JS/TestNamedDeleterWithIdentifier.inspector-native-function-parameters.json: Added. * Source/WebCore/bindings/scripts/test/JS/TestNamedGetterWithIdentifier.inspector-native-function-parameters.json: Added. * Source/WebCore/bindings/scripts/test/JS/TestNamedSetterWithIdentifier.inspector-native-function-parameters.json: Added. * Source/WebCore/bindings/scripts/test/JS/TestNamedSetterWithIndexedGetter.inspector-native-function-parameters.json: Added. * Source/WebCore/bindings/scripts/test/JS/TestNamedSetterWithIndexedGetterAndSetter.inspector-native-function-parameters.json: Added. * Source/WebCore/bindings/scripts/test/JS/TestNamespaceObject.inspector-native-function-parameters.json: Added. * Source/WebCore/bindings/scripts/test/JS/TestObj.inspector-native-function-parameters.json: Added. * Source/WebCore/bindings/scripts/test/JS/TestScheduledAction.inspector-native-function-parameters.json: Added. * Source/WebCore/bindings/scripts/test/JS/TestSerializedScriptValueInterface.inspector-native-function-parameters.json: Added. * Source/WebCore/bindings/scripts/test/JS/TestTypedefs.inspector-native-function-parameters.json: Added. Canonical link: https://commits.webkit.org/317857@main
rdar://183002185 https://bugs.webkit.org/show_bug.cgi?id=320082 Reviewed by Chris Dumez. As per fetch spec, we fail a stream upload in case of 401 response. We do this in NetworkDataTaskCocoa::didReceiveChallenge. Covered by rebased WPT tests. * LayoutTests/imported/w3c/web-platform-tests/fetch/api/basic/request-upload.h2.any-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/fetch/api/basic/request-upload.h2.any.serviceworker-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/fetch/api/basic/request-upload.h2.any.sharedworker-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/fetch/api/basic/request-upload.h2.any.worker-expected.txt: * Source/WebKit/NetworkProcess/cocoa/NetworkDataTaskCocoa.mm: (WebKit::NetworkDataTaskCocoa::didReceiveChallenge): Canonical link: https://commits.webkit.org/317858@main
https://bugs.webkit.org/show_bug.cgi?id=319190 rdar://182041352 Reviewed by Antti Koivisto. Font::platformInit computed line metrics differently on iOS than on macOS. The iOS path (inherited from the internal iOS WebKit fork via the old FontServicesIOS helper) rounded ascent, descent, and line gap up with ceil(), stored them as integers, and folded a 15% line-height adjustment for Times/Helvetica/.Helvetica NeueUI into the ascent. macOS instead keeps the fractional CoreText metrics, rounds only the derived line spacing with lround(), and adjusts Times/Helvetica/Courier by 15% (via round) for locally installed fonts only. The ceil() rounding made iOS line boxes systematically about a pixel taller than macOS. Route iOS through the shared macOS path so both platforms produce identical font metrics: - Keep ascent/descent/lineGap as fractional CoreText values instead of ceil()-ing them. - Compute lineSpacing as lround(ascent) + lround(descent) + lround(lineGap). - Use needsAscentAdjustment() (Times/Helvetica/Courier, gated on Origin::Local, using round()) for the ascent adjustment on all platforms, removing the iOS-only shouldUseAdjustment()/.Helvetica NeueUI variant. - Apply the Hiragino marked-text line-metrics hack on iOS as well. The only remaining iOS-specific behavior in platformInit is m_shouldNotBeUsedForArabic, which is about Arabic shaping performance (rdar://9823975), not font metrics. This shifts iOS text metrics by ~1px, so update the affected layout test results (regenerated from the iOS-26 simulator WK2 EWS run): - Where the iOS result is now byte-identical to macOS, consolidate the two platform baselines into one generic baseline (rename platform/mac -> generic) and drop the platform/ios override. This is safe because win and glib already carry their own overrides for these tests; verified per test. - Where removing the platform/ios override falls back onto a matching baseline, drop the override. - Where the iOS result still legitimately differs from macOS (different fallback fonts for Hebrew/Arabic/CJK, iOS compositing layer trees, selection geometry), rebaseline the platform/ios override in place. - A handful of iOS selection/caret tests assert hardcoded pixel values via shouldBe("rect.height", "28"); update those literals and expected output to the new measured values. Pre-existing expected failures are left untouched. Two tests are intentionally not rebaselined and need follow-up rather than baking a failure into their baseline: - editing/selection/caret-in-div-containing-empty-block.html: horizontal and text caret rects now round to different heights (18 vs 17); the fractional metrics exposed a rounding inconsistency between two caret-rect paths. - editing/selection/ios/bidi-visually-contiguous-selection-multiline.html: the touch-driven selection lands on a different line now that line positions moved, so selectedText no longer ends with the expected word. Canonical link: https://commits.webkit.org/317859@main
https://bugs.webkit.org/show_bug.cgi?id=205350 Unreviewed test gardening. * WebDriverTests/TestExpectations.json: Canonical link: https://commits.webkit.org/317860@main
https://bugs.webkit.org/show_bug.cgi?id=217173 Unreviewed test gardening. * WebDriverTests/TestExpectations.json: Canonical link: https://commits.webkit.org/317861@main
https://bugs.webkit.org/show_bug.cgi?id=263810 Reviewed by Carlos Garcia Campos. Currently, async overflow scrolling in TestRunner is always enabled on WPE and disabled on GTK. On macOS it is enabled only for WPT tests starting from 270071@main. Doing the same on WPE and GTK makes the test results more consistent with macOS and each other. * Tools/WebKitTestRunner/gtk/TestControllerGtk.cpp: (WTR::shouldEnableAsyncOverflowScrolling): (WTR::TestController::platformSpecificFeatureDefaultsForTest const): * Tools/WebKitTestRunner/wpe/TestControllerWPE.cpp: (WTR::shouldEnableAsyncOverflowScrolling): (WTR::TestController::platformSpecificFeatureDefaultsForTest const): * LayoutTests/platform/glib/TestExpectations: * LayoutTests/platform/glib/fast/text/mark-matches-overflow-clip-expected.txt: Renamed from LayoutTests/platform/gtk/fast/text/mark-matches-overflow-clip-expected.txt. * LayoutTests/platform/glib/scrollingcoordinator/scrolling-tree/coordinated-frame-expected.txt: Renamed from LayoutTests/platform/gtk/scrollingcoordinator/scrolling-tree/coordinated-frame-expected.txt. * LayoutTests/platform/glib/scrollingcoordinator/scrolling-tree/coordinated-frame-gain-scrolling-ancestor-expected.txt: Renamed from LayoutTests/platform/gtk/scrollingcoordinator/scrolling-tree/coordinated-frame-gain-scrolling-ancestor-expected.txt. * LayoutTests/platform/glib/scrollingcoordinator/scrolling-tree/coordinated-frame-in-fixed-expected.txt: Renamed from LayoutTests/platform/gtk/scrollingcoordinator/scrolling-tree/coordinated-frame-in-fixed-expected.txt. * LayoutTests/platform/glib/scrollingcoordinator/scrolling-tree/coordinated-frame-lose-scrolling-ancestor-expected.txt: Renamed from LayoutTests/platform/gtk/scrollingcoordinator/scrolling-tree/coordinated-frame-lose-scrolling-ancestor-expected.txt. * LayoutTests/platform/gtk/TestExpectations: * LayoutTests/platform/wpe/TestExpectations: * LayoutTests/platform/wpe/fast/forms/basic-textareas-expected.txt: * LayoutTests/platform/wpe/fast/overflow/scrollRevealButton-expected.txt: * LayoutTests/platform/wpe/fast/text/mark-matches-overflow-clip-expected.txt: Removed. * LayoutTests/platform/wpe/scrollingcoordinator/scrolling-tree/coordinated-frame-expected.txt: Removed. * LayoutTests/platform/wpe/scrollingcoordinator/scrolling-tree/coordinated-frame-gain-scrolling-ancestor-expected.txt: Removed. * LayoutTests/platform/wpe/scrollingcoordinator/scrolling-tree/coordinated-frame-in-fixed-expected.txt: Removed. * LayoutTests/platform/wpe/scrollingcoordinator/scrolling-tree/coordinated-frame-lose-scrolling-ancestor-expected.txt: Removed. Canonical link: https://commits.webkit.org/317862@main
…LayoutState https://bugs.webkit.org/show_bug.cgi?id=320148 Reviewed by Antti Koivisto. RenderFlexibleBox tracked whether the flex container's logical height (its block-axis size) is definite -- i.e. whether a flex item's percentage can resolve against it -- in an m_hasDefiniteHeight member. That is transient per-layout state; its own comment even said it "is SizeIsUnknown outside of layoutBlock()". Move it onto FlexLayoutState next to the other per-layout flex state, as a std::optional<bool> m_isBlockSizeDefinite (engaged only during layout; nullopt means not-yet-computed). RenderFlexibleBox and FlexFormattingContext go through isBlockSizeDefinite() / isBlockSizeIndefinite() / setBlockSizeIsDefinite() / resetBlockSizeDefiniteness(). It is the container's block-axis size specifically (not a "main-axis size"): the block axis is the main axis for a column flexbox -- where canComputePercentageFlexBasis reads it -- and the cross axis for a row flexbox -- where flexItemCrossSizeIsDefinite reads it. Both ask the same question, "does a percentage resolve against the container's logical height", which is exactly what computePercentageLogicalHeight answers. canComputePercentageFlexBasis keeps the same behavior: while laying ourselves out it consults the cached value, and when not yet known computes it (running computePercentageLogicalHeight, whose percent-height-descendant side effect callers rely on) and caches it for the item's remaining sub-queries; reached outside our own layout (percentage resolution for descendants, with m_flexLayoutState disengaged) it just computes without caching. Because the value now lives in the per-layout FlexLayoutState -- which starts fresh each layoutBlock -- the two explicit resets that only existed to clear the persistent member are no longer needed and are removed: the one at the end of layoutBlock, and the per-child one in LayoutIntegration::FlexLayout::collectFlexItems (which reset a child flexbox whose own FlexLayoutState is not even engaged at that point, so it was a no-op). Also switch the writing-mode-parallel check from an isHorizontalWritingMode() equality to writingMode().isOrthogonal(), matching the idiom already used in RenderFlexibleBox. * Source/WebCore/layout/formattingContexts/flex/FlexFormattingContext.cpp: (WebCore::FlexFormattingContext::computeFlexBaseAndHypotheticalMainSizes): (WebCore::FlexFormattingContext::flexItemCrossSizeIsDefinite): * Source/WebCore/layout/formattingContexts/flex/FlexLayoutState.h: (WebCore::FlexLayoutState::phase const): (WebCore::FlexLayoutState::isFlexBoxBlockSizeDefinite const): (WebCore::FlexLayoutState::isFlexBoxBlockSizeIndefinite const): (WebCore::FlexLayoutState::setFlexBoxBlockSizeIsDefinite): (WebCore::FlexLayoutState::resetFlexBoxBlockSizeDefiniteness): * Source/WebCore/layout/integration/flex/LayoutIntegrationFlexLayout.cpp: (WebCore::LayoutIntegration::FlexLayout::collectFlexItems): * Source/WebCore/rendering/RenderFlexibleBox.cpp: (WebCore::RenderFlexibleBox::layoutBlock): (WebCore::RenderFlexibleBox::canComputePercentageFlexBasis): * Source/WebCore/rendering/RenderFlexibleBox.h: (WebCore::RenderFlexibleBox::resetHasDefiniteHeight): Deleted. (WebCore::RenderFlexibleBox::hasDefiniteHeight const): Deleted. (WebCore::RenderFlexibleBox::setHasDefiniteHeight): Deleted. Canonical link: https://commits.webkit.org/317863@main
…derId from document identifier https://bugs.webkit.org/show_bug.cgi?id=308895 rdar://171780771 Reviewed by BJ Burg. Under Site Isolation the loaderId reported on Page.frameNavigated and Page.getResourceTree did not match the loaderId the Network domain emits for the same navigation's main resource. The frontend uses loaderId purely as a correlation key between the Network and Page event streams (NetworkManager.js): when a main-resource Network.requestWillBeSent whose loaderId differs from the frame's committed loaderIdentifier arrives, it starts a provisional load, and Page.frameNavigated commits that load only when the event's loaderId equals the recorded provisional loaderId. When the two disagree, the real main-resource load is discarded and a fresh, empty main resource is synthesized in its place. Root cause: the loaderId was derived from the frame's current document, which changes across a navigation's commit. The Network stream computes it at the main resource's willSendRequest -- before commit, when the frame still shows the previous document -- while the Page stream computes it at frameNavigated, after the new document has committed. Deriving from frame->document()->identifier() therefore yields two different strings for one load: the previous document's id on the network event and the new document's id on the navigation. The frontend never correlated them, so it discarded the real main resource for the synthesized empty one. Fix: derive the loaderId from the DocumentLoader's navigationID (BackendIdentifierRegistry::loaderId). navigationID is assigned when the load starts, while still provisional, and stays fixed for the load, so the Network stream's pre-commit computation and the Page stream's post-commit computation produce the identical string. It is process-local, so it is qualified with the hosting process ("loader-<pid>.<navigationID>"). The id can only be computed in the frame's hosting WebContent process -- the UIProcess has neither the DocumentLoader nor its navigationID -- so both proxy paths compute it there (FrameNetworkAgentProxy on the network side, PageAgentProxy::frameNavigated on the page side) and send the resulting string over IPC, rather than shipping a raw ScriptExecutionContextIdentifier and converting it in the UIProcess. A DocumentLoader never spans processes, so this is consistent. The obvious alternatives don't work: frame->document()->identifier() is the source of the bug above, and DocumentLoader::resultingClientId() -- the id the about-to-commit document will adopt -- is populated only for service-worker-eligible loads, so it is unavailable for the common navigation. Because the loaderIds now agree, the frontend takes the provisional-load commit path (WI.Frame.commitProvisionalLoad) for a cross-origin navigation instead of synthesizing a fresh main resource via WI.Frame.initialize. commitProvisionalLoad did not propagate the frame's name, so make it adopt and dispatch the navigation's name like initialize does; otherwise a window.name change reported on the committing navigation would no longer reach the frame model. Test: http/tests/site-isolation/inspector/page/frame-navigated-loader-id-matches-network-cross-origin-iframe.html * LayoutTests/http/tests/site-isolation/inspector/page/frame-navigated-loader-id-matches-network-cross-origin-iframe-expected.txt: Added. * LayoutTests/http/tests/site-isolation/inspector/page/frame-navigated-loader-id-matches-network-cross-origin-iframe.html: Added. * Source/WebCore/inspector/InspectorResourceUtilities.h: * Source/WebInspectorUI/UserInterface/Controllers/NetworkManager.js: (WI.NetworkManager.prototype.frameDidNavigate): * Source/WebInspectorUI/UserInterface/Models/Frame.js: (WI.Frame.prototype.commitProvisionalLoad): * Source/WebKit/Shared/InspectorPageTypes.serialization.in: * Source/WebKit/UIProcess/Inspector/Agents/ProxyingNetworkAgent.cpp: (Inspector::ProxyingNetworkAgent::requestWillBeSent): (Inspector::ProxyingNetworkAgent::responseReceived): (Inspector::ProxyingNetworkAgent::requestServedFromMemoryCache): * Source/WebKit/UIProcess/Inspector/Agents/ProxyingNetworkAgent.h: * Source/WebKit/UIProcess/Inspector/Agents/ProxyingNetworkAgent.messages.in: * Source/WebKit/UIProcess/Inspector/Agents/ProxyingPageAgent.cpp: (Inspector::ProxyingPageAgent::frameNavigated): (Inspector::ProxyingPageAgent::buildFrameTree const): * Source/WebKit/UIProcess/Inspector/Agents/ProxyingPageAgent.h: * Source/WebKit/UIProcess/Inspector/Agents/ProxyingPageAgent.messages.in: * Source/WebKit/WebProcess/Inspector/FrameNetworkAgentProxy.cpp: (WebKit::loaderIdForLoader): (WebKit::FrameNetworkAgentProxy::willSendRequest): (WebKit::FrameNetworkAgentProxy::willSendRequestOfType): (WebKit::FrameNetworkAgentProxy::didReceiveResponse): (WebKit::FrameNetworkAgentProxy::didLoadResourceFromMemoryCache): (WebKit::contextIdentifier): Deleted. * Source/WebKit/WebProcess/Inspector/PageAgentProxy.cpp: (WebKit::PageAgentProxy::frameNavigated): * Source/WebKit/WebProcess/Inspector/WebInspectorBackend.cpp: (WebKit::WebInspectorBackend::getFrameResourceData): * Source/WebCore/inspector/InspectorIdentifierRegistry.cpp: (Inspector::BackendIdentifierRegistry::loaderId): * Source/WebCore/inspector/InspectorIdentifierRegistry.h: (Inspector::IdentifierRegistry::parseProtocolFrameId): (Inspector::IdentifierRegistry::protocolLoaderId): Deleted. Canonical link: https://commits.webkit.org/317864@main
… process https://bugs.webkit.org/show_bug.cgi?id=320135 rdar://183071225 Reviewed by Ryosuke Niwa. Site Isolation's shared process mode puts multiple cross-site frames into one WebProcess for performance, trading away some of the process-boundary protection between the co-located sites. Loopback/local-network endpoints (routers, printers, NAS boxes, local dev servers) often expose sensitive data or privileged functionality behind weak or no authentication, so colocating them with an arbitrary other site's renderer increases the blast radius of a renderer compromise. Therefore, exclude them from the shared process pool. BrowsingContextGroup::sharedProcessForSite now bails out for any site whose host is a loopback/local-network IP literal or a literal localhost/*.localhost. Also, Added a WebCore::Site overload of determineIPAddressSpace() so the check can classify a Site the same way the existing URL overload classifies a URL. Test: TestWebKitAPI.IPAddressSpace TestWebKitAPI.SiteIsolation.SharedProcessExcludesLoopback * Source/WebCore/Modules/fetch/IPAddressSpace.cpp: (WebCore::determineIPAddressSpaceFromHost): (WebCore::determineIPAddressSpace): * Source/WebCore/Modules/fetch/IPAddressSpace.h: * Source/WebKit/UIProcess/BrowsingContextGroup.cpp: (WebKit::isLoopbackOrLocalNetworkSite): (WebKit::BrowsingContextGroup::sharedProcessForSite): * Tools/TestWebKitAPI/Tests/WebCore/IPAddressSpaceTests.cpp: (TestWebKitAPI::TEST(IPAddressSpace, SiteMatchesURLForIPLiterals)): (TestWebKitAPI::TEST(IPAddressSpace, SiteDoesNotSpecialCaseLocalhostName)): * Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm: (TestWebKitAPI::(SiteIsolation, SharedProcessExcludesLoopback)): Canonical link: https://commits.webkit.org/317865@main
…er case https://bugs.webkit.org/show_bug.cgi?id=320153 rdar://183089102 Reviewed by Tadeu Zagallo. Unicode character has some cases which lowercase / uppercase character is ASCII and vise versa. For example, Kelvin sign (U+212A)'s lowercase character is ASCII 'k'. But ECMAScript RegExp specifies that we should not handle this lower-casing when unicode flags are not specified. YarrJIT is correctly working, but YarrInterpreter was not. We accidentally found this bug through the other work (317836@main), and this patch fixes this bug, aligning the behavior to YarrJIT. * JSTests/stress/regexp-exec-anchored-first-char-filter.js: * JSTests/stress/regexp-test-anchored-first-char-filter.js: * Source/JavaScriptCore/yarr/YarrInterpreter.cpp: (JSC::Yarr::ByteCompiler::atomPatternCharacter): (JSC::Yarr::ByteCompiler::emitDisjunction): Canonical link: https://commits.webkit.org/317866@main
https://bugs.webkit.org/show_bug.cgi?id=320191 rdar://183138696 Broke Safari build. * Source/WebCore/CMakeLists.txt: * Source/WebCore/DerivedSources-output.xcfilelist: * Source/WebCore/DerivedSources.make: * Source/WebCore/WebCoreMacros.cmake: * Source/WebCore/bindings/scripts/CodeGenerator.pm: (ProcessInterfaces): (WriteInspectorNativeFunctionParameters): Deleted. * Source/WebCore/bindings/scripts/combine-inspector-native-function-parameters.pl: Removed. * Source/WebCore/bindings/scripts/test/JS/TestCallTracer.inspector-native-function-parameters.json: Removed. * Source/WebCore/bindings/scripts/test/JS/TestCallbackInterface.inspector-native-function-parameters.json: Removed. * Source/WebCore/bindings/scripts/test/JS/TestConditionalIncludes.inspector-native-function-parameters.json: Removed. * Source/WebCore/bindings/scripts/test/JS/TestDOMJIT.inspector-native-function-parameters.json: Removed. * Source/WebCore/bindings/scripts/test/JS/TestDomainSecurity.inspector-native-function-parameters.json: Removed. * Source/WebCore/bindings/scripts/test/JS/TestEnabledBySetting.inspector-native-function-parameters.json: Removed. * Source/WebCore/bindings/scripts/test/JS/TestEventTarget.inspector-native-function-parameters.json: Removed. * Source/WebCore/bindings/scripts/test/JS/TestGlobalObject.inspector-native-function-parameters.json: Removed. * Source/WebCore/bindings/scripts/test/JS/TestIndexedSetterWithIdentifier.inspector-native-function-parameters.json: Removed. * Source/WebCore/bindings/scripts/test/JS/TestInterface.inspector-native-function-parameters.json: Removed. * Source/WebCore/bindings/scripts/test/JS/TestLegacyOverrideBuiltIns.inspector-native-function-parameters.json: Removed. * Source/WebCore/bindings/scripts/test/JS/TestNamedAndIndexedSetterWithIdentifier.inspector-native-function-parameters.json: Removed. * Source/WebCore/bindings/scripts/test/JS/TestNamedDeleterWithIdentifier.inspector-native-function-parameters.json: Removed. * Source/WebCore/bindings/scripts/test/JS/TestNamedGetterWithIdentifier.inspector-native-function-parameters.json: Removed. * Source/WebCore/bindings/scripts/test/JS/TestNamedSetterWithIdentifier.inspector-native-function-parameters.json: Removed. * Source/WebCore/bindings/scripts/test/JS/TestNamedSetterWithIndexedGetter.inspector-native-function-parameters.json: Removed. * Source/WebCore/bindings/scripts/test/JS/TestNamedSetterWithIndexedGetterAndSetter.inspector-native-function-parameters.json: Removed. * Source/WebCore/bindings/scripts/test/JS/TestNamespaceObject.inspector-native-function-parameters.json: Removed. * Source/WebCore/bindings/scripts/test/JS/TestObj.inspector-native-function-parameters.json: Removed. * Source/WebCore/bindings/scripts/test/JS/TestScheduledAction.inspector-native-function-parameters.json: Removed. * Source/WebCore/bindings/scripts/test/JS/TestSerializedScriptValueInterface.inspector-native-function-parameters.json: Removed. * Source/WebCore/bindings/scripts/test/JS/TestTypedefs.inspector-native-function-parameters.json: Removed. * Source/WebInspectorUI/CMakeLists.txt: * Source/WebInspectorUI/Scripts/copy-user-interface-resources.pl: * Source/WebInspectorUI/Scripts/update-NativeFunctionParameters.py: Removed. * Source/WebInspectorUI/UserInterface/Models/NativeFunctionParameters-overrides.json: Removed. * Source/WebInspectorUI/UserInterface/Models/NativeFunctionParameters.js: Added. * Source/WebInspectorUI/UserInterface/Views/ObjectTreePropertyTreeElement.js: * Source/WebInspectorUI/WebInspectorUI.xcodeproj/project.pbxproj: Canonical link: https://commits.webkit.org/317867@main
…cestor-directory walk https://bugs.webkit.org/show_bug.cgi?id=320078 rdar://182999128 Reviewed by Aakash Jain. The while loops that walk up to find an ancestor directory's stats reassigned ancestor_dirname from os.path.dirname(dirname) instead of os.path.dirname(ancestor_dirname), so once the immediate parent wasn't in device_test_stats, the loop recomputed the same value forever instead of continuing up the tree. This made --print-summary hang. * Tools/Scripts/webkitpy/layout_tests/controllers/manager.py: (Manager.print_summary): Canonical link: https://commits.webkit.org/317868@main
…nstead of rejecting the fragment https://bugs.webkit.org/show_bug.cgi?id=318966 rdar://181820705 Reviewed by Chris Dumez. In parseNPTTime(), the NPT hours field ("npt-hh = 1*DIGIT", any positive number) was parsed with parseInteger<int>(digits1).value_or(0). When the value exceeded the range of int, parseInteger returned nullopt and value_or(0) silently coerced it to 0 hours, so a fragment such as "t=99999999999:00:05" was accepted as a valid seek to 00:05 (5 seconds) rather than being rejected. The same value1 is also used for plain npt-sec fragments (e.g. "t=99999999999"), so that path was affected too. Reject the fragment when the hours value fails to parse, consistent with how the minutes and seconds fields are already validated. Also fix a related integer overflow: the hours value was multiplied by secondsPerHour (3600) using plain int arithmetic before being converted to a double, so an in-range hours value like 1000000 (1000000 * 3600 = 3.6e9) could overflow INT_MAX and produce a wrong or negative seek time via signed integer overflow. Compute the total in double precision instead. Tests: media/media-fragments/TC0096.html media/media-fragments/TC0097.html media/media-fragments/TC0098.html * LayoutTests/media/media-fragments/TC0096-expected.txt: Added. * LayoutTests/media/media-fragments/TC0096.html: Added. * LayoutTests/media/media-fragments/TC0097-expected.txt: Added. * LayoutTests/media/media-fragments/TC0097.html: Added. * LayoutTests/media/media-fragments/TC0098-expected.txt: Added. * LayoutTests/media/media-fragments/TC0098.html: Added. * LayoutTests/media/media-fragments/media-fragments.js: Added TC0096, TC0097, and TC0098, covering an out-of-range npt-hh value, an out-of-range plain npt-sec value, and an in-range npt-hh value whose multiplication by secondsPerHour would overflow a 32-bit int. * Source/WebCore/html/MediaFragmentURIParser.cpp: (WebCore::MediaFragmentURIParser::parseNPTTime): Return false when the hours value overflows instead of defaulting it to 0. Compute the total number of seconds using double arithmetic to avoid a signed-integer overflow when multiplying the hours value by secondsPerHour. Removed the now-unused secondsPerHour and secondsPerMinute constants. Canonical link: https://commits.webkit.org/317869@main
https://bugs.webkit.org/show_bug.cgi?id=320152 rdar://183088481 Reviewed by Tadeu Zagallo and Marcus Plutowski. JSTests/wasm/stress/type-index-abstract-heap-types.js was very slow and frequently timing out. Split them into smaller tests. * JSTests/wasm/stress/type-index-abstract-heap-types-concrete-vs-abstract.js: Added. (testConcreteVsAbstract): * JSTests/wasm/stress/type-index-abstract-heap-types-globals-and-tables.js: Added. (testGlobalsAndTables): * JSTests/wasm/stress/type-index-abstract-heap-types-nulls-and-casts.js: Added. (testAbstractNullsAndCasts): * JSTests/wasm/stress/type-index-abstract-heap-types-subtype-validation.js: Added. (testSubtypeValidation): * JSTests/wasm/stress/type-index-abstract-heap-types.js: Removed. Canonical link: https://commits.webkit.org/317870@main
https://bugs.webkit.org/show_bug.cgi?id=320156 rdar://183089589 Reviewed by Tadeu Zagallo. This test takes very long time. This patch removes testLoopCount from this test as its intent is stressing RegExp, which is fine without warmup count. * JSTests/stress/regexp-unicode-bmp-fast-path-code-points.js: (const.first.of.codeUnits.const.second.of.followers.first.toString): (i.const.first.of.codeUnits.const.second.of.followers.first.toString): Deleted. Canonical link: https://commits.webkit.org/317871@main
https://bugs.webkit.org/show_bug.cgi?id=320140 rdar://183079408 Reviewed by Keith Miller. After 317795@main, --target jsc for example does not produce a JSC shell binary which is code-signed. This patch fixes the issue by setting a post-build task only for "EXECUTABLE" target. We do not do it for the other type of targets since POST_BUILD in Ninja is executed just after linking, and frameworks requires the other jobs before codesining the framework (WebKit.framework linking -> XPC services are linked against this framework -> XPC services are code-signed -> codesign WebKit.framework). But EXECUTABLE does not need to code-sign the other things before sealing. So using POST_BUILD is fine. We keep jsc_CodeSign etc. as a custom target which relies on jsc target to keep the downstream use of this name without hassle. * Source/cmake/WebKitMacros.cmake: Canonical link: https://commits.webkit.org/317872@main
…ions policy in cross-origin frames https://bugs.webkit.org/show_bug.cgi?id=320139 rdar://183074348 Reviewed by Jer Noble. Added site-isolation layout tests that verify camera, microphone, and display-capture permissions policy in cross-origin frames. * LayoutTests/http/tests/site-isolation/permissions-api-camera-expected.txt: Added. * LayoutTests/http/tests/site-isolation/permissions-api-camera.html: Added. * LayoutTests/http/tests/site-isolation/permissions-api-microphone-expected.txt: Added. * LayoutTests/http/tests/site-isolation/permissions-api-microphone.html: Added. * LayoutTests/http/tests/site-isolation/permissions-policy-camera-expected.txt: Added. * LayoutTests/http/tests/site-isolation/permissions-policy-camera.html: Added. * LayoutTests/http/tests/site-isolation/permissions-policy-display-capture-expected.txt: Added. * LayoutTests/http/tests/site-isolation/permissions-policy-display-capture.html: Added. * LayoutTests/http/tests/site-isolation/permissions-policy-microphone-expected.txt: Added. * LayoutTests/http/tests/site-isolation/permissions-policy-microphone.html: Added. * LayoutTests/http/tests/site-isolation/permissions-policy-sync-xhr-expected.txt: Renamed from LayoutTests/http/tests/site-isolation/permissions-policy-expected.txt. * LayoutTests/http/tests/site-isolation/permissions-policy-sync-xhr.html: Renamed from LayoutTests/http/tests/site-isolation/permissions-policy.html. * LayoutTests/http/tests/site-isolation/resources/getDisplayMedia-permission-frame.html: Added. * LayoutTests/http/tests/site-isolation/resources/getUserMedia-permission-frame.html: Added. * LayoutTests/http/tests/site-isolation/resources/permissions-query-frame.html: Added. Canonical link: https://commits.webkit.org/317873@main
https://bugs.webkit.org/show_bug.cgi?id=319995 rdar://182927210 Reviewed by Alan Baradlay. https://drafts.csswg.org/css-grid-1/#grid-item-sizing When a replaced element is not being stretched due to its alignment then we try to size it to its natrual sizes. This falls into the logic that comes from the rules of block-level elements from CSS2. There is extra work that is needed for the case where a repalced element does not have a natural size, but we defer to do that in a later patch since this should be the common case. After this there should only be two cases left that we need to figure out in terms of computing the automatic sizes for grid items. These are the replaced elements without a natural size and non-replaced elements with a preferred aspect ratio that are documented in the FIXME. Also, we work with the assumption that the content is all horizontal-tb since that is the only thing allowed into GFC. Incorporating other writing modes will ideally just be a small API changing to make sure the mapping is done correctly and the core logic this patch introduces should remain the same. * Source/WebCore/layout/layouttree/LayoutElementBox.cpp: (WebCore::Layout::ElementBox::hasNaturalWidth const): (WebCore::Layout::ElementBox::hasNaturalHeight const): (WebCore::Layout::ElementBox::naturalWidth const): (WebCore::Layout::ElementBox::naturalHeight const): We had an API that checked the box for an intrinsic width/height, but those also handle cases where the box is a non-replaced element which is something we are not concerned with for this portion of the spec. I added a set of natural size APIs that is similar but is targeted only boxes which are replaced elements since that is the type of content that has natural sizes. https://www.w3.org/TR/css-images-3/#natural-size Canonical link: https://commits.webkit.org/317874@main
…tion) https://bugs.webkit.org/show_bug.cgi?id=318144 rdar://180959164 Reviewed by Yusuke Suzuki. While optimizing instanceof, we first compute the result then trigger the IC generation. However, the prototype chain can be mutated by user code (e.g. a Proxy getPrototypeOf trap or a getter) that runs while defaultHasInstance computes the instanceof result. When that happens, the chain walked during inline cache generation may no longer match the result we observed, so we can reach the prototype even though the operation reported a miss (shouldHit is false). In that case there is no consistent IC to build, so bail out and let the caller fall back to the megamorphic case instead of caching a stale condition set. Test: JSTests/stress/instanceof-prototype-change-during-compilation.js * JSTests/stress/instanceof-prototype-change-during-compilation.js: Added. (attempt.rootACtor): (attempt.const.quietGate.get trip): (attempt.const.noisyGate.get trip): (attempt.hot): (attempt.drive): (attempt): * Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.cpp: (JSC::generateConditionsForInstanceOf): Canonical link: https://commits.webkit.org/317875@main
https://webkit.org/b/319803 rdar://182131572 Reviewed by Abrar Rahman Protyasha. Stop calling `update` on the refresh controller until the scroll stretch settles after activation. Added a basic NSRefreshController test along with a test for this specific bug. Test: Tools/TestWebKitAPI/Tests/WebKit/WKWebView/mac/NSRefreshControllerTests.mm * Source/WebKit/UIProcess/mac/WebViewImpl.h: * Source/WebKit/UIProcess/mac/WebViewImpl.mm: (WebKit::WebViewImpl::setRefreshController): (WebKit::WebViewImpl::applyRefreshControllerHeight): (WebKit::WebViewImpl::updateRefreshControllerFrame): (WebKit::WebViewImpl::topScrollStretchDidChange): (WebKit::WebViewImpl::updateRefreshControllerForWheelEvent): (WebKit::WebViewImpl::updateRefreshControllerForPanGesture): * Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * Tools/TestWebKitAPI/Tests/WebKit/WKWebView/mac/NSRefreshControllerTests.mm: Added. (-[TestRefreshControllerTarget refreshControllerActivated:]): (TestWebKitAPI::pullDownAndWaitForRefresh): (TestWebKitAPI::TEST(NSRefreshControllerTests, Basic)): (TestWebKitAPI::TEST(NSRefreshControllerTests, DoesNotRefireDuringSettleAtSmallWindowHeight)): Canonical link: https://commits.webkit.org/317876@main
https://bugs.webkit.org/show_bug.cgi?id=320194 rdar://problem/183142295 Reviewed by Alan Baradlay. We already disable for vertical writing modes and it seems like there are some tests that depend on some logic when we have a horizontal-bt writing mode so let's disable it for now. Canonical link: https://commits.webkit.org/317877@main
https://bugs.webkit.org/show_bug.cgi?id=320182 rdar://183123665 Reviewed by Simon Fraser. Some Apple internal build configurations attempt to enable the Swift back forward list on very recent iOS 26 SDKs. The open source configuration mistakenly declared that this was impossible, so builds fail. Adjust the configuration to state that such builds are impossible only on 26.5 and below. Canonical link: https://commits.webkit.org/317878@main
https://bugs.webkit.org/show_bug.cgi?id=320430 rdar://183391902 Reviewed by Alex Christensen. HistoryController::goToItem blocks the web process on BackForwardGoToItem in order to move the UIProcess's back/forward cursor before the load commits. This no longer needs to be synchronous. The only reply payload is WebBackForwardListCounts, used to refresh WebBackForwardListProxy's cached counts — but WebBackForwardList::goToItem already ends in didChangeBackForwardList(), which broadcasts InvalidateBackForwardListCache to every web content process, so the cache is invalidated regardless of the reply. * Source/WebKit/UIProcess/ProvisionalPageProxy.cpp: (WebKit::ProvisionalPageProxy::backForwardGoToItem): (WebKit::ProvisionalPageProxy::didReceiveMessage): (WebKit::ProvisionalPageProxy::didReceiveSyncMessage): * Source/WebKit/UIProcess/ProvisionalPageProxy.h: * Source/WebKit/UIProcess/WebBackForwardList.cpp: (WebKit::WebBackForwardList::backForwardGoToItem): (WebKit::WebBackForwardList::backForwardGoToItemShared): * Source/WebKit/UIProcess/WebBackForwardList.h: * Source/WebKit/UIProcess/WebBackForwardList.messages.in: * Source/WebKit/UIProcess/WebBackForwardList.swift: (MakeAPIArray.backForwardGoToItem(_:)): (MakeAPIArray.backForwardGoToItemShared(_:)): * Source/WebKit/UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::didCommitLoadForFrame): (WebKit::WebPageProxy::backForwardGoToItemShared): * Source/WebKit/UIProcess/WebPageProxy.h: * Source/WebKit/WebProcess/WebPage/WebBackForwardListProxy.cpp: (WebKit::WebBackForwardListProxy::goToItem): Canonical link: https://commits.webkit.org/318075@main
https://bugs.webkit.org/show_bug.cgi?id=320465 rdar://183413467 Unreviewed build fix. Fix the build by reverting the changes to the swift overlay file. * Source/WebKit/UIProcess/API/Cocoa/WebKitSwiftOverlay.swift: Canonical link: https://commits.webkit.org/318076@main
https://bugs.webkit.org/show_bug.cgi?id=320467 rdar://183436553 Broke internal watchOS and tvOS builds. We tried a more targeted fix in 318076@main, but that did not work either, so let's revert entirely for now. Reverted change: [SwiftUI WebKit API] Expose WebPage and related types as SPI on watchOS and tvOS https://bugs.webkit.org/show_bug.cgi?id=317726 rdar://180479038 318040@main (21a90b4) Canonical link: https://commits.webkit.org/318077@main
…nvert for short strings https://bugs.webkit.org/show_bug.cgi?id=320419 rdar://183378922 Reviewed by Yusuke Suzuki. stringCopyUpconvert() is stringCopySameType()'s Latin1-to-char16_t upconvert sibling and has the same gap: a scalar byte-at-a-time fallback and a 16-byte SIMD fast path, but nothing in between, so strings shorter than 16 bytes always took the scalar loop. Add the same 8-byte SWAR tier. Widening 4 packed Latin1 bytes into 4 char16_t lanes needs an extra step beyond stringCopySameType's plain copy, so this adds WTF::zeroExtendBytesToHalfwords(), a small bit-doubling "spread" helper, and reuses it instead of an 8-instruction unrolled extract-and-store loop. ToT Patched json-stringify-short-strings-upconvert 174.2817+-5.1099 ^ 144.8684+-5.8863 ^ definitely 1.2030x faster Tests: JSTests/microbenchmarks/json-stringify-short-strings-upconvert.js Tools/TestWebKitAPI/Tests/WTF/MathExtras.cpp Canonical link: https://commits.webkit.org/318078@main
…rithm https://bugs.webkit.org/show_bug.cgi?id=320394 Reviewed by Antti Koivisto. layoutColumnReverse walked each line a second time after placeFlexItems had already placed it, subtracting where the first walk added, to lay the items out from the container's main-axis end. Two placement functions had to stay in step, and column-reverse was the last flex-direction reversal the algorithm resolved while laying out rather than at the flow-relative-to-physical conversion. computeFlexItemRects can flip the positions instead, now that it runs after the container's block extent is final -- which is what the second pass was waiting for. It flips the item's *margin* box and steps back over its leading margin: the two walks consume marginStart and marginEnd in opposite orders, so flipping the border box only lines up if those two swap, while the margin box is symmetric under reversal by construction. The edge to flip about is the container's main border-box extent, less the main-axis scrollbar, adjusted by the difference between the flow-aware start and end border+padding -- the same quantities the removed walk started from. Note this flip keys off flex-direction alone and leaves isLeftToRightFlow untouched. For a column the writing mode's own reversal is already accounted for twice over: isLeftToRightFlow moves the flow-aware start edge, and the renderer flips the position in RenderBox::flipForWritingMode, since RenderBox::location is stored in flipped-blocks coordinates. Folding flex-direction into isLeftToRightFlow would reverse a vertical-rl column twice and leave vertical-rl column-reverse unreversed. With this, every reversed direction -- row-reverse, RTL rows, column-reverse, wrap-reverse and rtl-column -- is resolved in computeFlexItemRects, and the algorithm above it lays every line out forwards. No change in behaviour. * Source/WebCore/layout/formattingContexts/flex/FlexFormattingContext.cpp: (WebCore::FlexFormattingContext::layout): (WebCore::FlexFormattingContext::computeFlexItemRects): (WebCore::FlexFormattingContext::reverseColumnLinesFromContainerMainEndIfNeeded): Deleted. (WebCore::FlexFormattingContext::layoutColumnReverse): Deleted. * Source/WebCore/layout/formattingContexts/flex/FlexFormattingContext.h: Canonical link: https://commits.webkit.org/318079@main
https://bugs.webkit.org/show_bug.cgi?id=320459 rdar://183427197 Reviewed by Yijia Huang. Now that we run WPT tests in wasm.yaml these spec tests are subsumed by the official copy. Let's run those instead. There were a few tests that used the harness from the various spec tests forks. Those have been re-written to use some other method but produce the same wasm blob. The one remaining spec tests are the threads/atomics ones since those do not appear to have been imported into the WPT tests. Canonical link: https://commits.webkit.org/318080@main
https://bugs.webkit.org/show_bug.cgi?id=320405 rdar://183375912 Reviewed by Abrar Rahman Protyasha. The WPT `css/css-scroll-snap/overscroll-snap.html` has a fractional height scroll snap element that goes to the end of the scrolling content, which reveals a couple of issues in the scroll snap code. First, `snapOffsetCoversSnapport()` needs a bit of tolerance, because in this case the end snap point is at, say, 20.5px, but the `scrollHeight` is integral and rounded up to 21px, and we need to not thing we're outside this snap port, otherwise it triggers scrolling back to the start. Second, two places that use the destination scroll offset need to clamp for rubber-banding, otherwise we again think that the target scroll position is outside the last snap target element, and scroll to the wrong place. Tests: fast/scrolling/mac/hidpi-overscroll-snap-discrete-scroll.html fast/scrolling/mac/overscroll-snap-adjusted-scroll-destination.html * LayoutTests/fast/scrolling/mac/hidpi-overscroll-snap-discrete-scroll-expected.txt: Added. * LayoutTests/fast/scrolling/mac/hidpi-overscroll-snap-discrete-scroll.html: Added. * LayoutTests/fast/scrolling/mac/overscroll-snap-adjusted-scroll-destination-expected.txt: Added. * LayoutTests/fast/scrolling/mac/overscroll-snap-adjusted-scroll-destination.html: Added. * Source/WebCore/page/scrolling/ScrollSnapOffsetsInfo.cpp: (WebCore::RectType>::snapOffsetCoversSnapport const): * Source/WebCore/platform/ScrollSnapAnimatorState.cpp: (WebCore::ScrollSnapAnimatorState::adjustedScrollDestination const): (WebCore::ScrollSnapAnimatorState::targetOffsetForStartOffset const): Canonical link: https://commits.webkit.org/318081@main
…on watchOS and tvOS https://bugs.webkit.org/show_bug.cgi?id=320472 rdar://183440214 Unreviewed re-land of 318040@main. Re-land 318040@main but without exposing anything from `WebKitSwiftOverlay.swift`. Tests: Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm Tools/TestWebKitAPI/Tests/WebKit/WebPage/WebPageTests.swift Tools/TestWebKitAPI/Tests/WebKit/WebPage/WebPageTransferableTests.swift * Source/WTF/wtf/PlatformEnableCocoa.h: * Source/WebKit/Scripts/generate-swift-availability-macros: * Source/WebKit/UIProcess/API/Cocoa/WKUserContentController.swift: * Source/WebKit/UIProcess/API/Cocoa/WebKitSwiftOverlay.swift: (WKPDFConfiguration.rect): (WKWebView.createWebArchiveData(_:any:)): (WKWebView.pdf(_:)): (WKWebView.find(_:configuration:)): * Source/WebKit/UIProcess/API/Swift/URLSchemeHandler.swift: * Source/WebKit/UIProcess/API/Swift/WebPage+BackForwardList.swift: * Source/WebKit/UIProcess/API/Swift/WebPage+Configuration.swift: * Source/WebKit/UIProcess/API/Swift/WebPage+DialogPresenting.swift: * Source/WebKit/UIProcess/API/Swift/WebPage+FormInfo.swift: * Source/WebKit/UIProcess/API/Swift/WebPage+FrameInfo.swift: * Source/WebKit/UIProcess/API/Swift/WebPage+ImmersiveEnvironment.swift: * Source/WebKit/UIProcess/API/Swift/WebPage+Navigation.swift: * Source/WebKit/UIProcess/API/Swift/WebPage+NavigationDeciding.swift: * Source/WebKit/UIProcess/API/Swift/WebPage+NavigationPreferences.swift: * Source/WebKit/UIProcess/API/Swift/WebPage+Transferable.swift: * Source/WebKit/UIProcess/API/Swift/WebPage.swift: * Tools/TestWebKitAPI/Helpers/cocoa/ImageAnalysisTestingUtilities.swift: * Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm: * Tools/TestWebKitAPI/Tests/WebKit/WebPage/WebPageTests.swift: (WebPageTests.observableProperties): * Tools/TestWebKitAPI/Tests/WebKit/WebPage/WebPageTransferableTests.swift: Canonical link: https://commits.webkit.org/318082@main
…lure https://bugs.webkit.org/show_bug.cgi?id=299929 rdar://162168233 Reviewed by Tim Nguyen. The default orientation for a bare <page-size> on the `size` @page descriptor is still unsettled on w3c/csswg-drafts#13178, but presumably should be portrait. Hence, `letter portrait` should normalize to `letter`. The issue was that it was stored as a CSSValuePair and just serialized verbatim without normalization. This should fix the fails on https://wpt.fyi/results/css/css-page/page-rule-declarations-000.html and https://wpt.fyi/css/css-page/parsing/size-valid.html. Layout is unaffected: an absent orientation is already treated as portrait. Covered by existing WPT tests; no new tests needed. * LayoutTests/imported/w3c/web-platform-tests/css/css-page/page-rule-declarations-000.html: Corrected stale `a4 portrait`/`jis-b5 portrait` expectations to `a4`/`jis-b5`. * LayoutTests/imported/w3c/web-platform-tests/css/css-page/parsing/size-valid-expected.txt: * LayoutTests/printing/page-rule-css-text-expected.txt: * Source/WebCore/css/parser/CSSPropertyParser.cpp: (WebCore::consumePageDescriptor): Drop a redundant `portrait` from a page-size pair. Canonical link: https://commits.webkit.org/318083@main
…failure https://bugs.webkit.org/show_bug.cgi?id=320421 rdar://156429277 Reviewed by Alex Christensen. The generic expected result records beganEnterFullScreen()/beganExitFullScreen() origins of {8, 442}, which is the fullscreen element's position in macOS AppKit bottom-left screen coordinates (600 - 8 - 150 = 442). iOS uses a top-left coordinate system, so the same cross-origin iframe at page offset (8, 8) is reported as {8, 8}. iOS therefore produced a deterministic text mismatch against the macOS baseline (50/50 locally) rather than a genuine flake. Add an iOS-specific baseline with the correct top-left coordinates and remove the Pass/Failure expectation so the test is enforced on iOS. * LayoutTests/platform/ios/TestExpectations: * LayoutTests/platform/ios/http/tests/site-isolation/fullscreen-expected.txt: Added. Canonical link: https://commits.webkit.org/318084@main
https://bugs.webkit.org/show_bug.cgi?id=320223 rdar://183162111 Reviewed by Sihui Liu. When site isolation is enabled, an iframe's shield page fails to load if its content is blocked. The iframe's WebContent is torn down while it's committing the load for the shield / substitute data. The subframe teardown path needs to apply the same willContinueLoading check that the main-frame path already uses before destroying a process. Test: Tools/TestWebKitAPI/Tests/WebKit/WKWebView/ParentalControlsContentFilteringTests.mm * Source/WebKit/UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::didFailProvisionalLoadForFrameShared): * Tools/TestWebKitAPI/Tests/WebKit/WKWebView/ParentalControlsContentFilteringTests.mm: (TEST(ParentalControlsContentFilteringTests, BlockedIframe)): Canonical link: https://commits.webkit.org/318085@main
https://bugs.webkit.org/show_bug.cgi?id=316241 rdar://183365415 Reviewed by Taher Ali. Name it HTMLInCanvasEnabled and make it internal and off by default for now. * Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml: Canonical link: https://commits.webkit.org/318086@main
https://bugs.webkit.org/show_bug.cgi?id=320332 rdar://183271849 Reviewed by Rupin Mittal. The Cookie Store specification stores a service worker registration's cookie change subscriptions in a list. subscribe() appends new subscriptions to that list, and getSubscriptions() iterates the list in order. Use ListHashSet to preserve the specified list order while avoiding duplicate subscriptions. * LayoutTests/imported/w3c/web-platform-tests/cookiestore/cookieStore_subscribe_arguments.https.any-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/cookiestore/cookieStore_subscribe_arguments.https.any.serviceworker-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/cookiestore/httponly_cookies.https.window-expected.txt: * Source/WebCore/workers/service/server/SWServerRegistration.cpp: (WebCore::SWServerRegistration::addCookieChangeSubscriptions): (WebCore::SWServerRegistration::removeCookieChangeSubscriptions): * Source/WebCore/workers/service/server/SWServerRegistration.h: Canonical link: https://commits.webkit.org/318087@main
https://bugs.webkit.org/show_bug.cgi?id=320469 <rdar://problem/183436566> Reviewed by Antti Koivisto. * Source/WebCore/SaferCPPExpectations/NoDeleteCheckerExpectations: * Source/WebCore/SaferCPPExpectations/UncheckedCallArgsCheckerExpectations: * Source/WebCore/SaferCPPExpectations/UncheckedLocalVarsCheckerExpectations: * Source/WebCore/layout/formattingContexts/flex/FlexFormattingContext.cpp: (WebCore::FlexLayoutItem::borderAndPaddingLogicalHeight const): (WebCore::FlexLayoutItem::intrinsicSize const): * Source/WebCore/layout/formattingContexts/flex/FlexFormattingContext.h: * Source/WebCore/layout/formattingContexts/flex/FlexFormattingUtils.cpp: (WebCore::FlexFormattingUtils::willStretchFlexItem): * Source/WebCore/layout/integration/flex/FlexIntegrationUtils.cpp: (WebCore::LayoutIntegration::FlexIntegrationUtils::applyStretchedLogicalHeightToFlexItem): (WebCore::LayoutIntegration::FlexIntegrationUtils::layoutFlexItemForStretchedCrossSize): (WebCore::LayoutIntegration::FlexIntegrationUtils::layoutFlexItemWithMainSize): (WebCore::LayoutIntegration::FlexIntegrationUtils::updateAutoMarginsInMainAxis): (WebCore::LayoutIntegration::FlexIntegrationUtils::updateAutoMarginsInCrossAxis): (WebCore::LayoutIntegration::FlexIntegrationUtils::setFlexItemOverridingBorderBoxLogicalHeight): (WebCore::LayoutIntegration::FlexIntegrationUtils::invalidateFlexItemContentLogicalWidthsIfNeeded): (WebCore::LayoutIntegration::FlexIntegrationUtils::trimMainAxisMarginStart): (WebCore::LayoutIntegration::FlexIntegrationUtils::dirtyPercentHeightDescendantsWithinFlexItem): (WebCore::LayoutIntegration::FlexIntegrationUtils::flexItemHasPercentHeightDescendants const): (WebCore::LayoutIntegration::FlexIntegrationUtils::flexItemContentLogicalHeight const): (WebCore::LayoutIntegration::FlexIntegrationUtils::computeBlockAxisContentSizeForFlexItem): (WebCore::LayoutIntegration::FlexIntegrationUtils::maxContentMainAxisExtentForFlexItem): (WebCore::LayoutIntegration::FlexIntegrationUtils::minContentMainAxisContributionForFlexItem): (WebCore::LayoutIntegration::FlexIntegrationUtils::flexItemIntrinsicLogicalHeight const): (WebCore::LayoutIntegration::FlexIntegrationUtils::flexItemIntrinsicLogicalWidth): (WebCore::LayoutIntegration::FlexIntegrationUtils::constrainFlexItemLogicalHeightByMinMax const): (WebCore::LayoutIntegration::FlexIntegrationUtils::constrainFlexItemLogicalWidthByMinMax const): (WebCore::LayoutIntegration::FlexIntegrationUtils::computePercentageLogicalHeightForFlexItem const): (WebCore::LayoutIntegration::FlexIntegrationUtils::computeLogicalHeightUsingForFlexItem const): (WebCore::LayoutIntegration::FlexIntegrationUtils::computeLogicalWidthUsingForFlexItem const): * Source/WebCore/layout/integration/flex/LayoutIntegrationFlexLayout.cpp: (WebCore::LayoutIntegration::FlexLayout::marginTrimItemsBeforeFlexLayout const): * Source/WebCore/rendering/RenderBox.cpp: (WebCore::RenderBox::shouldResetLogicalHeightBeforeLayout const): * Source/WebCore/rendering/RenderFlexibleBox.h: Canonical link: https://commits.webkit.org/318088@main
https://bugs.webkit.org/show_bug.cgi?id=320371 Reviewed by Adrian Perez de Castro. Currently, when JOURNALD_LOG is enabled, RELEASE_LOG messages are sent to sd_journal_send_with_location without any fallback. But, according to this function's documentation: "If systemd-journald(8) is not running (the socket is not present), those functions do nothing, and also return 0." This behavior can lead to lost RELEASE_LOG messages. For example, small CI runners might not run systemd at all during the tests. This commit adds a stderr fallback, enabled when the journald's socket is not found at startup. The new WEBKIT_DEBUG_OUTPUT environment variable can be set to 'stderr' to replace the journal output, or to 'journal' to disable the fallback completely. Note that the actual filtering of what would be printed is still controlled by the WEBKIT_DEBUG variable as usual. That is, "off" channels are still filtered out. * Source/WTF/wtf/Assertions.cpp: * Source/WTF/wtf/Assertions.h: (wtfLogPriorityName): * Source/WTF/wtf/Logger.h: (WTF::Logger::log): (WTF::Logger::logVerbose): * Source/WebKit/glib/environment-variables.md.in: Canonical link: https://commits.webkit.org/318089@main
… kCFURLErrorCannotOpenFile (-3001) https://bugs.webkit.org/show_bug.cgi?id=319695 rdar://164578060 Reviewed by Per Arne Vollan. Loading a top-level file:// resource requires a sandbox extension to be handed down to the Networking process, which performs the file read. WebPageProxy::maybeInitializeSandboxExtensionHandle() cannot issue that extension while the target WebContent process is still launching (it has no audit token yet), so it returns std::nullopt and the load is expected to be deferred until the process finishes launching, at which point the extension is re-issued (WebProcessProxy::shouldSendPendingMessage). loadFile(), loadRequestWithNavigationShared(), and ProvisionalPageProxy all implement this deferral: for a file:// URL on a launching process they send the *WaitingForProcessLaunch variant of the load message. WebPageProxy::launchProcessForReload() -- the path taken to reload the current back/forward item after the WebContent process is killed or crashes -- did not. It relaunched the process and immediately sent WebPage::GoToBackForwardItem with an empty sandbox extension handle. For a file:// item the relaunched WebContent therefore had no file access, could not create a sandbox extension for the Networking process, and the main-resource read failed with EPERM -- surfaced to the client as NSURLErrorDomain -3001 (kCFURLErrorCannotOpenFile) and an error page. This is intermittent in the field because it requires the file load to coincide with a WebContent process launch/relaunch; it reproduces reliably by killing the WebContent process and reloading a local file (e.g. a Mail attachment or a file in ~/Downloads or ~/Documents). Granting the browser Full Disk Access masks it because TCC then bypasses the extension chain entirely. Fix launchProcessForReload() to defer the reload for a file:// item on a still-launching process by sending GoToBackForwardItemWaitingForProcessLaunch, matching the other load paths, so the sandbox extension is re-issued once the process has finished launching. Also add release-level error logging along the file-load sandbox-extension path -- when the extension fails to be minted in the Networking process (createSandboxExtensionHandlesIfNecessary) or fails to reach the loader (startNetworkLoad) -- so this class of failure can be diagnosed from a field log without a debug build. * Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp: (WebKit::NetworkResourceLoadParameters::createSandboxExtensionHandlesIfNecessary): * Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp: (WebKit::NetworkResourceLoader::startNetworkLoad): * Source/WebKit/UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::launchProcessForReload): * Tools/TestWebKitAPI/Tests/WebKit/WKPage/cocoa/FetchLocalFile.mm: (TEST(WebKit, ReloadLocalFileAfterWebContentProcessTermination)): Canonical link: https://commits.webkit.org/318090@main
https://bugs.webkit.org/show_bug.cgi?id=319918 rdar://182840873 Reviewed by Sam Sneddon. The validate-commit-message EWS step and the pull-request pre-check both matched Reviewed-by anywhere in the commit message body, causing false positives when the body text mentions Reviewed-by as a phrase (e.g. a commit message that describes the feature itself). In the EWS step, `git log` without `--format=%B` indents commit message lines with 4 spaces, so a `^` anchor in grep would not work. Switch to `--format=%B` to get the raw message without indentation, then add the `^` anchor to the grep patterns so only lines that start with a reviewer string are matched. In the pull-request check, replace the plain `Reviewed-by in message` string search with a regex anchored to the start of a line. * Tools/CISupport/ews-build/steps.py: (ValidateCommitMessage.run): Use --format=%B and ^ in grep so reviewer strings are only matched at the start of a line. * Tools/CISupport/ews-build/steps_unittest.py: * Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/pull_request.py: (PullRequest.create_pull_request): Use an anchored regex instead of a plain substring check for Reviewed-by. * Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/land.py: (Land.REVIEWED_BY_RE): Anchor to start of line. Canonical link: https://commits.webkit.org/318091@main
https://bugs.webkit.org/show_bug.cgi?id=320014 rdar://182949083 Reviewed by Keith Miller. This patch adds support for Table64 in the OMG tier. * JSTests/wasm/stress/table64-bulk.js: * JSTests/wasm/stress/table64-call-indirect.js: * JSTests/wasm/stress/table64-get-and-set.js: * JSTests/wasm/stress/table64-grow-and-size.js: * JSTests/wasm/stress/table64-overflow.js: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/js/memory64/table64.wast.js: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/js/memory64/table_copy64.wast.js: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/js/memory64/table_fill64.wast.js: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/js/memory64/table_get64.wast.js: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/js/memory64/table_grow64.wast.js: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/js/memory64/table_init64.wast.js: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/js/memory64/table_set64.wast.js: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/js/memory64/table_size64.wast.js: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/address64.wast.js.html: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/align64.wast.js.html: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/binary_leb128_64.wast.js.html: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/bulk64.wast.js.html: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/call_indirect64.wast.js.html: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/endianness64.wast.js.html: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/float_memory64.wast.js.html: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/load64.wast.js.html: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/memory64-imports.wast.js.html: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/memory64.wast.js.html: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/memory_copy64.wast.js.html: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/memory_fill64.wast.js.html: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/memory_grow64.wast.js.html: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/memory_init64.wast.js.html: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/memory_redundancy64.wast.js.html: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/memory_trap64.wast.js.html: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/table64.wast.js.html: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/table_copy64.wast.js.html: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/table_copy_mixed.wast.js.html: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/table_fill64.wast.js.html: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/table_get64.wast.js.html: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/table_grow64.wast.js.html: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/table_init64.wast.js.html: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/table_set64.wast.js.html: * LayoutTests/imported/w3c/web-platform-tests/wasm/core/memory64/table_size64.wast.js.html: * Source/JavaScriptCore/wasm/WasmBBQJIT.cpp: (JSC::Wasm::BBQJITImpl::BBQJIT::addTableSet): (JSC::Wasm::BBQJITImpl::BBQJIT::addTableInit): (JSC::Wasm::BBQJITImpl::BBQJIT::addTableSize): (JSC::Wasm::BBQJITImpl::BBQJIT::addTableGrow): (JSC::Wasm::BBQJITImpl::BBQJIT::addTableFill): (JSC::Wasm::BBQJITImpl::BBQJIT::addTableCopy): (JSC::Wasm::BBQJITImpl::BBQJIT::addCallIndirect): * Source/JavaScriptCore/wasm/WasmBBQJIT64.cpp: (JSC::Wasm::BBQJITImpl::BBQJIT::addTableGet): * Source/JavaScriptCore/wasm/WasmIPIntSlowPaths.cpp: (JSC::IPInt::WASM_IPINT_EXTERN_CPP_DECL): * Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp: (JSC::Wasm::OMGIRGenerator::addTableSize): (JSC::Wasm::OMGIRGenerator::addTableGrow): (JSC::Wasm::OMGIRGenerator::addCallIndirect): * Source/JavaScriptCore/wasm/WasmOperations.cpp: (JSC::Wasm::JSC_DEFINE_NOEXCEPT_JIT_OPERATION): * Source/JavaScriptCore/wasm/WasmOperations.h: * Source/JavaScriptCore/wasm/WasmOperationsInlines.h: (JSC::Wasm::tableGet): (JSC::Wasm::tableSet): (JSC::Wasm::tableInit): (JSC::Wasm::tableFill): (JSC::Wasm::tableGrow): (JSC::Wasm::tableCopy): * Source/JavaScriptCore/wasm/WasmTable.cpp: (JSC::Wasm::Table::grow): * Source/JavaScriptCore/wasm/WasmTable.h: (JSC::Wasm::Table::isValidLength): Canonical link: https://commits.webkit.org/318092@main
…ingTests https://bugs.webkit.org/show_bug.cgi?id=320470 rdar://183437138 Reviewed by Keith Miller. The tests here dirty a region and free it, so the zeroed path only ever runs over pages that are resident-dirty or decommitted, never over pages brought back by a read fault. Add a case that puts a large region through a randomized number of evict/read-fault rounds before freeing it, then reallocates the same size and verifies the reused region reads zero, across all three first-fault orders. Eviction uses madvise(MADV_PAGEOUT) where available; where it is not, the rounds degenerate into plain re-reads, which the test reports. * Source/bmalloc/libpas/src/test/AllocationZeroingTests.cpp: (addAllocationZeroingTests): Canonical link: https://commits.webkit.org/318093@main
https://bugs.webkit.org/show_bug.cgi?id=320096 Reviewed by Ryosuke Niwa. This updates the node traversal in moveBefore() to recurse into shadow roots, and updates a test to cover the scenario of a shadowroot inside the moved container. * LayoutTests/imported/w3c/web-platform-tests/dom/nodes/moveBefore/custom-element-move-reactions-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/dom/nodes/moveBefore/custom-element-move-reactions.html: * Source/WebCore/dom/ContainerNode.cpp: (WebCore::runMovingStepsForShadowIncludingInclusiveDescendants): (WebCore::ContainerNode::moveBefore): Canonical link: https://commits.webkit.org/318094@main
…o delete airport from box https://bugs.webkit.org/show_bug.cgi?id=320473 rdar://183391399 Unreviewed, reverting 314501@main (a8c7730) Reverted change: GitHub.com: emoji reaction touches code box in comment. https://bugs.webkit.org/show_bug.cgi?id=312152 rdar://174652842 314501@main (a8c7730) Canonical link: https://commits.webkit.org/318095@main
https://bugs.webkit.org/show_bug.cgi?id=320480 rdar://183449981 Reviewed by Per Arne Vollan. If build flag WEBCONTENTRESTRICTIONS_ASK_TO is enabled but there is no referrerURL, the provided completionHandler is not called. No new tests needed. * Source/WebKit/NetworkProcess/NetworkProcess.cpp: (WebKit::NetworkProcess::allowEvaluatedURL): Canonical link: https://commits.webkit.org/318096@main
…adcc23b7 # Conflicts: # Source/WTF/wtf/SegmentedVector.h
|
Companion Bun PR: oven-sh/bun#36267. |
| cmd: runWebAssemblySuite unless parseRunCommands | ||
| - path: wasm/spec-tests | ||
| cmd: runWebAssemblySpecTest :normal unless parseRunCommands | ||
| - path: wasm/simd-spec-tests | ||
| cmd: "$skipModes += ['wasm-eager-jettison'.to_sym, 'wasm-eager-jettison-eager'.to_sym] if ($architecture == 'arm64' and $hostOS == 'linux'); runWebAssemblySIMDSpecTest :normal" | ||
| - path: wasm/function-references-spec-tests | ||
| cmd: runWebAssemblyFunctionReferenceSpecTest :normal | ||
| - path: wasm/gc-spec-tests | ||
| cmd: runWebAssemblyGCSpecTest :normal | ||
| - path: wasm/threads-spec-tests | ||
| cmd: runWebAssemblyThreadsSpecTest :normal |
There was a problem hiding this comment.
🟡 (Upstream bug, not a merge artifact — noting for the upstream report.) In BBQJIT::addTableCopy (Source/JavaScriptCore/wasm/WasmBBQJIT.cpp:973-974), the new Table64 debug assertions have the table indices swapped: dstOffset is checked against m_info.table(srcTableIndex) and srcOffset against m_info.table(dstTableIndex). A valid table.copy between an i32-indexed and an i64-indexed table (permitted by memory64) passes validation but trips these ASSERTs under BBQ in a debug build. Release is unaffected.
Extended reasoning...
What & where
Upstream commits 184ee4c654 / d202bedc5f (Wasm Memory64 Table64, BBQ+OMG), merged verbatim in this sync, replaced the plain TypeKind::I32 assertions in BBQJIT::addTableCopy with per-table address-type checks. The new lines are:
// Source/JavaScriptCore/wasm/WasmBBQJIT.cpp:971-975
[[nodiscard]] PartialResult BBQJIT::addTableCopy(unsigned dstTableIndex, unsigned srcTableIndex, Value dstOffset, Value srcOffset, Value length)
{
ASSERT(dstOffset.type() == m_info.table(srcTableIndex).addressType().asWasmTypeKind());
ASSERT(srcOffset.type() == m_info.table(dstTableIndex).addressType().asWasmTypeKind());
...The dstOffset assertion looks up srcTableIndex, and the srcOffset assertion looks up dstTableIndex — the two indices are transposed.
Why it is wrong
The validator establishes exactly the opposite pairing before ever calling addTableCopy:
// Source/JavaScriptCore/wasm/WasmFunctionParser.h:2313-2323
auto dstTableAddressType = m_info.tables[immediates.dstTableIndex].addressType();
auto srcTableAddressType = m_info.tables[immediates.srcTableIndex].addressType();
WASM_VALIDATOR_FAIL_IF(dstOffset.type().kind() != dstTableAddressType.asWasmTypeKind(), ...);
WASM_VALIDATOR_FAIL_IF(srcOffset.type().kind() != srcTableAddressType.asWasmTypeKind(), ...);
...
WASM_TRY_ADD_TO_CONTEXT(addTableCopy(immediates.dstTableIndex, immediates.srcTableIndex, dstOffset, srcOffset, length));So the guaranteed invariant is dstOffset.type() == table(dstTableIndex).addressType() and srcOffset.type() == table(srcTableIndex).addressType(). The BBQ assertions check the crossed pairing, which the validator does not guarantee.
Step-by-step trigger
Take a module with two funcref tables of different address widths (permitted by the memory64 proposal):
- table 0: i32-indexed (
addressType() == I32) - table 1: i64-indexed (
addressType() == I64)
and a function containing (table.copy 0 1 (i32.const 0) (i64.const 0) (i32.const 0)) — dst = table 0, src = table 1.
- Validation (WasmFunctionParser.h:2315-2316):
dstOffsetis I32,dstTableAddressTypeis I32 → pass.srcOffsetis I64,srcTableAddressTypeis I64 → pass.lengthis I32 (min of the two widths) → pass. The module is valid. - BBQ compile reaches
addTableCopy(dstTableIndex=0, srcTableIndex=1, dstOffset:I32, srcOffset:I64, length:I32). - Line 973:
ASSERT(dstOffset.type() /* I32 */ == m_info.table(srcTableIndex /* 1 */).addressType() /* I64 */)→ fails.
In a debug build the process aborts on ASSERTION FAILED. In release, ASSERT compiles to nothing, so the (correct) codegen that follows runs fine.
Impact
Debug-only crash on a spec-valid but rare shape (mixed 32/64 table.copy). Release builds and every same-width copy — the vast majority of table.copy uses — are unaffected, since when both tables share an address type the swapped lookups happen to yield the same value. This is an upstream bug being taken as-is by the sync; per the fork's convention it should be reported upstream rather than patched locally.
Fix
Swap the indices so each offset is checked against its own table:
ASSERT(dstOffset.type() == m_info.table(dstTableIndex).addressType().asWasmTypeKind());
ASSERT(srcOffset.type() == m_info.table(srcTableIndex).addressType().asWasmTypeKind());
Preview Builds
|
Merges
WebKit/WebKit@2e37adcc23b7(2026-07-28) into the fork. 163 upstream commits since the previous sync point (01aaa3e0be0c); 17 touchSource/JavaScriptCore, 16 touchSource/WTF, 3 touchSource/bmalloc.Merge-base repair
The previous sync (#352) was squash-merged, so
01aaa3e0be0cis not inmain's ancestry and the git merge-base was still2603e9eb41f0. This branch starts with amerge -s ours 01aaa3e0be0ccommit to record the ancestor (same pattern asc01c667409did ford81bcc3d833c), advancing the merge-base to01aaa3e0be0c. The subsequentgit merge upstream/mainthen sees only the 163 new commits instead of re-merging the 538 already-squashed ones.Conflict resolution
One file conflicted.
Source/WTF/wtf/SegmentedVector.h: the fork's #352 and upstream's https://bugs.webkit.org/show_bug.cgi?id=320179 both wrapped the!sizeof(Segment)static assertion in#if !OS(WINDOWS)to fix the MSVC-ABI build break. Upstream additionally gives Windows anoffsetof(Segment, m_entries) == 0check. Took upstream verbatim; the fork's narrower#ifis dropped.All
USE(BUN_JSC_ADDITIONS)andUSE(BUN_EVENT_LOOP)guards survive the merge unchanged (373 and 37 occurrences respectively, same counts asmain).Notable upstream changes
None of these require Bun-side adaptation; all header changes in
runtime/,heap/,API/andWTF/are additive.defaultToPrimitiveFastAndNonObservableonStructureRareData; newStructure::defaultToPrimitiveFastAndNonObservable().computeStickyFirstCharacterBitmap/computeAnchoredFirstCharacterBitmapintocomputeFirstCharacterBitmap;RegExpgainsfirstCharacterBitmap()and lazy storage.^inside empty-matching parentheses.WasmOperations.htable op signatures widened to 64-bit indices;WasmTable::grow/isValidLengthtakeuint64_t.BasicBlock::intersectionOfPastValuesAtHeadonly for OSR-entry targets;DFGCommonData::m_regExpFirstCharacterBitmapsremoved.stringCopySameType/stringCopyUpconvert.toJSONcorrectly.Iterator.zip: null-prototype options/underlying-iterator objects.RobinHoodHashTable::removeIf.makeStringByReplacingAlluses SIMDfind().SegmentedVectoroffsetofassertion,Heap.hfriend decls gainJS_EXPORT_PRIVATE,DbgHelperWin/ThreadingWintweaks.ENABLE(JOURNALD_LOG)only).MADV_ZEROsupport latch.MTE_overrideEnablementForJavaScriptCore=truedisabling MTE.Verification
Built the Bun debug+ASAN target against this tree (
--webkit=local) from theclaude/webkit-upgrade-01aaa3e0be0cBun branch merged with currentmain.jscand the static libs build cleanly; the resultingbun-debuglinks and passestest/js/bun/jsc/bun-jsc.test.ts(36/36).