Repository navigation
Fix out of bounds text selection with line wrapping - #262910
Alexandru Dima (alexdima) merged 2 commits into
Conversation
The original behaviour is confusing and somewhat hard to explain. Given a Monaco editor with text wrapping enabled, if the user starts selecting text and moves the mouse outside of the editor viewbox, to the right of the screen, the cursor in the editor would be somewhere halfway the editor. The editor cursor did move with the mouse. So moving the mouse further right, moved the cursor further forward. The text cursor could even move onto the next line, below the mouse position. In case of RTL, the behaviour was the same. Further right means more forward, meaning it was visually mirrored. The new behaviour with this PR is easier to explain. If the cursor moves out of bounds while selecting text, the selection will match the end of the wrapped line at column matching the cursor height. It also takes RTL into account. The new behaviour matches gedit, LibreOffice, Google Docs, HTML content in browsers, and even Monaco Editor with text wrapping disabled.
|
Friendly ping :) I believe this is mostly up Aiday Marlen Kyzy (@aiday-mar)’s alley. |
|
Hi Remco Haszing (@remcohaszing), thank you for your PR. I am not sure I understand the initial issue as well as the PR fix. Could you please write a numbered set of steps for how to reproduce this issue, and include the expected result as well as the actual result? A screen recording showing the issue would be helpful. Could you also explain your fix in more detail? Thank you. |
|
You’re right. The issue is hard to explain in text. A screen recording explains it much better. I recorded a video where I selected and moved the mouse around. Especially towards moving further towards the right shows the issue. This is the original behaviour: simplescreenrecorder-2025-12-19_11.11.04.webmThis is the new behaviour: simplescreenrecorder-2025-12-19_11.08.13.webm |
|
I see I think from the videos I understood that the current behavior is that as you move the mouse the selection slowly increases along a line. With your PR, as you move the mouse, the selection will highlight the next full lines instead of highlighting slowly character by character. I see the value in this PR, but I am not sure we should merge it until we have gotten feedback on this issue. Could we create a feature request issue and gather feedback from the community? I don't think we should change the default behavior unless there is enough upvotes for that. |
|
You can see at 0:05 of the video showing the original implementation that when the mouse moves outside of the editor to the right, the text selection suddenly moves a few characters to the left. From there on the text selection behaves as if the line isn’t wrapped at all. You can try this in the current VSCode with default settings. For example, open README.md from the VSCode repo in VSCode with default settings. Make the editor narrow, so it starts wrapping line 8. Now start selecting text by moving the cursor to the beginning of line 8 and move it to the right, our of bounds. This behaviour feels very unnatural. 
The second video with my changes can be described as: the same as every other application that has selectable text. I really think the current behaviour without this PR is a bug. |
|
Hi Remco Haszing (@remcohaszing) thanks for the explanation. I agree that the cursor moving several characters back is a bug. This should indeed be fixed. I am not sure about the second part which is that when you move the mouse out of bounds, the selection increases by a full view line each time instead of character by character. Did you mention other editors behave this way? |
|
Yes, every other application I can think of and try, has the behaviour of this PR:
|
There was a problem hiding this comment.
Pull request overview
Fixes out-of-bounds mouse selection at wrapped-line boundaries, including RTL text.
Changes:
- Snaps selection to the appropriate wrapped-line endpoint.
- Accounts for RTL line direction.
Show a summary per file
| File | Description |
|---|---|
src/vs/editor/browser/controller/dragScrolling.ts |
Updates horizontal drag-selection targeting. |
Review details
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
- Files reviewed: 1/1 changed files
- Comments generated: 1
- Review effort level: Balanced
Alexandru Dima (alexdima)
left a comment
There was a problem hiding this comment.
Thank you! ❤️
|
Would adding a test for this change be a good idea? |
The original behaviour is confusing and somewhat hard to explain. Given a Monaco editor with text wrapping enabled, if the user starts selecting text and moves the mouse outside of the editor viewbox, to the right of the screen, the cursor in the editor would be somewhere halfway the editor. The editor cursor did move with the mouse. So moving the mouse further right, moved the cursor further forward. The text cursor could even move onto the next line, below the mouse position. In case of RTL, the behaviour was the same. Further right means more forward, meaning it was visually mirrored. The new behaviour with this PR is easier to explain. If the cursor moves out of bounds while selecting text, the selection will match the end of the wrapped line at column matching the cursor height. It also takes RTL into account. The new behaviour matches gedit, LibreOffice, Google Docs, HTML content in browsers, and even Monaco Editor with text wrapping disabled. Co-authored-by: Alexandru Dima <alex.dima@outlook.com> (cherry picked from commit 63da5e8)
The original behaviour is confusing and somewhat hard to explain. Given a Monaco editor with text wrapping enabled, if the user starts selecting text and moves the mouse outside of the editor viewbox, to the right of the screen, the cursor in the editor would be somewhere halfway the editor. The editor cursor did move with the mouse. So moving the mouse further right, moved the cursor further forward. The text cursor could even move onto the next line, below the mouse position. In case of RTL, the behaviour was the same. Further right means more forward, meaning it was visually mirrored.
The new behaviour with this PR is easier to explain. If the cursor moves out of bounds while selecting text, the selection will match the end of the wrapped line at column matching the cursor height. It also takes RTL into account.
The new behaviour matches gedit, LibreOffice, Google Docs, HTML content in browsers, and even Monaco Editor with text wrapping disabled.
Closes #291901