Download it now!
Bug 116083 - Table (and its row/columns/cells) resize behavior is random
Summary: Table (and its row/columns/cells) resize behavior is random
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
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:

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

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
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

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]
Comment 2 Nithin 2018-02-28 11:36:58 UTC
Created attachment 140215 [details]
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
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 (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?

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 <>	2017-04-12 13:38:31 +0200
committer	Noel Grandin <>	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":

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 in the next 24-48 hours. More
information about daily builds can be found at:

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

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

@Noel, Thanks for fixing this one!!!