[Regression] Context menu ALWAYS broken (under Windows?)

• Jun 23, 2019 - 20:50
Reported version
3.1
Priority
P0 - Critical
Type
Functional
Frequency
Many
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
Yes
Project
MuseScore

Last nightly: OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.2.0.7362, revision: f2634a0

Hmm.... something weird/unexpected with the selection in context menu.

1) Load this test file: lyrics.mscz
2) Simple/Left click a syllable
3) Right-click
Unexpected result: syllable is in edit mode
And so:
4) Try to select Cut, or Copy etc.
Result: failure

  • I just discovered this issue: no sure about the status, but probably critical if not more, considering the embarrassment on such basic/essential functions caused by this regression.
  • Of course, same behaviour with chord symbols (and other things I guess): chords.mscz

Comments

• Jun 23, 2019 - 22:45

I can't reproduce on Mac checking against latest master (more recent commit f2634a03c). A recent change is that a second NORMAL click now does put text element into text editing mode. Right (or control-click) doesn't do that for me. (Also note, the right click without selecting if over the target element does generate the context menu for the element). Might be related to https://musescore.org/en/node/10986 and/or https://musescore.org/en/node/290271. Are all PC users having this issue??

Reply

• Jun 24, 2019 - 01:31

I can reproduce, also on Windows. After a single click, another click on the same element - right or left - puts the element into Edit mode. It's the new ScoreView::startTextEditingOnMouseRelease() function that is kicking in, not sure why. But the line "startEditMode(textBase)" is being executed.

As far as I'm concerned it's a bug if either a second left click or a right click puts an element into Edit mode. Only double click, or right-click followed by an explicit Edit Element, should do that.

Reply

• Jun 24, 2019 - 05:41

And so, the context menu is broken.
By this way: right-click on text, lyrics, chord symbols, etc., you cannot Cut/Copy/Paste/Delete

Reply

• Jun 24, 2019 - 06:10
Title Problem with selection/edit mode in context menu ⇒ Problem with selection/edit mode in a broken context menu

Reply

• Jun 24, 2019 - 18:36

FWIW, the workaround is to press Esc or click elsewhere to leave edit mode, then it works. Or, just don't click to select the element in the first place - it's always been the case that a right-click is sufficient.

Reply

• Jun 24, 2019 - 18:44

"it's always been the case that a right-click is sufficient."
Of course, but as said, right-click no longer works too.
Right-click a text, or lyrics etc, try to cut/copy/paste ou delete: failure, nothing happens

And really a bit weird to use workarounds for basic/essential features waited by a such program.

Reply

• Jun 24, 2019 - 18:50
Priority ⇒ P0 - Critical

Sure, absolutely agreed. I know fixes are being investigated, but for the record, if one isn't found that is completely satisfactory. I'd favor reverting the change that caused this (the facility to allow double-click and triple-click to do interesting things once in edit mode) for 3.2 and revisiting that later.

But, for, me, right-click then cut/copy does work for me after pressing Esc.

Reply

• Jun 24, 2019 - 19:06

"for, me, right-click then cut/copy does work for me after pressing Esc."
Not here.
And really surprised that PRs can be merged without caring about the platform (in this case that breaks the Windows context menu)

Reply

• Jun 24, 2019 - 19:33

Realisticallly, what happens is that a PR is tested to see if does the things it is supposed to do, but sometimes it might not be noticed if it breaks something else. Probably no one understood at first that this would break the context menu, so whether it was tested on Windows or some other platform wouldn't have mattered. These things happen, I'm just glad you caught it!

To be clear, though, here is what works for me:

1) click text
2) right-click text
3) press Esc once to close context menu
4) ress Esc again to exit Edit mode, but leave text selected
5) right-click text again
6) cut or copy

It's not obvious to be sure, but it is the sort of thing one might eventually stumble on through trial and error.

Reply

• Jun 25, 2019 - 11:03
Title Problem with selection/edit mode in a broken context menu ⇒ [Regression] Context menu ALWAYS broken (under Windows?)

Sorry to tell you this guys, but I can't believe you could make such a mistake before the release of 3.2.
How should I tell you this? The context menu opens with a simple right-click, which has always been the case under Windows, and MuseScore.
But it's still broken.
1) Open this file: text.mscz
2) Right-click on the text

Result: does not work as expected.... Grrr! (sorry, a bit nervous here)

Reply

• Jun 25, 2019 - 12:34

This issue is about how right click switched to edit mode. That much has been fixed. The matter of certain options being disabled if the element is not selected first is present in MuseScore 2 and all previous versions of MuseScore 3. It is certainly not a new regression, and I have never seen it reported until just now.

Reply

• Jun 25, 2019 - 13:10
Status active ⇒ fixed

Ok, you are right, sorry for the direct words above! It seems that I found it tricky to untangle what was due to this specific issue (right-click/edit mode), and the changing behaviors/or rather the changing display with the single right-click.

With 2.3.2, Cut and Copy are inactive, they were active before the 3.2, and now again are greyed out.

But eg Delete, always active (among others), never works.

It seems that at least when items are active, the expected behaviour is that you can Cut or Copy or Paste or delete. For example, as it works for Selection or Edit element.

So, I close this issue, and we will have to review these behaviors in the context menu again for improve in consistence.

Reply

Fix version
3.2.0