Bad layout of mmrest at start of system

Actually, I might be confusing myself, not sure it's really an extra layout for the thumbnail here. But during the layout we are performing, both startTick and endTick in the LayoutContext are 0. That's the key for a layout all, I think. The the test I have for lc.endTick < lc.prevMeasure->tick() is probably not good, if we're doing a layout all we need to just keep plowing ahead.

I have verified it works to skip this code is endTick is zero (probably safest to check <= 0). But I'm still too confused to want to submit that as a PR just yet.

Hmm, zero really is a perfectly valid value for endTick; it happens if you change the pitch of the first note of the score, for instance. But in such cases, an mmrest on the next system should have already been laid out. What's special about the case at hand is that the mmrest seems not to have been laid out, even though it pretty clearly was, both when we loaded the score and when we did the pitch change. So it isn't clear what is invalidating that layout. But, it's not just save - that just happens to have been the trigger in my original steps. Also, changing a note on the first system has the same effect. It shouldn't, we should be doing the range layout thing, finishing the first system, then and calling it good. Which is to say, the code here should work. The question is, why isn't the mmrest laid out by now?

I finally figured it out. The issue isn't in the code shown above, but in the code a few lines earlier, where curHeader, curTrailer, and curWidth are being set. lc.nextMeasure at that point is the underlying measure, not the mmrest. The mmrest gets constructed immediately afterwards, in getNextMeasure(), presumably so we can check again whether it's still appropriate and how long it should be.

So, the fix is to check for an existing mmrest on nextMeasure and use that instead. Here is a PR:

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

This bug would have been around since the second beta so I'm a little surprised it hasn't been reported already, but it is pretty dependent on details of layout order and doesn't affect all mmrests at the beginning of systems, or at least not on all operations. Still, it's quite simple to reproduce from scratch now that I understand what is happening:

1) default empty score
2) enter notes into bars 1-4
3) enter note(s) into bar 8
4) press "M" to enable mmrests
5) change pitch of first note

Result:

See also #289933: Layout shift in measure at start of system. Not really the same cause but some of the same code is involved, so there are similarities in symptom (messed up layout at beginning of system after a range layout following an edit or save).