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

worldwideweary

• Jun 22, 2020 - 22:53

Reported version

3.x-dev

Type

Functional

Frequency

Once

Severity

S3 - Major

Reproducibility

Always

Status

closed

Regression

Yes

Workaround

Project

MuseScore

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:

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

Comments

Marc Sabatella

• Jun 22, 2020 - 23:04

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.

worldwideweary

• Jun 24, 2020 - 16:38

And yet in ScoreView::startDrag() there is a editData.clearData(); statement. Theoretically, it looks like this should work fine. Either way, maybe the people who implemented group dragging were the ones who introduced the error somehow.

worldwideweary

• Jun 25, 2020 - 00:53

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