[webkit-changes] [WebKit/WebKit] 8bf24b: Cherry-pick 284431 at main (64afe80b60e5). https://bu...

[Keith Miller]

  Branch: refs/heads/webkitglib/2.46
  Home:   https://github.com/WebKit/WebKit
  Commit: 8bf24b4eb7c0edeca2fa1745b4030da87ca5420a
      https://github.com/WebKit/WebKit/commit/8bf24b4eb7c0edeca2fa1745b4030da87ca5420a
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2024-10-04 (Fri, 04 Oct 2024)

  Changed paths:
    M Source/WebCore/dom/Document.cpp
    M Source/WebCore/dom/Document.h

  Log Message:
  -----------
  Cherry-pick 284431 at main (64afe80b60e5). https://bugs.webkit.org/show_bug.cgi?id=280578

    REGRESSION: 282146 at main made text entry in a quip document very slow
    https://bugs.webkit.org/show_bug.cgi?id=280578
    rdar://136905905

    Reviewed by Darin Adler.

    In 282146 at main, I converted EventTargetSet from a `HashCountedSet<Node*>` to a
    `WeakHashCountedSet<Node>` for safety reasons. However, this set is used in hot
    code and we end up spending a lot of time in WeakHashMap's amortized cleanup
    on certain pages.

    To address the performance issue while maintaining safety, I am now using a
    `HashCountedSet<CheckedPtr<Node>>`.

    * Source/WebCore/dom/Document.cpp:
    (WebCore::Document::willBeRemovedFromFrame):
    (WebCore::Document::wheelEventHandlersChanged):
    (WebCore::Document::didAddWheelEventHandler):
    (WebCore::removeHandlerFromSet):
    (WebCore::Document::didAddTouchEventHandler):
    (WebCore::Document::didRemoveEventTargetNode):
    (WebCore::Document::absoluteRegionForEventTargets):
    * Source/WebCore/dom/Document.h:
    (WebCore::Document::hasTouchEventHandlers const):
    (WebCore::Document::hasWheelEventHandlers const):

    Canonical link: https://commits.webkit.org/284431@main

Canonical link: https://commits.webkit.org/282416.189@webkitglib/2.46


  Commit: 2f79f4ce1c38cbe9ae7434a92241557d97dc7cff
      https://github.com/WebKit/WebKit/commit/2f79f4ce1c38cbe9ae7434a92241557d97dc7cff
  Author: Jer Noble <jer.noble at apple.com>
  Date:   2024-10-04 (Fri, 04 Oct 2024)

  Changed paths:
    M LayoutTests/media/now-playing-status-for-video-conference-web-page.html
    M LayoutTests/platform/mac-wk2/TestExpectations
    M Source/WebCore/html/HTMLMediaElement.cpp
    M Source/WebCore/html/HTMLMediaElement.h
    M Source/WebCore/testing/Internals.cpp
    M Source/WebCore/testing/Internals.h
    M Source/WebCore/testing/Internals.idl

  Log Message:
  -----------
  Cherry-pick 284177 at main (02cd89be8171). https://bugs.webkit.org/show_bug.cgi?id=277024

    REGRESSION (280914 at main): [macOS wk2] media/now-playing-status-for-video-conference-web-page.html is a flaky failure
    https://bugs.webkit.org/show_bug.cgi?id=277024
    rdar://132426511

    Reviewed by Youenn Fablet.

    NowPlayingState.haveEverRegisteredAsNowPlayingApplication is not consistently reset between tests, so do not rely
    upon its value for testing purposes. Instead, add an Internals method that returns whether a specific media element
    currently represents the "now playing session".

    * LayoutTests/media/now-playing-status-for-video-conference-web-page.html:
    * LayoutTests/platform/mac-wk2/TestExpectations:
    * Source/WebCore/html/HTMLMediaElement.cpp:
    (WebCore::HTMLMediaElement::isActiveNowPlayingSession const):
    * Source/WebCore/html/HTMLMediaElement.h:
    * Source/WebCore/testing/Internals.cpp:
    (WebCore::Internals::elementIsActiveNowPlayingSession const):
    * Source/WebCore/testing/Internals.h:
    * Source/WebCore/testing/Internals.idl:

    Canonical link: https://commits.webkit.org/284177@main

Canonical link: https://commits.webkit.org/282416.190@webkitglib/2.46


  Commit: 1772781ed47b3614e1bb8b313ba5293bd18c357f
      https://github.com/WebKit/WebKit/commit/1772781ed47b3614e1bb8b313ba5293bd18c357f
  Author: Jean-Yves Avenard <jya at apple.com>
  Date:   2024-10-04 (Fri, 04 Oct 2024)

  Changed paths:
    M Source/WebCore/platform/graphics/MediaSourcePrivate.cpp

  Log Message:
  -----------
  Cherry-pick 283309 at main (96a00f891524). https://bugs.webkit.org/show_bug.cgi?id=279269

    media-source-current-time.html tests and media-source-stalled-holds-sleep-assertion.html are crashing on WK1
    https://bugs.webkit.org/show_bug.cgi?id=279269
    rdar://135421843

    Reviewed by Chris Dumez.

    MediaSourcePrivate::hasAudio() can be called on the GC thread. When this
    happens m_dispatcher (either main or worker thread) is suspended.

    * Source/WebCore/platform/graphics/MediaSourcePrivate.cpp:
    (WebCore::MediaSourcePrivate::hasAudio const):

    Canonical link: https://commits.webkit.org/283309@main

Canonical link: https://commits.webkit.org/282416.191@webkitglib/2.46


  Commit: 7bda62da85a6b54a6dd53d56d3439075dbc4ab84
      https://github.com/WebKit/WebKit/commit/7bda62da85a6b54a6dd53d56d3439075dbc4ab84
  Author: Ryan Reno <rreno at apple.com>
  Date:   2024-10-04 (Fri, 04 Oct 2024)

  Changed paths:
    M Source/WebCore/bindings/js/JSAudioWorkletGlobalScopeCustom.cpp

  Log Message:
  -----------
  Cherry-pick 282644 at main (2ef9bf886adc). https://bugs.webkit.org/show_bug.cgi?id=278512

    REGRESSION (280975 at main) Null pointer deref crash in WebCore::AudioWorkletGlobalScope::createProcessor
    https://bugs.webkit.org/show_bug.cgi?id=278512
    rdar://133250806

    Reviewed by Chris Dumez.

    After 280975 at main, Audio Worklet processor constructors are weak
    handles and may be garbage collected prematurely, especially in WK1.
    This can lead to null pointer deref crashes in WebAudio WPT when trying
    to construct a new Audio Worklet processor.

    This change adds the AudioWorkletGlobalScope as a WebCore opaque root in
    order to keep registered processor constructors alive via the
    isReachableFromOpaqueRoots mechanism.

    * Source/WebCore/bindings/js/JSAudioWorkletGlobalScopeCustom.cpp:
    (WebCore::JSAudioWorkletGlobalScope::visitAdditionalChildren):

    Canonical link: https://commits.webkit.org/282644@main

Canonical link: https://commits.webkit.org/282416.192@webkitglib/2.46


  Commit: 39017e3c9324f1f1afc9b6f93b7a3c1fc20cf1d8
      https://github.com/WebKit/WebKit/commit/39017e3c9324f1f1afc9b6f93b7a3c1fc20cf1d8
  Author: Keith Miller <keith_miller at apple.com>
  Date:   2024-10-04 (Fri, 04 Oct 2024)

  Changed paths:
    A JSTests/stress/runString-returns-globalThis-not-globalObject.js
    M Source/JavaScriptCore/jsc.cpp
    M Source/JavaScriptCore/tools/JSDollarVM.cpp

  Log Message:
  -----------
  Cherry-pick 282453 at main (22b1c6974350). https://bugs.webkit.org/show_bug.cgi?id=276934

    ASSERTION FAILED: isCell() WebKit/Source/JavaScriptCore/runtime/JSCJSValueInlines.h(598) : JSC::JSCell* JSC::JSValue::asCell() const
    https://bugs.webkit.org/show_bug.cgi?id=276934
    rdar://132305364

    Reviewed by Yusuke Suzuki.

    Some of our debugging functions currently return the globalObject directly. This is mostly ok because we expect to not fall over when
    the globalObject is directly exposed (rather than the globalThis proxy). That said, it seems when extending the GlobalObject it's
    possible to crash because we put_by_id_direct on the result of `ToThis`, which when is the GlobalObject (not the proxy) becomes jsUndefined().
    To avoid spurious fuzzer crashes in the future this change has these functions return the globalThis. It seems none of the testing we did
    relies on the actual globalObject anyway and the globalThis is fine.

    * JSTests/stress/runString-returns-globalThis-not-globalObject.js: Added.
    (try.F):
    (try.C):
    * Source/JavaScriptCore/jsc.cpp:
    (JSC_DEFINE_HOST_FUNCTION):
    * Source/JavaScriptCore/tools/JSDollarVM.cpp:

    Canonical link: https://commits.webkit.org/282453@main

Canonical link: https://commits.webkit.org/282416.193@webkitglib/2.46


Compare: https://github.com/WebKit/WebKit/compare/dfb76f4eafe3...39017e3c9324

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