Element dragging with modifier keys [ctrl/shift] incorrectly apply offsettings of previous drags

• Jun 22, 2020 - 22:53
Reported version
3.x-dev
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project

Not sure to what kinds of elements this is applied, but the bug has occurred with tuple texts as well as staff text, so it may be generic. Happening in 3.5Beta but don't recall ever experiencing it in the past so this is marked as a regression.

Specific example steps:
1) Load up attached score
2) Move around a text element by click+dragging freely somewhere (the BPM text for instance
3) Now Shift+Drag mouse on another element (the staff text afterwards or tuple)
Result: The x-offset which was applied by user at (2) is applied to the element selected at (3)!

Demonstration:

shift-drag-offset-error.gif

Though rusty on severities - without rules, intuitively this seems between minor and major.


Comments

A quick glance at the code shows this is in dragelement.cpp, ScoreView::droDragElement(), where there is a check for ShiftModifier and then a use of editData.delta.x(). Probably that wasn't ever cleared from the previous edit or set on this one.

Title Offsetting of previous element is applied to next moved element when mouse shift dragging Element dragging with modifier keys [ctrl/shift] incorrectly apply offsettings of previous drags
Status active PR created

I'm going to submit a PR since I've tested a change and it works so far locally, but any further testing would be appreciated to be safe.

https://github.com/musescore/MuseScore/pull/6260

Fixed in branch 3.x, commit 030acb1f20

_Merge pull request #6260 from worldwideweary/307077-DragOffsetRetainedWithModifiers

Fix #307077: Dragging element(s) with keyboard modifiers were retaini…_

Fix version
3.5.0