Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: d146201b066c48c4254e948676a683a02bfa3402
      
https://github.com/WebKit/WebKit/commit/d146201b066c48c4254e948676a683a02bfa3402
  Author: Wenson Hsieh <wenson_hs...@apple.com>
  Date:   2025-08-07 (Thu, 07 Aug 2025)

  Changed paths:
    A 
LayoutTests/fast/page-color-sampling/blend-modal-background-color-expected.txt
    A LayoutTests/fast/page-color-sampling/blend-modal-background-color.html
    M Source/WebCore/page/LocalFrameView.cpp
    M Source/WebCore/page/Page.cpp
    M Source/WebCore/page/Page.h

  Log Message:
  -----------
  [Liquid Glass] indiatimes.com: opening the hamburger menu before scrolling 
causes the top scroll pocket to disappear
https://bugs.webkit.org/show_bug.cgi?id=297020
rdar://157665752

Reviewed by Abrar Rahman Protyasha and Megan Gardner.

When opening the hamburger menu on indiatimes.com without having scrolled the 
page, a dimming layer
appears over the page, which the heuristic in 
`LocalFrameView::fixedContainerEdges` correctly
identifies. We then attempt to take the sampled color (black at ~50% opacity) 
and use it as the
fixed color extension and solid color hard pocket background.

The problem with this is that `UIScrollView` internally rejects any rejects any 
explicitly-set
capture color that has an alpha < 1, instead treating the color as `nil`. This 
in turn breaks luma
tracking in the scroll pocket, resulting in an unexpected solid white top 
pocket in dark mode. To
mitigate this, we ensure that even in the modal "dimming layer" case, we always 
return an opaque
fixed color by blending the dimming layer's background color against the page 
background color (so
in this case, `rgba(0, 0, 0, 0.5)` against the white page background yields 
solid medium-gray).

It's also somewhat unexpected that the top scroll pocket background color 
changes as a result of the
user opening a menu — while our current policy prevents the pocket from 
changing after the user has
scrolled the page, it should probably extend to after the user has started 
interacting with the page
by clicking or tapping.

We fix both of these issues in this patch.

* 
LayoutTests/fast/page-color-sampling/blend-modal-background-color-expected.txt: 
Added.
* LayoutTests/fast/page-color-sampling/blend-modal-background-color.html: Added.
* Source/WebCore/page/LocalFrameView.cpp:
(WebCore::LocalFrameView::fixedContainerEdges const):

See above.

* Source/WebCore/page/Page.cpp:
(WebCore::Page::setUserDidInteractWithPage):
(WebCore::Page::didCommitLoad):
(WebCore::Page::updateFixedContainerEdges):

In addition to user-triggered scrolling, make it so that any other interaction 
with the page (i.e.
anything that triggers a user gesture token) will also prevent the sampled 
color from changing. This
prevents us from picking up the color change at all, in this case.

* Source/WebCore/page/Page.h:

Add a new flag to keep track of whether the user has interacted with the page, 
since the last load
committed.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to