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 <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 > [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 <rby...@chromium.org> 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 <mi...@mozilla.com> 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&utm_source=footer > > > >> . > >> > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > > > > -- > 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/8b44aa83-914f-344a-6da2-a56917230156%40mozilla.com > . > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform