Empty rehearsal mark not deleted after entering a line break.
Reported version
3.6
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
No
Workaround
Yes
Project
1) New score
2) Any measure --> New rehearsal mark.
3) Enter to enter a line break.
4) Delete the line break.
5) Click anywhere
Expected: The rehearsal mark disappear because it is empty (like it usually does)
Actual: 
Even more important maybe: If you enter something like "A" and then remove that line break. There is still space added below the A. Which makes the A not vertically centered in its box.
Fix version
3.6.2
Comments
Even more important maybe: If you enter something like "A" and then remove that line break. There is still space added below the A. Which makes the A not vertically centered in its box.
![2021-01-31 17_58_55-Window.png]( "2021-01-31 17_58_55-Window.png")
For anyone trying to reproduce this by following the steps provided, you should use the Add->Text->Rehearsal Mark (Ctrl+M) command. This way, the rehearsal mark is created empty, and it starts out in edit mode. This can happen with a rehearsal mark added from the palette, too, but it requires an extra step or two (i.e. editing the rehearsal mark and deleting the text).
This is an issue with any kind of text element, but the frame around the rehearsal mark makes it obvious that it is still there.
We've had a handful of other reports recently of layout issues that turned out to be caused by empty text elements, which normally are not possible to create. So chances are good this will turn out to have been the key. And my guess it was fairly recent changes in line break handling for 3.5 (see for instance https://github.com/musescore/MuseScore/pull/5881, although as I recall there were other relevant PR's) that introduced this. Could be this code itself is fine but it's the automatic deletion code that needs updating now.
See https://github.com/musescore/MuseScore/pull/7396.
Fixed in branch 3.x, commit a43712244a
_Fix #316754: Empty rehearsal mark not deleted after entering a line break
Resolves: https://musescore.org/en/node/315754.
When #4359 attempted to fix https://musescore.org/en/node/278068 (and was shortly followed up by #4364), the end result was that when a newline is inserted into a text block (causing it to split into two text blocks), the second text block would always end with a newline, even if the original text block did not. This is fixed here by setting the second text block's EOL flag to that of the original text block.
This is what is attempted by the function that joins two text blocks when a newline is deleted, but that function wasn't getting it right either. So that has been corrected here as well.
Taken together, these two errors meant that there would be a blank line at the end of any text element that had ever contained a newline. This blank line would be small, but it would always be present, even if you tried to delete it.
Because this blank was always present in multiline text elements, and because it was small enough to not attract much attention, #5881 only added an empty text fragment before a newline, and not after. But now that we do not have to have unwanted newline characters, in order to preserve the font size on a blank line, an empty text fragment may be needed after a newline also._
As a result of this commit, we should expect to start seeing reports of text elements from 3.6.1 or earlier not appearing correctly in 3.6.2 or later. I recommend responding with something like this:
Fixed in branch master, commit cceefb01e7
_Fix #316754: Empty rehearsal mark not deleted after entering a line break
Resolves: https://musescore.org/en/node/316754.
When #4359 attempted to fix https://musescore.org/en/node/278068 (and was shortly followed up by #4364), the end result was that when a newline is inserted into a text block (causing it to split into two text blocks), the second text block would always end with a newline, even if the original text block did not. This is fixed here by setting the second text block's EOL flag to that of the original text block.
This is what is attempted by the function that joins two text blocks when a newline is deleted, but that function wasn't getting it right either. So that has been corrected here as well.
Taken together, these two errors meant that there would be a blank line at the end of any text element that had ever contained a newline. This blank line would be small, but it would always be present, even if you tried to delete it.
Because this blank was always present in multiline text elements, and because it was small enough to not attract much attention, #5881 only added an empty text fragment before a newline, and not after. But now that we do not have to have unwanted newline characters, in order to preserve the font size on a blank line, an empty text fragment may be needed after a newline also._
Automatically closed -- issue fixed for 2 weeks with no activity.