Branch: refs/heads/webkitglib/2.52
  Home:   https://github.com/WebKit/WebKit
  Commit: 4978832afafcf5aad3eb3bcc70e9ce2f310f6b41
      
https://github.com/WebKit/WebKit/commit/4978832afafcf5aad3eb3bcc70e9ce2f310f6b41
  Author: Mark Lam <[email protected]>
  Date:   2026-02-26 (Thu, 26 Feb 2026)

  Changed paths:
    M Source/WTF/wtf/Atomics.h

  Log Message:
  -----------
  Cherry-pick 308243@main (9f672ca021c2). 
https://bugs.webkit.org/show_bug.cgi?id=308660

    Regression(302941@main): inline asm in WTF::opaque() needs to be volatile.
    https://bugs.webkit.org/show_bug.cgi?id=308660
    rdar://171189396

    Reviewed by Dan Hecht.

    Otherwise, compiler optimizations may elide or relocate the asm statement.

    See https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Extended-Asm.html:
    ```
    If an asm has output operands, GCC assumes for optimization purposes the 
instruction has no side
    effects except to change the output operands. This does not mean 
instructions with a side effect
    cannot be used, but you must be careful, because the compiler may eliminate 
them if the output
    operands aren't used, or move them out of loops, or replace two with one if 
they constitute a
    common subexpression. Also, if your instruction does have a side effect on 
a variable that
    otherwise appears not to change, the old value of the variable may be 
reused later if it happens
    to be found in a register.

    You can prevent an asm instruction from being deleted by writing the 
keyword volatile after the
    asm. For example:

         #define get_and_set_priority(new)              \
         ({ int __old;                                  \
            asm volatile ("get_and_set_priority %0, %1" \
                          : "=g" (__old) : "g" (new));  \
            __old; })
    ```

    This bug introduces race conditions into the code that are difficult to 
test for.  This fix is
    also effectively a partial revert of 302941@main.  Hence, no new test.

    * Source/WTF/wtf/Atomics.h:
    (WTF::opaque):

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

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


  Commit: 890e4c35215210668dab66f379c27b3710894218
      
https://github.com/WebKit/WebKit/commit/890e4c35215210668dab66f379c27b3710894218
  Author: Vitaly Dyachkov <[email protected]>
  Date:   2026-02-26 (Thu, 26 Feb 2026)

  Changed paths:
    M Source/WebKit/UIProcess/API/wpe/WPEWebViewPlatform.cpp
    M Source/WebKit/WPEPlatform/wpe/WPEGestureController.cpp
    M Source/WebKit/WPEPlatform/wpe/WPEGestureController.h
    M Source/WebKit/WPEPlatform/wpe/WPEGestureControllerImpl.cpp
    M Source/WebKit/WPEPlatform/wpe/WPEGestureDetector.cpp
    M Source/WebKit/WPEPlatform/wpe/WPEGestureDetector.h

  Log Message:
  -----------
  Cherry-pick 308271@main (f0af1daa9de5). 
https://bugs.webkit.org/show_bug.cgi?id=308643

    [WPEPlatform] Page scrolls at double speed when scrolling with two fingers
    https://bugs.webkit.org/show_bug.cgi?id=308643

    Reviewed by Carlos Garcia Campos.

    When scrolling begins with one finger and a second finger is placed on
    the screen and both fingers move together, the page scrolls at twice the
    expected speed.

    `WPEGestureDetector` only tracks the first touch sequence and ignores
    events from other sequences. However, `handleGesture()` did not check
    whether the event was actually processed and always proceeded to emit a
    scroll event based on the current gesture state. As a result, touch move
    events from the second finger triggered a second scroll event, doubling
    the scroll speed.

    Fixed by making `wpe_gesture_controller_handle_event()` return a boolean
    indicating whether the event was consumed.

    * Source/WebKit/UIProcess/API/wpe/WPEWebViewPlatform.cpp:
    (WKWPE::ViewPlatform::handleGesture):
    * Source/WebKit/WPEPlatform/wpe/WPEGestureController.cpp:
    (wpe_gesture_controller_handle_event):
    * Source/WebKit/WPEPlatform/wpe/WPEGestureController.h:
    * Source/WebKit/WPEPlatform/wpe/WPEGestureControllerImpl.cpp:
    (wpeHandleEvent):
    * Source/WebKit/WPEPlatform/wpe/WPEGestureDetector.cpp:
    (WPE::GestureDetector::handleEvent):
    * Source/WebKit/WPEPlatform/wpe/WPEGestureDetector.h:

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

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


  Commit: bd8c71c32abd6faceb18f7e32c33d8c49c71f0af
      
https://github.com/WebKit/WebKit/commit/bd8c71c32abd6faceb18f7e32c33d8c49c71f0af
  Author: Taher Ali <[email protected]>
  Date:   2026-02-26 (Thu, 26 Feb 2026)

  Changed paths:
    A 
LayoutTests/fast/events/resize-event-not-fired-during-page-scale-expected.txt
    A LayoutTests/fast/events/resize-event-not-fired-during-page-scale.html
    M Source/WebCore/page/LocalFrameView.cpp
    M Source/WebCore/page/LocalFrameView.h

  Log Message:
  -----------
  Cherry-pick 308244@main (d359a18a7a21). 
https://bugs.webkit.org/show_bug.cgi?id=308156

    REGRESSION (302097@main): pinch to zoom makes content jump or disappear
    https://bugs.webkit.org/show_bug.cgi?id=308156
    rdar://169593089

    Reviewed by Simon Fraser.

    302097@main added frameScaleFactor as a trigger for firing resize events
    in scheduleResizeEventIfNeeded(). On macOS, the main frame's
    frameScaleFactor() returns pageScaleFactor(), which changes when
    pinch-to-zoom commits. This caused resize event to fire even though
    the viewport didn't actually resize.

    innerWidth/innerHeight have always taken frameScaleFactor into account
    (in mapFromLayoutToCSSUnits), so they report smaller values at higher
    zoom levels. When the spurious resize event fires, sites that use
    JS-driven responsive breakpoints read the smaller innerWidth and
    switch to a mobile layout. This mismatch causes content to
    jump or disappear (e.g., roadburn.com/nightbus collapses from
    two-column to single-column layout on pinch zoom).

    Note: innerWidth/innerHeight changing during pinch-to-zoom may itself
    be a bug worth investigating separately. Chrome does not change these
    values on pinch zoom nor fire a resize event.

    This fix simply undoes the  frameScaleFactor addition from 302097@main
    to recover from the regression. Cmd+/- (page zoom) and CSS zoom changes
    still correctly fire resize events. only pinch-to-zoom no longer does.

    * 
LayoutTests/fast/events/resize-event-not-fired-during-page-scale-expected.txt: 
Added.
    * LayoutTests/fast/events/resize-event-not-fired-during-page-scale.html: 
Added.
    * Source/WebCore/page/LocalFrameView.cpp:
    (WebCore::LocalFrameView::scheduleResizeEventIfNeeded):
    * Source/WebCore/page/LocalFrameView.h:

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

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


  Commit: 0605c1e25952ec85ede31eea7cd923f98a145a5d
      
https://github.com/WebKit/WebKit/commit/0605c1e25952ec85ede31eea7cd923f98a145a5d
  Author: Charlie Wolfe <[email protected]>
  Date:   2026-02-26 (Thu, 26 Feb 2026)

  Changed paths:
    M Source/WebKit/UIProcess/WebPageProxy.cpp

  Log Message:
  -----------
  Cherry-pick 308176@main (be4914eab1fe). 
https://bugs.webkit.org/show_bug.cgi?id=308572

    Crash in `WebPageProxy::viewWillStartLiveResize`
    https://bugs.webkit.org/show_bug.cgi?id=308572
    rdar://170836812

    Reviewed by Rupin Mittal.

    * Source/WebKit/UIProcess/WebPageProxy.cpp:
    (WebKit::WebPageProxy::viewWillStartLiveResize):
    (WebKit::WebPageProxy::viewWillEndLiveResize):

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

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


  Commit: 8a02270ac5803fb002df83aab15badb6a070685a
      
https://github.com/WebKit/WebKit/commit/8a02270ac5803fb002df83aab15badb6a070685a
  Author: Charlie Wolfe <[email protected]>
  Date:   2026-02-26 (Thu, 26 Feb 2026)

  Changed paths:
    M Source/WebKit/UIProcess/SpeechRecognitionServer.cpp

  Log Message:
  -----------
  Cherry-pick 308166@main (fc1b5e8317bd). 
https://bugs.webkit.org/show_bug.cgi?id=308570

    Crash in `SpeechRecognitionServer::sendUpdate`
    https://bugs.webkit.org/show_bug.cgi?id=308570
    rdar://140082708

    Reviewed by Rupin Mittal.

    sendUpdate() can be called after the web process has been terminated. Don't 
send a message in this
    case to avoid crashing.

    * Source/WebKit/UIProcess/SpeechRecognitionServer.cpp:
    (WebKit::SpeechRecognitionServer::sendUpdate):

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

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


  Commit: 331ab4f97456d2b4c36dea4d78b8a3911eb2ae43
      
https://github.com/WebKit/WebKit/commit/331ab4f97456d2b4c36dea4d78b8a3911eb2ae43
  Author: Tyler Wilcock <[email protected]>
  Date:   2026-02-26 (Thu, 26 Feb 2026)

  Changed paths:
    A 
LayoutTests/accessibility/shadow-host-style-invalidation-during-text-under-element-crash-expected.txt
    A 
LayoutTests/accessibility/shadow-host-style-invalidation-during-text-under-element-crash.html
    M Source/WebCore/accessibility/AccessibilityNodeObject.cpp

  Log Message:
  -----------
  Cherry-pick 308173@main (54845b1b8742). 
https://bugs.webkit.org/show_bug.cgi?id=308467

    REGRESSION(305794@main): Unconditional CheckedPtr crash when loading any 
Reddit post with VoiceOver active
    https://bugs.webkit.org/show_bug.cgi?id=308467
    rdar://170985963

    Reviewed by Chris Fleizach.

    Narrow the scope of the CheckedPtr<RenderStyle> in 
AccessibilityNodeObject::textUnderElement
    (added in 305794@main)so it does not live across the child iteration loop.

    Previously, a CheckedPtr to the element's RenderStyle was captured at the
    top of the function and held until return. During child iteration,
    getOrCreate for a sibling slot element can trigger computedStyle() ->
    resolveComputedStyle(), which walks the ancestor chain and re-resolves
    the parent's m_computedStyle. This destroys the old RenderStyle that the
    CheckedPtr still references, resulting in a crash (EXC_GUARD from
    CheckedPtr accessing a scribbled-over object).

    This happens specifically for display:none shadow hosts with slot
    children, where a shadow-scoped stylesheet update sets
    IsComputedStyleInvalidFlag on the host and slots. The flag is never
    cleared by the style tree resolver because display:none subtrees without
    renderers are not visited during resolveStyle, and
    updateLayoutIgnorePendingStylesheets considers style clean despite the
    flag persisting on non-rendered elements.

    * 
LayoutTests/accessibility/shadow-host-style-invalidation-during-text-under-element-crash-expected.txt:
 Added.
    * 
LayoutTests/accessibility/shadow-host-style-invalidation-during-text-under-element-crash.html:
 Added.
    * Source/WebCore/accessibility/AccessibilityNodeObject.cpp:
    (WebCore::AccessibilityNodeObject::textUnderElement const):

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

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


Compare: https://github.com/WebKit/WebKit/compare/0f3a360d1716...331ab4f97456

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

Reply via email to