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

[Chris Harrelson]

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

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

[Emilio Cobos Álvarez]

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 . 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 mailto: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 

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

[Chris Harrelson]

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

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

[Emilio Cobos Álvarez]

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,

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 

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

[Chris Harrelson]

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
> 
> .
>
___
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?

[Rick Byers]

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
>
___
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?

[Chris Harrelson]

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

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

[Rick Byers]

On Fri, Sep 27, 2019 at 10:16 AM Emilio Cobos Álvarez 
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?).

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).

  -- Emilio
>
> > On Fri, 27 Sep 2019 at 09:09, Emilio Cobos Álvarez  > > wrote:
> >
> > And, to be clear, we _can_ fix these compat issues, some way or
> another.
> >
> > One thought is to limit the amount of scroll adjustments without user
> > scrolling or stuff like that, which would prevent the "you get stuck
> on
> > the page".
> >
> > Making anchoring opt-in rather than opt-out is another option, but
> that
> > defeats most of the purpose of the feature, I guess.
> >
> > See also some of the Chromium docs on the compat issues they found[1]
> > and how were they trying to fix them before adding the
> > "layout-affecting-property changed" heuristic, which is what is on
> the
> > spec right now and what they implement.
> >
> > I just think that these are very hacky heuristics that are just
> > going to
> > bring a lot of compat pain and developer confusion.
> >
> > It doesn't help that all these things can break or not depending on
> the
> > speed at which the user scrolls, the amount of scroll events that the
> > user dispatches, the timing of these events relative to other
> > events, etc...
> >
> >-- Emilio
> >
> > [1]:
> >
> https://docs.google.com/document/d/1nQAO4MYCDMn0rTkn_-WI6gjumk3Qi2Bn-MGuB3NlVxE/edit
> > <
> https://docs.google.com/document/d/1nQAO4MYCDMn0rTkn_-WI6gjumk3Qi2Bn-MGuB3NlVxE/edit
> >
> >
> > On 9/27/19 2:23 PM, Emilio Cobos Álvarez wrote:
> >  > Hi,
> >  >
> >  > (cc'ing webkit-dev@ and blink-dev@ in case they have feedback or
> >  > opinions, as WebKit 

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

[Kenji Baheux via dev-platform]

Hi,

When we initially started, we did have a rough time but I haven't seen any
issue nor heard any negative feedback about it. As far as I can tell from
the metrics, it seems to save a lot of user frustration.

Iirc, we collected a bunch of cases where the feature behave erratically.
We had a form, an outreach, perhaps some url-keyed metrics and/or what-if
metrics, auto-disengaging thresholds (?) It was a long time ago, perhaps
Steve has a better memory than I.

Are these compat issues specific to Firefox, or do they also trigger weird
behaviors on Chrome? Do you have a sense of the size and convergence for
the problematic cases?

On Fri, Sep 27, 2019, 21:23 Emilio Cobos Álvarez  wrote:

> Hi,
>
> (cc'ing webkit-dev@ and blink-dev@ in case they have feedback or
> opinions, as WebKit is the only engine which does not implement scroll
> anchoring, though I don't know if they plan to, and Blink is the only
> other engine that does implement it. Please reply to dev-platform@
> though.)
>
> TLDR: Scroll anchoring is really a mess.
>
> I didn't do the initial implementation of the feature in Gecko, but I've
> done a ton of work over the last few months to fix compat issues in our
> implementation (see all the bugs blocking [1]).
>
> At this point, our implementation is mostly compatible with Blink, but
> even with a bug-for-bug compatible implementation, we did get compat
> issues because of different content being served for different browsers,
> or because our anti-tracking protections changing the final content of
> the page slightly ([2] is an example of bug which only reproduces with
> ETP enabled only, but whose reduced test-case renders the site unusable
> in Chrome as well).
>
> If you hit one of the broken cases as a user you think the browser is
> completely broken, and the site is just unusable.
>
> I've fixed those by tweaking the heuristics Gecko uses. Those extra
> heuristics have also caused other compat issues, like [3], reported
> today, which will require other adjustments to the heuristics, etc...
>
> On top of that, the spec is not in a good state, with ton of open issues
> without feedback from the editors [4].
>
> So right now I'm at a stage where I think that the feature is just not
> worth it. It doesn't behave predictably enough for developers, and you
> have no guarantee of it behaving consistently unless you test a
> particular browser, with a particular content in a particular viewport
> size... That's not great given the current dominant position of
> Chromium-based browsers.
>
> On top, issues with scroll anchoring are pretty hard to diagnose unless
> you're aware of the feature.
>
> All in all, it doesn't seem like the kind of feature that benefits a
> diverse web (nor web developers for that matter), and I think we should
> remove the feature from Gecko.
>
> Does anyone have strong opinions against removing scroll anchoring from
> Gecko, based on the above?
>
> Thanks,
>
>   -- Emilio
>
> [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1519644
> [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1561450
> [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1584499
> [4]: https://github.com/w3c/csswg-drafts/labels/css-scroll-anchoring-1
>
> --
> 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/83f17f7c-6b68-b7dd-0761-239bd504e10e%40mozilla.com
> .
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Simon Fraser via dev-platform]

> On Sep 27, 2019, at 10:08 PM, Emilio Cobos Álvarez  wrote:
> 
> And, to be clear, we _can_ fix these compat issues, some way or another.
> 
> One thought is to limit the amount of scroll adjustments without user 
> scrolling or stuff like that, which would prevent the "you get stuck on the 
> page".
> 
> Making anchoring opt-in rather than opt-out is another option, but that 
> defeats most of the purpose of the feature, I guess.
> 
> See also some of the Chromium docs on the compat issues they found[1] and how 
> were they trying to fix them before adding the "layout-affecting-property 
> changed" heuristic, which is what is on the spec right now and what they 
> implement.
> 
> I just think that these are very hacky heuristics that are just going to 
> bring a lot of compat pain and developer confusion.
> 
> It doesn't help that all these things can break or not depending on the speed 
> at which the user scrolls, the amount of scroll events that the user 
> dispatches, the timing of these events relative to other events, etc…


I expressed my main issue with scroll anchoring at the F2F, which is that it’s 
an on-by-default behavior that is making up for bad web authoring, and is 
harmful if only implemented by a subset of browsers.

I would support removing it entirely, or having it be opt-in.

Simon

___
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?

[Steve Kobes]

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.

Steve

On Fri, 27 Sep 2019 at 09:09, Emilio Cobos Álvarez 
wrote:

> And, to be clear, we _can_ fix these compat issues, some way or another.
>
> One thought is to limit the amount of scroll adjustments without user
> scrolling or stuff like that, which would prevent the "you get stuck on
> the page".
>
> Making anchoring opt-in rather than opt-out is another option, but that
> defeats most of the purpose of the feature, I guess.
>
> See also some of the Chromium docs on the compat issues they found[1]
> and how were they trying to fix them before adding the
> "layout-affecting-property changed" heuristic, which is what is on the
> spec right now and what they implement.
>
> I just think that these are very hacky heuristics that are just going to
> bring a lot of compat pain and developer confusion.
>
> It doesn't help that all these things can break or not depending on the
> speed at which the user scrolls, the amount of scroll events that the
> user dispatches, the timing of these events relative to other events,
> etc...
>
>   -- Emilio
>
> [1]:
>
> https://docs.google.com/document/d/1nQAO4MYCDMn0rTkn_-WI6gjumk3Qi2Bn-MGuB3NlVxE/edit
>
> On 9/27/19 2:23 PM, Emilio Cobos Álvarez wrote:
> > Hi,
> >
> > (cc'ing webkit-dev@ and blink-dev@ in case they have feedback or
> > opinions, as WebKit is the only engine which does not implement scroll
> > anchoring, though I don't know if they plan to, and Blink is the only
> > other engine that does implement it. Please reply to dev-platform@
> though.)
> >
> > TLDR: Scroll anchoring is really a mess.
> >
> > I didn't do the initial implementation of the feature in Gecko, but I've
> > done a ton of work over the last few months to fix compat issues in our
> > implementation (see all the bugs blocking [1]).
> >
> > At this point, our implementation is mostly compatible with Blink, but
> > even with a bug-for-bug compatible implementation, we did get compat
> > issues because of different content being served for different browsers,
> > or because our anti-tracking protections changing the final content of
> > the page slightly ([2] is an example of bug which only reproduces with
> > ETP enabled only, but whose reduced test-case renders the site unusable
> > in Chrome as well).
> >
> > If you hit one of the broken cases as a user you think the browser is
> > completely broken, and the site is just unusable.
> >
> > I've fixed those by tweaking the heuristics Gecko uses. Those extra
> > heuristics have also caused other compat issues, like [3], reported
> > today, which will require other adjustments to the heuristics, etc...
> >
> > On top of that, the spec is not in a good state, with ton of open issues
> > without feedback from the editors [4].
> >
> > So right now I'm at a stage where I think that the feature is just not
> > worth it. It doesn't behave predictably enough for developers, and you
> > have no guarantee of it behaving consistently unless you test a
> > particular browser, with a particular content in a particular viewport
> > size... That's not great given the current dominant position of
> > Chromium-based browsers.
> >
> > On top, issues with scroll anchoring are pretty hard to diagnose unless
> > you're aware of the feature.
> >
> > All in all, it doesn't seem like the kind of feature that benefits a
> > diverse web (nor web developers for that matter), and I think we should
> > remove the feature from Gecko.
> >
> > Does anyone have strong opinions against removing scroll anchoring from
> > Gecko, based on the above?
> >
> > Thanks,
> >
> >   -- Emilio
> >
> > [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1519644
> > [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1561450
> > [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1584499
> > [4]: https://github.com/w3c/csswg-drafts/labels/css-scroll-anchoring-1
> > ___
> > 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/4fb3b637-50f5-1167-62a0-dffdeff06f48%40mozilla.com
> .
>
___
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?

[Mike Taylor]

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
___
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?

[Emilio Cobos Álvarez]

On 9/29/19 5:07 AM, Rick Byers wrote:
On Fri, Sep 27, 2019 at 10:16 AM Emilio Cobos Álvarez 
mailto:emi...@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

[1]: https://github.com/w3c/csswg-drafts/issues/3480
[2]: https://github.com/w3c/csswg-drafts/issues/3319
[3]: https://github.com/w3c/csswg-drafts/issues/4247



   -- Emilio

 > On Fri, 27 Sep 2019 at 09:09, Emilio Cobos Álvarez
mailto:emi...@mozilla.com>
 > >> wrote:
 >
 >     And, to be clear, we _can_ fix these compat issues, some way
or another.
 >
 >     One 

Re: What to do about scroll anchoring?

[Matt Woodrow]

On 29/09/19 1:54 PM, Cameron McCormack wrote:

How useful is scroll anchoring outside of the two cases mentioned in 
https://drafts.csswg.org/css-scroll-anchoring/#intro i.e. images loading and ad 
iframes being inserted?  Would it be feasible to make scroll anchoring a much 
less general mechanism, and to scope it down to handling these specific cases?


The virtual-scroller[1]/rendersubtree[2] demo that the Chromium team 
demoed at TPAC was also relying on scroll anchoring.


When you use the scrollbar to jump to a given spot, the custom scroller 
element then makes surrounding elements visible. Making them visible 
changes them from using their content-size [3] placeholder size to the 
real size, and we don't want the viewport to move in the process.


- Matt


[1] https://github.com/WICG/virtual-scroller

[2] https://github.com/whatwg/html/pull/4862

[3] https://github.com/w3c/csswg-drafts/issues/4229
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What to do about scroll anchoring?

[L. David Baron]

On Sunday 2019-09-29 10:54 +1000, Cameron McCormack wrote:
> How useful is scroll anchoring outside of the two cases mentioned in 
> https://drafts.csswg.org/css-scroll-anchoring/#intro i.e. images loading and 
> ad iframes being inserted?  Would it be feasible to make scroll anchoring a 
> much less general mechanism, and to scope it down to handling these specific 
> cases?

I think it's also quite useful for horizontal resizes of the browser
window (which can include device rotation on mobile, window
resizing/maximization on desktop, and also hiding/showing of browser
sidebar UI).

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What to do about scroll anchoring?

[Cameron McCormack]

How useful is scroll anchoring outside of the two cases mentioned in 
https://drafts.csswg.org/css-scroll-anchoring/#intro i.e. images loading and ad 
iframes being inserted?  Would it be feasible to make scroll anchoring a much 
less general mechanism, and to scope it down to handling these specific cases?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What to do about scroll anchoring?

[Jonathan Kew]

On 27/09/2019 23:19, Botond Ballo wrote:

Emilio, thanks for all your work on this!

On Fri, Sep 27, 2019 at 8:23 AM Emilio Cobos Álvarez  wrote:

Does anyone have strong opinions against removing scroll anchoring from
Gecko, based on the above?


My 2c: it would be unfortunate to give up on scroll anchoring as a
feature altogether.


Yes.


However, if we need to disable it for now, until its spec is in better
shape, I can understand that;


I'd be concerned that if we disable it, we'll in effect no longer be 
providing useful implementation feedback to help shape the spec, and 
neither site nor spec authors will be guided towards anything better or 
more clearly defined than "however Chrome behaves".



especially as the code would
(presumably) still be there and users for whom it works well and
really want it can turn it back on by flipping the pref.


Although our chances of noticing regressions in this code will be 
greatly diminished (as well as the likelihood of noticing site authoring 
problems and spec shortcomings).


JK
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What to do about scroll anchoring?

[Botond Ballo]

Emilio, thanks for all your work on this!

On Fri, Sep 27, 2019 at 8:23 AM Emilio Cobos Álvarez  wrote:
> Does anyone have strong opinions against removing scroll anchoring from
> Gecko, based on the above?

My 2c: it would be unfortunate to give up on scroll anchoring as a
feature altogether.

However, if we need to disable it for now, until its spec is in better
shape, I can understand that; especially as the code would
(presumably) still be there and users for whom it works well and
really want it can turn it back on by flipping the pref.

Thanks,
Botond
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What to do about scroll anchoring?

[L. David Baron]

On Friday 2019-09-27 14:23 +0200, Emilio Cobos Álvarez wrote:
> Does anyone have strong opinions against removing scroll anchoring from
> Gecko, based on the above?

It seems pretty sad, since I think it's a very useful feature for a
large class of pages -- particularly pages that are more "documents"
than "applications".

I wonder if it would be possible to disable the feature under
certain conditions, for example:
 * the page uses APIs that initiate scrolling from script, or
 * the page has handlers for scroll events, or
 * the page does both of the above
but leave the feature enabled for pages that don't do these things.

Based on what I've heard it seems like many of the cases where pages
are really broken involve some of those, although I haven't gone
through the bug lists.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What to do about scroll anchoring?

[Emilio Cobos Álvarez]

On 9/27/19 3:30 PM, twisniew...@mozilla.com wrote:

I suspect that if we can give our compat addon an easy way to specify sites 
which need an opt-out, that might ease the pain. Likewise, as obnoxious as the 
thought is, perhaps giving sites a standard way to opt out of anchoring could 
be a reasonable compromise, depending on developer feedback.


To be clear there is a standard way to opt out of scroll anchoring 
(overflow-anchor: none).


  -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What to do about scroll anchoring?

[twisniewski]

My gut tells me that there would be fallout with users. I've been personally 
told by more than one user that they are unwilling to use browsers without it, 
as they feel like user-unfriendly relics.

As such I would recommend not removing it unless Blink does. I suspect that if 
we can handle the compat fallout, we should document well our heuristics and 
try to standardize them properly. Blink should at least agree to that much if 
they want to push the notion, and it does seem worthy of that much effort if 
users truly are that invested.

I suspect that if we can give our compat addon an easy way to specify sites 
which need an opt-out, that might ease the pain. Likewise, as obnoxious as the 
thought is, perhaps giving sites a standard way to opt out of anchoring could 
be a reasonable compromise, depending on developer feedback.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Emilio Cobos Álvarez]

On 9/27/19 3:02 PM, Kenji Baheux wrote:
Are these compat issues specific to Firefox, or do they also trigger 
weird behaviors on Chrome? Do you have a sense of the size and 
convergence for the problematic cases?


Some of the ones we've seen reported are specific to Firefox in the 
sense that they only happen in Firefox because we block some tracking 
code on the page, for example.


But test-cases without that difference like [1] do happen on Chrome as 
well. Fixing that in turn causes other interop issues.


Other sites for which I've investigated scroll anchoring issues just 
eternally burn CPU (this is fixed in Firefox, but still happens in 
Chrome). STR for example:


 * Go to http://lembarsaham.com/
 * Scroll to the middle of the page.
 * On the devtools console, do: window.addEventListener("scroll", () => 
console.log("scroll"))
 * In Chrome, you'll see scroll event listeners being fired constantly, 
each of those trashing layout to do literally nothing and burning CPU.


I don't think the size of the compat issues is spectacularly big, it's 
just somewhat frustrating because fixing some of them causes others to 
break, and is just a very thin line to walk.


If heuristics between Chrome and Firefox differ, sites that only test on 
Chrome (specially on mobile) will break on Firefox, and the failure mode 
is terrible.


If the heuristics are the same, then Firefox still gets compat issues 
for those sites, because of stuff like tracking protection.


 -- Emilio

[1]: https://bugzilla.mozilla.org/attachment.cgi?id=9087497

On Fri, Sep 27, 2019, 21:23 Emilio Cobos Álvarez > wrote:


Hi,

(cc'ing webkit-dev@ and blink-dev@ in case they have feedback or
opinions, as WebKit is the only engine which does not implement scroll
anchoring, though I don't know if they plan to, and Blink is the only
other engine that does implement it. Please reply to dev-platform@
though.)

TLDR: Scroll anchoring is really a mess.

I didn't do the initial implementation of the feature in Gecko, but
I've
done a ton of work over the last few months to fix compat issues in our
implementation (see all the bugs blocking [1]).

At this point, our implementation is mostly compatible with Blink, but
even with a bug-for-bug compatible implementation, we did get compat
issues because of different content being served for different
browsers,
or because our anti-tracking protections changing the final content of
the page slightly ([2] is an example of bug which only reproduces with
ETP enabled only, but whose reduced test-case renders the site unusable
in Chrome as well).

If you hit one of the broken cases as a user you think the browser is
completely broken, and the site is just unusable.

I've fixed those by tweaking the heuristics Gecko uses. Those extra
heuristics have also caused other compat issues, like [3], reported
today, which will require other adjustments to the heuristics, etc...

On top of that, the spec is not in a good state, with ton of open
issues
without feedback from the editors [4].

So right now I'm at a stage where I think that the feature is just not
worth it. It doesn't behave predictably enough for developers, and you
have no guarantee of it behaving consistently unless you test a
particular browser, with a particular content in a particular viewport
size... That's not great given the current dominant position of
Chromium-based browsers.

On top, issues with scroll anchoring are pretty hard to diagnose unless
you're aware of the feature.

All in all, it doesn't seem like the kind of feature that benefits a
diverse web (nor web developers for that matter), and I think we should
remove the feature from Gecko.

Does anyone have strong opinions against removing scroll anchoring from
Gecko, based on the above?

Thanks,

   -- Emilio

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1519644

[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1561450

[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1584499

[4]:
https://github.com/w3c/csswg-drafts/labels/css-scroll-anchoring-1


-- 
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/83f17f7c-6b68-b7dd-0761-239bd504e10e%40mozilla.com

Re: What to do about scroll anchoring?

[Ryan Hunt]

Hi,

I was the one who originally implemented scroll anchoring in Firefox and just
want to say that I agree with Emilio here.

Scroll anchoring is a cool feature and would be great to have, but these
difficulties that Emilio has mentioned have been here since day-1.

It would be great to find a path forward here, but so far I haven't seen a
clear option that avoids the need for heuristics (hacks).

If it's decided to remove this feature from Gecko, it might be worth taking a
step back and trying to finding an alternative way to reduce layout jank.

Thanks,
Ryan


On Fri, Sep 27, 2019, at 8:08 AM, Emilio Cobos Álvarez wrote:
> And, to be clear, we _can_ fix these compat issues, some way or another.
> 
> One thought is to limit the amount of scroll adjustments without user 
> scrolling or stuff like that, which would prevent the "you get stuck on 
> the page".
> 
> Making anchoring opt-in rather than opt-out is another option, but that 
> defeats most of the purpose of the feature, I guess.
> 
> See also some of the Chromium docs on the compat issues they found[1] 
> and how were they trying to fix them before adding the 
> "layout-affecting-property changed" heuristic, which is what is on the 
> spec right now and what they implement.
> 
> I just think that these are very hacky heuristics that are just going to 
> bring a lot of compat pain and developer confusion.
> 
> It doesn't help that all these things can break or not depending on the 
> speed at which the user scrolls, the amount of scroll events that the 
> user dispatches, the timing of these events relative to other events, etc...
> 
>   -- Emilio
> 
> [1]: 
> https://docs.google.com/document/d/1nQAO4MYCDMn0rTkn_-WI6gjumk3Qi2Bn-MGuB3NlVxE/edit
> 
> On 9/27/19 2:23 PM, Emilio Cobos Álvarez wrote:
> > Hi,
> > 
> > (cc'ing webkit-dev@ and blink-dev@ in case they have feedback or 
> > opinions, as WebKit is the only engine which does not implement scroll 
> > anchoring, though I don't know if they plan to, and Blink is the only 
> > other engine that does implement it. Please reply to dev-platform@ though.)
> > 
> > TLDR: Scroll anchoring is really a mess.
> > 
> > I didn't do the initial implementation of the feature in Gecko, but I've 
> > done a ton of work over the last few months to fix compat issues in our 
> > implementation (see all the bugs blocking [1]).
> > 
> > At this point, our implementation is mostly compatible with Blink, but 
> > even with a bug-for-bug compatible implementation, we did get compat 
> > issues because of different content being served for different browsers, 
> > or because our anti-tracking protections changing the final content of 
> > the page slightly ([2] is an example of bug which only reproduces with 
> > ETP enabled only, but whose reduced test-case renders the site unusable 
> > in Chrome as well).
> > 
> > If you hit one of the broken cases as a user you think the browser is 
> > completely broken, and the site is just unusable.
> > 
> > I've fixed those by tweaking the heuristics Gecko uses. Those extra 
> > heuristics have also caused other compat issues, like [3], reported 
> > today, which will require other adjustments to the heuristics, etc...
> > 
> > On top of that, the spec is not in a good state, with ton of open issues 
> > without feedback from the editors [4].
> > 
> > So right now I'm at a stage where I think that the feature is just not 
> > worth it. It doesn't behave predictably enough for developers, and you 
> > have no guarantee of it behaving consistently unless you test a 
> > particular browser, with a particular content in a particular viewport 
> > size... That's not great given the current dominant position of 
> > Chromium-based browsers.
> > 
> > On top, issues with scroll anchoring are pretty hard to diagnose unless 
> > you're aware of the feature.
> > 
> > All in all, it doesn't seem like the kind of feature that benefits a 
> > diverse web (nor web developers for that matter), and I think we should 
> > remove the feature from Gecko.
> > 
> > Does anyone have strong opinions against removing scroll anchoring from 
> > Gecko, based on the above?
> > 
> > Thanks,
> > 
> >   -- Emilio
> > 
> > [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1519644
> > [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1561450
> > [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1584499
> > [4]: https://github.com/w3c/csswg-drafts/labels/css-scroll-anchoring-1
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What to do about scroll anchoring?

[Emilio Cobos Álvarez]

And, to be clear, we _can_ fix these compat issues, some way or another.

One thought is to limit the amount of scroll adjustments without user 
scrolling or stuff like that, which would prevent the "you get stuck on 
the page".


Making anchoring opt-in rather than opt-out is another option, but that 
defeats most of the purpose of the feature, I guess.


See also some of the Chromium docs on the compat issues they found[1] 
and how were they trying to fix them before adding the 
"layout-affecting-property changed" heuristic, which is what is on the 
spec right now and what they implement.


I just think that these are very hacky heuristics that are just going to 
bring a lot of compat pain and developer confusion.


It doesn't help that all these things can break or not depending on the 
speed at which the user scrolls, the amount of scroll events that the 
user dispatches, the timing of these events relative to other events, etc...


 -- Emilio

[1]: 
https://docs.google.com/document/d/1nQAO4MYCDMn0rTkn_-WI6gjumk3Qi2Bn-MGuB3NlVxE/edit


On 9/27/19 2:23 PM, Emilio Cobos Álvarez wrote:

Hi,

(cc'ing webkit-dev@ and blink-dev@ in case they have feedback or 
opinions, as WebKit is the only engine which does not implement scroll 
anchoring, though I don't know if they plan to, and Blink is the only 
other engine that does implement it. Please reply to dev-platform@ though.)


TLDR: Scroll anchoring is really a mess.

I didn't do the initial implementation of the feature in Gecko, but I've 
done a ton of work over the last few months to fix compat issues in our 
implementation (see all the bugs blocking [1]).


At this point, our implementation is mostly compatible with Blink, but 
even with a bug-for-bug compatible implementation, we did get compat 
issues because of different content being served for different browsers, 
or because our anti-tracking protections changing the final content of 
the page slightly ([2] is an example of bug which only reproduces with 
ETP enabled only, but whose reduced test-case renders the site unusable 
in Chrome as well).


If you hit one of the broken cases as a user you think the browser is 
completely broken, and the site is just unusable.


I've fixed those by tweaking the heuristics Gecko uses. Those extra 
heuristics have also caused other compat issues, like [3], reported 
today, which will require other adjustments to the heuristics, etc...


On top of that, the spec is not in a good state, with ton of open issues 
without feedback from the editors [4].


So right now I'm at a stage where I think that the feature is just not 
worth it. It doesn't behave predictably enough for developers, and you 
have no guarantee of it behaving consistently unless you test a 
particular browser, with a particular content in a particular viewport 
size... That's not great given the current dominant position of 
Chromium-based browsers.


On top, issues with scroll anchoring are pretty hard to diagnose unless 
you're aware of the feature.


All in all, it doesn't seem like the kind of feature that benefits a 
diverse web (nor web developers for that matter), and I think we should 
remove the feature from Gecko.


Does anyone have strong opinions against removing scroll anchoring from 
Gecko, based on the above?


Thanks,

  -- Emilio

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1519644
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1561450
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1584499
[4]: https://github.com/w3c/csswg-drafts/labels/css-scroll-anchoring-1
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

What to do about scroll anchoring?

[Emilio Cobos Álvarez]

Hi,

(cc'ing webkit-dev@ and blink-dev@ in case they have feedback or 
opinions, as WebKit is the only engine which does not implement scroll 
anchoring, though I don't know if they plan to, and Blink is the only 
other engine that does implement it. Please reply to dev-platform@ though.)


TLDR: Scroll anchoring is really a mess.

I didn't do the initial implementation of the feature in Gecko, but I've 
done a ton of work over the last few months to fix compat issues in our 
implementation (see all the bugs blocking [1]).


At this point, our implementation is mostly compatible with Blink, but 
even with a bug-for-bug compatible implementation, we did get compat 
issues because of different content being served for different browsers, 
or because our anti-tracking protections changing the final content of 
the page slightly ([2] is an example of bug which only reproduces with 
ETP enabled only, but whose reduced test-case renders the site unusable 
in Chrome as well).


If you hit one of the broken cases as a user you think the browser is 
completely broken, and the site is just unusable.


I've fixed those by tweaking the heuristics Gecko uses. Those extra 
heuristics have also caused other compat issues, like [3], reported 
today, which will require other adjustments to the heuristics, etc...


On top of that, the spec is not in a good state, with ton of open issues 
without feedback from the editors [4].


So right now I'm at a stage where I think that the feature is just not 
worth it. It doesn't behave predictably enough for developers, and you 
have no guarantee of it behaving consistently unless you test a 
particular browser, with a particular content in a particular viewport 
size... That's not great given the current dominant position of 
Chromium-based browsers.


On top, issues with scroll anchoring are pretty hard to diagnose unless 
you're aware of the feature.


All in all, it doesn't seem like the kind of feature that benefits a 
diverse web (nor web developers for that matter), and I think we should 
remove the feature from Gecko.


Does anyone have strong opinions against removing scroll anchoring from 
Gecko, based on the above?


Thanks,

 -- Emilio

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1519644
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1561450
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1584499
[4]: https://github.com/w3c/csswg-drafts/labels/css-scroll-anchoring-1
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform