Bug 142165 - Table lines in Writer 7.1.3: Change borders for selected cells will change borders in all table
Summary: Table lines in Writer 7.1.3: Change borders for selected cells will change bo...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.1.3.2 release
Hardware: All All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:7.2.0 target:7.1.4
Keywords: bibisected, bisected, regression
: 142166 142386 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-05-08 08:20 UTC by Hans
Modified: 2021-06-20 01:54 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Writer-Dokument mit der Tabelle (9.54 KB, application/vnd.oasis.opendocument.text)
2021-05-08 08:20 UTC, Hans
Details
Screenshots of the activities and results (117.84 KB, image/png)
2021-05-08 09:24 UTC, Hans
Details
confirm unfixed problem (18.59 KB, application/vnd.oasis.opendocument.text)
2021-06-17 14:32 UTC, kubbugrep
Details
confirm unfixed problem (8.91 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2021-06-17 14:32 UTC, kubbugrep
Details
buggy version 7.1.4 (28.32 MB, video/mp4)
2021-06-19 07:30 UTC, kubbugrep
Details
mostly fixed version 7.2.beta1 (21.60 MB, video/mp4)
2021-06-19 07:38 UTC, kubbugrep
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hans 2021-05-08 08:20:03 UTC Comment hidden (me-too)
Comment 1 Hans 2021-05-08 08:31:48 UTC
English translation:

I would like to separate the first table column and later also the top row from the other cells with a simple table line. The starting point is a table without dividing lines, in which the padding of the border is zero in both the table and the paragraph properties. (see attached writer file)

To do this, I mark the first column and click the "right inner line" button (see also my screenshots in my post in Ask-LibreOffice). Incomprehensibly, when the dividing line is inserted, the cell height is increased at the same time. In the table properties, the inner distance has been increased from 0.0 to 0.1 cm. I didn't order that and then I'll cancel it. The inner line moves to the far right next to the fourth column. The dividing line next to the first column has now disappeared. That is also incomprehensible to me.

Something similar happens when I want to draw a dividing line under the first line of the table.

Up to version 7.1.2 I was able to create such dividing lines without increasing the cell height after marking the table cells to be delimited via the table properties / border by clicking on the desired lines. This no longer works with version 7.1.3 either, the dividing line is now always drawn at the very edge of the table and the cell height is also increased.

How can you insert separating lines between columns or rows with version 7.1.3 without increasing the cell height and thereby shifting all page breaks in the document?
Comment 2 Hans 2021-05-08 09:24:54 UTC
Created attachment 171781 [details]
Screenshots of the activities and results

Screenshots of the activities and results
Comment 3 José Luís Andrade 2021-05-08 10:18:06 UTC Comment hidden (obsolete)
Comment 4 Hans 2021-05-10 05:57:12 UTC
Unlike https://bugs.documentfoundation.org/show_bug.cgi?id=139018

In the bug 139018 (see screencast in the belonging bugreport) the right and left borders are set to neutral and not to invisible as should be done to get the desired result. So bug 139018 might not be a bug.

Due to the bug described here, it is impossible to set internal table lines without getting the cell-sizes increased (by unwanted padding increase) and internal table lines are moved to the borders of the table without the request of the user.
Comment 5 Timur 2021-05-11 08:57:09 UTC
Let's try with steps, that are usual way to report (correct if wrong):
1. open attachment 171780 [details] 
2. select 1st column AAA 
3a. Set right border only via Borders icon in toolbar, OK - see that padding increased to 0,10 - NOK
3b. Set right border via Table Borders /Properties, as in screenshot - line is not after selected 1st but 4th column
3c. Set middle border via Table Borders /Properties - line is after selected 1st column as needed
4a. undo, see that padding is gone - OK
4b. after 3. do Set no borders, see that padding remains
4c. see that padding is 0,10 with column AAA selected, but 0 with no column selected, but with cursor in cell A1 - NOK

Note: good you prepared sample, just better to insert screenshot with steps there, to be easier to see. Not very important. 

Not sure if 3a is a bug, probably it will not be and was discussed somewhere, something in bug 106926. 4c doesn't seem proper to me, again it should be searched. 

I guess this report is about 3b for which I'm not sure if a bug, because 3c gives intended result. But seems like there was a change in LO 7.2+ and in 7.1.

Note: bug 142166 is related or same.
Comment 6 Hans 2021-05-11 09:27:15 UTC
Thank you timor. Acccording to your suggestions i describe my steps to reproduce:
1. Open attachment 171780 [details]     
2. Open the table properties and see that the padding is 0.0cm,
3. Close the table properties                                                               
4. Select 1st column AAA                                                                                              
5. Set right border via Borders icon in toolbar 
5a. See that the cell heights were increased and the line is right to column AAA                  
5b. Open the table properties and see that the padding now is 0.1cm 
5c. This is NOT OK, see my remark below
6. In the opened table properties set the padding back to 0.0cm (do nothing more here)
7. Close the table properties with OK
8. See that the vertical line moved from AAA to the right edge of the table
8a. This is NOT OK, the line-position was not changed in the table properties before. 

Remark: Up to Writer 7.1.2 it was possible to mark the 1st column AAA, then open the table properties and set the right border (always related to the selected cells) without increasing any padding.
Comment 7 Timur 2021-05-11 10:11:11 UTC
Bibisect in 7.2+ Linux, change for 3b. from Comment 5 and for 8. from Comment 6 was:

author	Caolán McNamara <caolanm@redhat.com>	2021-03-12 12:57:57 +0000
committer	Caolán McNamara <caolanm@redhat.com>	2021-03-12 17:17:35 +0100
commit	6db71f70a3b200d4074f6cda8ce445e9861d3296 (patch)
tree	533079dfe5e83a2e5034ae8c1bb51ab7e94bcdd9
parent	ce69ab8d61975d5d49142469115798b5b3688a63 (diff)
tdf#140977 drop possible table-cursor before setting the new one

I guess this can be called a regression, because selection (like a column) has no effect anymore in applying User-defined border via Table Borders /Properties. 
Left border is now absolute, middle border marks all inside vertical borders, and right border is also absolute. 

Not that new behavior is quite illogical, rather it's different (or I'm not aware where it's documented), but there are also other reports.
In bug 139018 was wrongly added example, which is this bug.
Steps:
1. open attachment 171780 [details]
2. set all borders
3. mark column BBB
4. via Table Borders /Properties remove horizontal borders
Expected: only marked borders are removed, as in screencast attachment 171481 [details]
Experienced: all horizontal borders are removed, as in screencast attachment 171482 [details]

Bug 142166 also sounds the same: "Change borders for selected cells will change borders in all table".

Apart from regression, there's a question why border adds padding. 
I don't see it that is changed, so I don't confirm previous remark.
Comment 8 Hans 2021-05-11 10:27:12 UTC
Hello Timur,

you wrote "Apart from regression, there's a question why border adds padding. 
I don't see it that is changed, so I don't confirm previous remark."

Up to Writer 7.1.2 the behaviour was:
a.) Adding a line using the Borders-icon in the toolbar added a padding without request. Already worse up to 7.1.2.
b.) Adding a line by selecting the appropriate cells, opening the table properties and switching the lines on/off worked without adding unwanted paddings. 

With the current behaviour of 7.1.3 it is no more possible to set internal lines in tables without additional padding. So you get increased table sizes disordering nearly all page-breaks the document. 

Really worse. At least for me and other users with size-optimized tables.
Comment 9 Timur 2021-05-11 12:35:41 UTC
*** Bug 142166 has been marked as a duplicate of this bug. ***
Comment 10 urly 2021-05-12 10:47:38 UTC
In 7.1.2: line formating in writer-tables work fine.
7.1.3: formating one line changes all lines in the table.
Comment 11 Aron Budea 2021-05-13 10:34:13 UTC
Let's add Caolán to CC, based on comment 7.
Comment 12 Caolán McNamara 2021-05-17 14:06:20 UTC
I'll take this for the regression, leaving aside the preexisting behaviour described in comment #1 para 2
Comment 13 Commit Notification 2021-05-17 16:12:46 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/4d52d2bc81f9d27472fe368785912a530489d046

tdf#142165 restore a SwShellTableCursor if the orig selection described that

It will be available in 7.2.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.
Comment 14 Commit Notification 2021-05-17 16:26:18 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/7cfae0ade31a5469331f5b0288e22aed6ec2fcc1

tdf#142165 restore a SwShellTableCursor if the orig selection described that

It will be available in 7.1.4.

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.
Comment 15 Timur 2021-05-20 06:46:19 UTC Comment hidden (obsolete)
Comment 16 Timur 2021-05-20 06:54:49 UTC
I set Verified for borders. (previous message was my bad). Thanks!

Note that it takes 3 clicks to remove, there's documentation bug for that.
Comment 17 Timur 2021-05-20 11:10:06 UTC
*** Bug 142386 has been marked as a duplicate of this bug. ***
Comment 18 Hans 2021-06-11 09:59:30 UTC
Unexpected and inconsistent adding of padding (define lines with the borders-icon in toolbar [+0,1mm] vs. using the table-properties [+0,05cm]) remains in version 7.1.4.2.
Comment 19 Timur 2021-06-11 10:32:00 UTC
Rule of thumb is one issue per bug. 
Here it was borders and it's resolved so I set back Fixed, do not change. 

For padding, you may search existing closed and open bugs for similar issue and if not found report new.
Comment 20 Timur 2021-06-11 10:38:07 UTC
Before reporting please see bug 106926 as indicated in comment 5.
Comment 21 Hans 2021-06-11 10:52:40 UTC
@Timur:
Caolan wrote in comment #12: "I'll take this for the regression, leaving aside the preexisting behaviour described in comment #1 para 2". Comment #1 para 2 concerns lines and adjoining padding.

So reopening the bug should be right, because with the bugfix the padding was affected also.
Comment 22 Hans 2021-06-11 11:07:29 UTC
@Timur:
bug 106926 states: "Padding and borders are independent properties" 

So changing table-lines shall not affect padding as is done with the bugfix state now, neither via toolbar-botton nor via table-properties.
Comment 23 Hans 2021-06-13 06:07:50 UTC
@Timur & all:
The padding-bug already was reported in 2015 (bug 93975) but remains obstructing users. So why reporting a new bug with new inconsistencies (Tooolbar-botton vs. table properties) you may see as conflicting with your thumb-rule?
Comment 24 Timur 2021-06-13 06:54:57 UTC
This bug remains fixed and no need to comment further, you may add comment in bug 93975 of you can clarify more, good to have padding explained there.
Comment 25 Timur 2021-06-14 17:24:18 UTC
*** Bug 142850 has been marked as a duplicate of this bug. ***
Comment 26 Timur 2021-06-15 12:44:04 UTC Comment hidden (obsolete)
Comment 27 Timur 2021-06-15 13:44:49 UTC Comment hidden (obsolete)
Comment 28 Xisco Faulí 2021-06-15 14:24:16 UTC
(In reply to Timur from comment #27)
> Seems that this is NOK is 7.1.4, cannot see why, because OK in 7.2+.

will be fixed in bug 142721
Comment 29 kubbugrep 2021-06-17 14:32:11 UTC
Created attachment 172988 [details]
confirm unfixed problem
Comment 30 kubbugrep 2021-06-17 14:32:36 UTC
Created attachment 172989 [details]
confirm unfixed problem
Comment 31 kubbugrep 2021-06-17 14:45:18 UTC
Please have a look at the files named "confirm unfixed problem".

By playing around with the cell's (top) borders of the cells with green text, either trying to add borders or remove them, in case there aren't any, the bug should become visible. It just seems inpossible to add or remove the top border of the left cell or the right one or of both cells with green text, neither in the upper line nor several lines below, without borders of other cells getting randomly removed or added.
 
It still works correctly in version 7.0.6, but not in 7.1.3, 7.1.4.2 nor in the already available 7.2.0.0.a.
Comment 32 Timur 2021-06-18 07:47:58 UTC
kubbugrep, it's good that we test resolved bugs, but you didn't show this was not fixed. 
What you wrote is too general "play around"...needed are exact steps. 
You attached ODT and DOCX, but DOCX is usually another bug. 
So best to download fresh daily master LO from https://dev-builds.libreoffice.org/daily/master/current.html that installs separately to working LO. The other day it went from 7.2+ to 7.2+. 
If you reproduce bug, please write exact steps in new report and connect via See Also.
Comment 33 Timur 2021-06-18 07:49:50 UTC
Note that fresh 7.2.0 beta is also good for testing, one you already used.
Comment 34 kubbugrep 2021-06-18 09:38:54 UTC
Timur, thanks for your comment. I wrote "play around" because it really doesn't matter whether you add or remove the border line on the top of the specified cells in one of the attached files (odt or docx).

1. Open file
2. look for first cell with text "occaecati cupiditate" in green colour
3. select that cell
4. open "frames" tab of the "table properties" window opened via the context menu 
5. here you will see first error in the "user defined" area: the left border line is missing
6. remove top border line by clicking twice on it in the "user defined" area and close that settings windows with ok
7. watch several border lines of some other cells being removed as well

Alternatively you can confirm the problem with the above steps for the cell with text "molestias excepturi sint \n dicta sunt explicabo" also in green.
There is one difference in step 6 since this cell doesn't have any top border line yet. Hence you have to add one in the already above mentioned "frames" tab of the "table properties" window opened via the context menu, but with only one click on the respecting place in the "user defined" area.


Both files were provided just for convenience, to show, that it doesn't work, no matter of the format and to make it easier to confirm that this is a clearly bug of the program rather than a problem with the file, since for the latter one should expect similiar problems by opening the docx file with word. Whether any of the persons trying to resolve this bug is making use of the information provided is completely up to that person. I can just try to make it easier by providing as much and as useful information as possible.
Comment 35 kubbugrep 2021-06-18 09:50:28 UTC
With the download links you provided users can download the daily master of version 7.3, which doesn't even have an official release schedule yet:
https://wiki.documentfoundation.org/ReleasePlan/7.3

For users it would be much more interesting, whether this is going to be fixed ni the 7.1 branch or whether users will have to wait another two months until the release of version 7.2. in mid/late August.

Anyway, the current status "RESOLVED FIXED" is definitely wrong, since there is no non-alpha or non-beta version available with this bug resolved. That also means there simply is _no_ version for people other than developers and those people who want to just have a look at alpha's or beta's.
Comment 36 Timur 2021-06-18 11:33:57 UTC
I don't reproduce. 
You may record a screencast, but be sure to show Help-About in the beginning. 
Fixed is proper status of this one, unless someone else in CC reproduces.
Comment 37 Hans 2021-06-18 11:49:55 UTC
I can confirm the bug described with the steps 6 and 7 of comment 34 using Writer 7.1.4.2 with the odt-Document. Status should not be "RESOLVED FIXED"
Comment 38 kubbugrep 2021-06-19 07:30:12 UTC
Created attachment 173008 [details]
buggy version 7.1.4
Comment 39 kubbugrep 2021-06-19 07:38:14 UTC
Created attachment 173009 [details]
mostly fixed version 7.2.beta1
Comment 40 kubbugrep 2021-06-20 01:54:42 UTC
(In reply to Timur from comment #36)

@Timur: You will find two videos showing the still existing problem in version 7.1.4. and the fixed version 7.2.beta1. However, the latter still does not correctly display the existing cell borders in the settings window.