Closed peterflynn closed 12 years ago
@njx I'm pretty sure this was working before the CodeMirror merge
Is this similar to #1025?
I added a few more cases where the selection highlight is even more screwed up
Oops, yes -- I think #1025 is "Bug 2" here. So this is a superset. Should we close the other one?
This should be fixed by https://github.com/adobe/CodeMirror2/pull/61. Note that in case 3, you might end up with the cursor on a different line after the page up--this is due to #1036--but that's not a new issue. (The highlighting should be consistent with the cursor position though, so if that's not the case let me know.)
FBNC to @peterflynn -- please update to the latest adobe/CodeMirror2 master.
I can no longer repro bugs 1-3 and bug 5, but bug 4 still occurs for me. Here are more detailed steps:
Bug 4
Result: after it starts scrolling, the top of the selection range moves upward one or more lines. It seems to jiggle around, moving up a bit, pulling back, moving up again. Depending on when you let go of the down arrow, the selection might be back in a good state or it might still be wrong.
It's purely a display problem: if I hit Ctrl+C or delete, it's clear that the selection range starts where I'd put the cursor even if the UI now shows it starting several lines earlier.
It almost seems as if the selection is being redrawn at a different pace from the scroll position: the selection moves upward more often, while the scroll position update is chunkier... leading to them being out of sync whenever the scroll position update lags the selection position update (but occassionaly being in sync, right after the scroll pos has updated).
It seems to be timing dependent, anyway: just tapping Shift+Down repeatedly does not repro the issue.
Also, I've been unable to repro this in the sprint-9 build.
Note: to repro Peter's bug, you need the window sized fairly large (e.g. full screen on a big monitor). This creates a race condition between the keyboard handling and the scroll event handling, so multiple keyboard events are processed before the scroll event is handled.
FBNC to @peterflynn (again :)) -- this should generally fix any remaining scrolling issues around keyboard navigation and selection.
Excellent! Confirmed: all the above bugs are now fixed.
Bug 1
Result: (3) no blinking cursor visible, (4) view scrolls up one line to reveal cursor
Bug 2
Result: (3) no blinking cursor visible, (4) blinking cursor appears on a line in middle of viewport (view does not scroll at all)
Bug 3
Result: (3) no selection visible, (4) selection appears covering top ~1/2 of the viewport
Bug 4
Result: after it starts scrolling, the top of the selection range moves upward one or more lines
This one only seems to repro inconsistently -- it appears to be timing dependent.
Bug 5
Result: (3) selection highlight misaligned with text -- ends in the middle of a line's vertical bounds, (4) selection highlight extends way higher than you started from (often to the first line in the file)