Created attachment 133409 [details]
spreadsheet to facilitate reproducing bug

After more research, this is a particularly severe bug. The attached spreadsheet is just the tip of the iceberg. This manifests itself in many ways, especially if the spreadsheet is imported from Excel, which, after all, is the whole point - make it easy for users to migrate from Excel.

Here's a broader way of explaining the problem:

At the very core of UI design philosophy is the idea that the user selects something, and then acts on it. If I type control-A and select every cell in a spreadsheet, and go to the toolbar and choose Courier, or Bold, or 12 pts - that attribute should be applied to every character in every cell. This is how every program works. To not behave this way is a bug so fundamental that there can be no argument - yes? Something is getting corrupted in the internal description of the cell contents such that various attributes can't be changed with the normal UI commands.

Created attachment 133657 [details]
Test spreadsheet with font colors

Kevin, thanks for reporting your problem.

I only can partially confirm your issues and only with your file. In my own tests none of your problems occur.

With your file it's not possible to change the font color if the already existing text is formatted with a font color word by word (first double clicking into the cell, then selecting a word and then applying a font color). But all other actions are possible (background color, underline, indent, etc.)with one or more cells.

Therefore I can't conform your bug report.

Kevin:
1. Could you test with a new user profile or with another installation of LibreOffice?
2. Please test my own file if you can change the font color for both cells at once.
3. How have you created your test file? Can you give a step by step instruction?

> 1. Could you test with a new user profile or with another installation of
> LibreOffice?

I tried both safe mode and deleting all the Libre folders in User\AppData\Roaming. In both cases the results were the same. The bug is active with my file and does not occur with your file.

> 2. Please test my own file if you can change the font color for both cells
> at once.

yes, it worked

> 3. How have you created your test file? Can you give a step by step
> instruction?

1. I started my project in Microsoft Excel 2010, got frustrated, and started using a release version of Calc  - 5.2.6 I think. I think I was still using that when I first reported this bug.

2. I continued to work full time adding my research to the spreadsheet and eventually switched to the 5.3.3.2 release.

I continue to get this type of problem (and all the other problems I've reported) on an ongoing basis.

3. My spreadsheet has no formulas - just formatted text cells - I'll upload the whole thing - it's called beatles form-5.3.3.2.xlsx. I am currently on Lovely Rita - anything past that will look weird. If you want to understand why the bugs I've reported are anything but "trivial", just try making a song after Lovely Rita conform to the formatting, or fix any of the notes, chords or rhythms. You will, as I am doing, pull out your hair in bunches. The bug where you select text, type and the formatting changes to some other earlier part of the cell is particularly crippling.

>I only can partially confirm your issues and only with your file.

Can't you look at the underlying code that tells the program what to display and see what's wrong?

Created attachment 133664 [details]
large spreadsheet

(In reply to Kevin from comment #5)
> Created attachment 133664 [details]
> large spreadsheet

Note: This problem of selecting ranges of cells and not being able to apply formatting commands happens often - it's not just the single instance that I pasted into the small spreadsheet I initially attached to this report.

Kevin, thanks for your replies.
I tested your files but I have to pass -- I'm no xlsx specialist and couldn't interpret the ods file. There's always the possibility for problems when converting files or when working with different programs. Some of them are weird.
Maybe another one can help finding a cause or categorize the problem.

Here are three steps, each with an attached JPG (step-1, step-2, step-3.jpg) that show unequivocal corruption. Before doing these steps I deleted the user profile and rebooted the computer. Each step is shown with a jpg.

1. click cell K2695
observe: there is nothing in the formula bar - the cell is empty
2. type "o"
observe: an "o" and nothing else appears in the formula bar
3. type space bar
expected: an "o" and a space should appear in the formula bar
actual: a whole string of text (from another cell that has not been accessed in any way since the PC was rebooted) appears. 

This problem occurs with some but not all of the cells in the document.

I am done trying to help improve this program if you don't take this seriously, realizing how many millions of your users will be opening Microsoft Excel documents. This is REALLY messed up.

Created attachment 133681 [details]
step 1 for most recent comment

Created attachment 133682 [details]
step 2 for most recent comment

Created attachment 133683 [details]
step 3 for most recent comment

All right - I think I figured this most recent problem out. When you had me delete my user profile I'd forgotten about the auto-input feature. Typing "o" made it think I'd wanted a string of text starting with "o". When I turned off auto-input it stopped adding the string of text. So now we're back to the core problem, which is that Calc fails repeatedly to obey the most basic premise of computing: 

1. show the computer your selection

2. ask the computer to perform an operation on that selection

Almost all of the reports I've submitted are variations on this core failing of the UI.

The most recent time Calc made me so angry that I went back to Excel, I also noticed that Excel is WAY WAY better at handling large files. I can zoom in and out with my large spreadsheet, select all, copy and paste and so on with Excel with no problems. Calc 5.3.3.2 gets very very sluggish with this large document.

That said, other problems of Excel drove me back once again. I have a slogan for you: "LibreOffice - the lesser of evils"

To clarify - there are two issues in this report - the original one is very real and very active and I don't understand how you can call it "unconfirmed" when all you have to do is open my attached spreadsheet to see it occur.

The second issue, added later, was a user error on my part regarding auto-input being turned back on when I deleted my user profiles. I would delete those comments if the system would allow me to.

Please take the initial problem serious - it is a very bad problem.

(In reply to Kevin from comment #13)
> To clarify - there are two issues in this report - the original one is very
> real and very active and I don't understand how you can call it
> "unconfirmed" when all you have to do is open my attached spreadsheet to see
> it occur.
> ...
> Please take the initial problem serious - it is a very bad problem.
We take your problem seriously. I'm also a LibreOffice user and know very, very well how frustrating it is to have a special problem.

I call this bug report "not reproducable" because a problem must be at least occur in a second LibO installation. QA and devs must be capable to reproduce the problem to be able to find the cause of the problem and to repair it.

This bug report has the status "unconfirmed" until someone else can reproduce the problem. QA members will find your bug as long as it has the status "unconfirmed". When confirmed and marked as "new", then the next step is to wait until a developer is ready to work on the problem.

I found Bug 39969 - "text FORMATTING does not work correctly when used on cells instead of selected text" which seems the same cause (also an Excel file originally) or a similar one at least.

Seems to be a problem of handling direct text formatting in LibO especially when imported from Excel.

(In reply to Thomas Lendo from comment #3)
> I only can partially confirm your issues and only with your file. In my own
> tests none of your problems occur.

I can confirm it in Calc with a brand new file.

1. Open Calc
2. Select B2 and press F2
3. Click Font Color main button to turn text red and type 'Red '
4. Click Font Color group button and select green and type 'Green '
5. Click Font Color group button and select blue and type 'Blue'
6. Select B2 and copy it to C2
7. Select both B2 and C2
8. Change font color to Black
9. B2 turns black but C2 doesnt
-- some extra fun --
10. Undo
11. Save file, close and reopen
12. Select both B2 and C2
13. Change font color to Black
14. Both turn to black

This is a regression first introduce in 4.4 as it is fine in 3.3 and 4.3. In 5.0.6.3, step 9 will not turn either of them black. In 5.1.6.2 and 5.2.0.4, it works correctly and both are black. In 5.3.2.2, it has broke again.

Version: 5.5.0.0.alpha0+
Build ID: b08217989558addbcaded122a4e7211ae24bbcff
CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-05-31_06:36:03
Locale: en-US (en_US.UTF-8); Calc: group

Beautiful steps - thank you.

> I can confirm it in Calc with a brand new file.
> 
> 1. Open Calc
> 2. Select B2 and press F2
> 3. Click Font Color main button to turn text red and type 'Red '
> 4. Click Font Color group button and select green and type 'Green '
> 5. Click Font Color group button and select blue and type 'Blue'
> 6. Select B2 and copy it to C2
> 7. Select both B2 and C2
> 8. Change font color to Black
> 9. B2 turns black but C2 doesnt

This may be the root cause for some of my other reports. Here's another variation on your steps

1. new file
2. enter cell B2
3. type Regular
4. set style to Bold
5. type Bold
6. copy B2 to C2
7. select both cells
8. Control+B - both cells turn Bold
9. Control+B again - now the Bold part of D2 remains bold

This happens to me all the time - command stop working - something issuing the Bold (or other) formatting command several times will clear it - sometimes it gets stuck and can only be fixed by clearing the cell and starting over.

I use Bold, Regular, Superscript and Underline in almost every cell (also multiple fonts and sizes) - and I hit this and other problems constantly.

(In reply to Kevin from comment #18)
> This may be the root cause for some of my other reports. Here's another
> variation on your steps

Lets keep this bug about font color, which is a regression, as bug 39969 is to cover all other formatting issues.

steps from comment 16

 ~/bibisect-win32-5.3

This seems to have begun at the below commit.
Adding Cc: to Markus Mohrhard; Could you possibly take a look at this one? Thanks
 403a7b2f27447d6fe94e4f3a01dd459a59a03dbc is the first bad commit
commit 403a7b2f27447d6fe94e4f3a01dd459a59a03dbc
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Sun Sep 25 16:35:09 2016 -0700

    source 8a11d34c7e08218b5ff9da4870c460297f312332
	
	author	Markus Mohrhard <markus.mohrhard@googlemail.com>	2016-09-24 23:01:16 (GMT)
committer	Markus Mohrhard <markus.mohrhard@googlemail.com>	2016-09-25 23:05:48 (GMT)
commit 8a11d34c7e08218b5ff9da4870c460297f312332 (patch)
tree 1aa048423a4773426fee571f050b02be55c58019
parent cda8ce18310c2c32166e03acd5e2a852b960a892 (diff)
tdf#91312, don't forget to delete the old cond format indices

Created attachment 140636 [details]
Input Word document to copy to Calc

Copy the red text lines to cells in a new Calc spreadsheet, select all cells and then try to change the color of all selected cells

There is a debilitating issue when copying/pasting text from another format than OO.

Please use the attachment above tot reproduce:
- copy the text in red to three cells in a new Calc sheet (format of the sheet does not matter, ods, xls, xslx will act the same)
- select all the cells
- change color to black
- The lowest cell of the selection will not change color.

Hi - Yes, this bug is still easily reproducible with the spreadsheet and steps in the first comment, like almost every one I reported on the topic of formatting in Calc. The reason I stopped regularly beta-testing was frustration. Calc fixed many of the most annoying things in Excel; that was all that was needed, but for some reason Calc introduced a whole system of graphics bugs that were never in Excel. The poster child for this complaint is Calc's approach of taking the border between two cells and treating it as if it were two borders, invisible to the user, with one controlled by editing one cell and one by editing the other. There is no way to know which formatting aspect is part of which cell. None of this is in Excel. At one point I was spending so much time working on a project in Calc and reporting these bugs and just getting the most arrogant uncaring non-responses. If you love software, this is just heartbreaking. It was such a great idea to have an open source version of Excel without the myriad hated bugs that everyone suffered through and then to unnecessarily add a whole complex of new bugs! WHY?

reverting the commit fixes the issue while it doesn't reintroduce tdf#91312: https://gerrit.libreoffice.org/c/core/+/152273

Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f447cb9bc8ab43a5f737d27dfa61bf0e71667bbb

tdf#107965: partially revert fix for tdf#91312

It will be available in 7.6.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

(In reply to Xisco Faulí from comment #26)
> reverting the commit fixes the issue while it doesn't reintroduce tdf#91312:
> https://gerrit.libreoffice.org/c/core/+/152273

Message from gerrit: Pushing it for now. The plan is to push it to master only without backporting it to older branches so there is time to react in case it causes problems...