Contenteditable causes line jumping when gaining focus with keyboard.

With the contenteditable input style, focusing CodeMirror with the tab key causes the active line jumps a about a page upwards

Browser

Occurs in:

Linux & Win Chrome 88.0.4324.146 (Official Build) (64-bit) Win Edge 88.0.705.63 (Official build) (64-bit)

Works correctly in Firefox 85.0 (64-bit)

Reproduction

1. Visit: https://codepen.io/billiam/pen/abBNLOz
2. Scroll to end of codemirror element, and select last line
3. Type tab to focus on next input or click input element, blurring codemirror
4. Type shift+tab to focus codemirror again

Expected

Previously active line is still active

Actual behavior

A line that was not visible before focusing codemirror scrolls into focus and is selected instead.

https://user-images.githubusercontent.com/242008/107131772-1ec13780-689f-11eb-9bbc-ddccb77778e6.mp4

Other variations:

• Works as expected with textarea input style: https://codepen.io/billiam/pen/ExNKwgj
• Weirdly, it works as expected with lineNumbers: true: https://codepen.io/billiam/pen/qBqZPNZ
• Does not work with active-line / styleActiveLine disabled, but is slightly different (always scrolls to the top): https://codepen.io/billiam/pen/JjbXrbX

I thought this might be a regression of https://github.com/codemirror/CodeMirror/issues/3979 but I’m not sure.

[marijnh]

I suppose what’s happening is that the browser puts the selection at the start of the editable element (which, since the document is viewported, would be about a page up from the top of the visible content). Browsers don’t really keep a ‘current selection’ for unfocused elements, so they just put it at their start when the focus is moved in via the keyboard.

[marijnh]

Okay, right, CM6 jumps back to the start of the document, but not to an arbitrary start of the viewport. I’m not entirely sure if this we should be overriding that native behavior.