Upgrade to upstream WebKit 6b58d86abe

[robobun]

Merges upstream WebKit main at 6b58d86abe (2026-09-13) into the fork: 216 commits since the previous merge base ccdcb8a026 (2026-09-09), 47 of them in JavaScriptCore, WTF, bmalloc, cmake or JSTests. The branch starts from the fork's main at 28f58fb055 (#634). The merge commit 89e6d367e7 has 6b58d86abe as its second parent.

The branch also contains the fork's main as of 299c532387 (2026-09-23), so GitHub can merge this PR as it is. The fork's main was merged in seven times so far, each time Bun's main moved its pin. The sections "Second merge", "Third merge" and "Later merges" below describe them. The fork's main moved to 35e8970dfd on 2026-09-24 (#718, the bytecode cache order file). Bun's main does not pin it yet, so the branch does not contain it yet. I checked that merge ahead of time on a local copy: no conflict, bun run jsc:build:debug builds with no error, and 6 JSTests pass, one of them bytecode-cache-persistent-payloads-are-released.js. #718 adds code to runtime/CachedBytecode.h and CachedBytecode.cpp next to the reconcileWeakReferencesAtGCEnd() edit of the second merge, and does not touch that function. So GitHub can still merge this PR as it is.

This PR contains every upstream commit of #623 (ccdcb8a026..50320fd3b3) plus 123 newer ones. If this PR merges, #623 is not needed.

Conflicts and how they were resolved

7 files conflicted.

• heap/FastMallocAlignedMemoryAllocator.cpp (b8d7e24add, the one that needs a decision). Upstream moves the MarkedBlock warm-up supply from JSC (WarmUpBlockProvider) into libpas (bmalloc_prefault_supply) and calls it only under USE(LIBPAS). The fork's release builds set USE_MIMALLOC=ON, so with upstream's file they get no prefaulted blocks at all. [JSC] WarmUpBlockProvider: start the helper thread after 64 block requests, not the first #553 measured that the helper makes an allocation-heavy script 19% faster on such a build. Resolution:
  • USE(LIBPAS) builds (the fork's debug and ASAN builds) use upstream's libpas supply.
  • Builds without libpas (mimalloc or system malloc) keep the JSC-side WarmUpBlockProvider as it is on the fork's main today. It sits under #else // !USE(LIBPAS). Its Phase enum moves into the class, because upstream removed it from the header.
  • The start threshold from [JSC] WarmUpBlockProvider: start the helper thread after 64 block requests, not the first #553 (warmUpMarkedBlockStartAfterBlocks, default 64) is now the free function isPastWarmUpStartThreshold(). Both paths test it before they touch the supply.
  • The new $vm functions work on both paths. Without libpas, warmUpMarkedBlocksAreEnabledForTesting() reports the option state and warmUpMarkedBlockCountForTesting() reads the provider's block count. JSTests/stress/warm-up-marked-blocks-state-machine.js is upstream's file, not changed. Its comment says that a build without libpas reports the supply as disabled. That is not true for the fork.
  • If you prefer upstream's behaviour (no supply on mimalloc builds), delete the #else block. Nothing else depends on it.
• runtime/JSBigInt.cpp (9e61914f4c). Upstream adds bounds hints to karatsubaStart() and divideSchoolbook(). The fork has the InterruptCheck plumbing in the same lines. Took upstream's RELEASE_ASSERTs, the window subspan and the overflow accumulator, and kept every interrupt check. The fork lets q omit its top digit when that digit is zero, so q = q.first(m + 1) became q.first(std::min(m + 1, q.size())), and the loop keeps the fork's RELEASE_ASSERT(!qhat) for the omitted digit.
• bytecode/CodeBlock.cpp (7189f73167). CodeBlock::inferredName() now returns UTF8CString. Kept the fork's inferredNameForTools() call and the USE(BUN_JSC_ADDITIONS) module name block, with upstream's _s literals. FunctionExecutable::inferredNameForTools() now returns UTF8CString too.
• runtime/WeakGCMap.h, runtime/WeakGCMapInlines.h (8ae0649a80). Include lines only. Kept the fork's quoted include style and dropped Weak.h and WeakInlines.h like upstream.
• wtf/URLParser.cpp (7bd7b6dfad) and wtf/UUID.cpp (74b519d7f9). Same one-line resolutions as in Upgrade to upstream WebKit 50320fd3b3 #623: upstream's legacyCStringPointer() log line with the fork's ASSERT (Make WTF::URLParser faster than Ada #452), and the fork's commented-out OS(DARWIN) branch of bootSessionUUIDString().

Second merge: the fork's main at c775a5dc52 (44 commits since 28f58fb055)

2 files conflicted.

• runtime/RegExp.cpp. Upstream e19f57a779 and the fork's d242f6dd4b make the same fix: RegExp::deleteCode() keeps m_atom and m_specificPattern. Kept the fork's comment. The code is the same on both sides.
• Source/cmake/WebKitCompilerFlags.cmake. Both sides add lines after list(APPEND ENABLED_COMPILER_SANITIZERS "-fsanitize=address"). Kept both: upstream's webkit_add_compile_definitions(__SANITIZE_ADDRESS__) and the fork's -fsanitize-address-use-after-return=never block (aa140ee23f).

2 pieces of new fork code use an API that upstream changed in this range. Git merges them without a conflict, and the tree does not compile until they change. Both edits are in the merge commit 6b1d0dff80.

• PersistentBytecodePayloads (runtime/CachedBytecode.h, from c6826dcbb1) is a WeakGCHashTable. Upstream 8ae0649a80 replaces the virtual pruneStaleEntries() with reconcileWeakReferencesAtGCEnd(VM&, CollectionScope). The override has the new name and the same body. It still runs only after a full collection, after reapWeakHandles(): Heap::reconcileWeakGCHashTables() visits every registered table in a full collection and only dirty tables in an eden collection, and this table never marks itself dirty. Its values stay Weak<UnlinkedFunctionExecutable>, which upstream did not change.
• The value profile briefDescription() in bytecode/MetadataTable.h (from 3aec93c668) returns UTF8CString and calls toUTF8CString(), like ValueProfile::briefDescription() after upstream 7189f73167.

Checked by reading, no edit needed: the new LLInt and common slow paths of the fork (slow_path_ensure_call_link_info, iterator_next_index_in_frame_*, slow_path_iterator_close_check, slow_path_new_reg_exp_shared) go through callSlowPath and the LLINT_* / CHECK_EXCEPTION macros. So they follow upstream's new exception convention from b9c0ed5b8c (LLInt::exceptionSignal() in the second result register). slow_path_ensure_call_link_info returns a CallLinkInfo* there, which is never all ones.

Third merge: the fork's main at c28156899e (5 commits since c775a5dc52)

1 file conflicted.

• runtime/JSModuleRecord.cpp. [JSC] Module linking: import slots without sorting; nothing resolved to compare records until there are two #665 makes the executables.set(...) call in getOrMakeExecutable() unconditional and still wraps the value in a Weak<>. This branch passes the raw pointer, because WeakGCMap::set() takes one since upstream 8ae0649a80. Result: executables.set(key, executable);. The reworked function reads the map only through get(), which returns a raw pointer or null as before.

No other code of these 5 commits uses an API that upstream changed in this range.

Later merges of the fork's main

None of these merges had a conflict. For each one I scanned the added lines of the fork commits for an API that upstream changed in this range (utf8(), toCString(), CString, WeakGCMap, dataLog() with a CString, String(std::span<const char>)), and found none. For each file with edits from both sides I read both sides. In every case the edits are in different functions or blocks.

Merge commit	Fork's main	Fork commits	Files with edits from both sides
a3b5a5cba9	000c489972	#684, #662, #346, #685, #688, #689	heap/Heap.cpp, heap/Heap.h, runtime/AbstractModuleRecord.cpp, runtime/VM.cpp, tools/JSDollarVM.cpp
6eafb22fb2	ebd5a6145b	#696	Source/cmake/WebKitCompilerFlags.cmake
65672fa42f	63a807e88c	#693, #677, #707	bytecode/CodeBlock.cpp, bytecode/CodeBlock.h, heap/Heap.cpp, runtime/JSModuleRecord.cpp, runtime/VM.cpp
90df1859d2	564ac2a6ca	#708, #676	heap/MarkedBlock.cpp
2ed8525752	299c532387	#712	runtime/FunctionExecutable.cpp

In runtime/FunctionExecutable.cpp, #712 adds visitSourceFetcher() to visitChildrenImpl(), and this branch changes the return type of the fork's inferredNameForTools() to UTF8CString. In runtime/JSModuleRecord.cpp, the executables.set(key, executable) line of the third merge is not touched by any later commit.

Fork-only code that needed an edit after the merge

• runtime/JSModuleRecord.cpp: moduleProgramExecutables() is a WeakGCMap. set() takes a raw pointer now (8ae0649a80), so the Weak<ModuleProgramExecutable>(...) wrapper is gone.
• builtins/BuiltinExecutables.cpp, ffi/FFIICStub.cpp, ffi/FFIInvokeThunk.cpp, runtime/AbstractModuleRecord.cpp: utf8().data() passed to a %s is now utf8().legacyCStringPointer(). data() returns const char8_t* since 00130dc2f3, which only caused -Wformat warnings here.

Checked and unchanged: runtime/JSType.h, .github/workflows, the release tarball names. Source/WebCore/bindings/scripts/CodeGeneratorJS.pm changes one line (RELEASE_ASSERT to RELEASE_ASSERT_WITH_UNQUALIFIED_FUNCTION_NAME in the generated verifyVTable), which does not affect Bun's bindings.

Verification

• bun run jsc:build:debug (Linux x64, Debug + ASAN, clang 21): builds, jsc runs. This configuration uses libpas, so it compiles the libpas path of FastMallocAlignedMemoryAllocator.cpp. The path without libpas was checked with -fsyntax-only on the same translation unit with USE_MIMALLOC=1. The preview build of this PR compiles it for real.
• JSTests/stress/warm-up-marked-blocks-state-machine.js passes 8 of 8 runs on that jsc, with the default start threshold and with --warmUpMarkedBlockStartAfterBlocks=1. The supply fills, drains when idle, fills again, survives the allocation failure and recovers.
• The JSTests files that upstream added or changed in the range pass: stress/weak-gc-map-keeps-live-values.js, stress/arraybuffer-grow-resize-huge-length.js, stress/multiply-negated-operand.js, stress/regexp-cached-result-one-character-atom-delete-all-code.js, wasm/gc/bulk-array-element-types.js.
• BigInt: 82 of 83 JSTests/stress files named bigint-*, big-int-division*, big-int-mul*, big-int-mod* pass, including the Karatsuba, Toom, Burnikel-Ziegler, Barrett and the 6 bigint-terminate-* files. The one failure is bigint-toLocaleString.js. It fails because my local jsc links the compressed ICU data without Bun's decompress hook, so every toLocaleString call fails in this setup.
• JSTests/modules: 107 of 115 pass, including the 5 module-loaders*.js files from [JSC] Additional module loaders per global object, sharing linked module code between them #522. The 8 failures fail with the same output on the jsc from the autobuild-cf1b36ec8703 debug-asan tarball. They compare error message text that the fork changes.
• A sample of 1075 JSTests/stress files (every file whose name matches weak, symbol, structure, dictionary, flatten, arraybuffer, resiz, json, mul, negat, finalization or gc, plus 500 random files): 1048 pass, 6 carry a //@ skip, 21 fail. Of the 21, 13 call toLocaleString or Intl (the ICU setup above), 5 fail the same way on the autobuild-cf1b36ec8703 jsc, and 3 run longer than 15 minutes on both.
• bun run build:local: Bun builds and links against this tree with the source edits in Upgrade WebKit to 6b58d86abe bun#42666 (67 lines in 25 files, nearly all utf8().data() to utf8().legacyCStringPointer()). bun-debug -p 42 prints 42. The Bun tests that touch the edited code pass on that build. Upgrade WebKit to 6b58d86abe bun#42666 lists them.
• The preview build of this PR (autobuild-preview-pr-651-3bec033f) built all 42 tarballs. bun bd against its debug-asan tarball builds, and the upgrade tests pass.

After the second merge (6b1d0dff80):

• bun run jsc:build:debug builds with no error and no new warning.
• CI of this PR at 6b1d0dff80 passed, all 48 jobs. It built the 42 tarballs (autobuild-preview-pr-651-6b1d0dff, same names as autobuild-c775a5dc52). Both Test jobs passed (bun-webkit-linux-amd64-lto and bun-webkit-linux-arm64-lto). Those lanes use mimalloc. So run-javascriptcore-tests ran on the path without libpas of FastMallocAlignedMemoryAllocator.cpp, with upstream's warm-up-marked-blocks-state-machine.js.
• The 125 JSTests files that the 44 fork commits add or change, plus the upstream files listed above, on the local debug + ASAN jsc: 121 pass, 7 carry a //@ skip, 3 fail, and none of the 3 is from the merge. intl-datetimeformat-default-timezone-change.js is the local ICU setup described above. wasm/stress/memory64-overflow.js ran into my 10 minute limit, and it takes 13 minutes on the autobuild-c775a5dc52 debug-asan jsc too. auxiliary-evacuation-with-concurrent-compiles.js fails only under load (8 copies at once: 3 of 8 fail here, 2 of 8 fail on the autobuild-c775a5dc52 jsc). Alone it passes 3 of 3 on both.
• bun run build:local: Bun's main at ee89bb8586 plus the edits of Upgrade WebKit to 6b58d86abe bun#42666 builds and links against this tree. The test files listed in Upgrade WebKit to 6b58d86abe bun#42666 pass on that build.
• For Bun, this tree behaves like the fork's main at c775a5dc52: the bytecode portability hashes are the ones of Evict code a parked process does not use: idle by allocation, module graph at 2 min, the executable's own pages and rebuildable bytecode at 10 min bun#42383, and test/cli/inspect/compile-bytecode-tooling.test.ts needs the change that Evict code a parked process does not use: idle by allocation, module graph at 2 min, the executable's own pages and rebuildable bytecode at 10 min bun#42383 makes for c03b1a9887 (a module's function declaration becomes a function object when its binding is first read).

After the third merge (269ab60de4):

• bun run jsc:build:debug with clang 23.1.1 (the fork and Bun moved to LLVM 23): builds with no error and no new warning.
• The 33 JSTests files that the 5 fork commits add or change (modules/import-slots-*.js, stress/module-loaders-share-released-code.js, stress/ftl-osr-exit-materialize-phantom-array-with-live-butterfly.js, wasm/modules/js-wasm-cycle-loaders.js), the 6 modules/module-loaders*.js files and the upstream files listed above: 41 of 41 pass on the local debug + ASAN jsc.
• bun run build:local: Bun's main at c6b7fcb5bb plus the edits of Upgrade WebKit to 6b58d86abe bun#42666 builds and links against this tree, and the test files listed in Upgrade WebKit to 6b58d86abe bun#42666 pass.
• CI of this PR at 269ab60de4: all 42 tarballs built (autobuild-preview-pr-651-269ab60d, same names as autobuild-c28156899e). All 48 jobs finished with no failure. Both Test jobs passed (bun-webkit-linux-amd64-lto and bun-webkit-linux-arm64-lto).

After each later merge (a3b5a5cba9, 6eafb22fb2, 65672fa42f, 90df1859d2, 2ed8525752) I ran the same checks, and all of them passed every time:

• bun run jsc:build:debug with clang 23: builds with no error. The same 16 warnings each time, all in code that this branch does not change (pas_thread_local_cache.c, CachedTypes.cpp, FFIConversions.cpp, RegExpCache.cpp).
• The JSTests files that the new fork commits add or change, plus a few upstream tests of this range each time (for example weak-gc-map-keeps-live-values.js, warm-up-marked-blocks-state-machine.js and arraybuffer-grow-resize-huge-length.js), on the local debug + ASAN jsc. My runner uses default options plus the first //@ options line, so the fork's CI is the stronger check.
• bun run build:local: Bun's main of that day plus the edits of Upgrade WebKit to 6b58d86abe bun#42666 builds and links against the tree, and the test files listed in Upgrade WebKit to 6b58d86abe bun#42666 pass. After 65672fa42f this includes bundler_bytecode_portable.test.ts with main's snapshot, so this branch encodes the same bytecode cache as the fork's main after [JSC] Bytecode cache: drop the payload damage checks and always-on options; link resolves each variable read once; inline one-byte varints #677 and [JSC] Bytecode cache: a payload records its size, and one shorter than that is a miss #707.
• CI of this PR: all 42 tarballs built with the same names as the release of the fork's main, all 48 jobs finished with no failure, and both Test jobs passed (bun-webkit-linux-amd64-lto and bun-webkit-linux-arm64-lto).

The latest run is at 2ed8525752: preview autobuild-preview-pr-651-2ed85257, Bun's main at 6d504dd983.

Upstream changes

Range: ccdcb8a026..6b58d86abe (216 upstream commits, 2026-09-09 to 2026-09-13, 47 touch JavaScriptCore, WTF, bmalloc, cmake or JSTests).

Not changed anywhere in the range: runtime/JSType.h, runtime/OptionsList.h, runtime/JSGlobalObject.h (so GlobalObjectMethodTable), runtime/VM.h, runtime/JSModuleLoader.*, builtins/, and every header in Source/JavaScriptCore/API. No JSC option is added, removed or given a new default. bytecode/BytecodeList.rb, generator/, runtime/CachedTypes.cpp and bytecode/UnlinkedCodeBlock.h are untouched, so the opcode layout and the bytecode cache format stay the same. The only inspector protocol edit is in Network.json (c4a7ebcc29). Each commit appears once, under the most specific heading that applies.

Needs an embedder-side change

Each entry says what a caller must change. Some entries need a check only, and say so.

• 74b519d7f9 WTF::String(std::span<const char>) is now private, next to String(const char*), because char carries no encoding. Callers name the encoding: String::fromLatin1(std::span<const char>) (new overload), String(std::span<const Latin1Character>), String::fromUTF8(...) or String(ASCIILiteral). In the same commit WTF::enumName() and WTF::enumTypeName() (wtf/EnumTraits.h) return ASCIILiteral. They returned std::span<const char> before, so callers now test isEmpty() and not empty(). https://bugs.webkit.org/show_bug.cgi?id=323650
• 7bd7b6dfad CString gains legacyCStringPointer(), which returns the same const char* as data(). Every upstream utf8().data() call site moves to it. CStringWithEncoding::characters() (the const char* accessor of UTF8CString and ASCIICString from 5f14e32e57) is renamed to legacyCStringPointer(). No type changes in this commit. It is the mechanical half of the retype of String::utf8(). The retype itself is 00130dc2f3, the next entry. https://bugs.webkit.org/show_bug.cgi?id=323722
• 00130dc2f3 String::utf8(), StringImpl::utf8(), StringView::utf8() and Identifier::utf8() now return UTF8CString. They returned CString before. UTF8CString is the alias CStringWithEncoding<char8_t> (alias in wtf/Forward.h, class in wtf/text/CString.h). The siblings are Latin1CString (Latin1Character) and ASCIICString (char). CStringWithEncoding is a final class that derives publicly from CString and adds no data member. It hides the CString accessors so that the character type carries the encoding. data() still exists, but for a UTF8CString it returns const char8_t*. span() and spanIncludingNullTerminator() return std::span<const char8_t>, and mutableSpan() returns std::span<char8_t>. legacyCStringPointer() returns the same address as const char*. It is the accessor for %s arguments and C functions, and Latin1CString does not have it. length(), isNull(), isEmpty(), hash() and toStdString() come from CString and do not change. A call such as s.utf8().data() that feeds a const char* parameter must become s.utf8().legacyCStringPointer(). The same applies to s.utf8().span().data(). For a std::span<const char>, write byteCast<char>(utf8.span()). A const void* parameter (fwrite, write) still accepts data(). The SAFE_PRINTF and SAFE_FPRINTF macros accept the UTF8CString itself. PrintStream has no overload for const char8_t*, so dataLog() must get the UTF8CString itself or the String. A UTF8CString converts implicitly to CString (derived to base). So CString c = s.utf8() still compiles and c.data() is const char*, but the encoding is lost. String gains an implicit constructor from const CStringWithEncoding<CharacterType>& that decodes by character type. CStringWithEncoding gains explicit constructors from const std::string& and from a null-terminated const CharacterType*. wtf/text/StringCommon.h gains unsafeSpan(const char8_t*). https://bugs.webkit.org/show_bug.cgi?id=323846
• 9b09294076 Upstream removes about 850 legacyCStringPointer() call sites where the destination already accepts a String. LOG with %s becomes LOG_WITH_STREAM, EXPECT_STREQ becomes EXPECT_EQ in tests, and dataLog() gets the String. Almost all edits are in WebCore, WebKit and TestWebKitAPI. In JSC and WTF the commit edits two lines. Options::dumpAllOptions() and the truncation path of printInternal(PrintStream&, const CString&) now print a String directly. No WTF or JSC function changes a parameter type or a return type. No caller edit is needed. https://bugs.webkit.org/show_bug.cgi?id=323859
• 7189f73167 StringPrintStream::toCString() is renamed to toUTF8CString() and returns UTF8CString. The function template WTF::toCString(...) is renamed to WTF::toUTF8CString(...) in the same way. The old names have no alias. printInternal(PrintStream&, const CString&) is now = delete, and the non-const CString& overload is removed. So out.print(cstring), dataLog(cstring) and dataLogLn(cstring) do not compile for an untyped CString. New overloads print const UTF8CString&, const ASCIICString& and const Latin1CString&. UTF-8 and ASCII bytes go through unchanged, and Latin-1 is transcoded to UTF-8. To replace out.print(someCString), keep the typed value (auto s = string.utf8(), toUTF8CString(...), string.ascii()) and print that. Or print the String or StringView itself, or pass cstring.data() as const char*. These bytecode helpers now return UTF8CString: CodeBlock::inferredName(), CodeBlock::sourceCodeForTools(), CodeBlock::sourceCodeOnOneLine(), InlineCallFrame::inferredName(), UnlinkedSourceCode::toUTF8(), reduceWhitespace(), ArrayProfile::briefDescription(), ValueProfile::briefDescription(), BytecodeDumper::registerName() and constantName(). These JIT and runtime helpers do the same: MacroAssemblerCodeRef::disassembly(), Compilation::disassembly(), ExceptionScope::unexpectedExceptionMessage(), Air::Special::name(), JITPlan::signpostMessage(), Wasm::Plan::signpostMessage(), DFG::nodeListDump(), nodeMapDump() and nodeValuePairListDump(). In WTF, sortedListDump(), sortedMapDump(), BackwardsGraph::dump(), SingleRootGraph::dump() and StringHashDumpContext::brief() return UTF8CString. Identifier::ascii() and StringHashDumpContext::getID() return ASCIICString, and Structure::dumpBrief() takes const ASCIICString&. PerfLog::log(), GdbJIT::log(), Profiler::Database::logEvent() and Profiler::Compilation::addDescription() take const UTF8CString&, and DFG::validate() takes a UTF8CString. As a side effect CodeBlock::inferredNameWithHash(), SamplingProfiler::reportTopBytecodes() and DebuggerCallFrame::functionName() no longer decode UTF-8 function names as Latin-1. https://bugs.webkit.org/show_bug.cgi?id=323960
• 25f7ce345a FileSystem::fileSystemRepresentation(const String&) returns UTF8CString. It returned CString before. A caller that passed .data() to open(), stat() or a similar C function must call .legacyCStringPointer(). On Windows the function now converts with CP_UTF8. It converted with CP_ACP (the active ANSI code page) before. The GLib functions currentExecutablePath(), currentExecutableName() and webkitTopLevelDirectory() also return UTF8CString, and Cocoa gains currentExecutableName(). createTemporaryFileInDirectory() (Cocoa only) returns std::pair<FileHandle, String>. wtf/StdLibExtras.h gains safeNSStringPrintfType() and the SAFE_WTFLOGALWAYS macro. CStringWithEncoding gains createNSString() for Objective-C++ code. The JSC callers (dumpJITMemory(), API/JSScript.mm) move to legacyCStringPointer(). https://bugs.webkit.org/show_bug.cgi?id=324034
• 8ae0649a80 WeakGCMap<Key, Value> now stores a raw Value* per entry. It stored a Weak<Value> before, which is a pointer to a separate WeakImpl that the heap reaps in each collection. ValueType is ValueArg*. So set(key, value) takes a raw pointer, and the ensureValue() functor returns a raw pointer. find()->value is a raw pointer with no .get(). isEmpty() is removed. pruneStaleEntries() is replaced by reconcileWeakReferencesAtGCEnd(VM&, CollectionScope). WeakGCMap.h no longer includes Weak.h, and WeakGCMapInlines.h no longer includes WeakInlines.h. A caller that wrote map.set(key, Weak<T>(cell)) must write map.set(key, cell). A file that got JSC::Weak through WeakGCMap.h must include <JavaScriptCore/Weak.h> itself. Old design: WeakBlock::reap cleared each Weak<> in every collection, and pruneStaleEntries() removed the cleared entries in full collections only. New design: Heap::runEndPhase() calls Heap::reconcileWeakGCHashTables(), and each table tests its values with Heap::isMarked(). A full collection visits every registered table and removes each entry whose value is null or not marked. An eden collection visits only the tables on the new list Heap::m_dirtyWeakGCHashTables. set() and ensureValue() put the map on that list through WeakGCHashTable::markDirty(VM&). In an eden collection the map only sets a dead value to null and does not rehash. get(), find(), contains() and ensureValue() treat the null entry as absent, and the next full collection removes it. A table that gained no entry since the last collection is skipped. All its values are old, and an eden collection cannot free them. WeakGCHashTable (runtime/WeakGCHashTable.h) now derives from BasicRawSentinelNode<WeakGCHashTable>. A subclass must override reconcileWeakReferencesAtGCEnd(VM&, CollectionScope) in place of pruneStaleEntries(). It must call markDirty(vm) when it adds an entry, if eden collections must visit it. Heap::unregisterWeakGCHashTable() also takes the table off the dirty list. WeakGCSet keeps Weak<> entries and removes them in full collections only, as before. https://bugs.webkit.org/show_bug.cgi?id=323958
• b8d7e24add The MarkedBlock warm-up (prefault) supply moves from JSC into libpas. The old code was WarmUpBlockProvider in heap/FastMallocAlignedMemoryAllocator.cpp. It ran a JSCWarmUp AutomaticThread that allocated blocks with tryFastCompactAlignedMalloc() and wrote one byte per page. It worked with every fastMalloc backend. The new code is bmalloc_prefault_supply.c and bmalloc_prefault_supply.h in libpas, and JSC calls it only under #if USE(LIBPAS). So upstream, a build whose fastMalloc is mimalloc or the system allocator gets no prefaulted blocks. In that build tryAllocateAlignedMemory() calls tryFastCompactAlignedMalloc() directly. With libpas, tryAllocateAlignedMemory() returns bmalloc_prefault_supply_try_allocate() for block-sized requests. The supply is a fixed array of at most 64 slots (BMALLOC_PREFAULT_SUPPLY_MAX_BLOCKS). Takers and the filler exchange slots with atomic operations and no lock. A mutex and a condition variable only wake or start the filler. The filler is a detached pthread. It allocates with bmalloc_try_allocate_with_alignment_inline() and touches pages with the new pas_page_malloc_populate(). After one idle interval with no demand it frees all blocks and exits, and a later take starts a new thread. The options useWarmUpMarkedBlocks (true), warmUpMarkedBlockCount (32) and warmUpMarkedBlockIdleTimeout (10 seconds) keep their names and defaults. JSC copies them once into bmalloc_prefault_supply_target and bmalloc_prefault_supply_idle_timeout_in_milliseconds. $vm.warmUpMarkedBlockState() is removed. $vm.warmUpMarkedBlocksAreEnabled() and $vm.warmUpMarkedBlockCount() replace it, and $vm.setWarmUpMarkedBlockAllocationShouldFail() stays. In C++, warmUpMarkedBlockStateForTesting(), WarmUpMarkedBlockPhase and WarmUpMarkedBlockState are removed. warmUpMarkedBlocksAreEnabledForTesting() and warmUpMarkedBlockCountForTesting() are added, and without libpas they return false and 0. pas_thread.h (the Windows pthread shim) gains include guards, PTHREAD_MUTEX_INITIALIZER, PTHREAD_COND_INITIALIZER, extern "C" and PAS_API exports. The new source file is listed in Source/bmalloc/CMakeLists.txt and Source/bmalloc/libpas/CMakeLists.txt. https://bugs.webkit.org/show_bug.cgi?id=323480
• 2aedf51ba6 WTF::UUID::emptyValue and UUID::deletedValue become private. The constructor UUID(HashTableEmptyValueType) becomes private too. Only HashTraits<UUID> and MarkableTraits<UUID> (now friends) can build the empty value. UUID(HashTableDeletedValueType) stays public. UUID(UInt128) now release-asserts that the value is not 0 (empty) and not 1 (deleted), so UUID { 0 } crashes. UUID(uint64_t high, uint64_t low) now rejects the empty value as well as the deleted value. Code that needs "no UUID" must use Markable<WTF::UUID> or std::optional<WTF::UUID>. createVersion4(), createVersion4Weak(), createVersion5(), parse(), parseVersion4() and toString() do not change. https://bugs.webkit.org/show_bug.cgi?id=323944
• a371ed3141 A caller can no longer construct a WTF::UUID from raw bits. UUID(std::span<const uint8_t, 16>) and UUID(UInt128) become private. UUID(std::span<const uint8_t>) and UUID(uint64_t, uint64_t) are removed. New factories replace them. static std::optional<UUID> tryCreate(std::span<const uint8_t>) returns std::nullopt if the size is not 16 or the value is reserved (0 or 1). static std::optional<UUID> tryCreate(uint64_t high, uint64_t low) does the same for two halves. static consteval UUID createConstant(uint64_t high, uint64_t low) is for hardcoded constants, and a reserved value is a compile error. The static UUID::isValid(uint64_t, uint64_t) is removed, and the member isValid() stays. The only raw constructor call in JSC (jscJITNamespace in jit/ExecutableAllocator.cpp, under HAVE(KDEBUG_H)) moves to createConstant(). The random, parse and string functions do not change. A caller that only uses createVersion4(), createVersion4UUIDString(), parse() or toString() needs no edit. https://bugs.webkit.org/show_bug.cgi?id=324032
• 2d4a4717af wtf/UUID.h gains the struct UUIDCanonicalForm (two uint64_t fields, high and low) and StringTypeAdapter<UUIDCanonicalForm>. The adapter holds the 8-4-4-4-12 lowercase hex layout. StringTypeAdapter<UUID> now derives from it and passes uuid.high() and uuid.low(). The output of makeString(uuid) does not change. The only new user is the FIDO AAGUID logging in WebKit. No caller edit is needed. https://bugs.webkit.org/show_bug.cgi?id=324075
• 6103d1b95a makeStringByJoining(std::span<const String>, const String& separator) is now makeString(interleave(strings, separator)). The old loop used StringBuilder::isEmpty() to detect the first element. So it dropped each separator that came before the first non-empty string. { "", "a" } joined with "\n" gave "a", and it now gives "\na". Null strings count as empty strings. Input with no empty or null element at the start gives the same result as before. An empty span still gives an empty string that is not null. A caller that relied on the dropped separators sees different output. https://bugs.webkit.org/show_bug.cgi?id=323919
• 4a94df6096 wtf/Assertions.h gains RELEASE_ASSERT_WITH_UNQUALIFIED_FUNCTION_NAME(assertion, ...) and CRASH_WITH_UNQUALIFIED_FUNCTION_NAME_AND_INFO(...). They work like RELEASE_ASSERT and CRASH_WITH_INFO, but they pass __func__ to WTFCrashWithInfo() and not WTF_PRETTY_FUNCTION. In a template, __PRETTY_FUNCTION__ holds the full instantiation, and those strings took much space in the C string table. Upstream measured a 43% smaller C string table in JavaScriptCore (macOS, release, no LTO). With ASSERT_ENABLED the new macro is a plain ASSERT. HashTable::validateKey(), the downcast<>() overloads in TypeCasts.h, Ref.h and RefPtr.h, and the vtable check that CodeGeneratorJS.pm emits now use it. Only the function name in the crash record changes. The new crash macro has its own #ifndef guard, like CRASH_WITH_INFO. No caller edit is needed. https://bugs.webkit.org/show_bug.cgi?id=322851
• 50c3a2fbf3 ASCIILiteral::isEmpty() is now constexpr. No caller edit is needed. https://bugs.webkit.org/show_bug.cgi?id=323911

Runtime and builtins

• 223bd0faee ArrayBuffer.prototype.resize and SharedArrayBuffer.prototype.grow now convert the new length with toIndex. The old code used ToIntegerOrInfinity and a cast to size_t, which was undefined for a value such as 1e20. A negative length or a length above 2^53 - 1 now throws RangeError before the detached check. So detached.resize(-1) throws RangeError where it threw TypeError before. https://bugs.webkit.org/show_bug.cgi?id=323440 https://bugs.webkit.org/show_bug.cgi?id=323441
• c194b75cde speculationFromString() (bytecode/SpeculatedType.h, used by the @idWithProfile bytecode intrinsic) now takes a StringView and looks the name up in a SortedArrayMap. The old code took a const char* and ran a chain of strncmp prefix tests. An unknown name still hits a RELEASE_ASSERT. The rest of the commit is review follow-up for 7bd7b6dfad in the Wasm debugger tests. https://bugs.webkit.org/show_bug.cgi?id=323841
• 9e61914f4c runtime/JSBigInt.cpp moves bounds checks out of inner loops, so that the hardened std::span checks do not emit a trap inside the loop. karatsubaStart(), divideSchoolbook(), spanCopy(), leftShift(), rightShift(), cachedModMakeInverse(), toStringGeneric() and truncateToNBits() get one RELEASE_ASSERT or one subspan up front. divideSchoolbook() now works on a window of n + 1 digits per quotient digit. JSBigInt::createFrom(JSGlobalObject*, double) turns two exponent ASSERTs into one RELEASE_ASSERT. Results do not change. The change is for speed only and follows 320745@main. https://bugs.webkit.org/show_bug.cgi?id=323899

Garbage collector and heap

• f6b9f5b24d Structure::flattenDictionaryStructure() could deadlock against the collector. When it flattens an uncacheable dictionary and the out-of-line capacity shrinks, it holds the cell lock of the object (JSCellLock). It then took m_lock with a GCSafeConcurrentJSLocker, which contains a DeferGC. That locker is destroyed before the cell lock is released. So a deferred collection could start while the mutator still held the cell lock. The collector takes the same cell lock to scan an ArrayStorage butterfly, and never gets it. The fix puts one DeferGC before the cell locker, so the collection runs after both locks are released. m_lock is now taken with a plain ConcurrentJSLocker, and JSObject::shiftButterflyAfterFlattening() takes const ConcurrentJSLocker&. A program can hit this when it flattens such an object while a collection is due. Upstream calls it extremely rare. https://bugs.webkit.org/show_bug.cgi?id=323913

RegExp (Yarr)

• e19f57a779 RegExp::deleteCode() no longer clears m_atom and m_specificPattern. They depend only on the pattern, like m_numSubpatterns. RegExpCachedResult::lastResult() reads RegExp::atom() to reify the position of a cached one-character global match. After VM::deleteAllCode() cleared the atom, it searched for U+0000. So RegExp.leftContext, RegExp.rightContext and RegExp.lastMatch could be wrong, and a debug build asserted. Bun calls deleteAllCode on hot reload and when a debugger attaches. https://bugs.webkit.org/show_bug.cgi?id=323838

JIT (B3, Air, DFG, FTL, LLInt)

• 41ec81351b B3 LowerToAir matches Mul(Neg(n), m) and Mul(n, Neg(m)) and emits one MultiplyNeg (ARM64 MNEG / FNMUL) when the Neg has no other user. This is the shape -n * m parses to. The floating point form emitted fneg plus fmul before. Upstream measured about 1.5x on the mul-negated-operand-chain microbenchmark. x86_64 has no such instruction form and sees no change. https://bugs.webkit.org/show_bug.cgi?id=323150
• 5e03b0c541 Air::allocateStackByGraphColoring no longer walks every instruction in each liveness pass. One forward pass collects the stack slot mentions, the dead store candidates and the coalescable moves into a flat array per block (StackSlotActions). The liveness fixpoint and the interference build then step over these actions only. Upstream measured that about 7% of the instructions in a large sqlite3 Wasm function touch a spill slot. The phase now takes about half the time. The allocation result is the same. The WTF::Liveness adapter contract (wtf/Liveness.h) gains ActionGroup, forEachActionGroupDescending(), forEachUseInGroup(), forEachDefInGroup() and forEachUseAtTail(). Liveness gains the public Workset, makeWorkset() and copyLiveAtTailInto(). Air::StackSlotLivenessAdapter and the Air::StackSlotLiveness typedef leave AirLivenessAdapter.h and AirLiveness.h and become private to the phase. This is compile time only, for the B3 clients (FTL and Wasm OMG). https://bugs.webkit.org/show_bug.cgi?id=323526
• b9c0ed5b8c LLInt slow paths change how they report a pending exception to the 64-bit interpreter. A slow path that throws still sets pc to the returnToThrow() sentinel. It now also returns the new LLInt::exceptionSignal() (all ones) in the second result register. It returned nullptr (LLIntSlowPaths.cpp) or the call frame (CommonSlowPaths.cpp) there before. restoreStateAfterCCall() in LowLevelInterpreter64.asm tests r1 for -1 and jumps to _llint_throw_from_slow_path_trampoline. The old code always rebuilt PC as r0 - PB and dispatched to the sentinel instruction. The sentinel lives in a different allocation from the instructions of the CodeBlock, so the two pointers have different MTE tags. On architectures with CPA2 support, the PC rebuild from these two pointers fails. LLINT_THROW, LLINT_CHECK_EXCEPTION, THROW and CHECK_EXCEPTION use the new convention. slow_path_handle_exception keeps the old return value, because the throw trampoline calls it. The prologue stack check tests r1 before it rebuilds PC. The two checkpoint OSR exit trampolines and the array sort comparator trampoline call branchIfException first. They then use the new macro restoreStateAfterCCallWithoutExceptionCheck(). The new path is active on every 64-bit LLInt build, not only on MTE hardware. Opcodes and bytecode layout do not change. https://bugs.webkit.org/show_bug.cgi?id=323984

WebAssembly

• 0d81375a0f JSWebAssemblyArray::fill of reference elements stores through the new gcSafeMemfill() (heap/GCMemoryOperations.h, next to gcSafeZeroMemory) and then runs one write barrier, like array.copy. The old loop of plain stores could be lowered to sub-8-byte writes, and the concurrent marker could read a torn value. https://bugs.webkit.org/show_bug.cgi?id=323628
• 0a09c02240 operationWasmArrayFillRefs (called from BBQ and OMG code) also uses gcSafeMemfill(). It used a loop of volatile uint64_t stores before, which was already safe against the concurrent marker. On x86_64 and ARM64, gcSafeMemfill() uses vector stores for the bulk and 8-byte stores for the tail. The JSWebAssemblyArray constructor keeps std::ranges::fill, because the cell is not visible to the marker before finishCreation. https://bugs.webkit.org/show_bug.cgi?id=323865
• 92a274ec73 The Wasm debugger BreakpointManager stores Ref<Breakpoint> in its map and returns RefPtr<Breakpoint>, so a breakpoint pointer no longer goes stale when the map rehashes. Breakpoint becomes ThreadSafeRefCounted. Debugger only. https://bugs.webkit.org/show_bug.cgi?id=323910
• e00002d2d8 Wasm debugger in IPInt. A breakpoint replaces the first byte of an instruction with unreachable. On resume the interpreter read the byte at PC again. So a resume with the patch still in place trapped at the same PC without end. handle_debugger_trap_if_needed now returns the displaced opcode (Wasm::OpType), and the new asm macro dispatchIPIntOpcode() dispatches it. It returned a boolean shouldThrow before. A return value of 0 (Unreachable) throws the trap, which is also the result when the debugger is off. BreakpointManager now keys breakpoints by physical PC and counts references to the patch. A z0 packet for an address with no site replies OK and no longer hits a RELEASE_ASSERT. Debugger only (ENABLE(WEBASSEMBLY_DEBUGGER) and Options::enableWasmDebugger()). https://bugs.webkit.org/show_bug.cgi?id=323845
• c3a249e707 The Wasm debugger now puts the instance ID, and not the module ID, in both halves of its 64-bit virtual address (wasm/debugger/WasmVirtualAddress.h). Each live instance gets its own library entry (<name>@<id>), module image and linear memory region in LLDB. IDs are never reused, and encode() release-asserts instanceId <= MAX_ID (30 bits). A breakpoint site belongs to one instance. A sibling instance that reaches the same patched byte resumes through it and reports no stop. Wasm::Module no longer registers itself with DebugServer. trackModule(), untrackModule(), Module::debugId() and Module::setDebugId() are removed. Debugger only. https://bugs.webkit.org/show_bug.cgi?id=323479

Inspector and debugger

• c4a7ebcc29 Network.setEmulatedConditions changes its parameters. The optional integer bytesPerSecondLimit is renamed to bandwidth (bytes per second). A new optional integer latency adds a round-trip delay in milliseconds to each request. No command, event or type is added. The command stays behind ENABLE_INSPECTOR_NETWORK_THROTTLING, and wtf/PlatformEnableCocoa.h now sets that flag to 1 (it was 0). Only that Cocoa header defines the flag, so other ports do not generate the command. The implementation is a throttle in the WebKit network process, outside JSC. A backend that implements Network.setEmulatedConditions itself must read the new parameter names. https://bugs.webkit.org/show_bug.cgi?id=287737

WTF and bmalloc

• 86f52ba2f2 libpas: pas_runtime_config::enabled (MTE enablement, a bool where 0 meant either "not initialized" or "off") becomes the tri-state mte_state. pas_mte_is_mte_enabled() is now an inlineable relaxed load. It falls back to the renamed pas_mte_is_mte_enabled_slow() only when the state is not initialized. By default MTE is compiled in only with the Apple internal SDK on arm64e. https://bugs.webkit.org/show_bug.cgi?id=323820
• 50320fd3b3 wtf/MathExtras.h gains absoluteValueAsUnsigned(), an abs that is defined for the most negative value of a signed type. The only adopter is WebCore. https://bugs.webkit.org/show_bug.cgi?id=257369
• 00991b6cdc wtf/text/CString.h includes <objc/objc.h> and <wtf/RetainPtr.h> under __OBJC__. 25f7ce345a added CStringWithEncoding::createNSString() without them. This affects Objective-C++ translation units only. https://bugs.webkit.org/show_bug.cgi?id=324080

Build system and platform

• b1865b2d63 Swift compiler flags for CMake move from OptionsCocoa.cmake and WebKitMacros.cmake into a new Source/cmake/WebKitSwiftFlags.cmake and are aligned with the Xcode build. Swift targets only. https://bugs.webkit.org/show_bug.cgi?id=322750
• bc5bc3c2d6 WebKitMacros.cmake normalizes MSVC-style /D definitions to -D when it forwards them to the Swift clang importer on Windows. Swift targets only. https://bugs.webkit.org/show_bug.cgi?id=323791
• 9bf932afff 62f9b5cd08 67f2974594 The first commit makes the CMake Cocoa ports build a WebKit that can be installed on a device. It adds dylibs for libwebrtc and ANGLE, XPC service bundles, entitlements and daemons. The second commit reverts it because it broke the CMake macOS build. The third commit lands it again. In Source/cmake it adds WEBKIT_SDK_IS_IOS and WEBKIT_SDK_IS_XROS to WebKitXcodeSDK.cmake. In OptionsCocoa.cmake it keeps ENABLE_AV1 on for iOS and visionOS. Cocoa ports only, no effect on PORT=JSCOnly. https://bugs.webkit.org/show_bug.cgi?id=323218 https://bugs.webkit.org/show_bug.cgi?id=323942
• c991f535a7 With USE_APPLE_INTERNAL_SDK, the Swift clang importer gets -I${WebKitAdditions_FRAMEWORK_HEADERS_DIR} and depends on WebKitAdditions_CopyHeaders (WebKitMacros.cmake, WebKitSwiftFlags.cmake). Swift targets only. https://bugs.webkit.org/show_bug.cgi?id=323959
• bd3aa163c8 OptionsGTK.cmake turns the WebDriver keyboard, mouse and wheel interaction options on by default, also when ENABLE_WEBDRIVER is off. GTK port only. https://bugs.webkit.org/show_bug.cgi?id=318171
• a761c97f80 The top-level CMakeLists.txt queries swiftc -print-target-info once through the new WEBKIT_QUERY_SWIFT_TARGET_INFO() (WebKitMacros.cmake). On Windows it writes the Swift runtime directory to swift-runtime-bin-directory.txt in the build directory. All of this is inside if (SWIFT_REQUIRED). One line runs without Swift: on WIN32, configure removes that file from the build directory with file(REMOVE). https://bugs.webkit.org/show_bug.cgi?id=323228
• ed458bb584 OptionsGTK.cmake and OptionsWPE.cmake require libpng 1.5.0 (find_package(PNG 1.5.0 REQUIRED)). GTK and WPE ports only. https://bugs.webkit.org/show_bug.cgi?id=323961
• 060527786c OptionsCocoa.cmake drops the block from 67f2974594 that turned ENABLE_AV1 off for tvOS and watchOS. It broke the link of the iOS simulator build. Cocoa ports only. https://bugs.webkit.org/show_bug.cgi?id=324000
• f45cdb1e65 The CMake option DEVELOPER_MODE_FATAL_WARNINGS is removed. WebKitCompilerFlags.cmake now sets the standard variable CMAKE_COMPILE_WARNING_AS_ERROR to ON when DEVELOPER_MODE is on and the variable is not defined. The old code prepended -Werror or /WX to the global compiler flags. Since 320261@main that flag was not applied in the GTK and WPE builds. The new variable applies to targets and not to compiler feature probes. A build that passed -DDEVELOPER_MODE_FATAL_WARNINGS=OFF must now pass -DCMAKE_COMPILE_WARNING_AS_ERROR=OFF. A build without DEVELOPER_MODE sees no change. The commit also wraps pas_mte_is_mte_enabled_unchecked() (pas_mte_config.c, added by 86f52ba2f2) in #if PAS_ENABLE_MTE || PAS_OS(DARWIN). That removes an unused function warning from libpas builds on other systems. The Swift warning groups NoUsage and NoUseUnstructuredThrowingTask are now fatal only with Swift 6.4 or later. https://bugs.webkit.org/show_bug.cgi?id=323574

WebCore-only or no effect on JSC embedders

• 1455983c9d wtf/PlatformHave.h defines HAVE_AVPLAYER_DISCONNECTEDFROMSYSTEMAUDIO for the iOS family 27.0 SDKs. https://bugs.webkit.org/show_bug.cgi?id=323772
• 8eb608658b UnifiedWebPreferences.yaml gains a WebRTC DNS preference. No JSC effect. https://bugs.webkit.org/show_bug.cgi?id=323606
• c0bc25fc16 wtf/PlatformHave.h defines HAVE_UIKIT_PRINTING for the iOS family except watchOS and tvOS. The users are in WebKit. https://bugs.webkit.org/show_bug.cgi?id=323918
• c1228445a4 Follow-up to c0bc25fc16: HAVE_UIKIT_PRINTING now excludes tvOS only. https://bugs.webkit.org/show_bug.cgi?id=323987
• 944f82d72a UnifiedWebPreferences.yaml marks LocalNetworkAccessEnabled as sharedPreferenceForWebProcess. The Local Network Access check itself is in WebCore and WebKit. No JSC effect. https://bugs.webkit.org/show_bug.cgi?id=319907

The other 169 commits in the range touch WebCore, WebKit, WebGPU, LayoutTests or tooling only.

[github-actions]

Preview build of 2ed8525: autobuild-preview-pr-651-2ed85257

[claude]

Code review found no issues

No high-confidence issues detected in this change.

[claude]

Code review found no issues

No high-confidence issues detected in this change.

[claude]

Code review found no issues

No high-confidence issues detected in this change.

[claude]

Code review found no issues

No high-confidence issues detected in this change.

[claude]

Code review found no issues

No high-confidence issues detected in this change.

[claude]

Code review found no issues

No high-confidence issues detected in this change.

[claude]

Code review found no issues

No high-confidence issues detected in this change.

[claude]

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

[claude]

🔴 The network process can use freed memory when a throttled response is cancelled from inside a data callback, which the base branch never does. ConditionEmulator::timerFired delivers queued chunks in a loop and calls client->didReceiveBuffer(chunk) at NetworkLoad.cpp:206; if the client cancels or drops the NetworkLoad synchronously, NetworkLoad::cancel() (NetworkLoad.cpp:318) deletes the emulator while its timerFired is still on the stack, and the loop then reads m_data on freed memory. Fix: make timerFired survive deletion of the emulator during didReceiveBuffer on every path (cancel() and NetworkLoad destruction), e.g. detect it after the call with a WeakPtr/CheckedPtr to self and return, or deliver from a local copy of the queue.

Why this was flagged

Web Inspector sets a bandwidth limit (Network.setEmulatedConditions), so NetworkLoad::didReceiveData queues bytes in ConditionEmulator::m_data and delivery happens from ConditionEmulator::timerFired (NetworkLoad.cpp:171-214). Inside the while loop at NetworkLoad.cpp:189 the emulator calls client->didReceiveBuffer(chunk) at line 206. Two NetworkLoadClients cancel the load synchronously from that callback: QualifiedServerTrustFetch::didReceiveBuffer (QualifiedServerTrustFetch.cpp:104-108) calls cancel(), which runs m_networkLoad->cancel() (QualifiedServerTrustFetch.cpp:143-146) once more than 10 MB has been buffered; on Cocoa NetworkResourceLoader::didReceiveBuffer (NetworkResourceLoader.cpp:1350-1354) calls failDueToExcessiveDeferredMessages(), which runs networkLoad->cancel() (NetworkResourceLoader.cpp:1973-1974) and then didFailLoading -> cleanup(), which drops m_networkLoad (NetworkResourceLoader.cpp:652) and so destroys the NetworkLoad and its unique_ptr. NetworkLoad::cancel() sets m_conditionEmulator = nullptr (NetworkLoad.cpp:318), deleting the emulator whose…

Verification: normal — triggers when Web Inspector has set a session-wide bandwidth limit (NetworkSession::setEmulatedConditions, NetworkSession.h:290 is per-session so every NetworkLoad in the session gets an emulator) and a NetworkLoadClient cancels the load synchronously from didReceiveBuffer. Mechanism verified in /home/claude/webkit/Source/WebKit/NetworkProcess/NetworkLoad.cpp (new in this PR; base has…

[claude]

🔴 Changing emulated latency while loads are in flight now resumes tasks that are already running or still queued in the scheduler, which the base branch never did. NetworkLoad::emulatedConditionsDidChange creates a fresh emulator via tryCreate at NetworkLoad.cpp:559 with no knowledge of whether the task was already resumed; with latency > 0 it enters WaitingForLatency and timerFired calls task->resume() again. NetworkDataTaskSoup::resume and NetworkDataTaskCurl::resume assert m_state != State::Running, and a load still pending in NetworkLoadScheduler is started before the scheduler releases it and then resumed a second time from start(). … [also at: Source/WebKit/NetworkProcess/NetworkLoad.cpp:560 - Turning on latency emulation in Web Inspector while a blob: URL load is streaming makes the network process resume that load a second time, which restarts the blob read and sends a second response mid-body.]

Why this was flagged

…Fix: only arm the latency phase for a task that has not been resumed yet (track it in NetworkLoad and create the emulator in State::None otherwise), so both already-started and scheduler-queued loads are covered.

Network.setEmulatedConditions with a positive latency reaches NetworkSession::setEmulatedConditions (NetworkSession.cpp:816-824), which calls task.notifyEmulatedConditionsChanged() for every task in m_dataTaskSet; NetworkDataTask registers itself there in its constructor (NetworkDataTask.cpp:106), before NetworkLoad::start() or the scheduler ever ran. NetworkDataTask::notifyEmulatedConditionsChanged (NetworkDataTask.cpp:120-124) calls NetworkLoad::emulatedConditionsDidChange (NetworkLoad.cpp:554-560). A load that had no conditions when it started has no emulator, so the else branch calls ConditionEmulator::tryCreate (NetworkLoad.cpp:64-77), which sets State::WaitingForLatency and starts the timer; timerFired (NetworkLoad.cpp:176-181) then calls task->resume()…

Verification: normal — triggers when Web Inspector's Network.setEmulatedConditions with latency > 0 arrives while a NetworkLoad exists whose task has not yet been (or has already been) resumed by NetworkLoad::start(). Mechanism verified: NetworkSession::setEmulatedConditions (Source/WebKit/NetworkProcess/NetworkSession.cpp:816-824) calls notifyEmulatedConditionsChanged() on every task in m_dataTaskSet (tasks…

[claude]

🔴 Web Inspector users inspecting an iOS 16.4-17.4 or macOS 13.3-14.4 backend can no longer apply or clear network throttling; the command is rejected client-side with a Protocol Error. NetworkManager.js:1574 always passes two positional arguments, but those legacy backends register Network.setEmulatedConditions with the single parameter bytesPerSecondLimit, so InspectorBackend treats the latency value as a bad callback argument and never sends the command. Fix: gate on target.hasCommand("Network.setEmulatedConditions", "latency") and fall back to a one-argument call for older backends, and fill in the real versions in the COMPATIBILITY comment at NetworkManager.js:1570 instead of the "macOS X.Y, iOS X.Y" placeholder.

Why this was flagged

Trigger: the experimentalEnableNetworkEmulatedCondition setting is on and the frontend connects to a backend whose legacy command table is Protocol/Legacy/iOS/16.4, 17.0, 17.2 or 17.4 or Protocol/Legacy/macOS/13.3, 14.0, 14.2 or 14.4; each registers Network.setEmulatedConditions with only [{"name": "bytesPerSecondLimit", "type": "number", "optional": true}] (e.g. Legacy/iOS/17.4/InspectorBackendCommands.js:401). _applyEmulatedCondition checks only that the command exists (NetworkManager.js:1571) and calls setEmulatedConditions(bandwidth, latency) (NetworkManager.js:1574). InspectorBackend._invokeWithArguments consumes one argument for the single signature entry and then, with one number left over, returns deliverFailure("Protocol Error: Optional callback argument for command ... must be a function but its type is 'number'") (InspectorBackend.js:509-524); this also happens for the None preset because latency is 0, not undefined. The base branch sent setEmulatedConditions(bytesPerSecondLimit) with one argument, which matched those backends. Backends from 18.0 on omit the…

Verification: normal — when the experimental network-throttling setting is enabled and the frontend is loaded with one of the shipped legacy command tables (Protocol/Legacy/iOS/16.4, 17.0, 17.2, 17.4 or macOS/13.3, 14.0, 14.2, 14.4). Mechanism verified: /home/claude/webkit/Source/WebInspectorUI/UserInterface/Controllers/NetworkManager.js:1571-1574 only checks… | normal — triggers when the experimental "Allow…

[claude]

🔴 With bandwidth throttling on, a multipart/x-mixed-replace stream (e.g. an MJPEG camera page) gets the tail of one part attributed to the next part, because responses bypass the throttling queue. Body chunks are held in m_data at NetworkLoad.cpp:103 and released later by timerFired, but NetworkLoad::didReceiveResponse at NetworkLoad.cpp:476-512 hands each new part's response to the client immediately. Fix: preserve delivery order under emulation by queueing didReceiveResponse (and its completion handler) behind pending data in the emulator, or flushing queued data before a subsequent response is delivered.

Why this was flagged

Trigger: NetworkSession emulated bandwidth set and a response that NSURLSession delivers as several didReceiveResponse callbacks, i.e. multipart/x-mixed-replace. Data for part N is appended to m_data in ConditionEmulator::didReceiveData (NetworkLoad.cpp:103) and delivered at most bandwidth * 50 ms per tick (NetworkLoad.cpp:57, 189-206). When part N+1 headers arrive, NetworkDataTaskCocoa::didReceiveResponse (NetworkDataTaskCocoa.mm:451-465) -> NetworkLoad::didReceiveResponse -> notifyDidReceiveResponse calls client->didReceiveResponse right away (NetworkLoad.cpp:512), with no emulator hook. NetworkResourceLoader::didReceiveResponse then resets m_bufferedData for multipart (NetworkResourceLoader.cpp:1154-1155) and on Cocoa sets m_isProcessingResponse (NetworkResourceLoader.cpp:1095) so the leftover part-N bytes later released by timerFired are deferred and sent after part N+1's response, i.e. prepended to part N+1's body. On the base branch throttling was done inside CFNetwork via _bytesPerSecondLimit so callbacks stayed in order.

Verification: nit — triggered when Web Inspector bandwidth throttling is on (NetworkSession::setEmulatedConditions, Source/WebKit/NetworkProcess/NetworkSession.cpp:816-823) and the load is a multipart/x-mixed-replace response, for which NSURLSession invokes URLSession:dataTask:didReceiveResponse: once per part (Source/WebKit/NetworkProcess/cocoa/NetworkSessionCocoa.mm:864-905; WebKit itself documents this at…

[claude]

🟡 nit (optional): Authors animating an SVG element's class with SMIL now see [class~="x"] rules toggle with the animated class list, which the base branch never did. isEquivalentToClassSelector() marks the selector so SelectorChecker.cpp:817 and SelectorCompiler.cpp:1637 test element->hasClassName() instead of the class attribute. For SVG, SVGElement.cpp:1094-1095 refills classNames() from the animated className() while the attribute keeps the base value, so the two are not equivalent there. Fix: keep the attribute path (or skip the flag) when the element is an SVGElement, or when the sheet can apply to SVG content, so attribute selectors keep matching the base attribute value like every other [attr~=] selector.

Why this was flagged

Trigger: a standards-mode document containing <svg><rect class="a"><animate attributeName="class" to="b" dur="1s" fill="freeze"/></rect></svg> and a rule rect[class~="b"] { fill: red }. CSSSelectorParser.cpp:840 marks that selector with setIsEquivalentToClassSelector() because it is a Match::List on HTMLNames::classAttr in HTMLStandardMode (CSSSelectorParser.cpp:776-799). During the animation SVGElement::svgAttributeChanged calls classAttributeChanged(className(), ...) at SVGElement.cpp:1094-1095, so ElementData::classNames() holds the animated list {b} while the DOM class attribute still holds the base value "a" (SVG synchronizes base values only). SelectorChecker::checkOne at SelectorChecker.cpp:817-820 (and the JIT fragment at SelectorCompiler.cpp:1637-1641, RuleSet bucket at RuleSet.cpp:220) now answers element->hasClassName("b") == true, so the rule applies and the rect turns red; RuleFeature.cpp:350 also routes the rule through class-change invalidation so the change is rendered. On the base branch Match::List compared the attribute value "a" and the rule…

Verification: nit — triggers when an SVG element's class attribute is animated by SMIL (<animate>/<set attributeName="class">) in a standards-mode document and a stylesheet or querySelector uses [class~="x"]. Mechanism verified: Source/WebCore/css/parser/CSSSelectorParser.cpp:776-799 (isEquivalentToClassSelector) marks any Match::List selector on HTMLNames::classAttr in HTMLStandardMode,…

[claude]

🟣 pre-existing, not blocking: Pre-existing: terminating a VM (worker.terminate) during a large BigInt % crashes the process on a RELEASE_ASSERT instead of unwinding with the TerminationException. When InterruptCheck breaks the row loop in divideSchoolbook (JSBigInt.cpp:3127), uSpan still holds unreduced digits, and rightShift(r, uSpan, shift) at JSBigInt.cpp:3185 fails z.size() >= x.size() at JSBigInt.cpp:3027 because r has only b.size() digits. Fix: return (or skip the remainder shift) when interrupted, so every caller passing r, including remainderImpl at JSBigInt.cpp:4918 and divideBasecase at JSBigInt.cpp:3306, sees the pending exception rather than a crash.
A small fix can ride a push you are already making; otherwise a short reply is enough.

Why this was flagged

Input: x % y with y of 2..56 digits and x long enough that the schoolbook loop accumulates 5,000,000 work units (about 90,000 rows of a 56-digit divisor, i.e. an x of roughly 6 million bits), reached through JSBigInt::remainderImpl, which passes r sized ySpan.size() at JSBigInt.cpp:4912 and 4918 into divideDigitsInto and then divideSchoolbook with &interrupt. While the loop runs, another thread requests termination (Bun worker.terminate). InterruptCheck::addWork at JSBigInt.cpp:1264 reaches workThreshold, checkSlow at 1283 sees hasExceptionsAfterHandlingTraps and sets m_interrupted, and the loop breaks at JSBigInt.cpp:3127. At that point uSpan (a.size()+1 digits, JSBigInt.cpp:3089) still holds the remainder of the previous row in uSpan[j+1..j+n] plus the unprocessed low digits, so normalize(uSpan) inside rightShift (JSBigInt.cpp:3020) is longer than n. divideSchoolbook then calls rightShift(r, uSpan, shift) at JSBigInt.cpp:3185; with shift > 0 the RELEASE_ASSERT(z.size() >= x.size()) at JSBigInt.cpp:3027 fires, with shift == 0 spanCopy's RELEASE_ASSERT at JSBigInt.cpp:2984 fires. The…

Verification: pre-existing (the base at 299c532 has the identical break on interrupt and the identical RELEASE_ASSERT(z.size() >= x.size()) in rightShift; this diff rewrites both functions but keeps the defect). Trigger: a termination request (VMTraps NeedTermination, e.g. worker.terminate) arrives while divideSchoolbook is running with an InterruptCheck bound to a VM and enough accumulated work to reach…

[robobun]

This PR is replaced by #725. That PR merges upstream 7b485a76e9, which includes this range, with the conflict resolutions of this PR. The branch stays, so this PR can be reopened. On the Bun side, oven-sh/bun#42666 is replaced by oven-sh/bun#43882.