Bug 94499 - FORMATTING: "Expand formatting" affects non-empty adjacent cell
Summary: FORMATTING: "Expand formatting" affects non-empty adjacent cell
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Calc-Cells
  Show dependency tree / graph
 
Reported: 2015-09-25 04:00 UTC by Tom
Modified: 2023-04-24 04:20 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Attachments
Calc (ods) document with a formatting example (10.14 KB, application/vnd.oasis.opendocument.spreadsheet)
2015-09-25 04:00 UTC, Tom 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tom 2015-09-25 04:00:40 UTC 
Created attachment 119005 [details]
Calc (ods) document with a formatting example

Version: 5.0.1.2
Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261
Linux x86-64

The help information of the option "Expand formatting" states: "Specifies whether to automatically apply the formatting attributes of the selected cell to the empty (!) adjacent cells". Unfortunately however, also non-empty (!) adjacent cells are affected by this feature, which is not what a user would expect (or want). For details please see the example attached.

While disabling the "Expand formatting" option as suggested in Bug 71941 avoids this effect, this behavior contradicts the specification in the help file. Therefore, I consider it a bug. Either calc should be fixed (preferred) or the help file should be corrected.

Regards
Tom
Comment 1 Cor Nouws 2015-09-25 06:38:26 UTC 
Hi Tom,

Thanks for filing and the test file.
I cannot reproduce the problem on Linux 32 bits with 5.0.2.2.

Cor
Comment 2 Tom 2015-09-25 12:38:32 UTC 
Hi Cor,

thanks for your quick feedback. I got me LO 5.0.2.2 and installed it to see if the issue is fixed in LO 5.0.2.2:

   Version: 5.0.2.2
   Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe
   Locale: de-DE (en_US.utf8)
   Linux x86-64

Maybe the contents of my example is not as self-explanatory as I thought? Here is a step-by step example:

- Opened Calc
- Enabled the option "Expand formatting"
- Cell "A1": Formatting = "Number Standard", Value = "Test" -> display = "Test" -> OK
- Cell "B1": Formatting = "Currency -1.234,00 €", Value = "123,45" -> display = "123,45 €" -> OK
- Cell "A1": Changed formatting = "Text" -> display = "Test" -> OK
- Cell "B1": Changed value = "234,56" -> display = "234,56", Format = "Text" -> WRONG

So after the format of cell "A1" was changed and the value of the non-empty cell "B1" was changed, the format of cell "A1" was automatically applied to cell "B1" (which contradicts the help information).

Regards
Tom
Comment 3 Cor Nouws 2015-09-25 20:52:27 UTC 
Hi Tom,

Thanks for your additional info.
It is the way I had understood it (after some reading ;) )
But the strange think is, that I could not really reproduce it. 
Maybe because I had done some various/random editing too?

Now, trying with only copy/paste C3:D3 to C9, and doing the steps, the problem clearly shows.
So set to new. Thanks!

Cor
Comment 4 QA Administrators 2016-11-08 10:26:00 UTC Comment hidden (obsolete)
Comment 5 Tom 2016-11-13 21:19:18 UTC 
Update:

I am sorry to say, but the reported issue still exists in:

   Version: 5.1.5.2
   Build ID: 7a864d8825610a8c07cfc3bc01dd4fce6a9447e5
   CPU Threads: 4; OS Version: Linux 3.7; UI Render: default; 
   Locale: de-DE (en_US.utf8); Calc: group

   Version: 5.2.3.3
   Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf
   CPU Threads: 4; OS Version: Linux 3.7; UI Render: default; 
   Locale: de-DE (en_US.utf8); Calc: group

Note, while in 5.1.5.2 the mis-formatted field B1 remains to be right justified, in 5.2.3.3 it is left justified, once the new value 234,56 is entered. Anyway, in both versions the field B1 adopts the text format of field A1 rather than to keep its original currency format.

Regards
Tom
Comment 6 QA Administrators 2017-11-14 08:57:40 UTC Comment hidden (obsolete)
Comment 7 Cor Nouws 2017-12-28 12:29:57 UTC 
Opening attachment 11905
Giving C9 format text, entering foo
Entering number 3456 in D9; cell retains format Number

Giving D11 format Currency
Giving D9 format text, entering foo
Entering number 3456 in D11; cell retains format Currency

So WorksForMe


tested in Version: 6.1.0.0.alpha0+
Build ID: a9b202a6b7000e7af34f2a639ca207122a3968bf
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-12-26_23:09:36
Locale: nl-NL (nl_NL.UTF-8); Calc: group threaded
Comment 8 Tom 2018-02-12 21:21:36 UTC 
Hi Cor,

sorry for being dormant for quite a while. I was busy upgrading my computers to a more recent Linux. I have now installed LO 6.0.1.1

   Version: 6.0.1.1
   Build ID: 60bfb1526849283ce2491346ed2aa51c465abfe6
   CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; 
   Locale: de-DE (en_US.UTF-8); Calc: group

and repeated exactly the steps described in my message dated "2015-09-25 12:38:32 UTC".

- Opened Calc
- Enabled the option "Expand formatting"
- Cell "A1": Formatting = "Number Standard", Value = "Test" -> display = "Test" -> OK
- Cell "B1": Formatting = "Currency -1.234,00 €", Value = "123,45" -> display = "123,45 €" -> OK
- Cell "A1": Changed formatting = "Text" -> display = "Test" -> OK
- Cell "B1": Changed value = "234,56" -> display = "234,56", Format = "Text" -> WRONG

I am sorry to say, but I can still reproduce the issue reported in 2015. I have ran my test twice. Could you please give it a try yourself and follow exactly the steps listed above?

Regards
Tom
Comment 9 Cor Nouws 2018-02-13 15:49:07 UTC 
strange (stupid from my side?) that I do not reproduce it consistent?

anyway
1 new Calc file
2 add Test in A1
3 change formatting of B1 to currency € 1.234,56--
4 add 123,45 in B1
5 change formatting of A1 from Number/General in Text/@
6 Focus on B1 and type 345,67
  > formatting of B1 changes to Text/@

is OK In 4.0.6.2 > regression
Comment 10 Buovjaga 2018-06-01 18:11:29 UTC 
Already in Version: 4.3.0.0.beta1 (tested on Win 10.
Comment 11 Xavier Van Wijmeersch 2018-06-01 19:09:59 UTC 
following the steps in comment2 can reproduce

Version: 6.0.0.2
Build ID: 06b618bb6f431d27fd2def25aa19c833e29b61cd
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
Locale: en-US (en_US.UTF-8); Calc: group

Version: 6.2.0.0.alpha0+
Build ID: 8f9f66e8d2bae94c1f469ffc51bdbffeba853a2b
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-05-29_00:00:31
Locale: nl-BE (en_US.UTF-8); Calc: group threaded
Comment 12 Buovjaga 2018-07-08 19:51:56 UTC 
Problem is already in 3.3.0. Before testing with it, I went through various Linux bibisect repos (oldest/latest commits) and the problem always appeared.
Comment 13 QA Administrators 2019-07-09 02:44:12 UTC Comment hidden (obsolete)
Comment 14 Tom 2019-07-11 20:09:37 UTC 
The reported bug was checked following the 6 steps reported on 2015-09-25 and was found to still exist in:

Version: 6.1.6.3
Build ID: 5896ab1714085361c45cf540f76f60673dd96a72
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk2; 
Locale: de-DE (en_US.UTF-8); Calc: group threaded

Version: 6.2.5.2
Build ID: 1ec314fa52f458adc18c4f025c545a4e8b22c159
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: de-DE (en_US.UTF-8); UI-Language: en-US
Calc: threaded

Regards
Tom
Comment 15 QA Administrators 2021-07-11 03:40:15 UTC Comment hidden (obsolete)
Comment 16 Tom 2021-07-11 08:41:08 UTC 
The reported bug was checked following the 6 steps reported on 2015-09-25 and was found to still exist in:

Version: 7.1.4.2 / LibreOffice Community
Build ID: a529a4fab45b75fefc5b6226684193eb000654f6
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: de-DE (en_US.UTF-8); UI: en-US
Calc: threaded

Regards
Tom

BTW: I wonder, why do I get review requests, when after 7 years it is obvious, that no developer is interested to fix this bug? As far as I am concerned, I have permanently disabled the option "Expand formatting" to workaround this persistent bug.
Comment 17 Buovjaga 2021-07-12 05:51:35 UTC 
(In reply to Tom from comment #16)
> BTW: I wonder, why do I get review requests, when after 7 years it is
> obvious, that no developer is interested to fix this bug? As far as I am
> concerned, I have permanently disabled the option "Expand formatting" to
> workaround this persistent bug.

Because sometimes reports are duplicates without anyone noticing and the bugs can get fixed while the duplicate reports stay open. In organised re-testing runs, this was found to be true with about 25% of the reports each year.
Comment 18 Andreas Heinisch 2023-03-03 13:28:12 UTC 
Checked the implementation details for this report. If you insert a value in a cell, LibreOffice checks for adjacent cells AFTER the entire process of cell value input was done. So atm it is impossible that the cell is empty.

Imo, not so easy to solve because the auto format depends on the newly inserted value of the cell.

We should correct the help file or is there an application where the auto format works without inputting a value? Opinions?