Skip to content

Upgrade to upstream WebKit 2e37adcc23b7 - #370

Open
robobun wants to merge 703 commits into
mainfrom
bun/upgrade-to-2e37adcc23b7
Open

Upgrade to upstream WebKit 2e37adcc23b7#370
robobun wants to merge 703 commits into
mainfrom
bun/upgrade-to-2e37adcc23b7

Conversation

@robobun

@robobun robobun commented Jul 28, 2026

Copy link
Copy Markdown
Collaborator

Merges WebKit/WebKit@2e37adcc23b7 (2026-07-28) into the fork. 163 upstream commits since the previous sync point (01aaa3e0be0c); 17 touch Source/JavaScriptCore, 16 touch Source/WTF, 3 touch Source/bmalloc.

Merge-base repair

The previous sync (#352) was squash-merged, so 01aaa3e0be0c is not in main's ancestry and the git merge-base was still 2603e9eb41f0. This branch starts with a merge -s ours 01aaa3e0be0c commit to record the ancestor (same pattern as c01c667409 did for d81bcc3d833c), advancing the merge-base to 01aaa3e0be0c. The subsequent git merge upstream/main then 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 an offsetof(Segment, m_entries) == 0 check. Took upstream verbatim; the fork's narrower #if is dropped.

All USE(BUN_JSC_ADDITIONS) and USE(BUN_EVENT_LOOP) guards survive the merge unchanged (373 and 37 occurrences respectively, same counts as main).

Notable upstream changes

None of these require Bun-side adaptation; all header changes in runtime/, heap/, API/ and WTF/ are additive.

  • cd91e7f128 runtime: cache defaultToPrimitiveFastAndNonObservable on StructureRareData; new Structure::defaultToPrimitiveFastAndNonObservable().
  • 1e43057f13 Yarr: merge computeStickyFirstCharacterBitmap / computeAnchoredFirstCharacterBitmap into computeFirstCharacterBitmap; RegExp gains firstCharacterBitmap() and lazy storage.
  • b128ddd863 / 98d0367d22 Yarr correctness fixes: sticky dot-star wrapping, ^ inside empty-matching parentheses.
  • 184ee4c654 / d202bedc5f Wasm Memory64 Table64 (BBQ+OMG); WasmOperations.h table op signatures widened to 64-bit indices; WasmTable::grow/isValidLength take uint64_t.
  • 8354048143 DFG: allocate BasicBlock::intersectionOfPastValuesAtHead only for OSR-entry targets; DFGCommonData::m_regExpFirstCharacterBitmaps removed.
  • 656d3c3683 / 1d355c27ea JSON.stringify: 8-byte SWAR fast path for stringCopySameType / stringCopyUpconvert.
  • 9f9370cc72 JSON.stringify: skip non-enumerable own toJSON correctly.
  • 0731b27c1b Iterator.zip: null-prototype options/underlying-iterator objects.
  • e1fc460b8f WTF: RobinHoodHashTable::removeIf.
  • 6cb1077d85 WTF: makeStringByReplacingAll uses SIMD find().
  • f2429bc794 WTF Windows build fixes: SegmentedVector offsetof assertion, Heap.h friend decls gain JS_EXPORT_PRIVATE, DbgHelperWin/ThreadingWin tweaks.
  • 33e302a9cc WTF: journald log fallback to stderr when unreachable (ENABLE(JOURNALD_LOG) only).
  • 8b8b3e5ee1 bmalloc: fix inverted MADV_ZERO support latch.
  • 05c83a6550 libpas: fix MTE_overrideEnablementForJavaScriptCore=true disabling MTE.

Verification

Built the Bun debug+ASAN target against this tree (--webkit=local) from the claude/webkit-upgrade-01aaa3e0be0c Bun branch merged with current main. jsc and the static libs build cleanly; the resulting bun-debug links and passes test/js/bun/jsc/bun-jsc.test.ts (36/36).

philn and others added 30 commits July 24, 2026 02:00
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
charliewolfe and others added 24 commits July 28, 2026 09:41
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
@robobun

robobun commented Jul 28, 2026

Copy link
Copy Markdown
Collaborator Author

Companion Bun PR: oven-sh/bun#36267.

Comment thread JSTests/wasm.yaml
Comment on lines 55 to 57
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

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 (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.

  1. Validation (WasmFunctionParser.h:2315-2316): dstOffset is I32, dstTableAddressType is I32 → pass. srcOffset is I64, srcTableAddressType is I64 → pass. length is I32 (min of the two widths) → pass. The module is valid.
  2. BBQ compile reaches addTableCopy(dstTableIndex=0, srcTableIndex=1, dstOffset:I32, srcOffset:I64, length:I32).
  3. 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());

@github-actions

Copy link
Copy Markdown

Preview Builds

Commit Release Date
06ee8632 autobuild-preview-pr-370-06ee8632 2026-07-28 23:17:44 UTC

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.