See PHI2090 for another report of this. Chrome hasn't changed behavior since the last update, so I'm more inclined to look at workarounds.
May 21 2021
Sep 28 2020
Aug 11 2020
Adding overflow-wrap: anywhere appears to fix this without breaking anything.
Nov 8 2019
I'm planning to give Chrome some time to triage the report. If it sits there for a while or they decide it's how LayoutNG is going to handle this case, I'll look for workarounds. I don't think our intent/markup is totally unambiguous, and it may be reasonable to decide that this behavior is acceptable, even though Safari and Firefox have different behavior.
Here's a simple reproduction case:
Sep 24 2019
This now appears to be fixed in the release version of Chrome. We can remove the workaround in some future change.
Sep 13 2019
Sep 11 2019
I upstreamed this to Chrome here: https://bugs.chromium.org/p/chromium/issues/detail?id=1003002
Aug 6 2017
No longer valid as far as I can find.
Jul 9 2017
Jan 12 2017
Chrome 56 has merged a fix for this so it should be moot in the not-too-distant future, although I'm not exactly sure what the Chrome release schedule looks like. If this only impacts ghost inlines for a few more weeks it's pretty tempting to just wait for it to resolve itself, but I may be digging around in that code soon so perhaps I'll take a more detailed look.
Is it possible that this issue effects Differential but only for inline-comments that have been ported forward from a previous diff (i.e. the ones that are rendered as slightly faded). I see this issue on this instance with this revision: https://secure.phabricator.com/D15675, none of the anchor links in the timeline work for me when I use Chrome 55, but I don't see the same issue on reviews where comments are on the most-recent diff (not faded).
Dec 28 2016
We haven't received more information about this in about a week and can't reproduce it, so we can't move forward. I'm going to close this until we get new information.
Dec 22 2016
Dec 20 2016
I wasn't immediately able to reproduce this:
Dec 19 2016
Jul 28 2016
No biggie, although the UI effect is obviously crucial for my org
Whoops, yeah the strikethrough isn't for some reason. Sorry I thought you meant an issue with the graph itself.
Jun 30 2016
I've located the mainframe and uploaded the downloads
Feb 20 2016
Ah cool, good to know. Thanks for the quick fix!
Feb 19 2016
Yeah, I came to approximately the same conclusion. Save + restore on the scroll position appears to be a complete fix as far as I can tell.
So I looked into this and it is the call to area.focus() in the setSelectionRange method in https://secure.phabricator.com/diffusion/P/browse/master/webroot/rsrc/js/core/TextAreaUtils.js (unsure what line, my view of this file is plaintext here) that causes the scrolling. I removed this line and it seemed to have the expected behavior but who knows what other problems removing it may cause.
Feb 2 2016
Jan 19 2016
Oct 22 2015
Yeah, I have the same guess as @chad on this.
Yes, you are right, we are on version from April 2015. Sorry for that.
I presume you are behind D12789, which was May 2015.
I tried to reproduce the issue here, but it looks fine (not sure which version is deployed here). I tried on https://secure.phabricator.com/D14297#inline-48363 and I can scroll with every means.
This does not reproduce for me with Chrome 46 on Windows 7.
Tried on Windows 7 and Windows 10.
Mac Desktop / Mouse / Chrome 46 also works fine. @oujesky what OS are you running and is your Phabricator at HEAD?
I also can't reproduce this with a similar setup (OSX / Macbook / Chrome 46).
I gave a quick test on a laptop / Mac / Chrome 46 and can't really reproduce anything on https://secure.phabricator.com/D14268#inline-48344. @epriestley can you?
See T7740 / https://code.google.com/p/chromium/issues/detail?id=473657 for a previous adventure with scrolling Chrome anchors.
May 14 2015
This should be resolved in HEAD because we no longer frame the page content. Chrome still has the underlying bug.
May 10 2015
May 7 2015
Apr 17 2015
In case it helps--calling window.scrollTo(window.scrollX, window.scrollY) right after I hit the back button appears to get my browser out of the broken state from the second repro (first one no longer works for me). Might it work to call that at various points when Chrome might have entered a broken state?
The only workarounds I can come up with are:
We should probably investigate a workaround, as any Chrome fix is months away, even when acknowledged.
Apr 12 2015
Apr 7 2015
Apr 3 2015
Mar 10 2015
Presume fixed since you don't to scroll left/right anymore.
Mar 5 2015
Just tested it again with a touchpad (laptop), and it still works.
Are you on a laptop? Seems touch specific.
works for me on Windows/Chrome 41. Just to make it more annoying, I guess.
Well this now repros in plain Mac/Chrome v41. Help me 1-up diff view, you're my only hope!
Jan 25 2015
This should be fixed in HEAD, and on this server. Let us know if you still run into issues. Thanks for the report!
I can confirm same behaviour on Firefox 35 on linux when browsing for example D11489