Works OK on linux M55.

Can repro on my work windows install as well as my personal. Doesn't repro on Cros (probly since its more like linux).

It reprod on the last 54 I had, and when I updated to 55. And also in incognito.

And to be clear, this is me clicking on the "Home" button on the webpage. Not the home key on my keyboard, and not wheel/trackpad scrolling myself.

Strange that it's only occurring on Windows, I couldn't repro on Linux either, regardless of prefer-compositing-to-lcd-text. I'll need to wait until I get back to my Windows box next week to take a look.

If I can collect any data for you lmk also, its very easy to repro for me.

Seeing the list of flags on the Windows machine might help.  E.g. maybe it's something like --use-zoom-for-dsf plus non-integer devicescalefactor.

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --flag-switches-begin --flag-switches-end

We do have use zoom for DSF on by default on windows tho right? Cuz I have a lot of weird sizes of stuff in blink (I was filing bugs about that too ystrdy)

I can't reproduce on Windows 10 with neither Stable (55.0.2883.87 -- logged in with my corp account) nor Canary (57.0.2956.0 -- not logged in). I've also tried flipping the zoom-for-DSF flag (which is default on for Windows and CrOS but nowhere else) and prefer-compositing but no difference.

Looking at a trace from my run, it seems that the scroll animation happens through setTimeouts and the scroll position is updated from Timers in Blink. Perhaps there's some kind of experiment in scheduling affecting this? +skyostil@, does this sound like anything you might be aware of?

Attaching aforementioned trace.

Deleted: trace_twitter_home.json.gz 2.4 MB

trace_twitter_home.json.gz 2.4 MB Download

> nor Canary (57.0.2956.0 -- not logged in). 

This makes me wonder if you're doing the right steps, as when you're not logged in your get a different landing page, there's no feed or home button there.

Today my reproduction has changed. Edge continues to scroll to the top of the page when I click on the Home link. Chrome now scrolls to the top..ish. It scrolls so the "What's happening?" box is halfway inside the viewport.

My chrome version hasn't changed tho: 55.0.2883.87

Sorry, I should have been clearer. I wasn't logged in to my user account in Chrome - I was logged into Twitter. I was ruling out any kind of Googler-only experiment as we sometimes do.

I was clicking both the "Home" link and the birdy Logo in the top bar.

This is the "Home" button I'm talking about just in case.. with my theme ofc.

Deleted: home.png 6.5 KB

	home.png 6.5 KB View Download

Oh ok good!

I don't think we've recently changed anything about timer throttling that would affect this. Would you mind recording another trace with the renderer.scheduler category enabled to be sure?

Also, could you try if chrome://flags/#enable-scroll-anchoring affects this?

Today twitter scrolls up by 1px again. I tried with scroll-anchoring default/enabled/disabled with no difference.

Here's another trace, I tried to turn on lots of things. I just click home 8 times and it scrolls 1px each.

Deleted: trace_8_scrolls_by_1_px.json.gz 2.9 MB

trace_8_scrolls_by_1_px.json.gz 2.9 MB Download

I have another random piece of data, I figured out why my bahaviour was changing locally:

1. If I refresh twitter, scroll down, click home button.. It always goes up by 1px.

2. If I refersh twitter, press the '.' key (which updates the feed and moves to the top), then scroll down and click the home button.. It will jump almost to the top (halfway thru the Whats Happening input field).

That's why it seemed to change behaviour the other day.

And for comparison, here's a trace of it working on my box with scheduler info.

Deleted: trace_twitter_home_good.json.gz 3.2 MB

trace_twitter_home_good.json.gz 3.2 MB Download

I thought maybe it is account specific so I made a new account in an incognito window and added some people to follow and it repros there also. It's danakj@chromium.org, and I sent u the pw in an IM.

Ok, figured out the repro. Device scale factor needs to be a non-whole number. I managed to repro on Linux as well with --force-device-scale-factor=1.5 (or 2.5). Will look into it deeper now. 

I've figured out this is occurring because we have fractional scroll offsets. You can reproduce on any low-DPI machine just by browser zooming out or in to a non-integer zoom (e.g. 150%). This is a long standing issue (see 461956) and seems that it's a problem with how Twitter handles fractional offsets.

I've filed a bug on twitter but it's a pretty generic "feedback" form so I'm not sure it'll ever get looked at. Absent a contact at twitter, I'm not sure there's much we can do.

Hm it's worth noting this works in other browsers tho, why would that be?

It seems Firefox and IE (haven't tried Safari but we changed this in WebKit post fork) don't return a fractional offset from window.scrollY|X. The change we made happened a while ago in  issue 373731  to match the change in the CSSOM spec ([1] Intent to ship) and was required to support some use cases - seems we expected some compat impact but felt it would be minimal and outweighed by the benefits.

From what I can tell in [2] it does seem this is a known issue in Firefox. Supposedly Edge/IE has also returned fractional scroll offsets since 10 but they're opt-in for the page.

cc'ing some dev rel folks in hopes they might have a twitter contact they could prod.

[1] https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/subpixel$20scrollTop/blink-dev/_Q7A4AQBFKY/S4ahQ5iE28QJ
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1151421

pinged some twitter contacts: https://twitter.com/paul_irish/status/816396354402467840

we should be hearing from someone soon.

Awesome, thanks Paul!

Tracking this from the Twitter side - we were able to repro and should get a fix out this week or next.

We have a fix and will deploy it this week. Some details below for the curious

The error was not exactly because element.scrollTop (the value we were reading) was no longer an integer, but because updating the value no longer set the value to the updated value.

Concretely: we have some code that detects whether document.body or document.documentElement is the scrollable container on the page. It looked like this:

```
[document.body, document.documentElement].forEach(function(el) {
  var scrollTop = el.scrollTop;
  var alternateTop = scrollTop > 0 ? scrollTop - 1 : scrollTop + 1;
  el.scrollTop = alternateTop;

  if (el.scrollTop === alternateTop) {
    scrollEl = el.tagName.toLowerCase(); 
  }
});
```

The condition in the if statement was no longer true. For example (at 125% zoom):

```
var scrollTop = el.scrollTop; // scrollTop === 2598.4
var alternateTop = scrollTop - 1; // alternateTop === 2597.4
el.scrollTop = alternateTop; // el.scrollTop === 2596.8
``
```

The fix was to compare the new el.scrollTop against the initial value:

```
[document.body, document.documentElement].forEach(function(el) {
  var initialScrollTop = el.scrollTop;
  var alternateTop = initialScrollTop > 0 ? initialScrollTop - 1 : initialScrollTop + 1;
  el.scrollTop = alternateTop;

  if (el.scrollTop !== initialScrollTop) {
    scrollEl = el.tagName.toLowerCase(); 
  }
});
```

Interesting, thanks for the explanation. Have you looked at using document.scrollingElement [1]? It's designed to make deciding between body and documentElement easier.

[1] https://developer.mozilla.org/en/docs/Web/API/document/scrollingElement 

Thanks for pointing that out - we'll look at using scrollingElement in environments where that's supported.