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
Created attachment 140214 [details] ODT_File
Created attachment 140215 [details] PDF_File
(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)
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 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
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.
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!!!