I wanted to provide an update on the proposed change. A single site/bug was brought to my attention, and after reaching out to the site's team, the issue has been addressed. I have not seen any other concerns or bugs reported since then.
Given that the Beta period appears stable, I believe we can proceed with the launch in Chrome 144 as planned. I will update the Chrome Platform Status entry shortly. Thanks! On Wed, Oct 8, 2025 at 9:16 PM Grant Gryczan <[email protected]> wrote: > As a web application developer brought here from > https://github.com/whatwg/html/issues/7732, I would love to see this. I > would be able to eliminate a lot of JavaScript from what's served, > particularly from a library ( > https://www.npmjs.com/package/body-scroll-lock) that tries to emulate > this behavior. > > On Tuesday, October 7, 2025 at 2:06:47 PM UTC-4 Bruno Stasse wrote: > >> Web developer and library author (silkhq.com) dealing with scrolling >> substantially here. >> >> One risk of breakage with this change is patterns like carousels applying >> `overscroll-behavior: contain | none` on both axis to prevent the "swipe to >> go back" behavior in most desktop browsers, which didn't capture scrolling >> on the vertical axis so far, but will now, thus preventing page scrolling. >> I have looked for such pattern and could only find carousels properly using >> `overscroll-behavior-x: contain | none`, but I suspect there are such cases >> in the wild. >> >> That being said, this change would be very useful in many cases, as >> mentioned in the thread, so it may be worth breaking some stuff to fix >> others and match the spec. >> >> Le vendredi 19 septembre 2025 à 22:27:37 UTC+2, Zouhir Chahoud a écrit : >> >>> from a Web author perspective, it's quite common that we *attempt* to >>> lock scrolling on the document's scrolling element when certain side-panels >>> or overlays are rendered. >>> >>> With this proposal, instead of managing overflow on scrolling elements >>> with javascript at application level, the side-panel or overlay can -at >>> local level- specify the desired scroll chaining behavior with a 1 line of >>> CSS and without needing to know if content can scroll or not. Definitely a >>> great improvement. >>> >>> On Wednesday, September 17, 2025 at 9:41:11 AM UTC-7 Mike Taylor wrote: >>> >>>> LGTM3 >>>> On 9/17/25 11:36 a.m., Daniel Bratell wrote: >>>> >>>> LGTM2 for the plan Philip outlined below. >>>> >>>> /Daniel >>>> On 2025-09-17 17:28, Philip Jägenstedt wrote: >>>> >>>> We discussed this at the API owners meeting today. (Present: Daniel, >>>> Yoav, Alex, Chris, Mike, Dan, Vlad, me.) >>>> >>>> LGTM1 >>>> >>>> Based on the use counter (8%) and the number of sites checked (10) we >>>> don't have high confidence that this won't break something. However, we >>>> also don't have a concrete way to further reduce the uncertainty beyond >>>> manually checking hundreds of sites and making a judgment call about >>>> whether each is improved or not, which does not feel reasonable. >>>> >>>> Instead, to shake out as much breakage as we can, we'd like to let this >>>> bake at 100% on beta for ~4 weeks (one extra milestone) and monitor for >>>> bugs. If there's nothing concerning, then launch at 100% on stable, while >>>> being prepared to revert if there are reports at that point. >>>> >>>> If you could report back here before going to stable that would be >>>> great, but no further approvals needed if things are looking good. >>>> >>>> On Wed, Sep 17, 2025 at 5:11 PM Alex Russell <[email protected]> >>>> wrote: >>>> >>>>> Thanks. I'm pinging people. Hopefully folks can weigh in here quickly. >>>>> >>>>> On Tuesday, September 16, 2025 at 7:11:54 AM UTC-7 Robert Flack wrote: >>>>> >>>>>> I completely agree, the point here isn't to follow the spec. The >>>>>> reason I think we should follow the spec in this case is that it is more >>>>>> ergonomic and predictable when applying overscroll-behavior doesn't just >>>>>> work sometimes. I think that developers are rightfully confused by those >>>>>> cases where it doesn't work which is why we have had several bugs filed >>>>>> about it. >>>>>> >>>>>> I have reached out to a few web developers. If you know anyone who >>>>>> might have thoughts on this please loop them in as well. >>>>>> >>>>>> On Mon, Sep 15, 2025 at 2:00 PM Alex Russell <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> I'd love for web developers who have been paying close attention to >>>>>>> scroll behaviour to weigh in here. This has been a deep well of sadness >>>>>>> in >>>>>>> a cross-browser sense, and they might have opinions as to the benefits >>>>>>> and >>>>>>> costs we aren't able to easily see. Spec compliance can either be great >>>>>>> or >>>>>>> pointless, and it would be helpful to get a sense from folks building >>>>>>> complex UIs which this is. >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>> On Friday, September 12, 2025 at 10:53:50 AM UTC-7 Robert Flack >>>>>>> wrote: >>>>>>> >>>>>>>> > is there any plausible pattern where web developers could depend >>>>>>>> on the current behavior intentionally? >>>>>>>> >>>>>>>> The change in behavior comes in roughly three patterns: >>>>>>>> >>>>>>>> 1. overscroll-behavior: contain | none is specified on an >>>>>>>> element with overflow: hidden. In these cases the >>>>>>>> overscroll-behavior used to have no effect, scrolls would propagate >>>>>>>> past >>>>>>>> the element to ancestor scrollers. In practice, when a developer has >>>>>>>> specified this they likely intended to prevent scroll propagation, >>>>>>>> however >>>>>>>> due to the implementation it had no effect. Authors typically try >>>>>>>> to do >>>>>>>> this to prevent scrolling while a modal dialog is open from >>>>>>>> scrolling the >>>>>>>> content behind it, e.g. as in the example posted to the bug >>>>>>>> <https://issues.chromium.org/issues/41371072> >>>>>>>> https://codepen.io/rctneil/pen/rJYONj. >>>>>>>> 2. The author specified overscroll-behavior: contain | none but >>>>>>>> on an element with overflow-y: scroll | auto (but implicit >>>>>>>> overflow-x: hidden). In this case, they may have accidentally >>>>>>>> applied >>>>>>>> overscroll-behavior to both axes and not realized that by spec this >>>>>>>> prevents overscroll propagation in both axes. I observed this on >>>>>>>> https://lichess.org/ though blocking horizontal scrolls on the >>>>>>>> open menu would not break using the site. >>>>>>>> 3. The author specified overscroll-behavior: contain | none on >>>>>>>> an element with overflow: scroll | auto. In this case, we have >>>>>>>> the unpredictable behavior that when you have overflow it prevents >>>>>>>> propagation, but if your containing element is large enough for its >>>>>>>> content >>>>>>>> then we don't. This is the common case for things like scrolling in >>>>>>>> a chat >>>>>>>> widget (demo <https://output.jsbin.com/helovikizu>, bug >>>>>>>> <https://issues.chromium.org/issues/40748098>) or in an >>>>>>>> embedded frame (bug >>>>>>>> <https://issues.chromium.org/issues/40736788>). >>>>>>>> >>>>>>>> Case 1 and 2 are sort of the same, overflow: hidden now preventing >>>>>>>> scroll propagation, but in case 1 it never did anything before so it >>>>>>>> feels >>>>>>>> similar to an author using a property that doesn't work yet. >>>>>>>> >>>>>>>> If we want to be conservative, we could only change the behavior >>>>>>>> for cases where it is currently layout dependent, i.e. case 3 overflow: >>>>>>>> auto | scroll. This would be an improvement however it wouldn't >>>>>>>> help with case 1 where you want to prevent scrolling from your >>>>>>>> component >>>>>>>> without risking that containing element becoming scrollable. Cases 1 >>>>>>>> and 2 >>>>>>>> are possible that developers are relying on this being incorrectly >>>>>>>> ignored >>>>>>>> and not preventing scroll propagation on overflow: hidden, similar to >>>>>>>> for >>>>>>>> example ignoring left or top on position: static. >>>>>>>> >>>>>>>> That said, I do think it would be more useful and predictable for >>>>>>>> it to apply to all scroll containers as it is spec'd. >>>>>>>> >>>>>>>> On Fri, Sep 12, 2025 at 4:15 AM Philip Jägenstedt < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hey Rob, >>>>>>>>> >>>>>>>>> Since the use counter is 8%, looking at 10 random popular sites >>>>>>>>> doesn't reduce the upper bound of breakage by a whole lot. Using the >>>>>>>>> rule >>>>>>>>> of three >>>>>>>>> <https://en.wikipedia.org/wiki/Rule_of_three_(statistics)> gives >>>>>>>>> 95% confidence that the rate of breakage is between 0 and 30%. But >>>>>>>>> 30% of >>>>>>>>> 8% is still a huge number when it comes to potential breakage. >>>>>>>>> (Reducing >>>>>>>>> this to a reasonable number with more random sampling isn't really >>>>>>>>> feasible >>>>>>>>> either, you'd need to test 800 sites with only negatives to get down >>>>>>>>> to >>>>>>>>> 0.03% if my math is right.) >>>>>>>>> >>>>>>>>> The fact that the change seems to make things work better and >>>>>>>>> aligns with apparent developer intention is great. But is there any >>>>>>>>> plausible pattern where web developers could depend on the current >>>>>>>>> behavior >>>>>>>>> intentionally? >>>>>>>>> >>>>>>>>> In a situation like this I think we should also consider how many >>>>>>>>> sites we fix and not just how many we break. If we have high >>>>>>>>> confidence >>>>>>>>> that many sites will be improved but can't find any that would >>>>>>>>> regress, >>>>>>>>> then that seems like a good trade even if some regressions do surface. >>>>>>>>> >>>>>>>>> If other vendors are interested in making the same change and >>>>>>>>> there's clear developer demand, I think we should try it, with a >>>>>>>>> Finch kill >>>>>>>>> switch in place. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Philip >>>>>>>>> >>>>>>>>> On Thu, Sep 11, 2025 at 10:13 PM Robert Flack <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Note that this is a repost of >>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/p2edIq4J-eQ/m/5MxPnuT8AwAJ >>>>>>>>>> as an I2S instead of PSA as I am seeking and will await LGTMs >>>>>>>>>> considering >>>>>>>>>> the potential compat risk. >>>>>>>>>> >>>>>>>>>> On the associated bug I have looked at a sampling of 10 popular >>>>>>>>>> sites affected by the overscroll-behavior change on httparchive >>>>>>>>>> <https://issues.chromium.org/issues/41371072#comment45> and >>>>>>>>>> found it to either not impact them or be beneficial: >>>>>>>>>> 1. https://lichess.org/ On smaller screens the `#topnav` element >>>>>>>>>> opens in a menu. The application of overscroll behavior seems to be >>>>>>>>>> there >>>>>>>>>> to prevent scrolling the content and so this site will be improved >>>>>>>>>> by the >>>>>>>>>> change. >>>>>>>>>> 2. https://cardgames.io/ Seems to just be the body element that >>>>>>>>>> has overscrollBehavior set. This shouldn't be affected. >>>>>>>>>> 3. https://open.spotify.com/ The body and "your library" panel >>>>>>>>>> fit into this case. I think this change would apply the intended >>>>>>>>>> behavior >>>>>>>>>> as they do not seem to intend for the scroll to propagate. >>>>>>>>>> 4. https://www.accuweather.com/ Only the body has overscroll >>>>>>>>>> behavior specified. >>>>>>>>>> 5. https://www.ikea.com/ Their mobile menu `#top-mobile-menu` >>>>>>>>>> has overscroll-behavior on it. This is presumably to prevent >>>>>>>>>> accidental >>>>>>>>>> pull to refresh while scrolling through the menu and would be fixed >>>>>>>>>> by this >>>>>>>>>> change. >>>>>>>>>> 6. https://www.tiktok.com/explore The side nav has contain >>>>>>>>>> overscroll-behavior. With this change you would no longer be able to >>>>>>>>>> scroll >>>>>>>>>> the main page by scrolling on top of the sidebar. This seems to be >>>>>>>>>> the >>>>>>>>>> intention but is not currently being honored. >>>>>>>>>> 7. https://x.com/ Only the root element seems to have >>>>>>>>>> overscroll-behavior defined. >>>>>>>>>> 8. https://store.epicgames.com/ I'm unable to find the affected >>>>>>>>>> element >>>>>>>>>> 9. https://www.airbnb.com/ There are several scrolling >>>>>>>>>> containers with overscroll-behavior defined however I think these >>>>>>>>>> are only >>>>>>>>>> "not scrollable" while the page is loading. By the time the user >>>>>>>>>> interacts >>>>>>>>>> with them they have scrollable overflow and so are unaffected. The >>>>>>>>>> usage >>>>>>>>>> also seems to indicate they would not want scroll to chain past those >>>>>>>>>> containers. >>>>>>>>>> 10. https://www.expedia.com/ I'm not able to find where the >>>>>>>>>> property is used. >>>>>>>>>> >>>>>>>>>> In terms of developer demand, there are many bugs that have been >>>>>>>>>> duped into https://issues.chromium.org/issues/41371072 all >>>>>>>>>> concerned that the incorrect behavior currently implemented in all >>>>>>>>>> browsers >>>>>>>>>> prevents using it for the intended purposes. In particular, >>>>>>>>>> developers want >>>>>>>>>> to be able to use overscroll-behavior without the unpredictability of >>>>>>>>>> whether it applies depending on the layout of their scrolling >>>>>>>>>> content. >>>>>>>>>> >>>>>>>>>> Common uses for this include, >>>>>>>>>> 1. Preventing scrolling in inner widgets from chaining to >>>>>>>>>> document scrolls >>>>>>>>>> 2. Preventing scrolling on a dialog covering the page from >>>>>>>>>> chaining to and scrolling the page >>>>>>>>>> 3. Preventing scrolling on a menu from chaining to and scrolling >>>>>>>>>> the page. >>>>>>>>>> >>>>>>>>>> Right now, authors have to carefully ensure that they have >>>>>>>>>> overflow: auto and some scrolling content and then presumably hide >>>>>>>>>> the >>>>>>>>>> scrollbar in cases where they are only adding overflow: auto; to >>>>>>>>>> allow >>>>>>>>>> overscroll-behavior to apply. >>>>>>>>>> >>>>>>>>>> On Thu, Sep 11, 2025 at 4:06 PM Robert Flack <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Contact emails [email protected], [email protected] >>>>>>>>>>> >>>>>>>>>>> Specification >>>>>>>>>>> https://www.w3.org/TR/css-overscroll-1/#propdef-overscroll-behavior >>>>>>>>>>> >>>>>>>>>>> Summary >>>>>>>>>>> >>>>>>>>>>> The overscroll-behavior applies to all scroll container >>>>>>>>>>> elements, regardless of whether those elements currently have >>>>>>>>>>> overflowing >>>>>>>>>>> content or are user scrollable. Developers can use >>>>>>>>>>> overscroll-behavior to >>>>>>>>>>> prevent scroll propagation on an `overflow: hidden` backdrop or an >>>>>>>>>>> `overflow: auto` element without needing to consider whether it will >>>>>>>>>>> currently be overflowing. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Blink component Blink>Scroll >>>>>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EScroll%22> >>>>>>>>>>> >>>>>>>>>>> Web Feature ID overscroll-behavior >>>>>>>>>>> <https://webstatus.dev/features/overscroll-behavior> >>>>>>>>>>> >>>>>>>>>>> TAG review None >>>>>>>>>>> >>>>>>>>>>> TAG review status Not applicable >>>>>>>>>>> >>>>>>>>>>> Risks >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>> >>>>>>>>>>> This should be implemented on other browsers as well, as it >>>>>>>>>>> matches the specification. However, until this happens there are >>>>>>>>>>> compatibility risks that some sites may over accidentally set >>>>>>>>>>> overscroll-behavior on elements which don't currently apply today >>>>>>>>>>> (either >>>>>>>>>>> overflow: auto or not having overflow) and will start applying, or >>>>>>>>>>> that >>>>>>>>>>> developers will rely on this behavior and have accidental scroll >>>>>>>>>>> chaining >>>>>>>>>>> in other browsers until they implement it as well. This change will >>>>>>>>>>> affect >>>>>>>>>>> a large number of sites per >>>>>>>>>>> https://chromestatus.com/metrics/feature/timeline/popularity/5596. >>>>>>>>>>> I have done compat analysis of many of the top sites affected by >>>>>>>>>>> this in >>>>>>>>>>> https://issues.chromium.org/issues/41371072#comment45 and found >>>>>>>>>>> it to either not have a meaningful impact or to better honor the >>>>>>>>>>> developer >>>>>>>>>>> specified intent. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *Gecko*: No signal >>>>>>>>>>> >>>>>>>>>>> *WebKit*: No signal >>>>>>>>>>> >>>>>>>>>>> *Web developers*: No signals >>>>>>>>>>> >>>>>>>>>>> *Other signals*: >>>>>>>>>>> >>>>>>>>>>> Ergonomics >>>>>>>>>>> >>>>>>>>>>> This improves the ergonomics of overscroll-behavior, fixing the >>>>>>>>>>> current unpredictable layout dependent behavior we have today. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Activation >>>>>>>>>>> >>>>>>>>>>> It may be difficult for developers to take advantage of this fix >>>>>>>>>>> before it is adopted in other browsers as it is likely not possible >>>>>>>>>>> to >>>>>>>>>>> feature detect. They could remove pre-existing hacks to get this >>>>>>>>>>> functionality (i.e. ensuring 1px overflow) on supporting chromium >>>>>>>>>>> browsers. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> WebView application risks >>>>>>>>>>> >>>>>>>>>>> Does this intent deprecate or change behavior of existing APIs, >>>>>>>>>>> such that it has potentially high risk for Android WebView-based >>>>>>>>>>> applications? >>>>>>>>>>> >>>>>>>>>>> None >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Debuggability >>>>>>>>>>> >>>>>>>>>>> None >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>>> (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? >>>>>>>>>>> Yes >>>>>>>>>>> >>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>> ? Yes >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://wpt.fyi/results/css/css-overscroll-behavior/overscroll-behavior-without-overflow.html?label=experimental&label=master&aligned >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Flag name on about://flags None >>>>>>>>>>> >>>>>>>>>>> Finch feature name OverscrollBehaviorRespectedOnA >>>>>>>>>>> llScrollContainers >>>>>>>>>>> >>>>>>>>>>> Rollout plan Will ship enabled for all users >>>>>>>>>>> >>>>>>>>>>> Requires code in //chrome? False >>>>>>>>>>> >>>>>>>>>>> Measurement The OverscrollBehaviorOnNonScrollableScrollContainer >>>>>>>>>>> feature counter measures how often this new behavior is or would be >>>>>>>>>>> triggered. >>>>>>>>>>> https://chromestatus.com/metrics/feature/timeline/popularity/5596 >>>>>>>>>>> >>>>>>>>>>> Sample links >>>>>>>>>>> https://ebidel.github.io/demos/chatbox.html >>>>>>>>>>> https://codepen.io/rctneil/pen/rJYONj >>>>>>>>>>> >>>>>>>>>>> Estimated milestones >>>>>>>>>>> >>>>>>>>>>> No milestones specified >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Anticipated spec changes >>>>>>>>>>> >>>>>>>>>>> Open questions about a feature may be a source of future web >>>>>>>>>>> compat or interop issues. Please list open issues (e.g. links to >>>>>>>>>>> known >>>>>>>>>>> github issues in the project for the feature specification) whose >>>>>>>>>>> resolution may introduce web compat/interop risk (e.g., changing to >>>>>>>>>>> naming >>>>>>>>>>> or structure of the API in a non-backward-compatible way). >>>>>>>>>>> None >>>>>>>>>>> >>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>> https://chromestatus.com/feature/5129635997941760?gate=5124735842910208 >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>> Google Groups "blink-dev" group. >>>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>>> send an email to [email protected]. >>>>>>>>>> To view this discussion visit >>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TPripgF_DY4adqs9wbtQV8XRTVdXER3SOR0-52SczULBA%40mail.gmail.com >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TPripgF_DY4adqs9wbtQV8XRTVdXER3SOR0-52SczULBA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "blink-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdPV-itQEK%2BbSPAR0u3SfLOqvSEe57TA5SFKRDTODi16g%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdPV-itQEK%2BbSPAR0u3SfLOqvSEe57TA5SFKRDTODi16g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "blink-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> >>>> To view this discussion visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bbb963e9-9acb-49b9-ae02-4c82e88d4e6d%40gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bbb963e9-9acb-49b9-ae02-4c82e88d4e6d%40gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TODPdOwQd0XEOAbQPW-f%2Bohuzms2e72eAx95yT6UFY_og%40mail.gmail.com.
