No response when attempting to position the text cursor at the end of a range selection
Musescore 3.5.2, on Windows 10.
To reproduce: Create a new score with the title "Example Text". Double-click the score's title on the canvas to enter text edit mode. Highlight all text from the capital E to the capital T inclusive, by dragging the mouse cursor from left to right, so that "Example T" is selected. Left-click the right-hand half of the letter "T".
Expected behaviour: The range selection should be dismissed. The text cursor should be positioned between the "T" and the lowercase "e" in "Text".
Observed behaviour: The selection does not change.
Note that this bug does not occur if:
- The range selection is created by dragging the mouse from right to left, rather than dragging from left to right. (In that case, the "E" becomes unresponsive, rather than the "T".)
- The user clicks the lowercase "e" in "Text", rather than the letter "T".
- The user clicks the left half of the letter "T", rather than the right half.
The bug still occurs if the range selection is created by double-clicking. In that case, the "dead zone" is positioned at the right-hand side of the selection, as though the mouse cursor had been dragged from left to right.
This bug isn't as trivial as it might sound. For example, when attempting to change the chord symbol "C" to "G", this bug will make half of the entire text item unresponsive to the mouse.
Comments
I can reproduce the issue, but honestly I can't imagine people actually trying to replacing a letter by dragging the mouse to select it, when there are so many more obvious and more efficient ways (e.g., just press Delete, or select the text then simply type the new text). Is there some special scenario I am missing?
Sorry, my last example was badly chosen. Instead, imagine that the user has the chord symbol "C", which they've triple-clicked. After selecting it, they decide that they'd like to change it to "Cm". Because the mouse cursor is already close where it needs to be and their hand is already on the mouse, they quite reasonably move the mouse cursor over to the right-hand side of the letter "C", but when they click, nothing happens. Frustration!
In any case, I question the wisdom of dismissing modes of input because they appear inefficient. Normal users frequently act inefficiently.
I'm not dismissing anything, just trying to understand the context to help us judge the priority - in particular to judge whether it is in fact more serious than it first appears.
In your example, I'm not understanding why anyone would triple-click in this case when double-click is simpler and doesn't have the undesired side effect of selecting something you don't want selected. Actually I doubt most people are even aware of triple-click as a thing, and until a few months ago it wasn't.
So, after double-clicking the chord symbol to put it in edit mode, cursor position depends on exactly where the mouse was when you double-click, but if it's not already at the end, I expect most people would simply move the cursor to the end of the text using the Right cursor key, or End key if it was something longer that they were trying to get to the end of. After all, their hand might be on the mouse, but they are about to type so they are already moving toward the keyboard. Plus move the cursor using cursor keys the vast majority of the time. Would be interesting to see data on that. But in any case, this same approach - cursor or End key - would work even after triple-clicking.
So to me it seems pretty unlikely most users would ever run into this, which is probably why no one has reported this issue before. But certainly, worth fixing as time permits. As with any bug, it just needs to be weighed in priority, so again, that's why I am trying to understand the use case here.
My expectation is that when I double click to edit text, the cursor is placed where I double click and nothing is selected. As others have said, I'm more likely to want to add something to an existing text than to replace something within the text.
Anecdotally, I've been using MuseScore for a year or two, and I've been frustrated by this bug almost every time I try to edit text. I can't provide a more specific use-case than that.
I would note that most users are not power users, so saying "this bug won't occur if the user edits text in an efficient way" isn't necessarily the same as saying "this bug is uncommon". I preferentially use the mouse for repositioning the text cursor, rather than using the keyboard.
I wouldn't attach too much weight to the fact that this bug has been unreported until now. Until I finally figured it out yesterday, this bug just presented itself to me as "left-clicking text frequently does nothing, forcing me to click around randomly until it starts working again". It wouldn't have been a useful bug report.
Looks similar to #294497: Text edit mode: highlighted text does not deselect consistently.
Fair enough, but now that you know you don't need to triplet-click - double-click suffices - and that if you want to select text, the usual shortcuts (eg Shift+cursor) work, and if you want to position the cursor after a selection, the cursor keys also work very well - hopefully you'll be less frustrated going forward while awaiting a fix for this.