Re: [blink-dev] Re: What to do about scroll anchoring?
Hi Emlio, Thanks for your patience with these fixes and taking the time to outline your concerns. Hope things are better now, and as always, if not just say so. :) Chris On Thu, Feb 20, 2020 at 7:39 AM Emilio Cobos Álvarez wrote: > A quick status update here: > > I landed some heuristics to disable scroll anchoring in pathological > cases in Firefox a long while ago. This stopped virtually all compat > issues, though it's obviously not great. > > Chris and other Chromium folks have been doing work to fix Chromium > issues that were causing these interop problems, and improving the > scroll anchoring spec. > > So I'm going to try and peek up those spec changes in Firefox and then > try to remove those heuristics on Nightly, and see how it goes. > > -- Emilio > > On 11/7/19 12:07 AM, Chris Harrelson wrote: > > HI Emilio, > > > > I'll follow up on crbug.com/920289 <http://crbug.com/920289>. Let's > > discuss there. > > > > On Tue, Oct 29, 2019 at 3:03 PM Emilio Cobos Álvarez > <mailto:emi...@mozilla.com>> wrote: > > > > Hi all, > > > >10/18/19 7:19 PM, Chris Harrelson wrote: > > > Hi, > > > > > > Another quick update: Emilio, Navid, Nick, Stefan and I met today > and > > > discussed which issues are important to fix and why. We now have > > a list of > > > spec issues, and WPT tests to fix that are Chromium bugs, that > should > > > substantially improve interop. Nick and Stefan will take on the > > work to fix > > > them, with the review and feedback support of Emilio. > > > > So, today another scroll-anchoring bug crossed my radar, and this one > > I'm not sure at all how to fix it, because there's no obvious answer > > here as far as I can tell. > > > > My diagnosis (for one of the pages, the one I could repro and > > reduce) is > > in here[1], but basically my current explanation is that the page > > should > > be broken per spec, and that when it works it's hitting a bug in both > > Chromium[2] which we have an equivalent of but are just not hitting > > because in Firefox changing `overflow` does more/different layout > work > > than in Chrome. > > > > The test-case may as well work if we change our scroll event or timer > > scheduling (see there), but that is obviously pretty flaky. > > > > I honestly don't have many better ideas for more fancy heursitics > about > > how to unbreak that kind of site. From the point of view of the > > anchoring code, the page is just toggling height somewhere above the > > anchor, which is the case where scroll anchoring _should_ work, > usually. > > > > I can, of course (and may as a short-term band-aid, not sure yet) add > > `overflow` to the magic list of properties like `position` that > > suppress > > scroll anchoring everywhere in the scroller, but that'd be just > kicking > > the can down the road and waiting for the next difference in layout > > performance optimizations between Blink and Gecko to hit us. > > > > I think (about to go on PTO for the next of the week) I'll add > > telemetry > > for pages that have scroll event listeners, and see if disabling > scroll > > anchoring on a node when there are scroll event listeners attached > > to it > > is something reasonable (plus adding an explicit opt-in of course). > > > > I'm not terribly hopeful that the percentage of such documents is > going > > to be terribly big, to be honest, but providing an opt-in and doing > > outreach may be a reasonable alternative. > > > > Another idea would be to restrict the number of consecutive scrolls > > made > > by scroll anchoring to a given number at most. That would made the > > experience in such broken websites somewhat less annoying, but it'll > > also show flickering until that happens, which would make the browser > > still look broken :/. > > > > Thoughts / ideas I may not have thought of/be aware of? > > > > Thanks, > > > >-- Emilio > > > > [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1592094#c15 > > <https://bugzilla.mozilla.org/show_bug.cgi?id=1592094#c15> > > [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=920289 > > <https://bugs.chromium.org/p/chromium/issues/detail?id=920289> > > > > > Thanks all, > > &
Re: [blink-dev] Re: What to do about scroll anchoring?
HI Emilio, I'll follow up on crbug.com/920289. Let's discuss there. On Tue, Oct 29, 2019 at 3:03 PM Emilio Cobos Álvarez wrote: > Hi all, > > 10/18/19 7:19 PM, Chris Harrelson wrote: > > Hi, > > > > Another quick update: Emilio, Navid, Nick, Stefan and I met today and > > discussed which issues are important to fix and why. We now have a list > of > > spec issues, and WPT tests to fix that are Chromium bugs, that should > > substantially improve interop. Nick and Stefan will take on the work to > fix > > them, with the review and feedback support of Emilio. > > So, today another scroll-anchoring bug crossed my radar, and this one > I'm not sure at all how to fix it, because there's no obvious answer > here as far as I can tell. > > My diagnosis (for one of the pages, the one I could repro and reduce) is > in here[1], but basically my current explanation is that the page should > be broken per spec, and that when it works it's hitting a bug in both > Chromium[2] which we have an equivalent of but are just not hitting > because in Firefox changing `overflow` does more/different layout work > than in Chrome. > > The test-case may as well work if we change our scroll event or timer > scheduling (see there), but that is obviously pretty flaky. > > I honestly don't have many better ideas for more fancy heursitics about > how to unbreak that kind of site. From the point of view of the > anchoring code, the page is just toggling height somewhere above the > anchor, which is the case where scroll anchoring _should_ work, usually. > > I can, of course (and may as a short-term band-aid, not sure yet) add > `overflow` to the magic list of properties like `position` that suppress > scroll anchoring everywhere in the scroller, but that'd be just kicking > the can down the road and waiting for the next difference in layout > performance optimizations between Blink and Gecko to hit us. > > I think (about to go on PTO for the next of the week) I'll add telemetry > for pages that have scroll event listeners, and see if disabling scroll > anchoring on a node when there are scroll event listeners attached to it > is something reasonable (plus adding an explicit opt-in of course). > > I'm not terribly hopeful that the percentage of such documents is going > to be terribly big, to be honest, but providing an opt-in and doing > outreach may be a reasonable alternative. > > Another idea would be to restrict the number of consecutive scrolls made > by scroll anchoring to a given number at most. That would made the > experience in such broken websites somewhat less annoying, but it'll > also show flickering until that happens, which would make the browser > still look broken :/. > > Thoughts / ideas I may not have thought of/be aware of? > > Thanks, > > -- Emilio > > [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1592094#c15 > [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=920289 > > > Thanks all, > > Chris > > > > > > On Thu, Oct 10, 2019 at 2:13 PM Rick Byers wrote: > > > >> Sorry for the delay. > >> > >> We agree that scroll anchoring has unrealized potential to be valuable > for > >> the web at large, and to make that happen we should be investing a lot > more > >> working with y'all (and if we can't succeed, probably removing it from > >> chromium). Concretely +Chris Harrelson who leads rendering for Chrome > (and > >> likely someone else from his team), as well as +Nick Burris from the > Chrome > >> input team will start digging in ASAP. In addition to just the normal > >> high-bandwidth engineer-to-engineer collaboration between chromium and > >> gecko I propose the following high-level goals for our work: > >> > >> - Ensure that there are no known deviations in behavior between > >> chromium and the spec (one way or the other). > >> - Ensure all the (non-ua-specific) site compat constraints folks are > >> hitting are captured in web-platform-tests. I.e. if Gecko passes > the tests > >> and serves a chromium UA string it should work as well as in Chrome > (modulo > >> other unrelated UA compat issues of course). > >> - Look for any reasonable opportunity to help deal with UA-specific > >> compat issues (i.e. those that show up on sites that are explicitly > looking > >> for a Gecko UA string or other engine-specific feature). This may > include > >> making changes in the spec / chromium implementation. This is > probably the > >> toughest one, but I'm optimistic that if we nail the first two,
Re: [blink-dev] Re: What to do about scroll anchoring?
Hi, Another quick update: Emilio, Navid, Nick, Stefan and I met today and discussed which issues are important to fix and why. We now have a list of spec issues, and WPT tests to fix that are Chromium bugs, that should substantially improve interop. Nick and Stefan will take on the work to fix them, with the review and feedback support of Emilio. Thanks all, Chris On Thu, Oct 10, 2019 at 2:13 PM Rick Byers wrote: > Sorry for the delay. > > We agree that scroll anchoring has unrealized potential to be valuable for > the web at large, and to make that happen we should be investing a lot more > working with y'all (and if we can't succeed, probably removing it from > chromium). Concretely +Chris Harrelson who leads rendering for Chrome (and > likely someone else from his team), as well as +Nick Burris from the Chrome > input team will start digging in ASAP. In addition to just the normal > high-bandwidth engineer-to-engineer collaboration between chromium and > gecko I propose the following high-level goals for our work: > >- Ensure that there are no known deviations in behavior between >chromium and the spec (one way or the other). >- Ensure all the (non-ua-specific) site compat constraints folks are >hitting are captured in web-platform-tests. I.e. if Gecko passes the tests >and serves a chromium UA string it should work as well as in Chrome (modulo >other unrelated UA compat issues of course). >- Look for any reasonable opportunity to help deal with UA-specific >compat issues (i.e. those that show up on sites that are explicitly looking >for a Gecko UA string or other engine-specific feature). This may include >making changes in the spec / chromium implementation. This is probably the >toughest one, but I'm optimistic that if we nail the first two, we can find >some reasonable tradeoff for the hard parts that are left here. Philip (our >overall interop lead) has volunteered to help out here as well. > > Does that sound about right? Any suggestions on the best forum for tight > engineering collaboration? GitHub good enough, or maybe get on an IRC / > slack channel together somewhere? > > Rick > > On Mon, Oct 7, 2019 at 2:11 PM Mike Taylor wrote: > >> Hi Rick, >> >> On 9/28/19 10:07 PM, Rick Byers wrote: >> > Can you give us a week or so to chat about this within the Chrome team >> > and get back to you? >> >> Any updates here? >> >> Thanks. >> >> -- >> Mike Taylor >> Web Compat, Mozilla >> > -- > 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 blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-DPW4tXA_R-c0WAj76Qtj4TYdjwHai3odyNdWYVfJhZA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-DPW4tXA_R-c0WAj76Qtj4TYdjwHai3odyNdWYVfJhZA%40mail.gmail.com?utm_medium=email_source=footer> > . > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [blink-dev] Re: What to do about scroll anchoring?
On Sun, Sep 29, 2019 at 2:24 PM Emilio Cobos Álvarez wrote: > pretty significant behavior differences were only > caught later by me and people finding compat issues in the wild, like > [3]. I was sad that the spec reflected absolutely nothing like what > Blink implements. For this issue in particular, Blink roughly uses > "whatever inherits from LayoutBox can be an anchor", which is obviously > not something that you can reasonably spec, and definitely not "block > boxes and text", which is what the spec said. > Quick note: this one can be spec'ed. The classes that inherit from LayoutBox all map directly to spec concepts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
