Description: Impress: Shrinking table by dragging bottom border up or top down not working anymore Steps to Reproduce: 1. Open the attached file 2. Click on top and of the table and drag down.. or visa versa bottom up.. 3. Or pick a corner to shrink proportionally Actual Results: Not working Expected Results: Should be Reproducible: Always User Profile Reset: No Additional Info: Found in 7.2 and in Version: 7.1.0.0.beta1+ (x64) Build ID: f9fab4203c1aa0b9a3f27ce2713b6d5addc7df19 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: nl-NL Calc: CL
Created attachment 168787 [details] Example file
Fine in Version: 7.0.0.0.beta1+ (x64) Build ID: 2891e91a513520d68ea2b8c59c14335861a15253 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Confirmed, and bibisected to the 7.0 backport of the following commit using repo bibisect-linux-64-7.0. Adding CC: to Gülşah Köse. https://cgit.freedesktop.org/libreoffice/core/commit/?id=b7b05dd36403af50b20fe06cbf8a10d8defb28a9 author Gülşah Köse <gulsah.kose@collabora.com> 2020-11-06 21:18:24 +0300 committer Gülşah Köse <gulsah.kose@collabora.com> 2020-11-09 12:36:07 +0100 tdf#137949 Fix table row heigths.
Bumping priority Backport + common action + scope appears to be slightly larger bug 139690
*** Bug 139690 has been marked as a duplicate of this bug. ***
*** Bug 139793 has been marked as a duplicate of this bug. ***
Hello Gülşah. Can you please confirm if you'll work on this. Otherwise, I suggest a revert. This looks more visible than original bug. Thanks.
Hello, I'll work on all of my regressions as soon as possible. Please don't revert, If it's not really urgent. Thanks.
(In reply to Gülşah Köse from comment #8) > Hello, I'll work on all of my regressions as soon as possible. Please don't > revert, If it's not really urgent. Thanks. The bug pretty obvious and problematic. I personally think we say we schedule a revert after +/-20 days if no fix present by then. So we have or a revert or fix landing in 7.0.5 (and 7.1.1) But that's my take..
Thanks Gülşah. If all devs would follow, LO would be even better place. Feel free to take in accordance to other obligations. When a dev responds, no need for further push. Surely not urgent, just to land to 7.0.6 by April. I wish you good health and pleasant work.
Sorry for inconvience. @Timur Thank you so much for understanding.
Solution is on the way https://gerrit.libreoffice.org/c/core/+/110662
Gülşah Köse committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b6d53ce5359d4f41b9fece475339cdf63c5817e9 tdf#139511 Correct calculation of minimum row height during resize. 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.
Verified in Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: a5d68a4f959804f93ddda61a45cedaadb504e3f2 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @Gülşah Köse, thanks for fixing this issue!
Gülşah Köse committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/1fe55d946f8f2adf4a2588dcc7d089b79611eddd tdf#139511 Correct calculation of minimum row height during resize. It will be available in 7.1.2. 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.
Gülşah Köse committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/51e4f716ea8416a1a8d90f8063a51ad130bd1743 tdf#139511 Correct calculation of minimum row height during resize. It will be available in 7.0.5. 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.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3d25de5440d310cef6c0c256c64472a928e4cb90 tdf#139511: sd: Add UItest 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.
Xisco, thanks for the test. o/
Gülşah Köse committed a patch related to this issue. It has been pushed to "libreoffice-7-1-1": https://git.libreoffice.org/core/commit/edc5ea345446fc0ca484a9c854d65dc5c1a39793 tdf#139511 Correct calculation of minimum row height during resize. It will be available in 7.1.1. 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.
Created attachment 177516 [details] ABC3b.odp: same problem happens when cells are not empty The patches for these related bugs are all based on a false premise that empty cells are irrelevant to the row height. Most reproduction steps so far used empty tables as examples, but the same problem is seen when the cells are not empty, and that has not been fixed. Re-opening because the patches here don't actually fix anything - they just avoid the problem in certain situations and are causing bugs in others. I confirmed the same commit is responsible in this non-empty-cells case (as expected). I also confirmed the problem still exists in 7.4 master.
Hi Justin, Should we create a follow-up ticket instead of reopening this one after it was closed 1 year ago ?
(In reply to Xisco Faulí from comment #21) > Should we create a follow-up ticket instead of reopening this one after it > was closed 1 year ago ? Why open a new ticket when the original ticket wasn't fixed? None of the patches here are true fixes, and all of this needs to be reverted. -fake fix started by synerzip in 5.0 for bug 48047/80340 -reverted and "refixed" by Xisco in 5.2/5.1/5.0 bug 91762 -modified by Gulsah in 7.1/7.0.4 bug 137949/139511
I have a mass revert patch at https://gerrit.libreoffice.org/c/core/+/128376. Obviously since some of these have been in the product since LO 5.0, it wouldn't be very nice to actually push this unless those bugs are fixed properly, but I post it here for the record. It fixes this bug, and bug 144092.
I guess there should be reviewers at the patch,it just sits there.
(In reply to Timur from comment #24 who didn't read comment #23 :) > Obviously since some of these have been in the product since LO 5.0, it > wouldn't be very nice to actually push this unless those bugs are fixed > properly, but I post it here for the record.
I set this one to Highest because it's a described situation with multiple that should be resolved, by commitment to fix what may follow up.
I don't understand how it is possible that regressions like this wind up in released versions (let alone then remain unfixed for over a year). Is there no testing going on to make sure that every user action works as it's supposed to?