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, 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,
>
