The above patch is okay as far as it goes, and it prevents the immediate crash, but it does not get at the root of the problem. When a slur is added, if both endpoints are not specified, the slur starts out in edit mode. When a slur is in edit mode, its grips are supposed to be visible. If the slur is added by pressing the "S" key or by double-clicking the slur icon in the palette, the grips are indeed visible. But if the slur is dragged from the palette onto a note, the grips will not be visible, even though the slur is in edit mode. It seems that at this point, the ScoreView's state property is set to ViewState::EDIT, but editData.element is NULL. If the user tries to adjust the slur (with Shift+right arrow, for example), the program will crash.
Crash with basic scenario disappears. As mattmcclinch says Shift+right arrow leads to crash. I checked the basic scenario on MuseScoreNightly-2018-08-24-0815-master-55e0a7a. And I founded that there was no crash. I don't know exactly which commit added the crash. But anyway we need add some tests to mtest to prevent such kind of crashes in the future.
Now, about adding tests to mtest: The crash only occurred when dragging and dropping a slur from the palette. Other methods of adding a slur (shortcut key, double-click) did not cause a crash. I do not see how a test in mtest could have prevented such a crash.
Comments
See https://github.com/musescore/MuseScore/pull/3916.
The above patch is okay as far as it goes, and it prevents the immediate crash, but it does not get at the root of the problem. When a slur is added, if both endpoints are not specified, the slur starts out in edit mode. When a slur is in edit mode, its grips are supposed to be visible. If the slur is added by pressing the "S" key or by double-clicking the slur icon in the palette, the grips are indeed visible. But if the slur is dragged from the palette onto a note, the grips will not be visible, even though the slur is in edit mode. It seems that at this point, the ScoreView's state property is set to ViewState::EDIT, but editData.element is NULL. If the user tries to adjust the slur (with Shift+right arrow, for example), the program will crash.
Fixed in branch master, commit 76c6353957
fix #275834: crash when add slur to score
Fixed in branch master, commit ee9531d06a
Merge pull request #3916 from mattmcclinch/275834-status-bar-label
fix #275834: crash when add slur to score
handrok, could you please check the case again with current master taking mattmcclinch's comment into account?
Crash with basic scenario disappears. As mattmcclinch says Shift+right arrow leads to crash. I checked the basic scenario on MuseScoreNightly-2018-08-24-0815-master-55e0a7a. And I founded that there was no crash. I don't know exactly which commit added the crash. But anyway we need add some tests to mtest to prevent such kind of crashes in the future.
See https://github.com/musescore/MuseScore/pull/3920. This takes care of the other problem that I mentioned a few comments up.
Now, about adding tests to mtest: The crash only occurred when dragging and dropping a slur from the palette. Other methods of adding a slur (shortcut key, double-click) did not cause a crash. I do not see how a test in mtest could have prevented such a crash.
Fixed in branch master, commit 5af04c45dd
fix #275834: crash on Shift+right arrow after drag-n-drop slur from palette
Fixed in branch master, commit ec64d9098e
Merge pull request #3920 from mattmcclinch/275834-drop-slur
fix #275834: crash when add slur to score
In reply to See https://github.com… by mattmcclinch
If mtest can't test mouse actions that means that an additional test tool should be used to get quality software.
Automatically closed -- issue fixed for 2 weeks with no activity.