Scroll anchoring: on reload, don't intervene if we did before |
|||
Issue descriptionAvoid any regression without sacrificing a lot of user value, is going to be very hard. Let's use Reload as a signal that we broke something: on reload don't intervene if we did before. It's a natural gesture for users to fix a page. Note: this might be too crude and we might want to make the decision sticky (session or exponential backoff) based on what we'll learn from the field trial but a simple logic is a good start.
,
Aug 4 2016
That said, we could consider turning off scroll anchoring for a page if we ever hit any of the exceptional hack cases (e.g. bounce suppression, 20 adjustment limit). I think that would make me considerably more comfortable shipping what we have now. That said, I'd be even happier if we could find ways to get rid of those hack cases, which we're looking into. :)
,
Aug 4 2016
Changing behavior on reload is the sort of thing that would drive web developers insane; I'd be extremely reluctant to do that. The suggestion in #2 sounds reasonable but I'm not sure it makes a big difference in terms of shippability.
,
Aug 6 2016
"We're trading one bad experience (broken scroll anchoring) for another (no scroll anchoring)." I'm not sure I agree here. Until Scroll Anchoring is flawless and, more importantly, until we also have a solution for the on-screen reflow, there will be no strong expectation that bad reflow (i.e. no scroll anchoring) are a thing of the past. The later part is in fact a crucial point because even if Scroll Anchoring nailed all the offscreen cases, the user will not even notice that we spared him a bad user experience. On the other hand, the user will notice the cases where the user experience regressed (especially when the scrolling position bounces multiple times) and sadly not understand that there is a ton of valuable intervention that happened being the scene so far. I think we should err on the side of caution. If not the reload (+some sort of stickiness) trick then we should think about which other signals we should rely on to determine that Scroll Anchoring on a particular page is making things worse and temporarily disable it for subsequent page views.
,
Aug 8 2016
,
Sep 6 2016
SANACLAP ( issue 637626 ) eliminates the "exceptional hack cases" mentioned in #2. I think we should close this, but we'll keep an eye out for new reports of broken anchoring as this rolls out to canary. |
|||
►
Sign in to add a comment |
|||
Comment 1 by ojan@chromium.org
, Aug 4 2016