Download it now!
Bug 126008 - TABLES STYLES: If you insert a row or column (with cursor in a cell), the formatting of the whole table changes (steps in comment 5)
Summary: TABLES STYLES: If you insert a row or column (with cursor in a cell), the for...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.1.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 120068 134462 136424 136532 (view as bug list)
Depends on:
Blocks: Writer-Tables-Style Cell-Add-Delete
  Show dependency treegraph
 
Reported: 2019-06-19 16:47 UTC by Michael Robinson
Modified: 2020-11-16 16:05 UTC (History)
17 users (show)

See Also:
Crash report or crash signature:


Attachments
screen capture of table after insertion (108.38 KB, image/png)
2019-06-19 16:48 UTC, Michael Robinson
Details
Writer document showing the bug (40.41 KB, application/vnd.oasis.opendocument.text)
2019-06-20 17:05 UTC, Michael Robinson
Details
Writer doc which shows change in table header and cells when adding new row (10.13 KB, application/vnd.oasis.opendocument.text)
2019-07-18 21:14 UTC, Gerhard Weydt
Details
table styles reset when adding a new row in the writer (16.12 KB, application/vnd.oasis.opendocument.text)
2020-07-25 16:21 UTC, Sahraiee
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Robinson 2019-06-19 16:47:00 UTC
Description:
When I insert a row above an existing row within a table, LibreWriter reverts the selected existing row to the default format. This is repeatable in multiple documents and different tables. I am using LibreOffice 6.2.4.2 (x64).

Steps to Reproduce:
1.Select row (highlights the row)
2.Click Table | Insert | Rows Above
3.

Actual Results:
A new blank row is inserted above the selected row. 
Before insertion, the selected row is formatted with Liberation Serif 10 and all columns but the first are centered.
After insertion, the selected row is formatted with Liberation Serif 12 and all columns are left justified(this is the default format)

Expected Results:
I expect there to be no change in the formatting of the selected row.


Reproducible: Always


User Profile Reset: No



Additional Info:
This occurs in separate installations on my desktop and laptop computers, both of which are kept completely up-to-date in software. Thus I don't believe it is necessary to confirm that my user profile is not corrupted. I don't have OpenGL enabled.
Comment 1 Michael Robinson 2019-06-19 16:48:55 UTC
Created attachment 152291 [details]
screen capture of table after insertion
Comment 2 Dieter 2019-06-20 06:35:04 UTC
I can't confirm this with

Version: 6.2.4.2 (x64)
Build-ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: threaded

and also not with

Version: 6.4.0.0.alpha0+ (x64)
Build ID: b170256fb6ebaf774b02b89835b19d9f3a1afb89
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-07_03:30:35
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded

Please attach a sample document, as this makes it easier for us to verify the bug. 
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
(Please note that the attachment will be public, remove any sensitive information before attaching it)
Comment 3 Michael Robinson 2019-06-20 17:05:21 UTC
Created attachment 152316 [details]
Writer document showing the bug

Look at line 4. I have just inserted a line above it. Before insertion, line 4 used Liberation Serif 10. Now it is Liberation Serif 12. Also, columns 2-5 used to be center-justified just like the rest of the table. Now they are right-justified.

None of those changes should have happened.

This has been happening for a long time, i.e. not just on Version 6.2.4.2. I am flummoxed about you not being able to reproduce it. There is nothing special about my LibreOffice installation. As I said before, it happens on two separate computers, both running the same version of Windows 10 (latest update).

If even after seeing this example you are unable to confirm the bug, then please terminate this bug report. I will just live with the problem.
Comment 4 QA Administrators 2019-06-21 02:54:23 UTC Comment hidden (obsolete)
Comment 5 Dieter 2019-06-21 06:38:38 UTC
I can confirm it with

Version: 6.4.0.0.alpha0+ (x64)
Build ID: b170256fb6ebaf774b02b89835b19d9f3a1afb89
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-07_03:30:35
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded

I found the reason: Table has table style "Default Style". If you add a row, the table changes back to setings of default style.

I created a new table without a style in comment 2 and so I couldn't reproduce it.


Steps to reproduce:

1. Create an empty table
2. Choose table style "Default Style"
3. Mark all and change alignment to center and font size to 10
4. Put cursor in one cell and add a row or a column

Actual result:
All cells change alignment and font size (Undo doesn't change this)

Expected result:
Only the new row or column has style of "Default Style".

You recieve the expected result, if you mark the whole row or column.
Comment 6 Dieter 2019-06-21 06:39:49 UTC
@Jim, @Miklos, I thought you could be interested in this issue...
Comment 7 Xisco Faulí 2019-06-28 14:08:10 UTC
(In reply to Dieter Praas from comment #5)
> I can confirm it with
> 
> Version: 6.4.0.0.alpha0+ (x64)
> Build ID: b170256fb6ebaf774b02b89835b19d9f3a1afb89
> CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
> TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-07_03:30:35
> Locale: de-DE (de_DE); UI-Language: en-US
> Calc: threaded
> 
> I found the reason: Table has table style "Default Style". If you add a row,
> the table changes back to setings of default style.
> 
> I created a new table without a style in comment 2 and so I couldn't
> reproduce it.
> 
> 
> Steps to reproduce:
> 
> 1. Create an empty table
> 2. Choose table style "Default Style"
> 3. Mark all and change alignment to center and font size to 10
> 4. Put cursor in one cell and add a row or a column

I can't reproduce it in

Version: 6.4.0.0.alpha0+
Build ID: a294457eb95e60028539b6783abac78b56561fe2
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

is this the same as bug 105799  ?
Could you please try with a recent master build ?
Comment 8 Dieter 2019-06-28 14:56:50 UTC
(In reply to Xisco Faulí from comment #7)
> is this the same as bug 105799  ?

Bug 105799 isn't about inserting new row

> Could you please try with a recent master build ?

Also present in actual master

Version: 6.4.0.0.alpha0+ (x64)
Build ID: ae823e4633a76d13cebc6432b9e44b9b2862326b
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-26_23:06:07
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded
Comment 9 mini-matze 2019-07-01 09:35:58 UTC
I can't reproduce the problem with your document too, but I have the same problem with another document. After insertion all formattings are replaced by "Liberation Serif 12" - just like yours.

I think this bugreport could be a duplicate to https://bugs.documentfoundation.org/show_bug.cgi?id=120068

I created a comment there and had add an attachment. I hope this file could show the problem to others... I don't want to spam by posting all twice now. So I hope you could switch to the other bugreport to...
Comment 10 Gerhard Weydt 2019-07-18 21:14:54 UTC
Created attachment 152866 [details]
Writer doc which shows change in table header and cells when adding new row
Comment 11 Gerhard Weydt 2019-07-18 21:35:20 UTC
Comment on attachment 152866 [details]
Writer doc which shows change in table header and cells when adding new row

I created Attachment 152866 [details] to show a similar malfunction:
I created a new document and a table with style "standard" (or may be "default", I didn't check in English). I then created a new table style "demo", which simply copies "standard", because it seems that the error occurs only with table styles other than "standard" or "none".
I then created paragraph styles "demoHeading" and "demoCell" for the first and second row, respectively, and applied them to these. That is the state you see in the document.
Now place the cursor in the bottom right cell, and key Tab: the formattings caused by these two paragraph styles will vanish.
Comment 12 Harald Koester 2019-07-19 10:44:05 UTC
*** Bug 120068 has been marked as a duplicate of this bug. ***
Comment 13 Seán Ó Séaghdha 2019-10-16 05:25:50 UTC
Still the same bug from 5.3?

Just created a new table in a new document in 6.3.2.2 and the bug still lives.
Comment 14 Aron Budea 2020-06-16 05:15:16 UTC
This is a regression that started from the following commit, bibisected using repo bibisect-linux-64-6.1, and Dieter's steps from comment 5.
Turns out this commit was never reverted in the end? Jim, can you please comment?

https://cgit.freedesktop.org/libreoffice/core/commit/?id=d1b13f486eacc60c9b71ec9f1b29cde2f4504d4e
author		Jim Raykowski <raykowj@gmail.com>	2018-02-06 22:50:02 -0900
committer	Thorsten Behrens <Thorsten.Behrens@CIB.de>	2018-02-13 15:00:06 +0100

tdf#108227 Set table style so it is highlighted in Sidebar styles list
Comment 15 Jim Raykowski 2020-06-17 20:21:06 UTC
(In reply to Aron Budea from comment #14)
> This is a regression that started from the following commit, bibisected
> using repo bibisect-linux-64-6.1, and Dieter's steps from comment 5.
> Turns out this commit was never reverted in the end? Jim, can you please
> comment?
> 
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=d1b13f486eacc60c9b71ec9f1b29cde2f4504d4e
> author		Jim Raykowski <raykowj@gmail.com>	2018-02-06 22:50:02 -0900
> committer	Thorsten Behrens <Thorsten.Behrens@CIB.de>	2018-02-13 15:00:06
> +0100
> 
> tdf#108227 Set table style so it is highlighted in Sidebar styles list

commit d1b13f486eacc60c9b71ec9f1b29cde2f4504d4e was superseded by
commit 1dc25980171ff79345484631882d6ea0eb6f9388 and
commit 1d5b89eccdccb3090b5503a60f829c54c077f328

IIRC, a table having a chosen table style will replace any direct formatting with the table style formatting when rows or columns are inserted or deleted or upon reloading of the document. 'Default Table Style' is a table style that apparently has Liberation Serif 12 font and left justification. I believe this has always been the behavior.
Comment 16 Aron Budea 2020-06-18 04:05:56 UTC
(In reply to Jim Raykowski from comment #15)
> IIRC, a table having a chosen table style will replace any direct formatting
> with the table style formatting when rows or columns are inserted or deleted
> or upon reloading of the document. 'Default Table Style' is a table style
> that apparently has Liberation Serif 12 font and left justification. I
> believe this has always been the behavior.
Thanks! Do you know what the reason for that could be? It's really not clear to me why everything should be reset to the table style, it makes any direct formatting in a table useless. I think the reasonable expectation would be that nothing changes when deleting a row/column, and when adding a row/column, the previous row/column's table style and direct formatting are applied together to the new one. Are there arguments against that?

Also, the steps in comment 5 certainly have a different outcome before the mentioned commit and now.
Comment 17 Jim Raykowski 2020-06-19 01:51:28 UTC
(In reply to Aron Budea from comment #16)
> Thanks! Do you know what the reason for that could be? It's really not clear
> to me why everything should be reset to the table style, it makes any direct
> formatting in a table useless. I think the reasonable expectation would be
> that nothing changes when deleting a row/column, and when adding a
> row/column, the previous row/column's table style and direct formatting are
> applied together to the new one. Are there arguments against that?

AFAIK this is how table styles was designed. I suggested that table styles could be used as a template by programmatically changing to no table style after table style was used for initial creation of a table or application to existing table. This allows inserts and deletes to be done without loosing direct formatting. https://bugs.documentfoundation.org/show_bug.cgi?id=107555#c15
Default used to be what is now None.
Comment 18 Maxim Monastirsky 2020-06-19 10:51:42 UTC
(In reply to Aron Budea from comment #16)
> Do you know what the reason for that could be? It's really not clear
> to me why everything should be reset to the table style, it makes any direct
> formatting in a table useless.
As Jim said, that's how table styles were implemented right from the beginning. Here are the relevant commits:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=ac6f8bc92b1abe995694602f43d8ad108b7030fb

https://cgit.freedesktop.org/libreoffice/core/commit/?id=73f4a06c0bce51c7c8b9ae9adfdc7ffac27d06b4

I don't think that the current behavior was on purpose; it just that the implementation was not completed, and no one made any fixes to it since initial introduction. 

> I think the reasonable expectation would be
> that nothing changes when deleting a row/column,
It's not that simple, e.g. table styles support banded columns and a different last column, so when deleting columns the formatting of the nearby columns might need to be adjusted. Of course this should not touch direct formatting that was explicitly applied by the user.

> Also, the steps in comment 5 certainly have a different outcome before the
> mentioned commit and now.
That commit only made the table insert dialog apply the table style, instead of just direct formatting based on it. You could reproduce the bug before it, by manually applying a table style from the sidebar.

(In reply to Jim Raykowski from comment #17)
> I suggested that table styles
> could be used as a template by programmatically changing to no table style
> after table style was used for initial creation of a table or application to
> existing table.
Table templates ("AutoFormat") is exactly how it used to work before the table styles work. I'm not sure that reverting the table styles work is good idea in the long run. It will be better to find and fix the bugs in it.
Comment 19 Maxim Monastirsky 2020-06-24 07:57:28 UTC
Just like to point out that there was a partial solution applied with commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=09fc6fef2d03ca8558dd6f0eec45d61ceb282cb5. One problem is that it was applied only to cell properties (e.g. cell background, vertical alignment), but not to text properties. By itself this isn't something hard to fix, but actually there's much bigger problem: There is no way to store this "direct formatting applied" flag in ODF, so this works only in the same editing session, but not the next time the file is opened. The problem is that as of now table styles are really applied as a direct formatting, so a fix would need to compare the actual cell formatting and the formatting of the table style, to try to figure out which part of the direct formatting came from the table style and therefore allowed to be changed, and which was applied by the user and should be retained.

A much better (but likely harder to implement) approach might be to make table styles work as real styles, and not as a direct formatting. In terms of the file format, we already have the formatting of table styles exported and imported as cell styles under <office:styles>, so we can make it possible to reference those styles by table cells, or to be listed as parents of cell styles from <office:automatic-styles>. One problem however is that according to the ODF spec, paragraph styles take precedence over the text properties inside a cell style. Which means that we'll need also a "no style applied" state for paragraph styles, which complicates this even more.
Comment 20 Maxim Monastirsky 2020-07-17 08:18:06 UTC
*** Bug 134462 has been marked as a duplicate of this bug. ***
Comment 21 Sahraiee 2020-07-25 16:21:25 UTC
Created attachment 163531 [details]
table styles reset when adding a new row in the writer

I have the same issue in the v: 6.4.5.2.
that the table styles reset when adding a new row in the writer.
also when the format was reset, the undo command not working.
Comment 22 Aron Budea 2020-07-25 16:53:56 UTC Comment hidden (obsolete)
Comment 23 Maxim Monastirsky 2020-09-03 15:20:19 UTC
*** Bug 136424 has been marked as a duplicate of this bug. ***
Comment 24 briandb1222 2020-09-08 15:56:21 UTC
*** Bug 136532 has been marked as a duplicate of this bug. ***
Comment 25 briandb1222 2020-09-08 20:18:46 UTC
I can confirm with 

Version: 7.0.1.2
Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452
CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 26 digg33 2020-11-16 16:05:08 UTC
I can confirm the same for any operation involving adding rows and/or columns left/right/above/below using any of the commands under [Table > Insert] . Tested in blank new Writer doc with Default template. Can also confirm the steps given in Comment 5.

Version: 6.4.5.2
Build ID: 6.4.5.2-5.fc32
CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Calc: threaded

Please let me know if I can do any further testing to help.