[blink-dev] Re: What to do about scroll anchoring?

# Emilio Cobos Álvarez (a month ago)

On 9/27/19 4:03 PM, Steve Kobes wrote:

Hi Emilio,

My recollection is that scroll anchoring was, in fact, a mess. I do not personally have any opinion about whether scroll anchoring should be removed from Gecko.

We (Chrome) decided to accept some compat issues for the sake of launching the feature. This was a judgment call and could reasonably have gone the other way.

Right, my concern is that taking compat fallout with Chrome's market share may be acceptable, because people will likely fix their websites if they misbehave.

But web developers may not take the same time to fix their site if it's broken on Firefox for Android, for example, which in turn drives Firefox users away (and you know this is a vicious cycle, the less users you have, the less people will care about fixing their websites in your browser).

That being said, more generally, I care about being interoperable / predictable here for web developers, and seems like that ship may have sailed if we need to fix some Gecko-specific issues by tweaking our heuristics, but Chromium / Blink doesn't change them in the same way (which is understandable, I guess, though I've filed spec issues for our reasoning behind these changes, which I think would apply to Chrome as well).

Contact us to advertise here
# Emilio Cobos Álvarez (a month ago)

On 9/29/19 5:07 AM, Rick Byers wrote:

On Fri, Sep 27, 2019 at 10:16 AM Emilio Cobos Álvarez

<emilio at mozilla.com <mailto:emilio at mozilla.com>> wrote:

Hi Steve,

On 9/27/19 4:03 PM, Steve Kobes wrote:
 > Hi Emilio,
 >
 > My recollection is that scroll anchoring was, in fact, a mess.  I
do not
 > personally have any opinion about whether scroll anchoring should be
 > removed from Gecko.
 >
 > We (Chrome) decided to accept some compat issues for the sake of
 > launching the feature.  This was a judgment call and could
reasonably
 > have gone the other way.

Right, my concern is that taking compat fallout with Chrome's market
share may be acceptable, because people will likely fix their websites
if they misbehave.

But web developers may not take the same time to fix their site if it's
broken on Firefox for Android, for example, which in turn drives
Firefox
users away (and you know this is a vicious cycle, the less users you
have, the less people will care about fixing their websites in your
browser).

That being said, more generally, I care about being interoperable /
predictable here for web developers, and seems like that ship may have
sailed if we need to fix some Gecko-specific issues by tweaking our
heuristics, but Chromium / Blink doesn't change them in the same way
(which is understandable, I guess, though I've filed spec issues for
our
reasoning behind these changes, which I think would apply to Chrome as
well).

FWIW, I agree with this principle. I'm sorry you've had to do a lot of compat work on this Emilio. Are you saying you've found many cases where chromium's behavior doesn't match the spec / web-platform-tests and the different is relevant to real-world website compat (forcing you to invest in "bug-for-bug compatibility")? That would definitely make me very sad. Or is the issue more about compat with sites which have UA-conditional behavior (either explicit or implicit based on some other Gecko/blink difference?).

Well, part of it is that. The initial implementation took a lot of just figuring out what Chromium was doing rather than implementing the spec, because the spec had clear issues (like referencing the DOM rather than layout stuff).

Some of them like 1 were pretty obvious and were caught during our initial implementation of the feature. Others like 2 Ryan probably found by testing Chromium's behavior.

Some other still 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.

Those are off the top of my head, Ryan probably has more examples.

IMHO In general, either an initially chromium-only feature is valuable enough that we should continue to invest as necessary to achieve interop with other engines when they implement (eg. adding web-platform-tests and improving the spec for the inevitable cases that appear with a second implementation), or we should decide the feature isn't worth the cost to properly support on the web at large and remove it from chromium.

Steve is the expert and can probably elaborate on details, but IIRC the real world web compat constraints of scroll anchoring ended up requiring a number of tough tradeoffs. If you're learning about new web compat constraints, then it's entirely possible that the cost/benefit equation is now different and we should be re-evaluating whether it still makes sense to keep scroll anchoring in chromium. Like David I like the feature - but only to the extent that it works alright for most of the web as it exists today, and developers can reliably reason about it (eg. by replacing any heuristics designed under the constraints of web-compat with explicit APIs).

Can you give us a week or so to chat about this within the Chrome team and get back to you?

Thanks, and sorry again for the frustration. When we ship a feature first in chromium, it's always our intent that subsequent compatible implementations should be MUCH easier to ship (it's one of the main reasons we invest so much in web-platform-tests).

Sure, no worries, and thanks for the reply.

-- Emilio

# Rick Byers (20 days ago)

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?

# Emilio Cobos Álvarez (a day ago)

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

Want more features?

Request early access to our private beta of readable email premium.