Resetting slur jumps to beginning of score

• Nov 25, 2019 - 00:46
Reported version
3.3
Priority
P1 - High
Type
Ergonomical (UX)
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore

Don't know the exact situations that cause this, but here is one that does it for me:

1) Make new score
2) Make sure to have two pages of staves
3) On second page, make two notes with slurs between them
4) Edit the slur and drag the left node a bit to the right
5) Reset the slur position by using the default [Ctrl+R] command

Result: The view-port jumps to page one for some reason, although it does carry through with the reset.

For testing purposes, included is a mscz file that already has a modified slur ready to be [selected] and then have a [Ctrl+R] to it (version 3.3.2).

It's really weird and confusing for this to happen when working, so in a sense I would describe this as a major bug, yet for now marking it as minor.

Attachment Size
bug_layout_slur.mscz 3.82 KB

Comments

• Nov 25, 2019 - 17:24
Status active ⇒ needs info
Type Functional ⇒ Ergonomical (UX)

I've seen this and a few other similar jumps since the recent change to the viewport positioning. However, it's not as simple to reproduce as the description above - when I try that exactly in a new score, I don't see it. So there is unfortunately more going on that needs to be understood in order to reproduce it. If you have a score and a more precise series of steps (how to position the score, which slur to edit, etc) that reproduces this reliably, please let us know.

Reply

• Nov 25, 2019 - 17:38
Regression No ⇒ Yes
Status needs info ⇒ active
Priority ⇒ P1 - High

I can reproduce this issue but the important part here is to make sure that this slur is not visible (I mean, it is out of viewport) when pressing Ctrl+R. If this slur is visible when this command is executed then no jump happens.

Reply

• Nov 25, 2019 - 18:29

Yes, I can reproduce in that case. And come to think of it, I think any other cases I saw probably also involved operations on elements currently not visible.

Reply

• Nov 25, 2019 - 20:50

If it's of any help, here's a .gif showing something similar to what I posted.
The steps are described: a few line breaks implemented, a new page, some line breaks, and then
two notes, give them a slur, then using tab I move the left node to the right. Finally. select the slur
and press Ctrl+R and the jump occurs. Here it is completely viewable, so it it seems not only to do with visibility:

jump_reset_slur.gif

Reply

• Nov 27, 2019 - 01:13

Another piece of related information:

During [edit mode] of a slur, if some changes are made to a node location and while in edit mode the user presses [undo / ctrl+z], a jump occurs, at least for me.

It's probably bad behavior on the user's end to do so, but it shouldn't force-jump to beginning at least and merely either do nothing while in edit mode, or reset to default positioning of the element (slur here).

Reply

Fix version
3.3.4