Pushing a system with an horizontal frame causes layout problem

• Mar 9, 2017 - 09:26
Reported version
2.1
Type
Graphical (UI)
Severity
S4 - Minor
Status
closed
Project

!This seems to be a UI issue and doesn't do any damage that I've found! It's just trippy.
I'm on a fully updated Windows 7 machine. Got the error on the release 2.0.3, but I tested in build 2.1-15a2ba4 also.

Edit any thing in the attached mscz
Hit ctrl+z to undo, or use the undo arrow in the ribbon
(Screenshot attached)
Saving during this does not seem to damage anything, the file reopens normally.
Making any edit returns the UI to normal.

Thought I'd mention because I'm trying out some quarter tone things and added a frame, and I haven't seen much usage of the note element tuning, microtone accidentals or frames.

Attachment Size
MuseScore ScreenShot.jpg 197.48 KB
Characters_without_a_Story.mscz 10.62 KB

Comments

Version 2.0.3 and current 2.1 dev. a062dec / Windows7

Steps from scratch:

1) Load this file: frame test.mscz
2) Extend the horizontal frame to the point of creating a second system. Like this (image below)
im1.jpg
3) Do: Escape -> Undo -> Redo
(or, alternatively: edit a note, eg the first A to A# -> Undo)

Result: im2.jpg

"I wonder if maybe the bug was there already but just not seen in this particular case?"

Could you suggest a scenario (steps) to check this ?

The description of the #54221: Horizontal frame before last measure of system creates crowded layout says "the last measure should be pushed to the next system long before it is". That implies it eventually is, if you keep pushing far enough. What happens if you extend the frame that far? Might also need to put more notes in the previous or next measure. Or put two measures before the frame. Not sure. It's also possible that the conditions leading to the bug would never occur without my fix for the other bug, but the bug may have still been there. Or I might be wrong and my fix really is bad - but looking at the code, it really doesn't seem like it should have changed anything about undo specifically.

BTW, workaround is to add an explicit break after the horizontal frame.

With this nightly (the last one before the behavior change as indicated previously: ea43dd9), the handle of the frame comes out of the score (with one, or two measures - I tried- before the frame), and nothing particular after undo.
frame1.jpg

I see the previous commit, which deals a bit with undo (but for another question, text frames): https://github.com/musescore/MuseScore/pull/2093/files
Could there be something related from a manner or another?

No, I don't think that text frame issue could be related. I still kind of suspect the bug was already lurking and just never had a chance to bite because the conditions that caused it would never happen. Which is to say, I expect the actual code that needs fixing will turn out to lie elsewhere. But it's definitely good information that my change triggers the problem. Regardless of the underlying cause, knowing that this particular bit of code is somehow involved should be helpful. I will try to investigate a bit over the next couple of days, but don't have a ton of time right now.