Branch: refs/heads/webkitglib/2.52
  Home:   https://github.com/WebKit/WebKit
  Commit: d1b06145a16e811421f34e40a5e460bf0920a196
      
https://github.com/WebKit/WebKit/commit/d1b06145a16e811421f34e40a5e460bf0920a196
  Author: Sammy Gill <[email protected]>
  Date:   2026-03-11 (Wed, 11 Mar 2026)

  Changed paths:
    M 
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/keyword-sizes-on-replaced-element-expected.txt
    A 
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/replaced-max-width-with-height-fit-content-expected.html
    A 
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/replaced-max-width-with-height-fit-content-ref.html
    A 
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/replaced-max-width-with-height-fit-content.html
    A 
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/replaced-max-width-with-height-max-content-expected.html
    A 
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/replaced-max-width-with-height-max-content-ref.html
    A 
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/replaced-max-width-with-height-max-content.html
    A 
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/replaced-max-width-with-height-min-content-expected.html
    A 
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/replaced-max-width-with-height-min-content-ref.html
    A 
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/replaced-max-width-with-height-min-content.html
    M Source/WebCore/rendering/RenderBox.cpp
    M Source/WebCore/rendering/RenderReplaced.cpp

  Log Message:
  -----------
  Cherry-pick 308995@main (99ecafd045f5). 
https://bugs.webkit.org/show_bug.cgi?id=309086

    glance.cx: Home page shows stretched image next to "Employee Workspaces" 
section.
    https://bugs.webkit.org/show_bug.cgi?id=309086
    rdar://168264069

    Reviewed by Alan Baradlay.

    The aforementioned image on the glance.cx homepage has styling with
    width: 100%, max-width: 100%, and height: fit-content. We compute the width
    of the image to be the same size as other engines, but the height of the
    image is much taller compared to the others. In fact, the height of the
    image comes from the natural size of it.

    We currently see to return the intrinsic size of the image when computing
    the fit-content size in 
RenderReplaced::computeReplacedLogicalHeightUsingGeneric,
    which gets from eventually calling into 
computeIntrinsicLogicalContentHeightUsingGeneric.
    This seems to be fine according to the way the intrinsic height is supposed
    to be computed according to CSS-Box-Sizing-3, which defers to some language
    from CSS2:
    https://www.w3.org/TR/2021/WD-css-sizing-3-20211217/#intrinsic-sizes

    However, there is an additional note that we do not seem to be taking
    into account.
    Note: When the box has a preferred aspect ratio, size constraints in the
    opposite dimension will transfer through and can affect the auto size in
    the considered one.

    Essentially, we are not taking into consideration the transferred min/max
    size constraints using those properties and the aspect ratio. The spec seems
    to imply that we should be doing this since it has some language that says
    it’s sized as "if it was a float given an auto size in that axis," and 
includes
    that note below the text.

    So here we just apply those transferred size constraints by using the
    computeMinMaxLogicalHeightFromAspectRatio helper that computes them and
    clamping the intrinsic size between them. I also went ahead and did this
    for the min-content and max-content cases since it was trivial to create
    those test cases and it seems like that is what other engines are doing
    as well. However, I did not do it for the WebkitFillAvailable since other
    engines end up actually using the intrinsic size in that case.

    Tests: 
imported/w3c/web-platform-tests/css/css-sizing/replaced-max-width-with-height-fit-content-ref.html
           
imported/w3c/web-platform-tests/css/css-sizing/replaced-max-width-with-height-fit-content.html
           
imported/w3c/web-platform-tests/css/css-sizing/replaced-max-width-with-height-max-content-ref.html
           
imported/w3c/web-platform-tests/css/css-sizing/replaced-max-width-with-height-max-content.html
           
imported/w3c/web-platform-tests/css/css-sizing/replaced-max-width-with-height-min-content-ref.html
           
imported/w3c/web-platform-tests/css/css-sizing/replaced-max-width-with-height-min-content.html

    * 
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/keyword-sizes-on-replaced-element-expected.txt:
    Rebasing this test since we were previously failing it and are still failing
    it, but the sizes of the boxes do seem to be much closer to what is 
expected.
    * Source/WebCore/rendering/RenderBox.cpp:
    (WebCore::RenderBox::computeMinMaxLogicalHeightFromAspectRatio const):
    We already make sure that the transferred max size is at least as large
    as the min at the end of this function, but I think it would be nice
    to have this be a bit more resilient to changes by having a ScopeExit
    check for this in debug builds.

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

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


  Commit: 9611dca55ba3719647f409508b62b64d2634d330
      
https://github.com/WebKit/WebKit/commit/9611dca55ba3719647f409508b62b64d2634d330
  Author: Simon Fraser <[email protected]>
  Date:   2026-03-11 (Wed, 11 Mar 2026)

  Changed paths:
    A 
LayoutTests/http/tests/navigation-api/scroll-offset-after-navigation-back-expected.html
    A 
LayoutTests/http/tests/navigation-api/scroll-offset-after-navigation-back.html
    M Source/WebCore/page/NavigateEvent.cpp

  Log Message:
  -----------
  Cherry-pick 308976@main (63798105bff3). 
https://bugs.webkit.org/show_bug.cgi?id=309542

    Pages using the Navigation API sometimes have offset hit test locations
    https://bugs.webkit.org/show_bug.cgi?id=309542
    rdar://171752650

    Reviewed by Abrar Rahman Protyasha.

    Navigation API was calling `LocalFrameView::scrollTo()`, which bypasses the 
normal async
    scrolling `requestScrollPositionUpdate` machinery; there's a comment in 
ScrollView.h about
    not calling this function. This could result in UI and web processes having 
different
    scroll offsets.

    Fix by having NavigateEvent call `setScrollPosition` instead.

    Test: http/tests/navigation-api/scroll-offset-after-navigation-back.html

    * 
LayoutTests/http/tests/navigation-api/scroll-offset-after-navigation-back-expected.html:
 Added.
    * 
LayoutTests/http/tests/navigation-api/scroll-offset-after-navigation-back.html: 
Added.
    * Source/WebCore/page/NavigateEvent.cpp:
    (WebCore::NavigateEvent::processScrollBehavior):

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

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


Compare: https://github.com/WebKit/WebKit/compare/487107cb4556...9611dca55ba3

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

Reply via email to