*Gecko*: No signal
*WebKit*: No signal Could you file for standards positions as well*?* Seems this was not done? I commented here https://bugzil.la/1837436 and here https://webkit.org/b/243452 Robert Flack schrieb am Freitag, 31. Oktober 2025 um 15:14:19 UTC+1: > 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/3c331413-2087-4b65-a577-94e0ca396e50n%40chromium.org.
