Bug 115573 - EDITING: Table loses formatting when inserting a new row in a table
Summary: EDITING: Table loses formatting when inserting a new row in a table
Status: CLOSED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.3.7.2 release
Hardware: All All
: highest major
Assignee: Not Assigned
URL:
Whiteboard: target:6.1.0 target:6.0.4 target:6.0.3
Keywords: bibisected, bisected, regression
: 115468 115482 115572 115606 115613 115677 115743 115761 115864 115929 115936 116114 116135 116178 116191 116207 116311 116366 116379 116380 116469 116493 116554 116564 116610 116652 116674 116719 116740 116764 116819 117387 117775 117802 117909 (view as bug list)
Depends on:
Blocks: Writer-Tables-Style Cell-Add-Delete
  Show dependency treegraph
 
Reported: 2018-02-09 09:11 UTC by Telesto
Modified: 2020-06-16 05:17 UTC (History)
59 users (show)

See Also:
Crash report or crash signature:


Attachments
Bibisect log (2.60 KB, text/plain)
2018-02-09 09:37 UTC, Telesto
Details
working file (11.30 KB, application/vnd.oasis.opendocument.text)
2018-02-15 08:31 UTC, Ljiljan
Details
1 paragraph of writing, Colour formated table, resets on edits (15.56 KB, application/vnd.oasis.opendocument.text)
2018-03-04 15:36 UTC, Pete
Details
not solved. Video (218.64 KB, video/mp4)
2018-09-27 04:31 UTC, BogdanB
Details
Demonstation that bug 115573 still exists in 6.1.3.2 (582.52 KB, video/mp4)
2019-01-09 15:42 UTC, J. Mahun
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2018-02-09 09:11:00 UTC
Description:
Source: https://ask.libreoffice.org/en/question/145799/lo-6003-writer-tables/
Problem with formatting when inserting a new row in a table.



Steps to Reproduce:
1. Insert a table
2. Remove all borders from the table
3. Add a row pressing tab (border is back)

Second one: 
4. Select the table
5. Change the font setting for the table
6. Add a row using table
6. Press CTRL+Z. Table font setting back to default

Actual Results:  
Borders aren't permanent

Expected Results:
Adding a table row shouldn't affect formatting


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.1.0.0.alpha0+
Build ID: 8a0b61172a14b8b766a2e85f27762db3558d3af7
CPU threads: 4; OS: Windows 6.3; UI render: GL; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-02-06_03:28:54
Locale: nl-NL (nl_NL); Calc: CL


User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Comment 1 Telesto 2018-02-09 09:12:39 UTC
@Jim Raykowski
Adding you for the record, another "default table style" (https://gerrit.libreoffice.org/#/c/46842/)
Comment 2 Telesto 2018-02-09 09:37:22 UTC
Created attachment 139719 [details]
Bibisect log

Bisected to:

author	Jan Holesovsky <kendy@collabora.com>	2015-09-26 16:19:24 +0200
committer	Jan Holesovsky <kendy@collabora.com>	2015-09-27 22:48:21 +0200
commit ac6f8bc92b1abe995694602f43d8ad108b7030fb (patch)
tree ae8ed9337704cd83ab10e4c9cce4b7e06aaa7e8e
parent 5c26f79467e4c5f920b77a058aa079654c322c25 (diff)
sw table styles: Implement table styles in Writer.
This extends the table auto formats so that SwDoc keeps track of the auto
formats used in the document.  With this in mind, we can update the format of
the table with every operation like adding/removing a line, splitting a table,
etc.

So far we only have the core functionality, and cover inserting a line in
the table; more to come.

Based on work of Alex Ivan <alexnivan@yahoo.com> during GSoC 2013 - thank you!
Comment 3 Telesto 2018-02-09 22:11:07 UTC
*** Bug 115482 has been marked as a duplicate of this bug. ***
Comment 4 Telesto 2018-02-09 22:14:56 UTC
*** Bug 115572 has been marked as a duplicate of this bug. ***
Comment 5 Telesto 2018-02-09 22:20:00 UTC
Adding CC to Jan Holesovsky
Comment 6 Jacques Guilleron 2018-02-10 08:03:29 UTC
*** Bug 115606 has been marked as a duplicate of this bug. ***
Comment 7 Jacques Guilleron 2018-02-10 14:25:36 UTC
*** Bug 115613 has been marked as a duplicate of this bug. ***
Comment 8 StamatisZ 2018-02-11 12:25:11 UTC
*** Bug 115468 has been marked as a duplicate of this bug. ***
Comment 9 Jim Raykowski 2018-02-11 20:03:53 UTC
GetDocShell()->GetFEShell()->UpdateTableStyleFormatting();

removing this from https://opengrok.libreoffice.org/xref/core/sw/source/core/doc/tblrwcl.cxx#638 seems to fix the inserting a row issue

and... 

removing it from https://opengrok.libreoffice.org/xref/core/sw/source/core/docnode/ndtbl.cxx#2135 seems to fix the deleting a row issue
Comment 10 Telesto 2018-02-14 08:08:43 UTC
*** Bug 115677 has been marked as a duplicate of this bug. ***
Comment 11 Yousuf Philips (jay) (retired) 2018-02-14 09:14:37 UTC
Has been around since 5.3 if a document is opened with a table style applied a table. Ljiljan will submit a sample document for it. It is only more prevelant now as we are applying the default table style to all inserted tables.
Comment 12 Andy 2018-02-14 10:13:58 UTC
When posting Bug 115677 I did not realize there was a link with styles.

However, I have now tried to take the table back to default text style before editing, but the formatting loss is still there.

Also, I tried to  change the "table style" before editing, bot no. Nothing changes and the problem is still there.

So I can see no workaround to this afforded by fiddling with style, eithre text or table ones.

If anyone has suggestions for a workaround please forward  it ASAP. My daily workload has increased significantly (5 to 10%) due to this, having to often work with tables.
Comment 13 Ljiljan 2018-02-15 08:31:31 UTC
Created attachment 139918 [details]
working file

Go to the last column, last row, and press Tab. Table formatting will be changed.
Comment 14 Telesto 2018-02-15 21:19:01 UTC
*** Bug 115743 has been marked as a duplicate of this bug. ***
Comment 15 Telesto 2018-02-16 09:03:43 UTC
*** Bug 115761 has been marked as a duplicate of this bug. ***
Comment 16 Buovjaga 2018-02-16 11:28:30 UTC
(In reply to Ljiljan from comment #13)
> Created attachment 139918 [details]
> working file
> 
> Go to the last column, last row, and press Tab. Table formatting will be
> changed.

I applied Jim's patch https://gerrit.libreoffice.org/#/c/49831/ but unfortunately the problem did not go away.
Comment 17 Jim Raykowski 2018-02-16 13:15:36 UTC
(In reply to Buovjaga from comment #16)
> (In reply to Ljiljan from comment #13)
> > Created attachment 139918 [details]
> > working file
> > 
> > Go to the last column, last row, and press Tab. Table formatting will be
> > changed.
> 
> I applied Jim's patch https://gerrit.libreoffice.org/#/c/49831/ but
> unfortunately the problem did not go away.

Yes it does not work with this attachment since the table in the attachment was created prepatch.

Try recreating the table after the patch is applied. You should notice in the sidebar styles table styles that the table style changes from highlighting whatever the initial chosen style is, Default Style if no style is selected when created, to no style highlighted when a change is made to the table using the table properties dialog.

Also I just noticed, and this may work pre patch, if the table is copied and pasted the initial table style is not highlighted in the sidebar styles for the pasted table. When the tab key is pressed in the last cell or insert or delete row or column is done on the pasted table it does not lose formatting.

Another thing I just noticed is it does not work if formatting changes to borders are made using the table toolbar unless the table properties dialog has been used to change a table property first.

This patch simply sets the table style of the table to none when the ok button is pressed in the table properties dialog.
Comment 18 Buovjaga 2018-02-16 13:32:17 UTC
(In reply to Jim Raykowski from comment #17)
> (In reply to Buovjaga from comment #16)
> > (In reply to Ljiljan from comment #13)
> > > Created attachment 139918 [details]
> > > working file
> > > 
> > > Go to the last column, last row, and press Tab. Table formatting will be
> > > changed.
> > 
> > I applied Jim's patch https://gerrit.libreoffice.org/#/c/49831/ but
> > unfortunately the problem did not go away.
> 
> Yes it does not work with this attachment since the table in the attachment
> was created prepatch.
> 
> Try recreating the table after the patch is applied. You should notice in
> the sidebar styles table styles that the table style changes from
> highlighting whatever the initial chosen style is, Default Style if no style
> is selected when created, to no style highlighted when a change is made to
> the table using the table properties dialog.

Ah, I confirm the problem is gone when I do the steps from Telesto's description.
Comment 19 bordfeldt 2018-02-16 17:01:34 UTC
With LO 6.0.0.3 on Windows 10 Pro I'm affected from this bug too. According to Andy this is a very severe bug for me, because I often work with tables with complex formatings in writer, which is now nearly impossible.
Comment 20 Jim Raykowski 2018-02-17 02:47:11 UTC
There is a workaround for the problems that are being reported here. 

1. insert a table using menu > Table > Insert Table... or Ctrl+F12
2. click on Auto Format button
None is selected in the Format list box  
3. click OK
4. click Insert
5. Make format changes to the table
Comment 21 Jim Raykowski 2018-02-17 02:53:24 UTC
When certain format changes are made to a table (font, font size, border, background, etc) the current table style of the table should be replaced with no table style. 

Patch set 2 doesn't do this but it does allow tables that are created using the toolbar table insert item and the Menu > Table > Insert Table... > Insert Button
to not be reverted to the Default Style when formatting changes are made.
Comment 22 Lee 2018-02-17 03:32:35 UTC
Changing font attributes for style table content is reverted or ignored.

1. create a table (2 column, 6 row)
2. Change the font and font size for the tyle element "table contents" apply change
3. Edit some cell contents - the changed attributes are not used, they should be
4. Select all cells in the table
5. Double click the table contents style to apply it - it is applied
6. Insert a row above some other row - those changed attributes disappear, the default values for table contents is applied - should not happen
7. Press Ctrl-z - this removes the inserted row however, it does not revert the changed font attributes incorrectly applied when the new row was inserted.

LO 5.3.7.2 does not have this issue.
Comment 23 Andy 2018-02-17 09:26:41 UTC
(In reply to Jim Raykowski from comment #20)
> There is a workaround for the problems that are being reported here. 
> 
> 1. insert a table using menu > Table > Insert Table... or Ctrl+F12
> 2. click on Auto Format button
> None is selected in the Format list box  
> 3. click OK
> 4. click Insert
> 5. Make format changes to the table

Hi, I am trying to follow your advice but...
when I click on the autoformat button in the toolbar, the dialog window that is shown has a list of styles on the left and the one selected is "default style". 
THere is no such a thing as a "none" item in the list, if that is what you mean....
Or, I can find no way to deselect that one without selecting another item in the list, if you meant to deselect all items.
Please help understand what I am missing. thanks
Comment 24 Jim Raykowski 2018-02-17 17:53:13 UTC
When certain format changes are made to a table (font, font size, border, background, etc) the current table style of the table should be replaced with no table style. 

Patch set 2 doesn't do this but it does allow tables that are created using the toolbar table insert item and the Menu > Table > Insert Table... > Insert Button
to not be reverted to the Default Style when formatting changes are made. (In reply to Andy from comment #23)
> (In reply to Jim Raykowski from comment #20)
> > There is a workaround for the problems that are being reported here. 
> > 
> > 1. insert a table using menu > Table > Insert Table... or Ctrl+F12
> > 2. click on Auto Format button
> > None is selected in the Format list box  
> > 3. click OK
> > 4. click Insert
> > 5. Make format changes to the table
> 
> Hi, I am trying to follow your advice but.
> when I click on the autoformat button in the toolbar, the dialog window that
> is shown has a list of styles on the left and the one selected is "default
> style". 
> THere is no such a thing as a "none" item in the list, if that is what you
> mean....
> Or, I can find no way to deselect that one without selecting another item in
> the list, if you meant to deselect all items.
> Please help understand what I am missing. thanks

Hi Andy,

To use this work around you need to insert the table by opening the Insert Table dialog and then clicking on the AutoFormat button. There are two ways I know of how to open the Insert Table dialog.

1. menu > Table > Insert Table...
2. Ctrl+F12

Another work around is to copy and paste the table. The pasted table will not loose formatting changes.
Comment 25 Jim Raykowski 2018-02-17 17:59:38 UTC
@Buovjaga
I'd like your thoughts on patch set 2 when you have time. Thanks.
Comment 26 Lee 2018-02-17 18:19:08 UTC
In my earlier comment I said that LO 5.3.7.2 does not have this issue.  LO 5.3.7.2 on XP did not have the issue however LO 5.3.7.2 taken from the archive on a Unix (deb) system does have the issue.
Comment 27 Lee 2018-02-17 18:30:35 UTC
There have been some work-around comments that mention using the 'none' option on the auto format button.  I too cannot find a 'none' option.  The only possibility is to make a selection of one of the styles presented.  If the default style is taken, it is not the current default style but the original style before the 'table contents' style was updated.  For whatever reason, after selecting something - it doesn't matter what - Ctl-Z can be used to remove the selection.  At this point, the table appears like it should.   In short, a work around might be:

1. Select the auto-format button
2. Choose any of the available styles
3. After it has been applied, use Ctl-Z to remove the choice

Any chance we'll see a real fix soon?
Comment 28 Buovjaga 2018-02-17 19:30:30 UTC
(In reply to Jim Raykowski from comment #25)
> @Buovjaga
> I'd like your thoughts on patch set 2 when you have time. Thanks.

Ok, I built it and did
1. Insert table
2. Change style to Box List Green
3. Formatted one row to be different color

Table style stayed Box List Green.
Comment 29 Jim Raykowski 2018-02-17 22:17:05 UTC
The following paragraph is from my interpretation of the AutoFormat code.

AutoFormat is not the same as a style or template. Once an AutoFormat is set for a table that table will lose user formatting when adding or removing a row or column because that is what it has been set to do.

The recent change to using the AutoFormat 'Default Style' when inserting a new table has caused the problems being reported. 

Patch set 2 removes the 'Default Style' style name from the inserted table so user formatting will work as expected. 

To see this is happening:

1. apply patch set 2
2. open the Sidebar - Styles - 'Table Styles'
3. insert a table using the toolbar 'Insert Table' tool item or Ctrl-F12 to open the 'Insert Table' dialog

Notice after the table is inserted 'Default Style' in the Sidebar is not highlighted.

4. make user format changes to the table
5. insert or delete row or column

My results: table does not lose formatting
Comment 30 Buovjaga 2018-02-18 07:14:21 UTC
(In reply to Jim Raykowski from comment #29)
> 1. apply patch set 2
> 2. open the Sidebar - Styles - 'Table Styles'
> 3. insert a table using the toolbar 'Insert Table' tool item or Ctrl-F12 to
> open the 'Insert Table' dialog
> 
> Notice after the table is inserted 'Default Style' in the Sidebar is not
> highlighted.
> 
> 4. make user format changes to the table
> 5. insert or delete row or column
> 
> My results: table does not lose formatting

I confirm with your patch.

Arch Linux 64-bit
Version: 6.1.0.0.alpha0+
Build ID: c902cbc7dc5294ab721a9aef3a152aa243d00011
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on February 17th 2018
Comment 31 Telesto 2018-02-22 07:52:57 UTC
*** Bug 115929 has been marked as a duplicate of this bug. ***
Comment 32 Jacques Guilleron 2018-02-22 16:46:08 UTC
*** Bug 115864 has been marked as a duplicate of this bug. ***
Comment 33 m_a_riosv 2018-02-22 17:28:47 UTC
*** Bug 115936 has been marked as a duplicate of this bug. ***
Comment 34 Xisco Faulí 2018-02-26 11:48:17 UTC Comment hidden (obsolete)
Comment 35 Aron Budea 2018-02-28 18:47:03 UTC
Jim, in [1] the conclusion is that the patches for bug 108227 and bug 107555 need to be reverted for now, can you please give an update on that?

[1] https://gerrit.libreoffice.org/#/c/49831/
Comment 36 Jim Raykowski 2018-03-01 04:50:13 UTC
(In reply to Aron Budea from comment #35)
> Jim, in [1] the conclusion is that the patches for bug 108227 and bug 107555
> need to be reverted for now, can you please give an update on that?
> 
> [1] https://gerrit.libreoffice.org/#/c/49831/

Hi Aron, 
Yes these patches should be reverted for now. I believe both are good ideas but need to wait until autoformat and user direct formatting of tables can be made to work well together. 

I have thought of two ways this can be accomplished and have had some success with both: 

1. When direct formatting is made to a table then the table's autoformat style is no longer used. This results in no table style highlighted in the sidebar styles table styles panel after a direct format is made. Autoformatting is no longer applied to the table afer row/column additions/deletions so that direct formatting is preserved.

2. The table retains the autoformat style for table boxes (cells) that do not have direct formatting by the user. This results in the sidebar style table style remaining highlighted after user direct formatting. When rows/columns are inserted/removed direct formatted cells are untouched by autoformatting. The table follows autoformatting style on inserts/removes. Background color position dependency is one advantage I can see with this approach. When insertions or deletions are made the row or column background color still follows the autoformat style.

Approach 1 may be easier to implement.

I have made some progress on approach 2 where table boxes keep their direct formatting of borders, line styles, number formatting, and background color, after insertion/deletions. Working on font retention. Insertions and deletions are made with autoformat style so the table keeps the autoformat style for table boxes that are not direct formatted.

Other ideas are welcome.

What is the best way to do the revert? I will do a revert patch if needed.
Comment 37 Xisco Faulí 2018-03-01 14:14:57 UTC
*** Bug 116114 has been marked as a duplicate of this bug. ***
Comment 38 haenig 2018-03-01 14:45:57 UTC
A solution seemingly not discussed here at all, but from my point of view the most preferrable, would be to allow a user to create his own "Default Style", which of course then has to be part of the users standard template. This way every new table would have exactly the style intended by the user without fiddling with AutoFormat options.

Certainly any style applied directly to cells should dominate over the ones from the template and e.g. kept also for new lines/columns.

Also I would like to have the option to disable AutoFormat globally.
Comment 39 Jacques Guilleron 2018-03-02 07:40:52 UTC
*** Bug 116135 has been marked as a duplicate of this bug. ***
Comment 40 Jim Raykowski 2018-03-02 07:52:32 UTC
Here is a patch that keeps direct formatting after rows/cols are inserted/deleted or table style is changed for cells with character attribute direct formatting. 

https://gerrit.libreoffice.org/#/c/50612/
Comment 41 Jim Raykowski 2018-03-02 08:35:59 UTC
(In reply to Jim Raykowski from comment #40)
> Here is a patch that keeps direct formatting after rows/cols are
> inserted/deleted or table style is changed for cells with character
> attribute direct formatting. 
> 
> https://gerrit.libreoffice.org/#/c/50612/

Unfortunately after document reload the table loses direct formatting on ins/del.
Comment 42 Jim Raykowski 2018-03-03 23:56:49 UTC
If a space or other character(s) are added to a table cell before changing font attributes the changed font attributes are not lost on row insert or delete or table style change and also remain after reloading the document and inserting or deleting a row or table style change.

Here are steps to confirm:

1. Insert a table
2. Enter a space or some characters in a cell
3. Select a font and enter more characters
4. Insert or delete a row

result: font is not lost

5. Save the document and reload
6. Insert or delete a row

result: font is not lost
Comment 43 Lee 2018-03-04 02:08:59 UTC
With regard to comment 42,
That first character should be formatted according to the "table content" style. Selecting a font changes the font characteristics for the  reset of the cell, as would be expected.  This bug is that the current definitions in the "table content" style are not applied where they should be, that being everywhere except those cells where a specific font treatment is individually applied cell by cell.  The font characteristics are taken using the default value of the "table content" style, not the value of the "table content" style as modified for the document.  It is the current definition of the "table content" style element is not used until auto-format is invoked (table->auto_format_styles) then reverted (Ctrl-Z).
Comment 44 Lee 2018-03-04 02:12:01 UTC
Slight typing error in comment 43
for the  reset of the cell
should be
for the rest of the cell
Comment 45 Jacques Guilleron 2018-03-04 12:59:35 UTC
*** Bug 116178 has been marked as a duplicate of this bug. ***
Comment 46 Pete 2018-03-04 15:36:23 UTC
Created attachment 140335 [details]
1 paragraph of writing, Colour formated table, resets on edits

For Diagnosis , if it helps.
File contains a table whos format resets on copy paste and editing in some cases.
Comment 47 Kumāra 2018-03-05 03:52:28 UTC
*** Bug 116191 has been marked as a duplicate of this bug. ***
Comment 48 Aron Budea 2018-03-05 06:44:55 UTC
Hi Jim,

(In reply to Jim Raykowski from comment #36)
> I have thought of two ways this can be accomplished and have had some
> success with both: 
Thanks for iterating on this! I'm not familiar with the inner working of autoformat styles... is it possible to know what formatting comes from direct formatting, and what comes from autoformat style in an existing cell/row/column?

> What is the best way to do the revert? I will do a revert patch if needed.
I'd suggest reverting the mentioned commits in branch libreoffice-6-0, so they don't cause regressions.
In master they can be kept, except maybe if they clash with the eventual fix, then reverting them there would make the actual fixing commit cleaner (just my two cents).
Comment 49 Aron Budea 2018-03-05 15:19:55 UTC
*** Bug 116207 has been marked as a duplicate of this bug. ***
Comment 50 Jim Raykowski 2018-03-06 04:21:28 UTC
(In reply to Aron Budea from comment #48)

Hi Aron, great to be able to discuss this with you.

> is it possible to know what formatting comes from
> direct formatting, and what comes from autoformat style in an existing
> cell/row/column?

The ability to know cells that have direct formatting is here [1] but there seems to be no provision for persistence. Using this is how the most recent patch submitted for cell font attributes works [2]. This can also be used for cell borders, cell number formatting, and cell background. 

How to make this persistent is beyond my knowledge.

[1] https://opengrok.libreoffice.org/xref/core/sw/inc/swtable.hxx#433
[2] https://gerrit.libreoffice.org/#/c/50612/
Comment 51 Telesto 2018-03-09 14:06:53 UTC
*** Bug 116311 has been marked as a duplicate of this bug. ***
Comment 52 Jean-Baptiste Faure 2018-03-13 13:16:18 UTC
*** Bug 116380 has been marked as a duplicate of this bug. ***
Comment 53 Jean-Baptiste Faure 2018-03-13 13:18:02 UTC
*** Bug 116379 has been marked as a duplicate of this bug. ***
Comment 54 Aron Budea 2018-03-13 13:54:11 UTC
(In reply to Jim Raykowski from comment #50)
> Hi Aron, great to be able to discuss this with you.
I'm sorry, I can't offer any useful advice on this. Let me see if I'm able to find someone who can.
In the meantime please revert the responsible commits in branch libreoffice-6-0, to stop the bug reports coming in. Thank you!
Comment 55 Aron Budea 2018-03-13 14:10:08 UTC
I wonder if this is conceptually different from working with text/paragraphs based on styles plus direct formatting over them. Obviously there must be some table-specific oddities, but maybe the logic used there can be used for reference? Or is this too naive of a thought? :)
Comment 56 Buovjaga 2018-03-13 20:07:02 UTC
*** Bug 116366 has been marked as a duplicate of this bug. ***
Comment 57 Jim Raykowski 2018-03-14 04:06:32 UTC
(In reply to Aron Budea from comment #55)
> I wonder if this is conceptually different from working with text/paragraphs
> based on styles plus direct formatting over them. Obviously there must be
> some table-specific oddities, but maybe the logic used there can be used for
> reference? Or is this too naive of a thought? :)

I'm not sure where to look but I do think this thought is worth looking into :) 

Here is a link to a revert patch:
https://gerrit.libreoffice.org/#/c/51253/
Comment 58 Aron Budea 2018-03-15 16:31:51 UTC
(In reply to Jim Raykowski from comment #57)
> Here is a link to a revert patch:
> https://gerrit.libreoffice.org/#/c/51253/

Thank you! Please prepare one for libreoffice-6-0 as well, and when that's released, for libreoffice-6-0-3 so it's included in the 6.0.3 update.
Comment 59 Commit Notification 2018-03-15 17:02:14 UTC
Jim Raykowski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=eeb4a2ec37bf88b26a9f243cc5682e96c9e35df6

tdf#115573 Revert: tdf#107555 Apply 'Default Style' table style

It will be available in 6.1.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 60 Volga 2018-03-17 03:53:53 UTC
(In reply to Jim Raykowski from comment #57)
> Here is a link to a revert patch:
> https://gerrit.libreoffice.org/#/c/51253/
Can you back port it into 6.0 branch?
Comment 61 Commit Notification 2018-03-18 10:03:36 UTC
Zdeněk Crhonek committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=fbe3b762e8e96f96afe5c79d1b9db5be3c7141a8

uitest for bug tdf#115573

It will be available in 6.1.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 62 Jacques Guilleron 2018-03-18 17:08:09 UTC
*** Bug 116469 has been marked as a duplicate of this bug. ***
Comment 63 Telesto 2018-03-19 14:01:15 UTC
*** Bug 116493 has been marked as a duplicate of this bug. ***
Comment 64 Milo Ocene 2018-03-21 22:48:07 UTC
*** Bug 116554 has been marked as a duplicate of this bug. ***
Comment 65 Xisco Faulí 2018-03-22 14:40:02 UTC
@Jim, Can this bug be closed? Do you plan to port the revert to 6-0 ?
Comment 66 Jim Raykowski 2018-03-22 16:10:29 UTC
(In reply to Xisco Faulí from comment #65)
> @Jim, Can this bug be closed? Do you plan to port the revert to 6-0 ?

The revert has been ported to 6-0 but has not been merged as of yet.

https://gerrit.libreoffice.org/#/c/51362/
Comment 67 Jacques Guilleron 2018-03-22 16:13:25 UTC
*** Bug 116564 has been marked as a duplicate of this bug. ***
Comment 68 Commit Notification 2018-03-26 19:05:29 UTC
Jim Raykowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=30db8c9b1d9654e62c11657140fac24f0f52c547&h=libreoffice-6-0

tdf#115573 Revert: tdf#107555 Apply 'Default Style' table style

It will be available in 6.0.4.

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

Affected users are encouraged to test the fix and report feedback.
Comment 69 Xisco Faulí 2018-03-28 09:03:21 UTC
*** Bug 116652 has been marked as a duplicate of this bug. ***
Comment 70 Xisco Faulí 2018-03-28 09:05:01 UTC
*** Bug 116674 has been marked as a duplicate of this bug. ***
Comment 71 Commit Notification 2018-03-28 14:36:55 UTC
Jim Raykowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-0-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=55a27458831d1a7d203479c9d713d2f3e57c25a4&h=libreoffice-6-0-3

tdf#115573 Revert: tdf#107555 Apply 'Default Style' table style

It will be available in 6.0.3.

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

Affected users are encouraged to test the fix and report feedback.
Comment 72 Telesto 2018-04-01 08:31:33 UTC
*** Bug 116719 has been marked as a duplicate of this bug. ***
Comment 73 raal 2018-04-02 12:51:26 UTC
*** Bug 116610 has been marked as a duplicate of this bug. ***
Comment 74 Buovjaga 2018-04-02 17:27:55 UTC
*** Bug 116740 has been marked as a duplicate of this bug. ***
Comment 75 Dieter 2018-04-03 07:11:09 UTC
*** Bug 116764 has been marked as a duplicate of this bug. ***
Comment 76 Dieter 2018-04-05 12:06:24 UTC
*** Bug 116819 has been marked as a duplicate of this bug. ***
Comment 77 David 2018-04-13 07:31:20 UTC
I just got my 6.0.3 upgrade (Version: 6.0.3.2; Build ID: 1:6.0.3-0ubuntu1
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); Calc: group) -- and sadly, NOT FIXED.

When I add a row, the formatting is reset for the whole table. Nasty. :( I was hopeful that this was squashed, but it seems not to be.
Comment 78 David 2018-04-13 08:06:16 UTC
Sorry -- was a little hasty! I read some of the earlier comments, and noticed in #17 that you needed to start with a doc created in 6.0.3n. So:

- If I use a "fresh" doc created in 6.0.3.2, then either create a table, or copy/paste one from an older (6.0.2) doc, then the table format is NOT reset when adding a row, etc.

- If I simply load up a doc created in an earlier version, then the table re-formatting still occurs in 6.0.3n.

So, FIXED, then! But people concerned about this bug should be made aware of this behaviour: edit your tables in docs *created* in 6.0.3+.

(In reply to David from comment #77)
> I just got my 6.0.3 upgrade (Version: 6.0.3.2; Build ID: 1:6.0.3-0ubuntu1
> CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-GB
> (en_GB.UTF-8); Calc: group) -- and sadly, NOT FIXED.
> 
> When I add a row, the formatting is reset for the whole table. Nasty. :( I
> was hopeful that this was squashed, but it seems not to be.
Comment 79 Cor Nouws 2018-04-20 21:26:41 UTC
needs this one to be set fixed, or kept open for the long term solution?
Comment 80 Dieter 2018-05-02 12:37:07 UTC
*** Bug 117387 has been marked as a duplicate of this bug. ***
Comment 81 Cor Nouws 2018-05-03 11:47:49 UTC
(In reply to Cor Nouws from comment #79)
> needs this one to be set fixed, or kept open for the long term solution?

Works with a new table in a new document ..
Let me set to fixed and see what people think :)

Version: 6.1.0.0.alpha1+
Build ID: 8a2745e1beee722c8c9691c397e493cc1160bedf
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-04-30_23:34:23
Locale: nl-NL (nl_NL.UTF-8); Calc: group
Comment 82 Aron Budea 2018-05-24 10:25:29 UTC
*** Bug 117775 has been marked as a duplicate of this bug. ***
Comment 83 Dieter 2018-05-25 14:53:14 UTC
*** Bug 117802 has been marked as a duplicate of this bug. ***
Comment 84 Aron Budea 2018-05-30 17:52:14 UTC
*** Bug 117909 has been marked as a duplicate of this bug. ***
Comment 85 Maxime THEPAULT 2018-09-02 14:46:09 UTC
Hi,

For few month I kept LibreOffice 5.4 because it don't have the bug.

But today I tried newer versions : 6.0.6 / 6.1.0 / and even future 6.1.1

The 2 latest versions have the bug, and it's very annoying.

Example : I open any of my ODT document (LibreOffice Writer) with table, I delete a column : table formatting is lost (font, size, bold).
Also, if I use Ctrl+Z it will not restore the formatting, I must close LibreOffice and open my ODT document again.

2 differents ways to have the bug :

1) Add or Delete a column
2) Add or Delete a row

With that bug, I can't use tables, it's a big problem to me, it's unusable.

Please, do you plan to fix 6.0.x and 6.1.x versions ?

With 5.4.7 : no problem.

Thank you.
Comment 86 David 2018-09-02 14:54:21 UTC
(In reply to Maxime THEPAULT from comment #85)
> . . .
> Example : I open any of my ODT document (LibreOffice Writer) with table,...

Hi Maxime - did you read the earlier comments in this thread? See, for example, my notes at #78 (referring to #17!):

https://bugs.documentfoundation.org/show_bug.cgi?id=115573#c78

If you're opening your *old* documents, the bug "persists". You need to copy/paste those tables into a document created in the newer ("fixed") version. Cumbersome, but that's the way it is at the moment.
Comment 87 Maxime THEPAULT 2018-09-02 15:49:58 UTC
Is it a joke ?

Create again all my documents ??

I'm very surprised bug is not fixed, it's very annoying, you can't seriously propose to create new documents, with all lost work time...

I have many documents since about 10 years ago, I will not create my documents again... it's crazy.

Why 5.4.7 don't have the bug ? You can't copy working code from this version ?


I hope bug will be fixed, it's not possible to work as is, how can you imagine LibreOffice will be kept into companies with a big bug like this one.
Comment 88 Lee 2018-09-02 17:44:29 UTC
I agree with maxime who recently posted a comment.  Although it is possible to make tables obey the current table styling by placing them into a new document, that is awkward and costly.  Consider a large document for which an individual is responsible for only a portion of one chapter.  Who would be the appropriate person to restart the entire document?  Who would be responsible for proof reading the new document?  To what part of the organization should this cost be assigned?

Perhaps the status of this bug should be changed as it is not yet resolved.
Comment 89 Aron Budea 2018-09-02 19:53:36 UTC
(In reply to Maxime THEPAULT from comment #87)
> Create again all my documents ??
> 
> I'm very surprised bug is not fixed, it's very annoying, you can't seriously
> propose to create new documents, with all lost work time...
> 
> I have many documents since about 10 years ago, I will not create my
> documents again... it's crazy.
No, only documents that have been saved with versions 6.0.0-6.0.2.

> Why 5.4.7 don't have the bug ? You can't copy working code from this version
> ?
That's exactly what happened, it's the same code now as before. And older versions can't handle the bad files without the one-time manual fix, either. If you see something else, it's a different bug.
Comment 90 Maxime THEPAULT 2018-09-03 08:51:08 UTC
(In reply to Aron Budea from comment #89)
> (In reply to Maxime THEPAULT from comment #87)
> > Create again all my documents ??
> > 
> > I'm very surprised bug is not fixed, it's very annoying, you can't seriously
> > propose to create new documents, with all lost work time...
> > 
> > I have many documents since about 10 years ago, I will not create my
> > documents again... it's crazy.
> No, only documents that have been saved with versions 6.0.0-6.0.2.
> 
> > Why 5.4.7 don't have the bug ? You can't copy working code from this version
> > ?
> That's exactly what happened, it's the same code now as before. And older
> versions can't handle the bad files without the one-time manual fix, either.
> If you see something else, it's a different bug.

I see...

I checked : I have recent (2018) documents with the bug, and older documents without the bug, so it seems you are right.

Thank you, it relieves me...
Comment 91 BogdanB 2018-09-15 15:51:30 UTC
I can NOT reproduce

Version: 6.2.0.0.alpha0+
Build ID: 9a9b81c7212fa6a6762246593acf3f1950677a22
CPU threads: 4; OS: Linux 4.15; UI render: GL; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-09-08_00:00:43
Locale: ro-RO (ro_RO.UTF-8); Calc: threaded
Comment 92 BogdanB 2018-09-27 04:31:12 UTC
Created attachment 145202 [details]
not solved. Video

See the video. This bug it is not yet solved.

Tested on:
Version: 6.2.0.0.alpha0+
Build ID: 66232248ff55639052ddb76918d555e21dc9c46b
CPU threads: 4; OS: Linux 4.15; UI render: GL; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-09-20_19:40:04
Locale: ro-RO (ro_RO.UTF-8); Calc: threaded
Comment 93 perie_gut 2018-09-27 12:21:08 UTC
No Issues under this version 


Version: 6.1.1.2 (x64)
Build ID: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b
CPU threads: 4; OS: Windows 10.0; UI render: default; 
Locale: en-PH (en_PH); Calc: threaded
Comment 94 BogdanB 2018-09-27 12:46:09 UTC
(In reply to perie_gut from comment #93)
> No Issues under this version 
> 
> 
> Version: 6.1.1.2 (x64)
> Build ID: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b
> CPU threads: 4; OS: Windows 10.0; UI render: default; 
> Locale: en-PH (en_PH); Calc: threaded

Please try with the document from comment 13. I reply like you that it is not my case, but after trying this document, I could test this bug.
Comment 95 perie_gut 2018-09-27 13:04:01 UTC
(In reply to BogdanB from comment #94)
> (In reply to perie_gut from comment #93)
> > No Issues under this version 
> > 
> > 
> > Version: 6.1.1.2 (x64)
> > Build ID: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b
> > CPU threads: 4; OS: Windows 10.0; UI render: default; 
> > Locale: en-PH (en_PH); Calc: threaded
> 
> Please try with the document from comment 13. I reply like you that it is
> not my case, but after trying this document, I could test this bug.

Yes, if I am going to use the said sample document, I can reproduce the issue. However, I cannot reproduce the said issue if I am going to copy the table (from the sample) to a new writer document.
Comment 96 Aron Budea 2018-09-27 13:10:14 UTC
(In reply to BogdanB from comment #94)
> Please try with the document from comment 13. I reply like you that it is
> not my case, but after trying this document, I could test this bug.
Please see previous replies, eg. comment 78. Buggy files that were edited between versions 6.0.0-6.0.2 keep this issue, and require manual fix, but with files not touched with a buggy LO version the issue is gone.
Comment 97 perie_gut 2018-09-27 13:30:34 UTC
(In reply to Aron Budea from comment #96)
> (In reply to BogdanB from comment #94)
> > Please try with the document from comment 13. I reply like you that it is
> > not my case, but after trying this document, I could test this bug.
> Please see previous replies, eg. comment 78. Buggy files that were edited
> between versions 6.0.0-6.0.2 keep this issue, and require manual fix, but
> with files not touched with a buggy LO version the issue is gone.

What's the use of having this issue open when in fact we cannot reproduce this using the newer LO versions? This is already a file issue that originated from a faulty LO writer version. 

Yes, I do understand your point but forcing the community to fix a certain file issue that originated from a bleeding edge version is already a waste of time given the fact that none of the stable versions encountered it.
Comment 98 Aron Budea 2018-09-27 13:52:20 UTC
(In reply to perie_gut from comment #97)
> What's the use of having this issue open when in fact we cannot reproduce
> this using the newer LO versions? This is already a file issue that
> originated from a faulty LO writer version. 
It's not open (status is RESOLVED), and I agree. Let's set this to verified.
Comment 99 marcus905 2018-10-07 17:32:08 UTC
I'm unsure if the bug needs to be reopened but I'd like to add that this happens also from files created using templates that have been previously edited under the affected versions, so the manual fix must be done to those files also.
Comment 100 marcus905 2018-10-07 18:07:04 UTC
Also, does somebody know which part of the XML files in the document is corrupted by the bug in the saved files? I ask this so that we can manually fix the files without having to copy/paste the content in new files.

If the content that makes the issue persist in older files is identified I could probably code a small utility that to batch fix the affected files for all to use.

I tried to diff (after delinearization) the XML files in hopes to find the corrupted section but the differences were too many to understand what went wrong.

Can anybody help me?
Comment 101 J. Mahun 2019-01-09 15:42:58 UTC
Created attachment 148171 [details]
Demonstation that bug 115573 still exists in 6.1.3.2

Bug 115573 Table loses formatting when inserting a new row in a table.
Status: Verified Fixed.
Attached video shows it is still a bug in v6.1.3.2
Comment 102 Telesto 2019-01-09 15:57:49 UTC
(In reply to J. Mahun from comment #101)
> Created attachment 148171 [details]
> Demonstation that bug 115573 still exists in 6.1.3.2
> 
> Bug 115573 Table loses formatting when inserting a new row in a table.
> Status: Verified Fixed.
> Attached video shows it is still a bug in v6.1.3.2

Thanks for the report. Already report. See bug 120068
Comment 103 Seán Ó Séaghdha 2019-10-16 05:23:09 UTC
Just created a new table in 6.3.2.2 and this bug is still there.

These reports keep getting closed for one reason or another - the current one seems to be 126008.
Comment 104 Emanuele Gissi 2020-06-15 14:05:09 UTC Comment hidden (obsolete)
Comment 105 Xisco Faulí 2020-06-15 14:08:19 UTC Comment hidden (obsolete)
Comment 106 Timur 2020-06-15 17:19:15 UTC
(In reply to Xisco Faulí from comment #105)
> (In reply to Emanuele Gissi from comment #104)
> > I can confirm this bug too.
> > Libreoffice 6.4.4.2 on Ubuntu Linux 20.04
> 
> Please, report it in a new ticket. thanks

Please report *only* if you reproduce with new document, and link to this bug.
If it's old documents per comment 78, do not report, it's as it is.
Comment 107 Aron Budea 2020-06-16 05:17:08 UTC
Bug 126008 is open on a leftover part of this bug.