Shift / Control and dragging an element does not work (drags the score instead)

• Nov 28, 2018 - 10:49
Reported version
P0 - Critical
S3 - Major

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0, revision: 747f3e9

Open the attached file. Press [Shift] or [Control] while dragging any element.

Expected result: As in 2.x, confines drag to the vertical or horizontal.
Actual result: The element does not move, but the whole score is dragged

Attachment Size
shift_control.mscz 11.17 KB


Regression Yes No
Workaround No Yes
Priority P1 - High

Works as expected for me. You need to press Ctrl/Shift after you start dragging (and change the position a bit). The issue is here, indeed. We need to stop process Ctrl/Shift as panning when mouse button down event was received.

Not a regression. There was no panning in 2.3.

Regression No Yes

Good to know the workaround exists. But for the record, in 2.3.2 you can press Shift or Ctrl first on an element and dragging still works fine, and Shift+drag also worked fine to pan the score. So this is a regression. I do recall a previous release having an issue with misinterpreting one or the other unless you pressed it afterwards. I think it was Ctrl, and the issue was that Ctrl+click would activate "add element to list selection" had a chance to start dragging. Somehow it seems that must have gotten fixed before 2.3.2, but now broken again for both Shift & Ctrl.

Anyhow, the relevant code is ScoreView::mouseMoveEvent in events.cpp, which I happened to be looking at for other reasons today, which is how this came up again.

The problem with pressing shift/ctrl only after the item has started moving is that it is possible for the move motion prior to the keypress to happen along the undesired axis. I usually use the constrain dragging feature when I don't want an element to move even a single pixel either horizontally or vertically.

Priority P1 - High P0 - Critical

Agreed. I see no good reason not to fix this. Looking at the relevant code, it seems there were changes made do to general refactoring, making it hard to track things more specifically, but it seems more an oversight than anything intentional here. Right now this is on a very short of feature regressions, would be nice to eliminate as many of these as possible.

Fix version