Scroll position jumps when mousedown on multi-line selection in nested inline editor

[peterflynn]

This may only reproduce on Mac. I'm able to repro with Chrome 40.0.2214.111 on both Mac OS 10.9 and Mac OS 10.10. Haven't tried other browsers yet.

1. Open https://gist.github.com/peterflynn/0f6cd0af22edb543f56f
2. Scroll down until line 33 is at the top of the viewport
3. Inside the inline editor, select from the start of line 2 to the end of line 14
4. Mousedown on the selection

Result: outer editor's viewport scrolls down ~7 lines, so line 40 is now at the top of the view

Expected: no scrolling

Although this simple testcase isn't tuned to show it, in Brackets we're seeing cases where the scroll position will jump by several hundred lines.

Note that if you select fewer lines, or if the inline editor is near the top of the viewport, the bug is less likely to reproduce (and if it does repo, the jump is smaller).

[peterflynn]

I did a little investigation in the downstream Brackets bug (adobe/brackets#10590), but it's tough to tell what's going on. Mousedown causes a brief focus change from the textarea to the .CodeMirror-scroll div (unavoidable when dragDrop is enabled, since preventDefault() can't be called on mousedown). When focus changes, browsers always try to scroll focused element into view, and here it looks like the browser may be confused about how to scroll when .CodeMirror-scroll gains focus -- afaict it's already entirely in view, so no scrolling should be needed.

I'm unclear why the length of the text selection has any influence on this behavior -- that may be a valuable clue.

[marijnh]

What appears to be happening is that Chrome tries to scroll the whole block of selected text (in the hidden textarea) into view, whether it is visible or not. That is why this doesn't happen if you only select a few lines.

I've submitted Chrome issue 459071 with a reduced reproduction case. I tried some workaround (fiddling with the CSS style on the textarea, and setting selectionDirection to "backward") but nothing seems to have an effect.

If you have leverage to help get this fixed on the Chrome side, that's probably our best bet.

[marijnh]

Mitigated by #3100. Closing in the hope that the Chrome team will fix the underlying bug and eventually cause this to become a non-issue entirely.