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.

Adding overflow-wrap: anywhere appears to fix this without breaking anything.

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:

This now appears to be fixed in the release version of Chrome. We can remove the workaround in some future change.

I upstreamed this to Chrome here: https://bugs.chromium.org/p/chromium/issues/detail?id=1003002

No longer valid as far as I can find.

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

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.

I wasn't immediately able to reproduce this:

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.

I've located the mainframe and uploaded the downloads

Ah cool, good to know. Thanks for the quick fix!

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.

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.