Chord names display wrongly when being editted from the front
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Randomly
Status
duplicate
Regression
Yes
Workaround
Yes
Project
Procedure
1. Input a chord name (Shortcut: Ctrl + K) and quit editting mode
2. Double-click on the left of the first character of the chord name
3. Add any text from the front
4. <font face=""/> (text added) <font face="FreeSerif"/> (chord name) is displayed
This can be reproduced by repeating the process for a few times.
Workaround
Two ways:
1. Delete the chord name and input it again with the added text
2. Do not click on the left of the first character of the chord name
Comments
I can reproduce, but not with Standard style chord symbols, just with Jazz style
I cannot reproduce even with Jazz style. Can someone provide a sample score and more precise steps (which note to enter the chord on, which chord to enter, etc).
Any score (i think, i tool a random one of mine)
Switch to Jazz style chord symols
Follow the steps fron the top
In reply to Any score (i think, i tool a… by Jojo-Schmitz
Again, I cannot reproduce, so perhaps there is something score-specofoc, or maybe it has to do with the specific chord being entered, etc. So please, can someone attach a score and more precise steps?
here a score from the piano template, 2 normal chord symbils in Jazz style, the first modified as per this issue, with some useless prefix ("aa")
Trying to the same to the 2nd with valid content ("c/") results in a crash, sometimes, works on other and leats to the same bogus behavior on some more...
Huh. I tried about 20 times to reproduce the issue by adding "C/" in front of the "a". It worked, worked, worked, worked, worked, worked... and then failed. About 1 time in 10 I can reproduce. Are others find it always happens for them?
One clue is that on the times when it is going to fail, the new text chord gets marked in red as a misspelling, and it actually displays on top of the existing text rather than being inserted in front - do others see that too?
Today it was the 1st time I got it not to reproduce on occasions
See also #281831: text cursor before first character of a text element or before a special character of text aren't initialized to text element's default. Could be related to exactly where you actually double-click (I mean to the point of a few pixels difference).
Yes, when I saw that, I had that feeling
It can actually be reproduced in standard style. I can reproduce it quite often, not like 1 fail in 10 times. Just 2 or 3 trials can reproduce it.
The size of the "sweet spot" could depend on screen resolution, view magnification, the font size of your chords, etc. Anyhow, let's see if the fix for #281831: text cursor before first character of a text element or before a special character of text aren't initialized to text element's default addresses this, once it gets merged.
Now that the aforementioned fix is in, can anyone reproduce on current master? I'm guessing not.
No. So ot was a duplicate