Undocumented behavior change on vertical cursor movement

[LSViana]

Describe the issue

The package @codemirror/view at v6.39.0 introduced an undocumented behavior change.

The behavior change relates to the cursor vertical movement and how the column position of the cursor is handled when moving up and down between the lines.

The repro steps are simple:

1. Visit the Try CodeMirror page
2. Put cursor at the end of line 6
3. Push "Page Up"
4. Push "Home"
5. Push "Arrow Down"

When executing step #5, the behaviors compare as follows:

Version	Behavior
v6.38.8	The cursor remains at the beginning of lines when moving up and down.
v6.39.0	The cursor tries to move to the previous column position when moving up and down.

The previous behavior matched the behavior of VS Code & IntelliJ IDEs. The new behavior doesn't match it anymore. Besides that, pushing "Home" is essential to reproduce the bug. If it's not pressed, the behavior is correct.

---

After some quick review of the code changes between v6.38.8 and v6.39.0, I believe the possible culprit could be the following changes at the src/cursor.ts file (view with GitHub UI):

   for (let extra = 0;; extra += 10) {
     let curY = startY + (dist + extra) * dir
     let pos = posAtCoords(view, {x: resolvedGoal, y: curY}, false, dir)!
-    if (curY < rect.top || curY > rect.bottom || (dir < 0 ? pos < startPos : pos > startPos)) {
-      let charRect = view.docView.coordsForChar(pos)
-      let assoc = !charRect || curY < charRect.top ? -1 : 1
-      return EditorSelection.cursor(pos, assoc, undefined, goal)
-    }
+    return EditorSelection.cursor(pos.pos, pos.assoc, undefined, goal)
   }
 }

At the end, I'd like to ask:

1. Was this change intentional?
2. Was this change documented (and maybe I missed it)?
3. Will this behavior change be fixed?

Browser and platform

Chrome on Windows & macOS

Reproduction link

https://codemirror.net/try/

[marijnh]

This seems like a very specific scenario to worry about. Is it an instance of a wider issue you are running into, or did this specific scenario somehow cause issues?

The change wasn't intentional. The new posAtCoords implementation provides a more meaningful assoc value, which caused the cursor produced by moving to the start of the document with curorPageUp to have a different assoc than it used to have, which in turn made it compare equal to the position computed by cursorLineStart, preventing that command from updating the selection.

Attached patch makes it so that goal columns are compared when deciding on selection equality, so that this now behaves the way it used to, but in a more intentional way.