beginning clef changes back after hiding first barline, reopening file

[Brathenning]

Issue type

Engraving bug

Bug description

After reopening a file where you changed a clef at the beginning and hid the very first barline, the original clef is at the beginning and the new clef is added as an in-stave clef change.

Steps to reproduce

create a file with at least two staves (to make sure, that there is a a barline on the left most side)
change the clef of any stave to any other clef
hide (V) the very first barline of the corresponding stave
save
close
reopen

Screenshots/Screen recordings

No response

MuseScore Version

4.0.2-230651553, revision: github-musescore-musescore-dbe7c6d

Regression

I don't know

Operating system

Windows 11

Additional context

Once the bug is there it won't go away: everytime you reopen the project after saving, the clef is wrong again, even if you show the barline again

I'm on Windows 11 (I updated from Windows 10) and have the newest version to my knowledge but the copied revision from Help > About MuseScore dialog said I had Windows 10 2009 version

[oktophonie]

Interesting one!

A clef change added to the beginning of the score does not actually replace the initial clef; it creates a clef change, which (because there is no intervening barline) is drawn in place of the initial clef (which comes from the instrument definition).

The system barline is normally an 'implicit' item and so isn't saved directly in the file; it is just drawn (where appropriate) at the start of the first measure in the system automatically. However, if you alter it in some way, for example by making it invisible, an explicit barline item is created at the very beginning of that measure; and, because this comes before the clef change in the file, this causes the clef to be drawn as a clef change at the start of the measure, rather than just replacing the initial clef.

This behaviour is similar with all 'system header' items (clefs, key signatures, time signatures). A very closely related issue is #15311

Ultimately #16814 will address this problem comprehensively, so I will close this issue as incorporated into that (but will link this one from there).