TextEdit edit mode lost after undo...shouldn't be deselected

• Dec 23, 2018 - 12:12
Reported version
S3 - Major

repo steps:
1. start with default "Untitled" score
2. double click the Title text
3. select the first character ('T')
4. cut it (ctrl->X)
5. click between the 'i' and 't'
6. paste it (ctrl->V)
7. undo that (ctrl->Z)
8. paste again (ctrl->V)
9. select the first character ('i')
10. cut it (ctrl->X)

Observe a strange upward arrow symbol:

Screenshot (33).png

Note that the moment user clicks outside of the textbox, that strange symbol dissapears. But it is still indicative that there is some corruption going on, possibly either in the undo stack or in the text.

On MuseScore 3.0 rc1 OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit):, revision: 96c1f7b

(Aside: I also notice I can create some corruptions in 2.3.2, but that is without using the undo command which is actually not allowed in 2.3.2)


Simplified, more minimal reproduction steps:

  1. start with a text element which has text "ab".
  2. Select the 'a'
  3. Cut (ctrl->X)
  4. Put cursor on right of 'b'
  5. Paste (ctrl->V)
  6. Undo (ctrl->Z)
  7. Undo (ctrl->Z)
  8. Select initial 'a'
  9. Cut (ctrl->X)

Result, the 'a' turns into an up arrow.

Even more simplified minimal steps (probably as minimal as can get):

  1. start with a text element which has single character.
  2. select that character (ctrl->A)
  3. Cut (ctrl->X)
  4. Paste (ctrl->V)
  5. Undo (ctrl->Z)
  6. Undo (ctrl->Z)
  7. Select that character again (ctrl->A)
  8. Cut (ctrl->X)

What I'm discoverring is strange...when the final cut is performed, for some reason in
void ScoreView::keyPressEvent(QKeyEvent* ev)
the line
editData.s = ev->text();
gets assigned to a string with 1 entry 0x18 which turns out to be the mysterious up arrow (http://www.fileformat.info/info/unicode/char/18/index.htm which calls it "CANCEL").

So maybe the whole problem has nothing to do with stack being corrputed? I will have to see why hat ev->txt() contains the up arrow....

So I've determined that it has nothing to do with undo stack being corrupted. Rather what it is is that upon the last undo, ScoreView's state get's set incorrectly and so ScoreView::keyPressEvent() performs a test state != ViewState::EDIT, which messes everything up, such that the user subsequently enters special characters produced by holding Ctrl and the keys. It turns out that Ctrl->X produces the special unicode character of an uparrow that means "CANCEL". And other funny chracters can be produced with other key combinations.

Here is an illustration of how after the edit mode disappears (when text no longer becomes blue), then I can press other Ctrl->key combinations like Ctrl->x, Ctrl->c, Ctrl->v, Ctrl->b which are interpreted as their actual unicode text, rather than as the special commands they should be:


So the absolute minimal repro steps can be created by causing an undo to happen. Step 1 here is

  1. Double-click text element
  2. Do some edit (could delete a character, could add a character, could cut a character)
  3. Undo (ctrl->Z). This causes the blue coloring to disappear, indicating that textedit state is confused
  4. Now any Ctrl->letter will produce one of their special unicode chars, rather than what is intended
Title TextEdit edit mode lost after undo TextEdit edit mode lost after undo...shouldn't be deselected

commit 68f87040f8b92fd4a588f5997b7fbc74cb5a17be sems suspect....particularly the


in UndoMacro::undo(). If I comment that out, then the text edit works, since it doesn't get deselected. So I guess the solution might lie in not deselecting everything if in text edit mode. I don't know quite the best wa to check if in text edit mode, though....

Status PR created fixed

Fixed in branch master, commit 6f07a47e41

fix #280522 undo text edit keep TextBase selected

Previously when undid an edit in a TextBase element, that TextBase element would be unintentionally deselected, resulting in subsequent inputs with Ctrl-> to produced undesired unicode values instead of performing their typical commands of cut, copy, etc.

This commit tries to make sure TextBase elements aren't deselected if undid an edit that was simply for text in that textedit box.

Dmitrio suggeseted adding TextBase to the list of elements for which single selection will be restored, and that works.

Fix version