Bug Hunting Session
Bug 116083 - Table (and its row/columns/cells) resize behavior is random
Summary: Table (and its row/columns/cells) resize behavior is random
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.1.1 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:6.1.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Writer-Tables
  Show dependency treegraph
 
Reported: 2018-02-28 11:35 UTC by Nithin
Modified: 2018-10-29 18:27 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
ODT_File (13.59 KB, application/vnd.oasis.opendocument.text)
2018-02-28 11:36 UTC, Nithin
Details
PDF_File (12.29 KB, application/pdf)
2018-02-28 11:36 UTC, Nithin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nithin 2018-02-28 11:35:27 UTC
Description:
The behavior of the table and its rows/cells/columns when resize using mouse and/or keyboard key combinations should be revisited/re-planned. There are many improvements possible. As of now it is random and confusing. This can be verified using the attached odt file. The attached pdf file is what happens during resizing. However when the odt file is saved and reopened the table has what appears to be normal width.

Steps to Reproduce:
1.Using the mouse click on the last cell of the second row of the table.
2.Press  Shift+Alt+LeftKey 3 times. (This is a valid key combination as per Writer documentation page 285)
3. Make pdf or simply scroll up and down <-here is the error
4. Save document and reopen <- here everything seems normal again. 


Actual Results:  
The second row is longer than the rest. 

Expected Results:
The table width across all rows should remain constant.


Reproducible: Always


User Profile Reset: No



Additional Info:
The other problem is, when using this key combination i would expect the cursor to remain the same cell. However it moves to the left cell each time the key combination is used.

I am just wondering if the table behavior for each possible key/mouse combination is defined. If it is not yet defined, it would be better to redo it and standardize it from now. If a similar bug has not yet been reported then it would be be OK to change some behavior as well. 

The rest of the text in the odt file is present because I was documenting the behavior myself to update my answer on ask.LibreOffice.org.


User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Comment 1 Nithin 2018-02-28 11:36:15 UTC
Created attachment 140214 [details]
ODT_File
Comment 2 Nithin 2018-02-28 11:36:58 UTC
Created attachment 140215 [details]
PDF_File
Comment 3 Buovjaga 2018-03-10 13:43:35 UTC
(In reply to Nithin from comment #0)
> Actual Results:  
> The second row is longer than the rest. 

Repro, but not in 3.6.

Arch Linux 64-bit
Version: 6.1.0.0.alpha0+
Build ID: 22b1d4784d02070ae1933c59cf2c9bb5a5284773
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on March 10th 2018

Arch Linux 64-bit
Version 3.6.7.2 (Build ID: e183d5b)
Comment 4 raal 2018-03-19 18:06:27 UTC
This seems to have begun at the below commit.
Adding Cc: to Noel Grandin ; Could you possibly take a look at this one?
Thanks

0bf242133202f41361143a5508d1e981fc549411 is the first bad commit
commit 0bf242133202f41361143a5508d1e981fc549411
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Tue Apr 25 18:37:05 2017 +0200

    source sha:890d6790715c4c3f3565b476d538643f04dc6936

author	Noel Grandin <noel.grandin@collabora.co.uk>	2017-04-12 13:38:31 +0200
committer	Noel Grandin <noel.grandin@collabora.co.uk>	2017-04-13 08:48:23 +0200
commit	890d6790715c4c3f3565b476d538643f04dc6936 (patch)
tree	068639197df4994b2025cba2284686829a2aea1d
parent	5b6b0bb47aae0dfafb09f4ccf794a921e3717055 (diff)
convert TableChgWidthHeightType to o3tl::typed_flags
Comment 5 Adolfo Jayme 2018-03-20 11:09:51 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

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

tdf#16083 writer table resize behavior is random

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 6 Xisco Faulí 2018-10-29 18:27:03 UTC
Seem to be fine in

Version: 6.2.0.0.alpha1+
Build ID: 19a0698079fbba36646a2d06eaec3a7fde60b2f5
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: threaded

Closing as RESOLVED FIXED.
@Noel, Thanks for fixing this one!!!