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.

This should be resolved in HEAD because we no longer frame the page content. Chrome still has the underlying bug.

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.

Presume fixed since you don't to scroll left/right anymore.

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!

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