Bug 107857 - Incorrect formatting logic when replacing formatted selected text (should be true replace instead of delete+insert)
Summary: Incorrect formatting logic when replacing formatted selected text (should be ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
: 108333 112056 (view as bug list)
Depends on:
Blocks: Styles Writer-UX Cell-Direct-Formatting-Parts Formatting-Text-Diverse
  Show dependency treegraph
Reported: 2017-05-15 02:08 UTC by Kevin
Modified: 2024-02-20 04:33 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:

demonstrates both sets of steps (8.34 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-05-15 06:46 UTC, Kevin
Screencast (224.34 KB, image/gif)
2017-05-17 11:24 UTC, Heiko Tietze
steps for alternate aspect of bug described in comment (10.37 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-05-20 04:43 UTC, Kevin
This goes with the comment that references 10857-b.ods (steps in spreadsheet) (17.24 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-05-21 09:26 UTC, Kevin
steps for the comment referencing 10857-c.ods (12.52 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-05-21 09:47 UTC, Kevin
absolute simplest case (13.31 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-06-21 21:09 UTC, Kevin

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin 2017-05-15 02:08:38 UTC
Calc fails to retain format of a selected character in a way that contradicts every other program I've ever used, including Excel.

Steps to Reproduce:
1. in Excel, enter a cell
2. set the font color to Red
3. type R - a red R appears - type space
4. set the font color to Green
5. type G - a green G appears - type space
6. set the font color to Blue
7. type B - a blue B appears now you have R G B, each letter with its own color
8. with the mouse select only the green G
9. type g - a green g replaces the green G - this is desirable behavior - the user will often want to change a value without changing its format
10. repeat with Calc - a red g replaces the green G - it's same with superscript, bold and all other formatting options

Actual Results:  
When selecting and replacing a character, Calc, instead of retaining the format, looks backwards to the previous character (within the same cell) and forces that formatting on the user.

Expected Results:
Calc should behave like Excel unless Excel has a bug or bad design. It should also behave like almost every other program on the market. Even after understanding Calc's behavior, it still take more keystrokes and mouse clicks to perform the same operation.

Reproducible: Always

User Profile Reset: No

Additional Info:
I wish you could stand behind a user and watch him or her spend hours working on formatting a massive spreadsheet with lots of border, backgrounds, format and font changes - and especially changes to individual characters within the same cell. You would see just how incredibly frustrating the program is. As always, I realize I'm complaining about a product that's free, and I still find it significantly less frustrating than Excel on balance, but Calc is not anywhere near as intuitive and intelligent as I would expect from such an ambitious un-corporate product. Excel is already there as a model. I would expect that you would take what works well in Excel and fix what doesn't, rather than leaving out superior Excel behavior for which millions of users have already transversed the learning curve.

User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36
Comment 1 Kevin 2017-05-15 06:46:36 UTC
Created attachment 133324 [details]
demonstrates both sets of steps
Comment 2 Thomas Lendo 2017-05-16 15:29:08 UTC
This behavior​ is the same in all LibO applications. Therefore I set component to LibreOffice, hardware to all and version to inherited from OOo because LibO 3.3.0 shows the same.

Tested with and 3.3.0.

LibO uses the formatting of the space before the inserted character. I couldn't reproduce it without spaces.
Comment 3 Thomas Lendo 2017-05-16 15:34:23 UTC
Add keyword needsUXEval, maybe it's an intended behavior. But I also stumbled over this issue in Writer in the past.
Comment 4 Regina Henschel 2017-05-16 20:05:23 UTC
I think it is a bug, because it leaves over an empty span element. If it was an intended behavior, the empty span element would have been removed.
Comment 5 Heiko Tietze 2017-05-17 11:24:17 UTC
Created attachment 133373 [details]

I don't get the issue, see my screencast.

In general, we keep the style from the previous part for good reasons. Lets say want you enter a statement in bold, then you switch bold on first and enter the text later. If you do the same afterwards with a selection it makes of course no sense to keep bold active. The same is true for other style elements such as font color. Is that really different from other tools?
Comment 6 Regina Henschel 2017-05-17 12:07:01 UTC
Your screencast does not contain the critical part. Mark the green G and enter a g.

Expected: You get a green g.
Currently: You get a red g.

Another hint (besides the empty <text:span> element), that this is really a bug: Do the same with RGB without spaces. Now you get a green g.

The same error is in Writer.

The behavior is different from MS Office and WordPad, SoftMaker and KingSoft Writer. Gnumeric gives a red g.
Comment 7 Heiko Tietze 2017-05-17 14:14:38 UTC
(In reply to Regina Henschel from comment #6)
> Your screencast does not contain the critical part. Mark the green G and
> enter a g.

Ah... on editing it takes the style from the character before. 

Make me *bold*.
Make me *b * (continuation the style is not questionable)
Make *me* bold. (entering text after the e keeps the bold style)
Make *me *bold. (entering text before the b keeps the bold style)
Make *me* bold. (entering text before the b has no bold style)

Doing the same with colors it works similarly:

RedR RGreenG GBlue
(Font color set to red/green/blue until the next word, ie. including the character. R=Entered text is red, G=Green.)

Same is true for LibO and Office2010
Comment 8 Kevin 2017-05-20 04:43:23 UTC
This has another manifestation - simply changing the font (or format) affects characters not even selected - see new attachment107857.ods.

1. insert blinking cursor between "I" and "N" in cell B3 (don't select any characters, just put the cursor in that position)
2. set the font to Symbol, planning to type the U+2665 necessary to get the heart

result: see D3 – simply change the font without typing anything automatically changes the font for the existing characters!

to reproduce without the ods file:

1. set the font to arial
2. type two characters
3. position the cursor between the characters
4. change font to symbol
5. the whole cell changes to symbol on its own (the user desires to type new characters in symbol font
Comment 9 Kevin 2017-05-20 04:43:59 UTC
Created attachment 133410 [details]
steps for alternate aspect of bug described in comment
Comment 10 Heiko Tietze 2017-05-20 07:23:20 UTC
If you have a whitespace between the characters you can change the font being entered. The same is true for selections.

But anyway, I believe there are good reasons to keep the formatting as it is. The continuation of formatting until a whitespace character is more convenient as the rare cases when properties are changed arbitrarily. Of course, I might be wrong.
Comment 11 Regina Henschel 2017-05-20 13:13:32 UTC
Heiko: I see it different. Perhaps the problem is clearer, if I describe it with markup, although that is not the internal representation:

The text has the form
<text:p text:style-name="Standard"><text:span text:style-name="myRed">R </text:span><text:span text:style-name="myGreen">G </text:span><text:span text:style-name="myBlue">B </text:span></text:p>

Now I select the G and press key g.

Expected: G has been replaced with g
<text:p text:style-name="Standard"><text:span text:style-name="myRed">R </text:span><text:span text:style-name="myGreen">g </text:span><text:span text:style-name="myBlue">B </text:span></text:p>

But I get
<text:p text:style-name="Standard"><text:span text:style-name="myRed">R g</text:span><text:span text:style-name="myGreen"> </text:span><text:span text:style-name="myBlue">B </text:span></text:p>

It seems, that LO does a "delete" followed by an "insert" instead of a true "replace". For an "insert" it is the correct behavior to continue the style of the previous character, but here a "replace" is intended and the undo names it "Replace". To get what you want, you have to insert the g after the G and then go back and delete the G.
Comment 12 Heiko Tietze 2017-05-20 19:09:48 UTC
(In reply to Regina Henschel from comment #11)
> Heiko: I see it different. Perhaps the problem is clearer, if I describe it
> with markup, although that is not the internal representation:
> ...

If we talk about overriding a character only, as you describe very clearly, with the intention to keep and harmonize the current workflow I have no concerns. But when it's about how insert/edit works, we should make sure to not harm any other use case.

So actually this is not a UX question but an ordinary bug. Removing the keyword.
Comment 13 Kevin 2017-05-21 08:24:21 UTC
(In reply to Heiko Tietze from comment #10)

> Of course, I might be wrong.

As someone who has been using this small portion (formatting) of the program 8 to 12 hours a day, seven days a week, abd using it only to create graphics (no math functions), I hope I can convince you that you are indeed quite wrong. There's no substitute for the understanding gained from spending hundreds of hours trying to make a super complex spreadsheet look right, and there's no substitute for the experience gained from being forced to keep proofreading the content of the spreadsheet and having to re-enter cells to correct the data or format. It's down here in the trenches that the faulty logic of the program makes itself so painfully apparent.

I'm making an elaborate representation of all of the songs of The Beatles - well over 200 - and each one has many complex sections. Each time I get to a new section or a new song I use similar functions of Calc. I'm only using less than 1% of the code you've written but I'm using that 1% in every possible way - if I can find a more convenient way to do any single operation it will save me hours in the long run because of the repetitive nature of what I'm doing. I've tried many different workflows.

I've tried this in Excel and Calc. Calc - on balance - has less problems and that's why I'm taking the time to try to convince you to fix it. Trust me - it needs fixing very badly. The way you've got it coded now is enough to make the user rip his or her hair out in large bunches. The user needs to be able to act on a selection without the program changing something that's not selected. I can't say it enough - it's not enough to code the program - you have to USE the program to see why your users are so frustrated.
Comment 14 Kevin 2017-05-21 08:39:07 UTC
(In reply to Regina Henschel from comment #11)

> It seems, that LO does a "delete" followed by an "insert" instead of a true
> "replace". 

YES! When you select something, what you type should "replace" the text and retain the format. That's how users understand computers:

1. select something to the computer what you want to apply a command to

2. apply the command - it changes the selection

But the way Calc is coded, when you apply the command, it goes to an unselected part of the document and changes that!!!! 
How can that possibly not be a bug? How can you trust and become intuitive about a program that keeps changing things you didn't ask it to change?

I admit that I do not know how to write a line of code, but I was a full-time professional software tester for 15 years and the bugginess this behavior is supported by every instinct I learned during that time, in addition to the thousands of hours I've spent as a user of this type of program.
Comment 15 Kevin 2017-05-21 09:25:09 UTC
Here's another way that this problem manifests itself, including a bizarre mystery I can't solve. In the attached .ODS file (10857-b.ods) there are steps and two cells that LOOK completely identical but the buggy behavior only occurs in one of them.
Comment 16 Kevin 2017-05-21 09:26:01 UTC
Created attachment 133428 [details]
This goes with the comment that references 10857-b.ods (steps in spreadsheet)
Comment 17 Kevin 2017-05-21 09:47:32 UTC
Created attachment 133429 [details]
steps for the comment referencing 10857-c.ods
Comment 18 Kevin 2017-05-21 09:54:28 UTC
The new attachment, 10857-c.odsm demonstrates (and includes steps and notes for) another buggy behavior that I believe shares the same root cause. I could give you 50 or 100 different sets of steps, each producing another result that appears to be a separate bug, but I'm pretty sure they all stem from the same code behavior that you guys are discussing - this thing about "not doing a true replace", but as you can see, it goes well beyond just "unexpected UI behavior" - it can cause behavior that is unequivocally buggy (i.e., the same steps produce different results in seemingly identical situations), as opposed to simply being different from Excel but consistently different.

I don't use Writer, but I tried the original steps and it did indeed occur in that program (but not in Word or Excel or any other non-Office program).
Comment 19 Heiko Tietze 2017-05-21 12:21:36 UTC
I believe everything is clear now and the bug can be fixed: instead of delete+insert the override function has to work as a true replace. More comments would add confusion only.

(In reply to Kevin from comment #13)
> I'm making an elaborate representation of all of the songs of The Beatles -
> well over 200 - and each one has many complex sections.

Hope you will share the result with the community so that everyone can get an impression of the power of Calc :-). 
The design team has a nice blog for that purpose, in case you don't know how to do it.
Comment 20 Kevin 2017-06-21 21:09:25 UTC
Created attachment 134204 [details]
absolute simplest case

Reading some of the comments on other reports I'm starting to see that Calc differentiates between formatting set from within the cell versus to the cell itself. This attachment demonstrates the bug completely within a fresh cell - absolutely no complications.
Comment 21 Telesto 2017-08-28 07:14:12 UTC
*** Bug 112056 has been marked as a duplicate of this bug. ***
Comment 22 QA Administrators 2019-10-04 03:05:34 UTC Comment hidden (obsolete)
Comment 23 Cor Nouws 2020-02-19 20:14:03 UTC
I agree that it is wrong behavior.

If you do the same text without spaces, so RGB, the selected G will be replaced with a green g.

(In reply to QA Administrators from comment #22)

Still unchanged in LODev7.0
Comment 24 Timur 2020-03-08 19:17:14 UTC
*** Bug 108333 has been marked as a duplicate of this bug. ***
Comment 25 Christopher Yeleighton 2021-11-12 09:08:58 UTC
To reproduce in Writer:
1. Open a new empty document.
2. [A] [ ] [Ctrl [B]] [B] [Home] [Shift [→] [→]] [C]

Result: Bold "cb".
Comment 26 QA Administrators 2023-11-13 03:12:16 UTC Comment hidden (obsolete)
Comment 27 Matt K 2023-11-25 02:58:39 UTC
I can still reproduce in Calc using:

Version: (X86_64) / LibreOffice Community
Build ID: e37dcb3ca36bb6c23b15757e6e556ad25832398c
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded