Selection highlighting changes unpredictably when adjusting with Shift + Arrow keys

[okrick]

I have difficulty making precise selections using the keyboard. I expected someone else might report this issue, but I have not seen it mentioned, so I am reporting it.

Please consider this an accessibility issue. Reliable keyboard selection behavior is important for users who depend on precise cursor movement and keyboard-based editing.

Steps to reproduce:

Case 1: Reducing a selection from the end of a line

1. Position the cursor at the extreme left of a line.
2. Press Shift + End to select to the end of the line.
3. Press Shift + Left Arrow once.

Actual behavior:
The left side of the highlighted area moves right by one character, and the right side moves left by a variable number of characters.

Expected behavior:
The left side of the selection should remain fixed, and only the right side should move left by exactly one character.

---

Case 2: Reducing a selection from the beginning of a line

1. Position the cursor at the end of a line.
2. Press Shift + Home to select to the beginning of the line.
3. Press Shift + Right Arrow once.

Actual behavior:
The left side of the highlighted area moves right by one character, and the right side moves left by a variable number of characters.

Expected behavior:
The left side of the selection should move right by exactly one character, and the right side should remain fixed.

This makes precise keyboard-based editing difficult, especially when trying to select or adjust small portions of text. Consistent selection behavior would improve usability and accessibility.

[windymilla]

Thanks for the report, @okrick - we'll look into it.
In the meantime, I think it works if you click at the beginning of a line, then Shift+End to the end, then Shift+Left. I suspect you are clicking in the middle of the line, then using Home to go to the beginning. It's the click that resets the "anchor" that it thinks it is selecting from.
It's certainly a bug, and I hope I'll be able to fix it for the next release.

[okrick]

Nigel, thank you. That may explain how large chunks of text sometimes get selected when I am not intending to select them.

I also tried to reproduce that behavior, but I have not been able to trigger it today. If I encounter it again, I will post the steps here if they appear to be different from the issue I described above.

[okrick]

Finally reproduced the issue where a huge section of text is selected.

Steps to reproduce:

1. Search for: <i>((.|\n)*?)</i>
2. Replace with: <i><lang=fr>\1</lang></i>
3. Correct the language code.
4. Pressed F3 to search for the next occurrence of a word (in this case, “mêlée”).
5. Click on the word "mêlée.".
6. The entire section of text from the location of my previous edit to the point where I clicked is highlighted.

This appears to be related to the cursor/selection position not being reset correctly after the previous operation.

blackwood496.zip

[okrick]

This does not happen consistently, but it appears that double-click word selection sometimes includes adjacent HTML markup characters when it should select only the word itself.

Example:
The text was: <i>mêlée</i>

I double-clicked on mêlée to copy it to Google Translate to determine the appropriate language code.

Actual behavior:
The selected text was: >mêlée

The closing greater-than sign from the HTML tag was included in the selection.

I clicked somewhere else and tried again. This time the selection was correctly: mêlée

---

On further examination this seems to always occur after the huge section issue preciously mentioned has happened. I feel this likely would be corrected if that issue is fixed.

[srjfoo]

Thanks for reporting the issue, Rick. As Nigel said, I think we need to get the bug we identified (both he and I could repeat that there's a selection issue, so it's definitely not-just-windows and not-just-mac!), and see if that fixes anything else you're seeing. Until we get that fixed, I don't think we can properly diagnose any other problems.