[sosukesuzuki]

Merges upstream WebKit 33ce3bf11a71 (2026-10-20): 520 commits since 23b0720b40 (#814), 89 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.

JSType.h, BytecodeList.rb, OptionsList.h, .github/ and the Dockerfiles are untouched by the merge.

The commits:

1. The merge. What was done about the conflicts, and about the places that merged cleanly but no longer fit, is below.

2. [WTF] Atomics.h: keep the Atomic<T> casts where the standard library has no std::atomic_ref. 89f96182aa wrote the free functions of Atomics.h with std::atomic_ref, which libc++ has from LLVM 19 on. The Android NDK the android lanes (and Bun) build against, r27c, ships an older one, and all six android lanes failed in WTF. Where __cpp_lib_atomic_ref is not defined, the functions are what they were before that commit. The other way is a newer NDK, here and in Bun.

3. [JSC] The count of private names a function uses does not depend on the SourceProviderCache. c5f66f3853 reserves a register for each private name a function uses, and counts them only when the parser has seen a private name. An inner function whose body is skipped through the SourceProviderCache hands over its used variables without the parser seeing anything, so a function that uses no private name itself but contains one that does got registers with --useSourceProviderCache=0 and none without. The bytecode cache's output has to be a function of the source alone, and Bun's test/bundler/bundler_bytecode_portable.test.ts ("encoder output does not depend on the encoding process") failed on it. A skipped body now sets the flag when one of its used variables is a private name.

4. [WTF] Vector::crashIfBorrowed(): one shared crash instead of RELEASE_ASSERT. cc50ab1fce made the check a RELEASE_ASSERT. On Darwin that hands __FILE__ and __PRETTY_FUNCTION__ to the crash, in a template inlined into every mutation of every Vector, and Bun's macOS binaries grew by 1.3 MB (0.3 to 0.4 MB elsewhere). The check stays in release builds; when it fails it calls one out-of-line WTF::crashDueToBorrowedVector(). bin/jsc of the macOS arm64 LTO lane, against main's:

   	file	__text	__cstring
   with upstream's RELEASE_ASSERT (5ac1583e)	+1,132 KB	+773 KB	+166 KB (814 strings)
   with the shared crash (70d3fedb)	+349 KB	+183 KB	0

   A decision for the maintainers: it makes Vector.h differ from upstream's by a few lines. The other way is to take the growth.

5. A merge of main at d0b16ad0 ([JSC] The control flow profiler has basic blocks for what is skipped and for what is after a yield or an await #851, the control flow profiler's basic blocks), which landed after this branch was cut and which Bun's main now requires. No conflicts. It changes the signatures of emitOptionalCheck(), pushOptionalChainTarget() and emitShortCircuitAssignment(); every call site in the merged tree was checked to pass the new arguments, upstream's new code in this range included. At bc7aebee all 45 lanes build and run-javascriptcore-tests passes on the Linux x64 and arm64 LTO lanes; the other results below are for 70d3fedb.

6. A second merge of main, at 7d0c8a7d ([JSC] Keep expression info sorted when a peephole replaces a wider instruction #861, expression info stays sorted when a peephole replaces an instruction; CI: two Linux x64 lanes with the stack protector, _FORTIFY_SOURCE, stack clash protection and zeroed locals #865, two hardened Linux x64 lanes), which Bun's main pins now. No conflicts. At this head (35cf4b1e) all 47 lanes build and run-javascriptcore-tests passes on the three tested lanes (Linux x64 LTO, x64 LTO hardened, arm64 LTO).

What needs a careful look

• BlockDirectory's bits are behind a mutate/grow lock now (847b1d1f5e). A block's inUse bit is a per-block lock, and only its holder may write the block's other bits. The fork's code was adapted in two places:
  • Heap.cpp, the evacuation of auxiliary blocks: it used to take bitvectorLock() and flip a candidate's CanAllocate bit. It now goes through a new static exchangeCanAllocate(), which takes bitvectorLock().mutate(), claims the block's inUse bit, reads and writes CanAllocate, and releases inUse. A block somebody else holds is left alone (and reported as "could not allocate", so it is not restored later either).
  • MarkedBlock::Handle::decommitUnusedPages(): releaseAssertAcquiredBitVectorLock() is gone upstream; the call is dropped, and the read of the MarkingRetired bit stays under assertIsMutatorOrMutatorIsStopped(). In sweep(), upstream's locking, with the fork's isFirstSweepSinceFullCollection and the call to decommitUnusedPages() before the mutate lock is taken (the lock is not recursive).
• Heap lost 14 friend declarations (4f97164ba5), CodeBlock among them. The fork's CodeBlock aging read two private members of Heap; currentGCStartApproximateTime() and isIdleCollection() are public now. This merged without a conflict and would not have compiled.
• CodeBlock::checkIfJITThresholdReached() is out of line (ad96437625): upstream's new body, ending in the fork's call with startupJITDeferralScale().
• The conservative scan (68b19b2888, check mayHaveIndexingHeader before marking the previous cell): the fork already had the stricter mayBeReferencedByButterflyEndPointer() on that line, which includes it. The fork's line.

The other conflicts

20 files conflicted.

• DFG/FTL (TypedArraySet is a new node, added next to the fork's BufferReadInt/BufferReadFloat/BufferWrite): both, in DFGNodeType.h, DFGClobberize.h, DFGFixupPhase.cpp, DFGPredictionPropagationPhase.cpp, FTLCapabilities.cpp and FTLLowerDFGToB3.cpp.
• DFGStrengthReductionPhase.cpp: the fork's bail-out for a sticky non-global RegExp, then upstream's StringBuilder builder(OverflowPolicy::RecordOverflow).
• BytecodeGenerator.cpp (5d5248a69a, the private class brand is installed before class elements are evaluated): upstream removed the TDZ check on the brand in emitCheckPrivateBrand(); the fork had only rewritten that line as emitTDZCheck(brand). Removed.
• BytecodeGenerator.h, Nodes.h: both sides' declarations.
• JSObject.h: the fork's quoted includes, without IndexingHeaderInlines.h, which upstream deleted (a3c8dbf35b).
• Heap.cpp: upstream's new addGCAwareJITStubRoutine(), and the fork's signature of addReference().
• URLParser.{h,cpp} (cf30450ee4, 16a7f29cda, LEGACY_NODELETE on definitions): the fork's parser, with the annotation added to the two definitions that still exist in it (parseIPv4PieceInsideIPv6, parseIPv4AddressInsideIPv6).
• POSIXExtras.h (75bd0aeec2): upstream fixed the same thing the fork had (no shm_open() on Android). Upstream's file.
• MemoryUnsafeCastCheckerExpectations: upstream's list, plus the fork's two entries.
• WebCore/html/track/TrackOpaqueRoot.h and WTF/wtf/darwin/WebKitReasonCode.h are new upstream files that git took for renames of the deleted IndexingHeaderInlines.h. Upstream's files.

How it was verified

Nothing was compiled locally: the machine this was done on has 4 cores and could not get the pinned LLVM 23. This pull request's CI is what built and tested it.

• All 45 lanes build at 70d3fedb. run-javascriptcore-tests passes on the Linux arm64 LTO lane at 70d3fedb, and passed on both tested lanes at 5ac1583e. On x64 at 70d3fedb the first run had one failure, stress/sampling-profiler-line-column.js.ftl-eager. It is an intermittent failure the fork already has: the command from jsc-failures.log fails 8 times in 1,600 with this build, with 5ac1583e's, and with autobuild-274ebb3c… from before the merge (details in a comment below). The job was re-run once and passed; the test is not changed or skipped here.
• Bun's side is Upgrade WebKit to 33ce3bf11a71 bun#46279, which points WEBKIT_VERSION at this pull request's preview build. Bun builds against it on all thirteen targets; what its tests found is commits 3 and 4 above, and two things fixed on Bun's side (an allowlist entry for three outline-atomics helpers, and a stale stack word in Bun.gc()). With 70d3fedb, Bun's binary-size check passes and the only failing test on its Linux and Windows shards was the bytecode snapshot, which is updated there.

What was checked without a compiler:

• Every file the fork had not changed is identical to upstream's, and every file upstream had not changed is identical to main's.
• No use is left of what upstream removed or renamed in this range: jitStubRoutines(), releaseAssertAcquiredBitVectorLock(), assertSweeperIsSuspended(), noteBlockMayBeStealable(), MarkedBlock::Handle::setIsDestructible(), IndexingHeader::preCapacity(), IndexingHeaderInlines.h, dragonbox, B3 MemoryCopy, m_discoveredAccessedStringsFromGCOwnedDataScope, two-argument FOR_EACH_BLOCK_DIRECTORY_BIT callbacks, two-argument OpCheckTdz::emit.
• The fork's lines outside Heap.{h,cpp} that reach into Heap were checked against what is private there now.

---

Generated by Claude Code

[github-actions]

Preview build of 35cf4b1: autobuild-preview-pr-860-35cf4b1e

[claude]

Findings marked 🟡 are optional suggestions and need no follow-up push.

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

• 🔴 Source/WebCore/html/canvas/PlaceholderRenderingContext.cpp:140 — Pages that read a displayed OffscreenCanvas placeholder once (toDataURL, toBlob, drawImage, createImageBitmap) now get an older frame or transparent black instead of the last drawn frame. Once the placeholder's layer has a delegate, LocalPlaceholderRenderingContextSource::setPlaceholderBuffer at PlaceholderRenderingContext.cpp:137 stops cloning the buffer, so surfaceBufferToImageBuffer only returns stale data and schedules a recommit for later; if the worker was terminated or the OffscreenCanvas is gone, the recommit never runs and reads stay stale forever. Fix: a synchronous read must return the frame currently shown on the layer, e.g. keep cloning until the first read completes, or fetch the frame from the delegate on demand, covering 2D, WebGL and WebGPU sources. [also at: Source/WebCore/html/canvas/PlaceholderRenderingContext.cpp:139 - Pages that read a worker-driven placeholder canvas once (toDataURL, toBlob, drawImage, texImage2D) now get an old frame or a blank image, not the latest frame.]

  Why this was flagged

  A page transfers a canvas to a worker (or main-thread) OffscreenCanvas, lets it render while composited, then calls placeholder.toDataURL() or ctx.drawImage(placeholder) once, as a 'save image' button would. Reads go through CanvasBase::makeRenderingResultsAvailable at CanvasBase.cpp:88 into PlaceholderRenderingContext::surfaceBufferToImageBuffer at PlaceholderRenderingContext.cpp:327, which only calls requestFrameBuffersIfStale and then returns the old m_buffer, or createTransparentBlackImageBuffer when no buffer ever arrived. On the base branch every commit cloned the buffer (the code now under the needsFrameBuffers check at PlaceholderRenderingContext.cpp:137-140 ran unconditionally), so the read returned the last committed frame. The recommit path depends on the OffscreenCanvas's event loop: OffscreenCanvas.cpp:178-183 posts to the original context identifier, so after worker.terminate() or once the OffscreenCanvas is collected the task is dropped and no buffer ever reaches the placeholder. The new test works around it by polling up to 120 frames (offscreen-canvas-worker-placeholder-readback.html:29-46), which real pages do not do.

  Verification: PlaceholderRenderingContext.cpp:73-77 needsFrameBuffers() returns !m_delegate || m_frameBuffersRequested, so once the layer has a delegate setPlaceholderBuffer (lines 137-140) never clones the buffer. The synchronous read then returns m_buffer or createTransparentBlackImageBuffer() (line 330-333). If the worker was terminated, ScriptExecutionContext::postTaskTo (ScriptExecutionContext.cpp:838-849) drops the task.

• 🟣 Source/WebCore/page/cocoa/ContentChangeObserver.cpp:703 — pre-existing: on iOS, a tap after a tap handled as hover can still be misclassified; only one stale per-tap set is cleared. The hover path at WebPageCocoa.mm:3333 returns without stopContentObservation(). ContentChangeObserver.cpp:703 clears m_visibilityCandidateList but leaves m_initialElementVisibility and m_elementsWithDestroyedVisibleRenderer from the previous tap. An element hidden during tap 1 is ignored when tap 2 reveals it (ContentChangeObserver.cpp:519, :839), so tap 2 becomes a click instead of a hover. Fix: reset every per-tap set in resetToStartObserving, or call stopContentObservation on the hover path, so the next tap starts clean.

  Why this was flagged

  Tap 1 lands on a hidden element T (opacity 0) whose touchstart handler shows T and hides an open menu M with display:none. During touchstart ContentChangeObserver is observing, so rendererWillBeDestroyed adds M to m_elementsWithDestroyedVisibleRenderer (ContentChangeObserver.cpp:496) and elementDidBecomeHidden records M as initially Visible (:531). WebPage::handleSyntheticClick sees targetNodeWentFromHiddenToVisible and calls didHandleTapAsHover and returns (WebPageCocoa.mm:3333-3336) without stopContentObservation(), so reset() (:452-473) never runs. Tap 2 lands on a button whose touchstart shows M again. StartedTouchStartEventDispatching runs resetToStartObserving (:701-713), which now clears the candidate list but not the two other sets. StyleChangeScope for M then skips observation because visibleRendererWasDestroyed(M) is true (:839, :848), and even without that elementDidBecomeVisible would ignore M because its recorded initial state is Visible (:519-522). On the base branch the stale candidate T made tap 2 a hover; after this change the remaining stale sets make it a click, so the stale-state root cause is only partly fixed.

  Verification: WebPageCocoa.mm:3333-3336 returns before the stopContentObservation() at :3365. resetToStartObserving (ContentChangeObserver.cpp:701-713) now clears m_visibilityCandidateList (:703) but not m_initialElementVisibility or m_elementsWithDestroyedVisibleRenderer. When tap 2 reveals M, visibleRendererWasDestroyed(M) (:839) blocks tracking and :519 returns the stale Visible entry, so tap 2 completes as a click.

[sosukesuzuki]

On the review's two findings outside the diff (PlaceholderRenderingContext.cpp:140, 🔴, and ContentChangeObserver.cpp:703, 🟣): no change here for either.

Both files are upstream WebCore, identical to WebKit/WebKit at 33ce3bf11a71; they are in this pull request only because it merges upstream. This fork builds the JSCOnly port (ENABLE_WEBCORE is OFF in OptionsJSCOnly.cmake), so neither file is compiled into any lane or reaches Bun. A fix in the fork would only make these files differ from upstream for the next merge. If the OffscreenCanvas readback finding is real, it belongs on bugs.webkit.org.

---

Generated by Claude Code

[claude]

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

Beyond the inline finding, I also checked the new ARM64 tryEmitXorOrChainBranch lowering in Source/JavaScriptCore/b3/B3LowerToAir.cpp (around line 3021) for a comparison that is both a branch condition and used elsewhere being consumed without lowering — the Branch case only reaches it under canBeInternal(m_value->child(0)), and tryAppendXorOrChainCompare checks canBeInternal on the inner values, so a multi-use comparison falls back to the generic path.

Extended reasoning...

The diff is a very large sync of upstream changes (about 6500 files) rather than a focused change; the one confirmed finding is a pre-existing stale is8Bit issue in FTLLowerDFGToB3.cpp, and the one new concrete candidate in B3LowerToAir.cpp was ruled out by the canBeInternal guards at the call site and inside the chain matcher.

[sosukesuzuki]

The test job for bun-webkit-linux-amd64-lto failed at 70d3fedb with one test: stress/sampling-profiler-line-column.js.ftl-eager ("Bad stack trace": no sample landed inside test within its 50 s budget). The arm64 leg passed, and both legs passed at 5ac1583e.

This is an intermittent failure that the fork already has, not something this branch introduces. I ran the exact command from jsc-failures.log 1,600 times (16 at a time on 4 cores) against each of three Linux amd64 LTO builds:

build	failures
autobuild-274ebb3cf6008f627197d818e3939d1e2bfc514d (what Bun pins today, before this merge)	8 / 1600
autobuild-preview-pr-860-5ac1583e	8 / 1600
autobuild-preview-pr-860-70d3fedb	8 / 1600

Every failing run takes the full 50 s and ends the same way on all three: the traces that are left are either empty or only show samplingProfilerStackTraces called from the outer function once that function is running in FTL; a run that passes does so within about 20 ms, before tier-up. The test has no private names and borrows no Vector, so neither of the two commits added since 5ac1583e is on its path.

I have not root-caused the flake itself and am not changing or skipping the test in this PR. Re-running the failed job once.

---

Generated by Claude Code

[claude]

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

• 🔴 Source/WebCore/html/track/TrackBase.cpp:106 — Pages that reach a track through HTMLTrackElement.track can lose that TextTrack's JS listeners and expandos after a GC, which the base branch kept alive. TrackBase::opaqueRoot at TrackBase.cpp:101-106 now returns the HTMLMediaElement pointer (HTMLMediaElement.cpp:666), and that pointer is only added as an opaque root by JSHTMLMediaElementCustom.cpp:37 when the media element's own wrapper is marked. The base returned the element's shadow-including root (the Document), which is always marked while the page lives. Fix: make the root reachable whenever the media element is in a live document, e.g. have TrackOpaqueRoot hold the element's tree root and update it on insertion, removal and didMoveToNewDocument.

  Why this was flagged

  A page with <video><track src=...></video> runs document.querySelector('track').track.addEventListener('cuechange', fn) without ever touching the <video> element from script. TextTrack.idl:35 uses GenerateIsReachable, so JSTextTrack survives only while containsWebCoreOpaqueRoot(visitor, root(&wrapped())) is true, and root(TrackBase*) at TrackBase.h:151 returns TrackBase::opaqueRoot(). After TextTrackList::append calls setTrackList (TextTrackList.cpp:216, TrackBase.cpp:120-124) that root is HTMLMediaElement::m_trackOpaqueRoot's WebCoreOpaqueRoot { this } (HTMLMediaElement.cpp:666). Only JSHTMLMediaElement::visitAdditionalChildrenInGCThread (JSHTMLMediaElementCustom.cpp:37) and the GenerateAddOpaqueRoot wrappers of TextTrackList/TextTrack add that pointer, and none of those wrappers exist here, so the next GC collects the JSTextTrack wrapper; cuechange stops firing. On the base branch TrackListBase::opaqueRoot called the observer returning weakThis->opaqueRoot(), i.e. Node::opaqueRoot() at Node.h:314 (the Document), which every live node wrapper marks, so the TextTrack wrapper stayed alive.

  Verification: Source/WebCore/html/HTMLMediaElement.cpp:666 m_trackOpaqueRoot(TrackOpaqueRoot::create(WebCoreOpaqueRoot { this })): the shared root is now the raw HTMLMediaElement pointer. The only addWebCoreOpaqueRoot call site that adds that pointer is the new Source/WebCore/bindings/js/JSHTMLMediaElementCustom.cpp:37, which runs only when a JSHTMLMediaElement wrapper exists and is marked.

• 🔴 Source/WebCore/page/RuntimeQuirkTable.cpp:616 — PlayStation users lose every site-specific quirk after this merge, because the quirk table now comes only from QuirkTable.json and that port cannot read it. loadQuirkTable at RuntimeQuirkTable.cpp:609-616 returns an empty table when loadQuirkTableJSON() is null, and QuirkTablePlayStation.cpp:32-37 always returns null. The base resolved quirks from the compiled SiteSpecificQuirks::table on every port. Fix: when the JSON cannot be loaded, fall back to the compiled table (WTF::map(compiledQuirks(), RuntimeQuirk::from)) instead of an empty table, so ports without a runtime resource still get the shipped quirks; the FIXME(327589) notes the gap but the consequence is a silent loss of all quirks, not a missing feature.

  Why this was flagged

  On PlayStation, WebProcessPool.cpp:1108 fills parameters.quirkTable from quirkTable(), which calls QuirkTableHolder::table() -> loadQuirkTable() at RuntimeQuirkTable.cpp:609. loadQuirkTableJSON() at Source/WebCore/page/playstation/QuirkTablePlayStation.cpp:32-37 is notImplemented() and returns a null String, so loadQuirkTable logs "QuirkTable.json could not be loaded; no site-specific quirks will apply" and returns an empty RuntimeQuirkTable; WebProcess.cpp:804 installs that empty table. resolveSiteSpecificQuirks at QuirkTable.cpp:1265-1273 now iterates quirkTable().quirks, so no quirk ever applies. On the base branch the same function iterated compiledQuirkTable(), built from SiteSpecificQuirks::table via RuntimeQuirk::from, which is still compiled in (QuirkTable.cpp:1252 and compiledQuirks() at :1286) but is no longer consulted. Every behavior in QuirkTable.json (user-agent overrides, script injection, form-control focus quirks, etc.) stops working on that port, with only a release log as a hint.

  Verification: Triggering condition: any PlayStation build. loadQuirkTable() (RuntimeQuirkTable.cpp:609-622) on null JSON returns { }. loadQuirkTableJSON() for PlayStation (QuirkTablePlayStation.cpp:32-37) is always null. There is no fallback to compiledQuirks(). Many compiled rows have no .isAvailable restriction, so on the base they applied on PlayStation and after this merge they do not.

[sosukesuzuki]

On the two findings of the review of bc7aebee (Source/WebCore/html/track/TrackBase.cpp, the track opaque root, and Source/WebCore/page/RuntimeQuirkTable.cpp, the PlayStation quirk table): not changing either here, for the same reason as the earlier WebCore findings. Both files, and the ones the findings cite with them (HTMLMediaElement.cpp, JSHTMLMediaElementCustom.cpp, QuirkTablePlayStation.cpp), are byte-identical to upstream at 33ce3bf11a71, and no lane of this fork builds WebCore (the lanes are the JSCOnly port: JavaScriptCore, WTF and bmalloc). They are upstream's behaviour and would be upstream's to fix; a fork-only edit would just be a conflict in the next sync.

---

Generated by Claude Code

[claude]

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

• 🔴 Source/WebCore/dom/Document.cpp:10627 — Pages without a body element (SVG, XML, XHTML before body) now get null from document.activeElement where the base branch returned the document element. Document::activeElement at Document.cpp:10627 returns bodyOrFrameset() and drops the documentElement() fallback, so when no element is focused and there is no body the result is null. The HTML spec step 6 returns the document element in that case, and the diff turns the WPT svg/struct/scripted/autofocus-attribute.svg third case from PASS to FAIL with "TypeError: null is not an object (evaluating 'w.document.activeElement.tagName')". Fix: keep returning documentElement() when bodyOrFrameset() is null so every document with a root element reports a non-null activeElement.

  Why this was flagged

  A script reads document.activeElement in a document that has no body element and no focused element, for example the SVG window opened by LayoutTests/imported/w3c/web-platform-tests/svg/struct/scripted/autofocus-attribute.svg:39-52. Document::activeElement at Source/WebCore/dom/Document.cpp:10624-10627 returns treeScope().focusedElementInScope() if set, otherwise bodyOrFrameset(), which is null for an SVG root; the base branch fell back to documentElement() here. The caller now gets null and the test's w.document.activeElement.tagName throws; the diff records this at LayoutTests/imported/w3c/web-platform-tests/svg/struct/scripted/autofocus-attribute-expected.txt:4 as a new FAIL where the base had PASS. The test comment cites https://html.spec.whatwg.org/C/#dom-documentorshadowroot-activeelement step 6, which returns the document element when there is no body, so no other safeguard restores the old value.

  Verification: HEAD Source/WebCore/dom/Document.cpp:10624-10628 returns bodyOrFrameset() when no element is focused, which is null for an SVG root. The base commit 7d0c8a7 fell back to documentElement(), matching HTML spec step 6. The diff rebaselines LayoutTests/imported/w3c/web-platform-tests/svg/struct/scripted/autofocus-attribute-expected.txt from PASS to a null-dereference TypeError FAIL.

[sosukesuzuki]

On the finding of the review of 35cf4b1e (Source/WebCore/dom/Document.cpp, document.activeElement without a body): same answer as for the earlier WebCore findings. Document.cpp and the rebaselined expectation are byte-identical to upstream at 33ce3bf11a71, and no lane of this fork builds WebCore, so it is upstream's behaviour and not something to change in a sync.

---

Generated by Claude Code