Navigation shuts down after the last note of a score

Confirmed, thanks for catching this, investigating.

I may figure this out before you, but in case you see this soon: are you sure it wasn't #294485: Previous/next element commands should not wrap around begin/end of score, which was merged around the same time? This changed the behavior of Alt+right to no longer wrap back to the beginning of the score, and I could easily beleive that would cause a problem in the "fingering mode", as I previously never needed to check for end of score.

As far as I can tell, it's definitely about the change to wrapping, not the fix for the 4th voice issue (edit: our post crossed, thanks for the confirmation). And it has nothing to do with rests, I can make the same happen any time I hit "Space" after the last note of a score. Also, I can also get a related hang in 3.2.3 if I have a score with only a single note, which was fixed at some point (#283316: Hang on pressing space after entering fingering on only note of score) but apparently came back.

Anyhow, I should have a fix soon.

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

As stated in the PR, "The issue is a crash or hang on navigation while in text edit mode (aka "fingering mode") after the last note of a score. Results differ according to whether you actually enter text onto that note or not, whether it was a fingering or a different type of text (segment attached), and for fingering, whether you press Space or Alt+Right to navigate. All of these presented slightly different different aspects of the problem and needed to be dealt with slightly differently." Also, I should mention, some but not all of these were also a problem in 3.2.3, also depending on whether there was only one note in the score. But I believe I fixed all the cases.

Fixed in branch master, commit 68a3791c47

_fix #295107: hang or crash on fingering mode after last note

There turned out to be several aspects to this.
In 3.2.3, we could get a hang if there was literally only one note,
as the navigation would loop back around and we didn't always catch it.
For 3.3 I eliminated the looping back around on navigation,
but neglected to add a check for start/end of score in "fingering mode".
This adds that check (in ScoreView::textTab(), the test for el2 == el).
But further testing revealed further checks we need to make to be safe.
The checks that the current element is actually a child of the note
in Note::nextInEl() and Note::prevInEl() prevents a crash
if one navigates before the fingering has been added to its parent
or after it has been removed (which happens with empty fingering elements).
For consistency with how chord symbols work, and to circumvent other future problems,
I elected to have Space exit "fingering mode" after reaching the end of the score.
This required making a reasonable selection (the "exit cleanly" code in textTab)
but also calling mscore->endCmd() and returning immediately in events.cpp in that case.
This had the side benefit of allowing me to remove the updateInspector() call
in textTab(), as it is covered by the endCmd() call.
I should note there are other code paths in, for example, the harmony tab functions,
that can leave an empty / deleted element still selected
when hitting space upon reaching the last note of a score.
But I could cause an actual problem to occur and chose to not deal with that here.

Script test added to cover the basic issue here._

Fixed in branch master, commit c236e88a6d

_Merge pull request #5358 from MarcSabatella/295107-nav-crash

fix #295107: hang or crash on fingering mode after last note_

Automatically closed -- issue fixed for 2 weeks with no activity.