Branch: refs/heads/webkitglib/2.52
  Home:   https://github.com/WebKit/WebKit
  Commit: 737fdb4546461effea038f3c25ddc0702935df09
      
https://github.com/WebKit/WebKit/commit/737fdb4546461effea038f3c25ddc0702935df09
  Author: Ryosuke Niwa <[email protected]>
  Date:   2026-05-20 (Wed, 20 May 2026)

  Changed paths:
    M Source/WebCore/bindings/js/JSRangeCustom.cpp
    M Source/WebCore/dom/Range.cpp
    M Source/WebCore/dom/Range.h

  Log Message:
  -----------
  Cherry-pick 305413.623@safari-7624-branch (2c31f99593da). 
https://bugs.webkit.org/show_bug.cgi?id=311261

    Data race in Range::visitNodesConcurrently during GC, leading to a 
use-after-free of RangeBoundaryPoint container nodes
    https://bugs.webkit.org/show_bug.cgi?id=311261
    rdar://173502014

    Reviewed by Chris Dumez.

    Add a lock for mutating m_start and m_end.

    No new tests since there is no reliable way of testing this data race.

    * Source/WebCore/bindings/js/JSRangeCustom.cpp:
    (WebCore::JSRange::visitAdditionalChildren):
    * Source/WebCore/dom/Range.cpp:
    (WebCore::Range::setStart):
    (WebCore::Range::setEnd):
    (WebCore::Range::collapse):
    (WebCore::Range::selectNodeContents):
    (WebCore::Range::nodeChildrenChanged):
    (WebCore::Range::nodeChildrenWillBeRemoved):
    (WebCore::Range::nodeWillBeRemoved):
    (WebCore::Range::textInserted):
    (WebCore::Range::textRemoved):
    (WebCore::Range::textNodesMerged):
    (WebCore::Range::textNodeSplit):
    (WebCore::Range::visitNodesInGCThread const): Renamed from 
visitNodesConcurrently.
    * Source/WebCore/dom/Range.h:

    Identifier: 305413.623@safari-7624-branch

Canonical link: https://commits.webkit.org/305877.623@webkitglib/2.52


  Commit: 0a44fc26b48db01d414f0aeaa4e9459274ca2700
      
https://github.com/WebKit/WebKit/commit/0a44fc26b48db01d414f0aeaa4e9459274ca2700
  Author: Kai Tamkun <[email protected]>
  Date:   2026-05-20 (Wed, 20 May 2026)

  Changed paths:
    A LayoutTests/js/regress-311234-expected.txt
    A LayoutTests/js/regress-311234.html
    M Source/JavaScriptCore/runtime/DeferredWorkTimer.h
    M Source/JavaScriptCore/runtime/WaiterListManager.cpp
    M Source/JavaScriptCore/runtime/WaiterListManager.h

  Log Message:
  -----------
  Cherry-pick 305413.625@safari-7624-branch (3b7488ef5bc6). 
https://bugs.webkit.org/show_bug.cgi?id=311234

    [JSC] Data race in WaiterListManager::unregister
    https://bugs.webkit.org/show_bug.cgi?id=311234
    rdar://173161138

    Reviewed by Yijia Huang.

    Stores a JSGlobalObject pointer in JSC::Waiter so that it doesn't
    have to be fetched from the target.

    Test: js/regress-311234.html

    * LayoutTests/js/regress-311234-expected.txt: Added.
    * LayoutTests/js/regress-311234.html: Added.
    * Source/JavaScriptCore/runtime/DeferredWorkTimer.h:
    * Source/JavaScriptCore/runtime/WaiterListManager.cpp:
    (JSC::Waiter::Waiter):
    (JSC::WaiterListManager::unregister):
    (JSC::Waiter::dump const):
    * Source/JavaScriptCore/runtime/WaiterListManager.h:

    Identifier: 305413.625@safari-7624-branch

Canonical link: https://commits.webkit.org/305877.624@webkitglib/2.52


  Commit: 5fda2837c10197f7b721bf628e3136cbb2c8ea06
      
https://github.com/WebKit/WebKit/commit/5fda2837c10197f7b721bf628e3136cbb2c8ea06
  Author: Ryosuke Niwa <[email protected]>
  Date:   2026-05-20 (Wed, 20 May 2026)

  Changed paths:
    M Source/WebCore/dom/Range.cpp

  Log Message:
  -----------
  Cherry-pick 305413.632@safari-7624-branch (0c74ffa4edbc). 
https://bugs.webkit.org/show_bug.cgi?id=311261

    Data race in Range::visitNodesConcurrently during GC, leading to a 
use-after-free of RangeBoundaryPoint container nodes
    https://bugs.webkit.org/show_bug.cgi?id=311261
    rdar://174214346

    Unreviewed. Addressing the review comments in the original PR.

    * Source/WebCore/dom/Range.cpp:
    (WebCore::Range::setStart):
    (WebCore::Range::setEnd):
    (WebCore::boundaryNodeChildrenChanged):
    (WebCore::Range::nodeChildrenChanged):
    (WebCore::boundaryNodeChildrenWillBeRemoved):
    (WebCore::Range::nodeChildrenWillBeRemoved):
    (WebCore::boundaryNodeWillBeRemoved):
    (WebCore::Range::nodeWillBeRemoved):
    (WebCore::boundaryTextInserted):
    (WebCore::Range::textInserted):
    (WebCore::boundaryTextRemoved):
    (WebCore::Range::textRemoved):
    (WebCore::boundaryTextNodesMerged):
    (WebCore::Range::textNodesMerged):
    (WebCore::boundaryTextNodesSplit):
    (WebCore::Range::textNodeSplit):

    Identifier: 305413.632@safari-7624-branch

Canonical link: https://commits.webkit.org/305877.625@webkitglib/2.52


  Commit: fb51e57e31d1e3f31bd9c2ca855601d2bf20c1a4
      
https://github.com/WebKit/WebKit/commit/fb51e57e31d1e3f31bd9c2ca855601d2bf20c1a4
  Author: Shu-yu Guo <[email protected]>
  Date:   2026-05-20 (Wed, 20 May 2026)

  Changed paths:
    A 
JSTests/stress/ftl-osr-exit-phantom-new-array-with-butterfly-having-a-bad-time.js
    M Source/JavaScriptCore/ftl/FTLOperations.cpp

  Log Message:
  -----------
  Cherry-pick 305413.641@safari-7624-branch (899331a21899). 
https://bugs.webkit.org/show_bug.cgi?id=311883

    [JSC] Array rematerialization should know how to have a bad time
    https://bugs.webkit.org/show_bug.cgi?id=311883
    rdar://174420676

    Reviewed by Keith Miller.

    Sunk Arrays that are rematerialized with a butterfly are always 
rematerialized
    with a contiguous butterfly. If, in the meantime, the VM had a bad time and
    moved all Array structures to SlowPutArrayStorage, rematerialization can 
end up
    treating remterialized Arrays, which are now ArrayStorage, as if they had
    contiguous butterflies.

    This PR fixes that by always rematerializing with the contiguous butterfly, 
but
    switching to SlowPutArrayStorage after the fact if the VM is having a bad 
time.

    Test: 
JSTests/stress/ftl-osr-exit-phantom-new-array-with-butterfly-having-a-bad-time.js

    * 
JSTests/stress/ftl-osr-exit-phantom-new-array-with-butterfly-having-a-bad-time.js:
 Added.
    (cb):
    (collect):
    (opt):
    * Source/JavaScriptCore/ftl/FTLOperations.cpp:
    (JSC::FTL::JSC_DEFINE_NOEXCEPT_JIT_OPERATION):

    Identifier: 305413.641@safari-7624-branch

Canonical link: https://commits.webkit.org/305877.626@webkitglib/2.52


  Commit: 628f1ee208cef2b8173aa83f7a01a76a683db2dd
      
https://github.com/WebKit/WebKit/commit/628f1ee208cef2b8173aa83f7a01a76a683db2dd
  Author: Shu-yu Guo <[email protected]>
  Date:   2026-05-20 (Wed, 20 May 2026)

  Changed paths:
    A JSTests/stress/string-at-cse-array-mode.js
    M Source/JavaScriptCore/dfg/DFGClobberize.h

  Log Message:
  -----------
  Cherry-pick 305413.642@safari-7624-branch (b2284d1674da). 
https://bugs.webkit.org/show_bug.cgi?id=311976

    [JSC] StringAt should respect arrayMode in CSE
    https://bugs.webkit.org/show_bug.cgi?id=311976
    rdar://174422482

    Reviewed by Yusuke Suzuki.

    String.prototype.at returns a string when the index is in-bounds and 
undefined
    when the index is out-of-bounds. Since these are different types, StringAts
    with different arrayModes should not be CSE'd.

    Test: JSTests/stress/string-at-cse-array-mode.js
    * JSTests/stress/string-at-cse-array-mode.js: Added.
    (opt):
    * Source/JavaScriptCore/dfg/DFGClobberize.h:
    (JSC::DFG::clobberize):

    Identifier: 305413.642@safari-7624-branch

Canonical link: https://commits.webkit.org/305877.627@webkitglib/2.52


  Commit: 164dfa85049b32b11acdf16b5fb8c5d6db3eccfe
      
https://github.com/WebKit/WebKit/commit/164dfa85049b32b11acdf16b5fb8c5d6db3eccfe
  Author: Kai Tamkun <[email protected]>
  Date:   2026-05-20 (Wed, 20 May 2026)

  Changed paths:
    A JSTests/stress/regress-173924142.js
    M Source/JavaScriptCore/dfg/DFGClobberize.h

  Log Message:
  -----------
  Cherry-pick 305413.657@safari-7624-branch (882fc55c5e17). 
https://bugs.webkit.org/show_bug.cgi?id=311663

    [JSC] ToBoolean/TypeOfIsUndefined/TypeOfIsFunction/TypeOf/CompareEq def 
value in DFGClobberize doesn't depend on node's origin.semantic
    https://bugs.webkit.org/show_bug.cgi?id=311663
    rdar://173924142

    Reviewed by Marcus Plutowski.

    The semantics of operations like `typeof` are realm-dependent when the 
input has the
    `MasqueradesAsUndefined` flag set. This patch prevents constant folding of 
these
    expressions if they have different realms to preserve the semantics.

    Added regress-173924142.js to ensure that the operations behave as expected 
even across realms.

    * JSTests/stress/regress-173924142.js: Added.
    (assert):
    (otherGlobal.eval.returnMultipleValues):
    (returnMultipleValues):
    (i.returnMultipleValues):
    (otherGlobalMasqueraderAfter.const.property.of.Object.getOwnPropertyNames):
    * Source/JavaScriptCore/dfg/DFGClobberize.h:
    (JSC::DFG::clobberize):

    Identifier: 305413.657@safari-7624-branch

Canonical link: https://commits.webkit.org/305877.628@webkitglib/2.52


  Commit: 3558568ec9c0c54a64583a4cc0f9f97b31be5c60
      
https://github.com/WebKit/WebKit/commit/3558568ec9c0c54a64583a4cc0f9f97b31be5c60
  Author: Shu-yu Guo <[email protected]>
  Date:   2026-05-20 (Wed, 20 May 2026)

  Changed paths:
    A JSTests/stress/dataview-bytelength-ic-stub-stack-desync.js
    M Source/JavaScriptCore/bytecode/InlineCacheCompiler.cpp

  Log Message:
  -----------
  Cherry-pick 68274fa2f297. https://bugs.webkit.org/show_bug.cgi?id=312218

    [JSC] Move DataView null vector check in IC outside of register save/restore
    https://bugs.webkit.org/show_bug.cgi?id=312218
    rdar://174627873

    Reviewed by Marcus Plutowski.

    In the DataView byteLength getter IC, there is a null vector check which
    executes before a preserveReusedRegistersByPushing, but jumps to a point 
before
    restoreReusedRegistersByPopping. In other words, causing a misbalanced push 
and
    pop of register state.

    This PR fixes by making the null vector check jump to after the popping of
    saved registers.

    Test: JSTests/stress/dataview-bytelength-ic-stub-stack-desync.js
    * JSTests/stress/dataview-bytelength-ic-stub-stack-desync.js: Added.
    (hot):
    * Source/JavaScriptCore/bytecode/InlineCacheCompiler.cpp:
    (JSC::InlineCacheCompiler::emitIntrinsicGetter):

    Identifier: 305413.668@safari-7624-branch

    Canonical link: 
https://commits.webkit.org/[email protected]

Canonical link: https://commits.webkit.org/305877.629@webkitglib/2.52


  Commit: 18856f29747eef91a29f2220f59439cb359753f0
      
https://github.com/WebKit/WebKit/commit/18856f29747eef91a29f2220f59439cb359753f0
  Author: Vassili Bykov <[email protected]>
  Date:   2026-05-20 (Wed, 20 May 2026)

  Changed paths:
    A JSTests/wasm/stress/tail-call-v128-ref-stack-overlap.js
    M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp
    M Source/JavaScriptCore/wasm/WasmBBQJIT.h
    M Source/JavaScriptCore/wasm/WasmBBQJIT64.h

  Log Message:
  -----------
  Cherry-pick 73c288dd8c72. https://bugs.webkit.org/show_bug.cgi?id=312288

    [JSC] BBQJIT tail call shuffle should detect overlapping stack slots
    https://bugs.webkit.org/show_bug.cgi?id=312288
    rdar://174490087

    Reviewed by Dan Hecht.

    Because in a tail call the caller and the callee frames overlap, 
BBQJIT::emitTailCall()
    uses emitShuffle() to orchestrate the copying of call arguments into their 
destination
    locations in such a way that if a caller temp resides in the callee 
argument space and is
    itself passed as an argument, it is not clobbered before it's been moved to 
its final
    location.

    The move hazard detection in emitShuffleMove() compares stack locations by 
offset only
    (via Location::operator==). The core assumption here is that source and 
destination values
    with different base addresses never overlap, so a write to a destination 
address A never
    clobbers a source value at address B.

    This assumption does not always hold. Caller temps (source values) are 
always 16-byte
    aligned regardless of value type. Callee arguments (destination values) are 
packed
    contiguously. If an i64 argument at address B is followed by a v128 
argument, the v128
    argument occupies the address range [B+8, B+24). This range overlaps two 
temp slots with
    ranges [B, B+16) and [B+16, B+32). Because hazard detection currently only 
considers the
    base address, this overlap will go unnoticed and the shuffle may write the 
v128 argument
    before the values in the overlapping source slots have been moved.

    This patch adds Location::overlaps() method which considers actual ranges 
for Stack and
    StackArgument locations. The method replaces Location::operator==() for 
hazard detection.

    The new method is also used in destination uniqueness assertion in 
emitShuffle.

    Test: JSTests/wasm/stress/tail-call-v128-ref-stack-overlap.js
    Identifier: 305413.670@safari-7624-branch

    Canonical link: 
https://commits.webkit.org/[email protected]

Canonical link: https://commits.webkit.org/305877.630@webkitglib/2.52


  Commit: dce97f6125c4aa90d67224344cc3d048c040f130
      
https://github.com/WebKit/WebKit/commit/dce97f6125c4aa90d67224344cc3d048c040f130
  Author: Ryosuke Niwa <[email protected]>
  Date:   2026-05-20 (Wed, 20 May 2026)

  Changed paths:
    A LayoutTests/http/tests/web-locks/resources/shared-worker.js
    A LayoutTests/http/tests/web-locks/web-lock-in-blob-url-expected.txt
    A LayoutTests/http/tests/web-locks/web-lock-in-blob-url.html
    A LayoutTests/http/tests/web-locks/web-lock-in-data-url-expected.txt
    A LayoutTests/http/tests/web-locks/web-lock-in-data-url.html
    A LayoutTests/http/tests/web-locks/web-lock-in-opaque-srcdoc-expected.txt
    A LayoutTests/http/tests/web-locks/web-lock-in-opaque-srcdoc.html
    A LayoutTests/http/tests/web-locks/web-lock-in-serviceworker-expected.txt
    A 
LayoutTests/http/tests/web-locks/web-lock-in-serviceworker-service-worker.js
    A LayoutTests/http/tests/web-locks/web-lock-in-serviceworker.html
    A LayoutTests/http/tests/web-locks/web-lock-in-sharedworker-expected.txt
    A LayoutTests/http/tests/web-locks/web-lock-in-sharedworker.html
    A LayoutTests/http/tests/web-locks/web-lock-in-srcdoc-expected.txt
    A LayoutTests/http/tests/web-locks/web-lock-in-srcdoc.html
    A LayoutTests/ipc/weblock-registry-origin-expected.txt
    A LayoutTests/ipc/weblock-registry-origin.html
    M Source/WebKit/UIProcess/WebFrameProxy.cpp
    M Source/WebKit/UIProcess/WebLockRegistryProxy.cpp
    M Source/WebKit/UIProcess/WebProcessProxy.cpp
    M Source/WebKit/UIProcess/WebProcessProxy.h

  Log Message:
  -----------
  Cherry-pick 305413.548@safari-7624-branch (e509924cdce7). 
https://bugs.webkit.org/show_bug.cgi?id=310289

    WebLockRegistryProxy should validate its message
    https://bugs.webkit.org/show_bug.cgi?id=310289
    rdar://172389530

    Reviewed by Brady Eidson and Chris Dumez.

    Check the authenticity of origins given to 
WebLockRegistryProxy::requestLock by
    keeping track of every ClientOrigin that got committed in WebFrameProxy.

    Test: http/tests/web-locks/web-lock-in-blob-url.html
          http/tests/web-locks/web-lock-in-data-url.html
          http/tests/web-locks/web-lock-in-opaque-srcdoc.html
          http/tests/web-locks/web-lock-in-serviceworker.html
          http/tests/web-locks/web-lock-in-sharedworker.html
          http/tests/web-locks/web-lock-in-srcdoc.html
          ipc/weblock-registry-origin.html

    * LayoutTests/http/tests/web-locks/resources/shared-worker.js: Added.
    (self.onconnect):
    * LayoutTests/http/tests/web-locks/web-lock-in-blob-url-expected.txt: Added.
    * LayoutTests/http/tests/web-locks/web-lock-in-blob-url.html: Added.
    * LayoutTests/http/tests/web-locks/web-lock-in-data-url-expected.txt: Added.
    * LayoutTests/http/tests/web-locks/web-lock-in-data-url.html: Added.
    * LayoutTests/http/tests/web-locks/web-lock-in-opaque-srcdoc-expected.txt: 
Added.
    * LayoutTests/http/tests/web-locks/web-lock-in-opaque-srcdoc.html: Added.
    * LayoutTests/http/tests/web-locks/web-lock-in-serviceworker-expected.txt: 
Added.
    * 
LayoutTests/http/tests/web-locks/web-lock-in-serviceworker-service-worker.js: 
Added.
    (event.event.request.url.indexOf):
    * LayoutTests/http/tests/web-locks/web-lock-in-serviceworker.html: Added.
    * LayoutTests/http/tests/web-locks/web-lock-in-sharedworker-expected.txt: 
Added.
    * LayoutTests/http/tests/web-locks/web-lock-in-sharedworker.html: Added.
    * LayoutTests/http/tests/web-locks/web-lock-in-srcdoc-expected.txt: Added.
    * LayoutTests/http/tests/web-locks/web-lock-in-srcdoc.html: Added.
    * LayoutTests/ipc/weblock-registry-origin-expected.txt: Added.
    * LayoutTests/ipc/weblock-registry-origin.html: Added.
    * Source/WebKit/UIProcess/WebFrameProxy.cpp:
    (WebKit::WebFrameProxy::didCommitLoad):
    * Source/WebKit/UIProcess/WebLockRegistryProxy.cpp:
    (WebKit::WebLockRegistryProxy::requestLock):
    (WebKit::WebLockRegistryProxy::releaseLock):
    (WebKit::WebLockRegistryProxy::abortLockRequest):
    (WebKit::WebLockRegistryProxy::snapshot):
    (WebKit::WebLockRegistryProxy::clientIsGoingAway):
    * Source/WebKit/UIProcess/WebProcessProxy.cpp:
    (WebKit::WebProcessProxy::hasCommittedClientOrigin const):
    (WebKit::WebProcessProxy::didCommitLoadClientOrigin):
    * Source/WebKit/UIProcess/WebProcessProxy.h:

    Identifier: 305413.548@safari-7624-branch

Canonical link: https://commits.webkit.org/305877.631@webkitglib/2.52


  Commit: ecf7025919fc53ef635995040b033cb2d5ca72db
      
https://github.com/WebKit/WebKit/commit/ecf7025919fc53ef635995040b033cb2d5ca72db
  Author: Ryosuke Niwa <[email protected]>
  Date:   2026-05-20 (Wed, 20 May 2026)

  Changed paths:
    M Source/WebKit/UIProcess/WebProcessProxy.cpp
    M Source/WebKit/UIProcess/WebProcessProxy.h
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/WebLocks.mm

  Log Message:
  -----------
  Cherry-pick 4fcd36e3a363. https://bugs.webkit.org/show_bug.cgi?id=312335

    REGRESSION(305413.548@safari-7624-branch): Crash in 
WebProcessProxy::hasCommittedClientOrigin
    https://bugs.webkit.org/show_bug.cgi?id=312335
    rdar://174679141

    Reviewed by Chris Dumez.

    WebProcessProxy::hasCommittedClientOrigin has a code path for processes 
running workers (isRunningWorkers())
    that dereferences m_site as in *m_site. m_site is a 
WTF::Expected<WebCore::Site, SiteState> — when it holds
    the error value SiteState::MultipleSites, operator*() accesses the 
non-existent value member, throwing
    std::bad_variant_access. This propagates uncaught to the Objective-C run 
loop boundary, triggering std::terminate().

    The three conditions that must hold simultaneously for this crash to occur:
      1. isRunningWorkers() is true — a service worker is running inside a web 
content process (not a dedicated worker
         process), so m_serviceWorkerInformation is set.
      2. m_site holds MultipleSites — a cross-site navigation occurred in that 
same web content process (no process swap),
         so didStartProvisionalLoadForMainFrame set m_site = 
makeUnexpected(SiteState::MultipleSites).
      3. A RequestLock IPC from the service worker arrives after condition 2 — 
the service worker's termination is
         deferred (terminateRemoteWorkerContextConnectionWhenPossible instead 
of the old disableRemoteWorkers), so
         isRunningWorkers() remains true during a window where the worker can 
still send IPCs.

    Fixed the bug by adding a HashSet<WebCore::Site> m_committedSites to 
WebProcessProxy, populated whenever m_site is
    assigned a valid Site (in createForRemoteWorkers, 
didStartProvisionalLoadForMainFrame, and
    didStartUsingProcessForSiteIsolation). In hasCommittedClientOrigin, when 
isRunningWorkers() is true but m_site does
    not holds a value (it's MultipleSites), the check falls back to 
m_committedSites instead of dereferencing m_site
    in an error state. This correctly validates the worker's origin against the 
sites the process has legitimately
    committed — rather than crashing or incorrectly rejecting a legitimate lock 
request and killing the web process.

    Test: Tools/TestWebKitAPI/Tests/WebKitCocoa/WebLocks.mm

    * Source/WebKit/UIProcess/WebProcessProxy.cpp:
    (WebKit::WebProcessProxy::createForRemoteWorkers):
    (WebKit::WebProcessProxy::hasCommittedClientOrigin const):
    (WebKit::WebProcessProxy::didStartProvisionalLoadForMainFrame):
    (WebKit::WebProcessProxy::didStartUsingProcessForSiteIsolation):
    * Source/WebKit/UIProcess/WebProcessProxy.h:
    * Tools/TestWebKitAPI/Tests/WebKitCocoa/WebLocks.mm:
    (TestWebKitAPI::enableWebLocksAPI):
    (TestWebKitAPI::runSnapshotAcrossPagesTest):
    (TestWebKitAPI::runLockRequestWaitingOnAnotherPage):
    (TestWebKitAPI::TEST(WebLocks, 
ServiceWorkerLockRequestAfterCrossSiteNavigationInSameProcess)):

    Identifier: 305413.672@safari-7624-branch

    Canonical link: 
https://commits.webkit.org/[email protected]

Canonical link: https://commits.webkit.org/305877.632@webkitglib/2.52


  Commit: 302c510deea66ab78470c5bb52e777b99221b4e7
      
https://github.com/WebKit/WebKit/commit/302c510deea66ab78470c5bb52e777b99221b4e7
  Author: Yijia Huang <[email protected]>
  Date:   2026-05-20 (Wed, 20 May 2026)

  Changed paths:
    A JSTests/wasm/stress/deferred-work-timer-cancel-duplicate-ticket.js
    M Source/JavaScriptCore/runtime/DeferredWorkTimer.cpp

  Log Message:
  -----------
  Cherry-pick 09af279a99da. https://bugs.webkit.org/show_bug.cgi?id=312314

    [JSC] Remove unneeded m_tasks append in 
DeferredWorkTimer::cancelPendingWorkSafe
    https://bugs.webkit.org/show_bug.cgi?id=312314
    rdar://174738881

    Reviewed by Keith Miller.

    cancelPendingWorkSafe() was unconditionally appending a (ticket, noop) 
entry to
    m_tasks for every weak ticket of a dying global. This is unnecessary because
    doWork() already has a removeIf(isCancelled) pass at the end that purges 
cancelled
    tickets from m_pendingTickets without needing a m_tasks entry, and
    setTimeUntilFire(0_s) already ensures doWork() fires to run that cleanup.

    Test: JSTests/wasm/stress/deferred-work-timer-cancel-duplicate-ticket.js
    Identifier: 305413.677@safari-7624-branch

    Canonical link: 
https://commits.webkit.org/[email protected]

Canonical link: https://commits.webkit.org/305877.633@webkitglib/2.52


  Commit: 7adb7d379d57a791e4f1ebd33691590053b432b7
      
https://github.com/WebKit/WebKit/commit/7adb7d379d57a791e4f1ebd33691590053b432b7
  Author: Ryosuke Niwa <[email protected]>
  Date:   2026-05-20 (Wed, 20 May 2026)

  Changed paths:
    A LayoutTests/streams/pipeTo-removed-iframe-crash-expected.txt
    A LayoutTests/streams/pipeTo-removed-iframe-crash.html
    M Source/WebCore/Modules/streams/StreamPipeToUtilities.cpp
    M Source/WebCore/bindings/js/InternalReadableStreamDefaultReader.cpp
    M Source/WebCore/bindings/js/InternalWritableStreamWriter.cpp

  Log Message:
  -----------
  Cherry-pick 90e48031ed4d. https://bugs.webkit.org/show_bug.cgi?id=312938

    REGRESSION(305413.674@safari-7624-branch): Crash in 
StreamPipeToState::globalObject
    https://bugs.webkit.org/show_bug.cgi?id=312938
    rdar://175084445

    Reviewed by Chris Dumez.

    The crash was caused by StreamPipeToState::globalObject calling 
jsDynamicCast<JSDOMGlobalObject*>
    on context->globalObject() without a nullptr check. Fixed the crash by 
adding a nullptr check.

    The newly written test revealed a related bug that we were calling 
DOMPromise::status even when
    active DOM objects had been stopped. Added a bunch of early returns to 
functions in
    InternalReadableStreamDefaultReader and InternalWritableStreamWriter to 
avoid debug assertions
    in these cases, one of which is hit by the new test.

    Test: streams/pipeTo-removed-iframe-crash.html

    * LayoutTests/streams/pipeTo-removed-iframe-crash-expected.txt: Added.
    * LayoutTests/streams/pipeTo-removed-iframe-crash.html: Added.
    * Source/WebCore/Modules/streams/StreamPipeToUtilities.cpp:
    (WebCore::StreamPipeToState::globalObject):
    * Source/WebCore/bindings/js/InternalReadableStreamDefaultReader.cpp:
    (WebCore::InternalReadableStreamDefaultReader::onClosedPromiseRejection):
    (WebCore::InternalReadableStreamDefaultReader::onClosedPromiseResolution):
    * Source/WebCore/bindings/js/InternalWritableStreamWriter.cpp:
    (WebCore::InternalWritableStreamWriter::onClosedPromiseRejection):
    (WebCore::InternalWritableStreamWriter::onClosedPromiseResolution):
    (WebCore::InternalWritableStreamWriter::whenReady):

    Identifier: 305413.711@safari-7624-branch

    Canonical link: 
https://commits.webkit.org/[email protected]

Canonical link: https://commits.webkit.org/305877.634@webkitglib/2.52


Compare: https://github.com/WebKit/WebKit/compare/2f59b476703b...7adb7d379d57

To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications

Reply via email to