Crash on next-element when editing fingering with user text style

• Aug 29, 2019 - 18:05
Reported version
3.2
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
Yes
Project
MuseScore

1) score with two notes
2) add fingering to first note
3) change text style to user-1
4) edit the fingering
5) press Space

Result: crash

We're trying to add a text to the second note, using the same text style as the previous element using cmdAddText(), which derives the element type from the text style. For user text styles, this will fail, but nowhere does the code check for failure, and at some point after that, it can crash (different results depending on element type).

While a simple fix is to add the necessary checks, better I think would be to actually force the correct element type to be created, so that's the approach I plan to try first.

Comments

• Aug 30, 2019 - 22:26
Status PR created ⇒ fixed

Fixed in branch master, commit 7cb3bc28e0

_fix #293894: crash on Space when editing custom fingering

When editing fingering with a "User" text style applied and then hitting Space,
we try to create a new text element on the next note,
but the attempt fails because cmdAddText() keys off the text style,
and there is no handling for user styles (not clear what element type should be created).
Unfortunately there are no further checks for this and eventually there is a crash
as we attempt to update the text toolbar on the non-existent text element.
I should note that Alt+Right does not crash, but the operation still fails for the same reason.

This commit addresses the underlying problem directly
by making sure we create the element correctly:
passing in the default Tid for the desired element type in cmdAddText(),
and then overriding the Tid afterwards if necessary.
Thus, we never fail to create the text and thereby avoid any ill effects.
As a bonus, we gain the ability to add texts with a style different from the default.

Also fixed a gltich in Inspector not updating after using Space for fingering.
The update happens for Alt+Left/Right because those are in ScoreView::MuseScore::cmd()
which calls results in an eventual call to MuseScore::endCmd()
but this doesn't happen during TextBase::edit(),
which is where Space is processed._

Reply

Fix version
3.3.0