Upgrade to upstream WebKit 23b0720b40

[sosukesuzuki]

Merges upstream WebKit 23b0720b40 (2026-10-15): 1013 commits since dbdca7545d (#773), 170 of them in Source/JavaScriptCore, Source/WTF or Source/bmalloc.

Please land this as a merge commit, not a squash. The merge records upstream/main as a parent, which is how the next upgrade finds its base.

The commits:

1. The merge. Its message lists every conflict and every place that merged cleanly but no longer fit; the same list is below.
2. [JSC] Keep ShadowRealm. Upstream removed ShadowRealm and JSRemoteFunction in 323565@main (d5f13fa851) because WebKit never shipped them. Bun does: it is a documented global, it is in bun-types, and Bun's tests use it. The merge takes the removal as it is, and this commit brings back the JavaScriptCore and JSTests parts, from the fork's versions of the files. This is a decision for the maintainers: it means the fork carries about 1,700 lines of engine code that upstream no longer maintains. To let ShadowRealm go instead, drop or revert this one commit (Bun then has to drop the global, its types, docs and tests, the deriveShadowRealmGlobalObject entries of its method tables, and renumber JSType.rs).
3. CI: take CombinedDomains.json from JavaScriptCore/Scripts. Upstream generates the file in another directory now, and the tarballs had lost it.
4. [JSC] Windows: yield once where a collection resumes the mutators, and its follow-up at the head. See below. Also a decision for the maintainers.
5. A merge of main, for 4556ec7c1c (SourceProvenance). SourceProvider.h conflicted next to lines where upstream had turned SourceTaintedOrigin into SourceTaintedness. What that commit adds takes a SourceTaintedness too now, like its neighbours. The constructor's definition in SourceProvider.cpp had merged cleanly with the old type and would no longer have matched its declaration.

With the second commit, JSType.h, GlobalObjectMethodTable.h, Intrinsic.h, LinkTimeConstant.h, BuiltinNames.h, BytecodeIntrinsicRegistry.h and BytecodeList.rb are what they were before the merge.

The collector's yield on Windows

Collector::resumeThePeriphery() used to end its wait for the parallel visitors with a SpinBackoff::spinOnce(), which ran at least once per call. SpinBackoff has no pause steps on Windows, so there that was a SwitchToThread(); on Linux it is a pause. 1d86f80869 (323742@main) removed the wait, rightly, and the yield went with it.

Bun's test/js/bun/module-graph/module-graph-workers.test.ts then timed out on Windows Server 2019 x64, every time. Its cells wait for 1 ms timers of a sleeping worker while dozens of threads spin on setImmediate() on four cores. Such a loop collects every 14 ms or so, so it used to give up the CPU that often, and without the yield it runs out its quantum. By topology (A to E), in seconds, from oven-sh/bun#45303's CI:

	A	B	C	D	E	sum
before the upgrade	14	36	26	10	4	90
upgraded, without the yield	18	84	78	22	12	214
upgraded, with it	16	34	30	10	4	94

This puts one Thread::yield() back in the same place, under USE(BUN_JSC_ADDITIONS) && OS(WINDOWS). It keeps a side effect on purpose: what Bun did before this upgrade, for that test and for any program with busy threads and workers on a loaded Windows server. The other way is to leave the engine as upstream has it and make the test wait without spinning. Windows 11 aarch64 lost the same yield and is no slower (56 in all three rows), which is not explained.

What needs a careful look

• OptionsMSVC.cmake. 0a75fded40 sets CMAKE_MSVC_RUNTIME_LIBRARY to MultiThreadedDLL with a plain set(), which overrides what is passed with -D. It merged without a conflict and would have replaced the static CRT that Dockerfile.windows and Bun pass. It is now only the default. Not built locally.
• Latin1Character is a struct (50a617392b). The fork's own code needed byteCast in jsc.cpp, CachedTypes.cpp and JSDateMath.cpp. Only what Linux x64 compiles has been compiled; the Windows-only templates of URL.cpp were instantiated by hand on Linux and are fine.
• ScriptFetchParameters::Type::CSS comes after HostDefined, and SourceProviderSourceType::CSS after BunTranspiledModule, unlike upstream's order. HostDefined has to stay 5: Bun's transpiler writes the number into the module info it serializes, and BunAnalyzeTranspiledModule.cpp asserts it.
• GCIncomingRefCountedSet::sweep() combines upstream's eden sweep of new and dirty ArrayBuffers (91e8fd1b2f) with the fork's accounting of m_bytes after an eden sweep.
• The Collector serves several heaps upstream now. The fork's begin-phase stamps moved into beginCollectionInEachHeap(), and totalMaxEdenSize() sums effectiveMaxEdenSize().

The merge

66 files conflicted. What was done about them, and about the places where the
two sides merged without a conflict but no longer fit:

NODELETE is now LEGACY_NODELETE (e795d5a, e4be394, b8f13b0):

• In most of the conflicting files this was the whole conflict: upstream renamed
  the annotation on a line the fork had changed or sat next to. The fork's lines,
  renamed. That is all of the conflicts in yarr/ but one, CachedTypes.{h,cpp},
  JSBigInt.h, JSCell.h, URL.h, URLParser.h, and single lines in many other
  headers.
• NODELETE is no longer defined under clang, so the 16 uses the fork had added in
  places that did not conflict are renamed too.

Heap / Collector (729712a and the fourteen commits after it let one Collector
serve several heaps):

• Collector.cpp: there is no m_heap any more. The stamps the fork takes at the
  start of a collection are per heap, so they moved from runBeginPhase() to
  beginCollectionInEachHeap(), still ahead of willStartCollection(); nothing in
  between reads them. GCRequest::didFinishEndPhase still runs where it did;
  didFinishCollection() went to endCollectionInEachHeap() with upstream.
• The mutator schedulers ask Collector::totalMaxEdenSize(), which sums the fork's
  Heap::effectiveMaxEdenSize() so that the cap under critical memory still holds.
• GC rate limiting stays reverted (642e225).
• GCIncomingRefCountedSet (91e8fd1, an eden sweep only looks at new and dirty
  ArrayBuffers): upstream's sweep, with the fork's accounting of m_bytes after an
  eden sweep. What upstream's eden sweep visits is what the fork counted
  separately, and m_oldCount is the fork's m_sizeAfterLastSweep, which is gone.
• MarkedBlock.cpp: marksConveyLivenessDuringMarking() is now
  staleMarksStillRecordSurvivors() (b8c79b4).
• VM::shrinkFootprintNow() clears sourceProviderCacheMap itself:
  clearSourceProviderCaches() became pruneUnusedSourceProviderCaches(), which
  keeps the caches used since the last prune (92e99db).

Latin1Character is a struct (50a6173): byteCast where the fork's code passes
bytes for characters or the reverse, in jsc.cpp, CachedTypes.cpp and
JSDateMath.cpp (the V8 date parser takes bytes).

Source taintedness (ac57a2a): SourceTaintedOrigin.h is SourceTaintedness.h.
JSModuleRecord's hasSameObservableSource() compares taintedness().

CSS module scripts (b1913f6):

• makeModule() and provideFetch() take a JSValue. They stay member functions, and
  the new default-export path passes the loader on.
• SyntheticModuleRecord::tryCreateDefaultExportSyntheticModule() is public, with
  the fork's JSModuleLoader* parameter.
• ScriptFetchParameters::Type::CSS comes after HostDefined, which stays 5: Bun's
  transpiler writes that number into the module info it serializes.
  SourceProviderSourceType::CSS comes after BunTranspiledModule likewise.
• with { type: "css" } stays a HostDefined type with USE(BUN_JSC_ADDITIONS), as
  "text" does: Bun loads it itself.
• JSModuleLoader::registryEntry() looks under Type::CSS too.

Exception stacks (70896f2, no stack is captured for a throw that a user's
catch clause is certain to handle): Exception visits m_asyncContext and takes
upstream's lock. The fork's createScriptCallStackFromException() reads
stackForReporting().

BigInt (e2ffc55 adds a divide-and-conquer toString): the fork already has one,
on Barrett division and interruptible. The fork's is kept and upstream's tests
run against it.

Yarr:

• 7a8cc2f (bit tables for Unicode property escapes): the fork has
  matchCharacterClassMatchesAndRanges() inlined in matchCharacterClass(), so
  upstream's new helpers landed inside a function body. They now precede it.
• 8d2c95e (length checks for an EOL string list): the fork has no
  consumeIndex(). A string list is only made of the whole pattern's body, which
  is matched forward, so it is an add32.
• stress/regexp-stringlist-eol-length-groups.js expects no match from a lastIndex
  inside a surrogate pair. That is A6 of JSTests/BUN-TEST-DIFFERENCES.md; the
  expectation is updated and the file is listed there.

Others:

• ExecutableMemoryHandle.h (e2e0869): ENABLE_LIBPAS_JIT_HEAP is defined above
  the includes. The exclusion of ARM64 Windows went with it.
• pas_thread_local_cache.c (69e1e79): pas_memory_flavor_plain, still
  asymmetric.
• OptionsMSVC.cmake (0a75fde) set CMAKE_MSVC_RUNTIME_LIBRARY to
  MultiThreadedDLL whatever was passed. It merged cleanly and would have replaced
  the static CRT that Dockerfile.windows and Bun pass. It is now only the default.
• CMakeLists.txt (e8c36a1): CombinedDomains.json is generated in
  JavaScriptCore_SCRIPTS_DIR, by the fork's command (the output path as an
  argument, no redirect).
• JSGlobalObject.cpp (733b18f): cachedToLocaleStringNumberFormat() is in;
  exposeDollarVM() stays in JSDollarVM.cpp.
• Nodes.h (e5f751c): neededConstants() is gone, statements() stays.
• InjectedScriptSource.js (b0bb30b): upstream's shape, testing for the fork's
  one-line "[native code] }".
• RuntimeManager.js (f87677d): upstream's parse, with ecmaVersion "latest".
• Symbol.h, VerifierSlotVisitorScope.h, WasmFunctionIPIntMetadataGenerator.h,
  IntlDateTimeFormat.cpp, SourceProvider.h: both sides' includes.
• WebCore/page/Viewport.h, ProofOfPossessionProviderInfo.h and
  FindInteractionTester.h are new upstream files that git took for renames of the
  deleted ShadowRealm headers. Upstream's files.

JSType.h loses ShadowRealmType here and gets it back in the next commit. Nothing
else in it changed. .github/ and the Dockerfiles are untouched.

How it was verified

Linux x64 only, with clang 20 (not the LLVM 23 that CI uses), from a machine that could reach neither the pinned toolchain nor the prebuilt releases.

• jsc builds and links, Debug with assertions, with the flags of scripts/build/deps/webkit.ts in oven-sh/bun and libpas.
• JavaScriptCore, WTF and bmalloc also build in the configuration Bun ships (USE_MIMALLOC, USE_EXTERNAL_MIMALLOC, -fno-pic), from Bun's own build graph.
• run-javascriptcore-tests --quick on that Debug jsc, filtered to every test under JSTests/stress and JSTests/wasm/stress that the merge adds or changes, plus the ShadowRealm, remote function, string list, BigInt, ArrayBuffer, WeakMap, import attribute, Unicode property and toLocaleString tests: 440 runs of 125 files pass. One file needed its expectation changed, stress/regexp-stringlist-eol-length-groups.js (A6, see above). The whole suite has not been run; this pull request's test job is the first full run.
• All 64 tests of test262's built-ins/ShadowRealm pass (default, no JIT, validateExceptionChecks).
• Of the lines the fork had added to a file that upstream also changed (382 files), 35 are not in the result. Each is one of the rewrites listed above. Counting repeated lines found one more that the ShadowRealm revert had lost, which is back (AllowLazyMaterializationOfImmutableProperties in JSFunction.cpp).
• Bun's C++ compiles against this tree, with the changes it needs (mostly Latin1Character). No Bun could be linked or run: Bun's Rust needs the pinned nightly.
• macOS, Windows, FreeBSD, Android, musl, arm64, ASAN, LTO: nothing has been built. CI here is the first build of all of them.

Found on the way, not from this merge, not changed here

In ShadowRealm, in code that is the same as on main; 2 to 4 also happen on Bun 1.4.2:

1. new ShadowRealm().evaluate("(function (v) { throw v })")(Symbol()) fails ASSERT(!scope.exception()) in sanitizeRemoteFunctionException() (toWTFString() of a Symbol throws). A build without assertions throws a TypeError.
2. remoteFunctionCallGeneric() wraps its return value for targetGlobalObject, where remoteFunctionCallForJSFunction() has globalObject. A function returned through a wrapped Proxy has the inner realm's Function.prototype.
3. An error is only replaced when Interpreter::unwind() unwinds the remote function's frame. When C++ calls the wrapped function (Promise.prototype.then, Array.prototype.sort, String.prototype.replace), the inner realm's error object comes out.
4. f.caller of a sloppy function in the realm skips the remote function's frame and returns the outer realm's function.
5. stress/remoteFunctionCallForJSFunction-should-placate-overflow-check{,2}.js do not pass --useShadowRealm=1, so all they see is a ReferenceError. They are as upstream had them.

---

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

Preview build of 2ef4a7a: autobuild-preview-pr-814-2ef4a7ab

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

Beyond the inline findings (both in upstream WebCore code pulled in by the merge), I also checked the two fork-specific commits: the new hard-coded JavaScriptCore/Scripts/CombinedDomains.json path in the five Dockerfiles matches where Source/cmake/WebKitFS.cmake sets JavaScriptCore_SCRIPTS_DIR for every non-Apple build, and the arm64 Linux un-skip of type-index-abstract-heap-types-subtype-validation.js and the .wkdev-sdk-version bump are expectation/toolchain changes only.

Extended reasoning...

This is an upstream WebKit sync of roughly 100 commits (13k files) into the Bun fork plus two fork-specific commits: keeping ShadowRealm and pointing the Dockerfiles at the new CombinedDomains.json location. The two inline findings are in upstream WebCore rendering code and a layout test, not in fork-authored code. The Dockerfile path change was verified against the CMake variable definition; it only falls back to the PrivateHeaders location on Apple non-Bun builds, which these Dockerfiles do not cover. No security-sensitive surface is touched by the fork-specific commits; the sheer size of the upstream merge and the incomplete conversation history mean a human look is still warranted.

Additional findings (outside the current diff — GitHub can't attach inline comments there):

• 🟡 Source/WebCore/rendering/RenderBox.cpp:515 — Pages that change -apple-color-filter at runtime now get scrollbar thumb and track colors filtered with the old filter until scrollbar-color itself changes. The push in RenderBox::styleDidChange at Source/WebCore/rendering/RenderBox.cpp:508 only fires when oldStyle->scrollbarColor() != newStyle.scrollbarColor(), yet the value it pushes now depends on appleColorFilter() (lines 514-515). Fix: recompute and push the scrollbar color whenever either scrollbar-color or -apple-color-filter changes (and ideally the currentColor source), for both the document element path at line 520 and the overflow path at line 522. On the base branch the pushed value ignored the filter, so a filter change never left it stale.

  Why this was flagged

  A page sets scrollbar-color: blue green and later toggles a class that changes -apple-color-filter (for example adding or removing invert(1)), the common way apps implement a smart-invert mode. Style resolution runs RenderBox::styleDidChange (Source/WebCore/rendering/RenderBox.cpp:508); the guard compares only scrollbarColor(), which is unchanged, so no ScrollbarColor is pushed through frameView().scrollbarColorDidChange (line 520) or scrollableArea->scrollbarColorDidChange (line 522). The value pushed earlier was computed with colorResolvingCurrentColorApplyingColorFilter (lines 514-515) using the previous filter. The page content repaints with the new filter while the scrollbar keeps the colors derived from the old filter. On the base branch the pushed colors never depended on the filter (colorResolvingCurrentColor), so there was no stale state; the diff makes the value filter-dependent without widening the change guard. The new tests in LayoutTests/css3/color-filters only change scrollbar-color, never the filter, so they do not exercise this path.

  Verification: Source/WebCore/rendering/RenderBox.cpp:508 gates the push on oldStyle->scrollbarColor() != newStyle.scrollbarColor() only, while the value pushed at lines 514-515 is now colorResolver.colorResolvingCurrentColorApplyingColorFilter (new in this diff; base used colorResolvingCurrentColor). A color-filter change is only a repaint-level difference, so nothing else re-pushes the color.

[claude]

Code review found no issues

No high-confidence issues detected in this change.

This review covers commit 9aec710, which is no longer the latest commit on this pull request; later commits are not covered by it.

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

Additional findings (outside the current diff — GitHub can't attach inline comments there):

• 🟡 Source/JavaScriptCore/runtime/JSModuleLoader.cpp:851 — Hosts that fulfil a module fetch with a non-JSSourceCode value (the new makeModule contract) now crash on the require(esm) sync-replay path while the async path accepts it. JSModuleLoader.cpp:851 still casts fetchPromise->result() with uncheckedDowncast before passing it to makeModule, which since this merge takes a JSValue and handles non-JSSourceCode data itself (JSModuleLoader.cpp:1467). Fix: pass fetchPromise->result() straight to makeModule, as moduleRegistryFetchSettled does at JSMicrotask.cpp:1026, so both paths honour the same contract. Conditional on a host (Bun's loader lives outside this tree) resolving a fetch with a non-JSSourceCode value.

  Why this was flagged

  Trigger: vm.m_synchronousModuleQueue is set (require(esm)), a dependency's fetch promise was already fulfilled by the host, and its result is not a JSSourceCode; hostLoadImportedModule reaches the BUN_JSC_ADDITIONS replay block at JSModuleLoader.cpp:844-851. This merge changed makeModule to take JSValue and to turn any non-JSSourceCode moduleData into a default-export SyntheticModuleRecord (JSModuleLoader.cpp:1467-1474), and the async reaction now forwards the raw value (call at JSMicrotask.cpp:1026). The replay at JSModuleLoader.cpp:851 was not updated: uncheckedDowncast(fetchPromise->result()) (JSCast.h:348-356) calls reportZappedCellAndCrash for a non-JSSourceCode cell under ASSERT_ENABLED or ENABLE(SECURITY_ASSERTIONS) on x86_64, and for a primitive result asCell() yields a garbage pointer that makeModule's dynamicDowncast then dereferences in every build. On the base branch both paths required a JSSourceCode, so the two paths agreed; now only the sync path rejects the value the contract allows. No safeguard applies: makeModule's own dynamicDowncast runs only after the unchecked cast has already produced the bad pointer.

  Verification: nit. Trigger: a host that drives require(esm) through JSModuleLoader::loadModuleSync fulfils a dependency's fetch promise with a non-JSSourceCode value, and the replay block at Source/JavaScriptCore/runtime/JSModuleLoader.cpp:844-851 runs in an ASSERT_ENABLED or ASAN build. JSModuleLoader.cpp:851 is unchanged by the diff and still reads makeModule(globalObject, resolved, uncheckedDowncast<JSSourceCode>(fetchPromise->result())).

• 🟡 Source/JavaScriptCore/heap/Collector.cpp:378 — If Bun's idle-GC completion callback must run to finish something, an embedder whose VM shuts down with that collection still queued now never gets it. Heap::shutDown at Source/JavaScriptCore/heap/Heap.cpp:471 only requests a Leave, and runNotRunningPhase at Collector.cpp:375-378 clears every pending request once the heap set is empty, so a GCRequest::didFinishEndPhase set by JSC__VM__collectAsyncIdle is dropped instead of reaching Collector.cpp:650. On the base branch shutDown called waitForAllCollections() first, which ran the collection and the callback. Fix: before leaving the collector, serve or explicitly complete pending requests that carry didFinishEndPhase (for example wait for them in shutDown as the base did, or run the callback when the request is discarded).

  Why this was flagged

  The trigger is Heap::collectAsync with a GCRequest whose didFinishEndPhase is set (GCRequest.h:57-58 says Bun sets it from JSC__VM__collectAsyncIdle) followed by VM destruction before the next GC poll; the request cannot be subsumed (GCRequest.cpp:34-35) so it stays queued. Heap::shutDown (Heap.cpp:470-473) no longer waits for pending collections; it queues a Leave membership change and waits only for that. The collector enters runNotRunningPhase (Collector.cpp:367-388): applyAllMembershipChangesWithLock removes the heap, then because m_heaps.isEmpty() it does m_requests.clear() and advances m_lastServedTicket, so the End phase at Collector.cpp:649-651 that runs didFinishEndPhase never happens for that request. On the base branch Heap::shutDown called waitForAllCollections() before stopping the thread, so the queued collection ran and the callback fired. Whether the dropped callback matters depends on what Bun's callback does, which is outside this checkout.

  Verification: runNotRunningPhase (Collector.cpp:367-388) applies the Leave first (line 373), then m_requests.clear() (lines 375-378), so the m_currentRequest.didFinishEndPhase->run() at Collector.cpp:650-651 never executes. On the base commit, Heap::shutDown called waitForAllCollections() when m_collector->hasOutstandingRequest() (base Heap.cpp:470-472), so the callback was guaranteed to run before teardown.

[claude]

Code review found no issues

No high-confidence issues detected in this change.