Repository navigation
Conversation
… copy Bun's structured clone serializer in src/jsc/bindings/webcore/SerializedScriptValue.cpp is its own copy. It does not derive from the JSC clone base classes, so a WebKit upgrade does not update it. Add a checklist item that names the upstream files to read and tells the upgrader to port each behavior change by hand.
|
Status This is a docs-only change: one new item in the checklist of Checked on main (179664e) and on the pinned WebKit (oven-sh/WebKit@680ef47cec2c):
No open PR makes the same edit. #46623 (draft) appends a different item to the same list, and a test merge with this branch is clean. PR: #46773 |
|
Updated 1:08 PM PT - Oct 24th, 2026
✅ @robobun, your commit 84c0a775bbf694a3b8b50c1d977fe173cc176f92 passed in 🧪 To try this PR locally: bunx bun-pr 46773That installs a local version of the PR into your bun-46773 --bun |
|
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Structured-clone upgrade check .claude/commands/upgrade-webkit.md |
The checklist identifies JavaScriptCore and WebCore structured-clone files to check. It directs maintainers to port behavior changes to Bun’s SerializedScriptValue.cpp, which does not derive from the JSC clone base classes. |
Priority:
Merge Risk: 
Minimal · up to 84c0a
-
This documentation-only change is mergeable.
Pre-merge checks: 
4
-
Full details: Description check
-
Explanation
The pull request description is complete. It explains the problem, the fix, the scope, verification, and why no test is required for this documentation-only change. It does not use the exact template headings, but it provides the required information in equivalent sections.
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands.
There was a problem hiding this comment.
LGTM — a one-line addition to the WebKit upgrade checklist, no code change.
What was reviewed:
- Confirmed the in-tree claim: src/jsc/bindings/webcore/SerializedScriptValue.cpp defines its own CloneBase (line 621) with CloneSerializer/CloneDeserializer deriving from it (lines 714, 2252), and nothing under src/ includes a JSC clone header, so a merge does not update it.
- The upstream file list could not be confirmed from this checkout (vendor/WebKit is not populated); a wrong name there would only make the checklist item harder to follow, not affect the build.
- Placement next to the JSType.h item matches the existing pattern of hand-mirrored files.
Extended reasoning...
The diff adds one bullet to the "Things to check for a successful upgrade" list in .claude/commands/upgrade-webkit.md, a Claude slash-command prompt; no source, build, test, or CI files change. It touches no security-sensitive surface. The checkable factual claim (Bun's SerializedScriptValue.cpp has its own CloneBase hierarchy and does not include JSC's clone base headers) was verified against the current tree. The path is not covered by CODEOWNERS and the change is small and self-contained, which decided approve.
|
The review could not confirm the upstream file names, because
The pinned fork commit carries the same six files with the same blob hashes. Upstream's serializer and deserializer derive from the JSC base classes at |
Related to #45739
Problem
src/jsc/bindings/webcore/SerializedScriptValue.cppis Bun's own copy, with its ownCloneBase,CloneSerializerandCloneDeserializerclasses..claude/commands/upgrade-webkit.mddoes not mention this copy. An upstream change to the clone code stays unported until a user reports the difference.WebAssembly.Memoryon 2026-08-08 (WebKit/WebKit@3e351c7849f3). Bun's copy still hard-codesWasm::AddressType::I32(SerializedScriptValue.cpp:3779), and Shared WebAssembly.Memory with address: 'i64' (Memory64) is received as i32 memory in a worker_threads Worker #45739 reported it on 2026-10-17.Fix
JSType.hitem. Both items cover a Bun file that mirrors upstream source by hand.prettier --checkpasses on the file. The PR has no code change, so it has no test.Background
structuredClone()andpostMessage().CloneBase.h,CloneSerializerBase.h,CloneDeserializerBase.handStructuredCloneTags.h. WebCore'sSerializedScriptValue.cppderives its serializer from them.CloneSerializerBase.h:589andCloneDeserializerBase.h:719-725already handle Memory64.Behaviour change: none
Notes
WEBKIT_VERSIONis oven-sh/WebKit@680ef47cec2c. The latest upstream commit in it is f59345e04a8d. The six files below have the same blob hashes in both.Source/JavaScriptCore/runtime/CloneBase.h,CloneSerializerBase.h,CloneDeserializerBase.h,StructuredCloneTags.h,StructuredCloneTags.cpp, andSource/WebCore/bindings/js/SerializedScriptValue.cpp.SerializedScriptValue.cpp:487declaresclass CloneSerializer : public JSC::CloneSerializerBase<CloneSerializer>. Line 1790 does the same for the deserializer.class CloneBaseat line 621,CloneSerializer : public CloneBaseat line 714 andCloneDeserializer : public CloneBaseat line 2252. It has its ownenum SerializationTag(line 150) and its ownCurrentVersion = 14(line 426). No file undersrc/includes a JSC clone header.StructuredCloneTags.cppis in the item because upstream reads the fields of anErrorthere (extractErrorInformationFromErrorInstance). Bun's copy has its own code for that at lines 1172-1233.CloneSerializerBase.hon 2026-06-12 (WebKit/WebKit@177aa8b796d4). Nine upstream commits touch it up to the pinned commit.bun build --compile --aot#45631 carry the same version, which changes lines 20 and 22 only. build(android): pin NDK r30 together with the prebuilt WebKit #46623 appends a list item. To find them, I compared the blob of this file at the head of all 5753 open PRs with the six blobs the file has had on main.no test proof · iteration 0 · docs-only change; test-proof not applicable