Bad focus behavior when using contenteditable on Chrome [+ Partial Fix]

[schanzer]

To reproduce:

1. Open the demo file for any mode (I used coffeescript)
2. Change the inputStyle option to "contenteditable"
3. Open the demo file in a browser, and scroll to the bottom of the code
4. Click elsewhere to blur, then back in the code to focus
   Note: this also happens if a scrolled CM receives focus by tabbing - the display jumps up.

EXPECTED: cursor appears on the line that was clicked, and the editor does not scroll
ACTUAL: cursor sometimes appears on the line that was clicked, and the editor scrolls to put that line at the bottom of the viewport. If the line that was clicked cannot be placed at the very bottom, the editor scrolls to the very top, and the cursor appears on line 1.

This is on OSX 10.11.4, Chrome 50.

• No issues when using Safari
• On Firefox, the editor does not scroll but the cursor is placed incorrectly

It appears that CodeMirror's input element (contentEditable or default) calls its own focus() method twice when receiving focus from a blurred state. I inserted some console logs before and after the focus call, printing out the BoundingClientRect of the Display.mover element. Following steps 1-4 will print out this rect four times, allowing me to see how the mover changes position.

With the default input mode, the BoundingClientRect is the same all four times.

In contentEditable mode, the first call to focus() switches the top to be the be the vertical offset of the parent CodeMirror element! If I move the editor itself so it's 200px below the top of the page, I'll see the mover element jump to 200px after the first call to focus().

This suggests that the focus call on https://github.com/codemirror/CodeMirror/blob/master/lib/codemirror.js#L1740 is causing the entire div to scroll to the top.

[Dominator008]

I think I've hit something like this before, and had to force inputStyle to "textArea" on mobile browsers: GerritCodeReview/gerrit@44679ef.

[schanzer]

Right, thus the title.

[schanzer]

This problem can be resolved by saving the scroller element's scrollTop position before the call to focus, and then restoring it afterwards.

[marijnh]

Does attached patch help?

[schanzer]

Works like a charm! Thanks! (Not sure what your policy is on having users close issues, so I'll leave this open for now.)

[marijnh]

Closing your own issues if the problem has been resolved is definitely okay!