Description: When a table is placed in a frame, there seems to be no way to drag the borders of the columns and rows to resize them as you can with a normal table. Steps to Reproduce: 1. Insert | Frame | Frame. Check relative to entire paragraph area. Width: 100%. Anchor: as character. (AFAICT none of these settings affect the bug.) 2. Click inside the frame. Table | Insert Table | 2 columns x 2 rows. 3. Try to hover the mouse over the line between the columns and the rows. It never changes to the resize arrow and therefore one cannot resize the columns or rows by dragging. Actual Results: Cursor never changes to the resize arrow. Expected Results: Cursor should change to the resize arrow. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Created attachment 190305 [details] Video demonstrating the problem Here's a video demonstrating the problem. The table outside the frame can be resized by dragging; the table inside the frame cannot be.
Created attachment 190306 [details] Gif video demonstrating the problem Here's that same video in gif format in case anyone can't view the webm format.
Tested with OpenSUSE 15.4 64bit rpm Linux and LO 7.6.2.1. Mouse changes here to resize the with of the columns and the height of the rows of a table in a frame. Might be a special Windows bug. Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 6; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded
Thank you for reporting the bug. I can confirm that the bug is present in Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 32; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7fff4e2ca6739928f72e5f0d2eb5820823916769 CPU threads: 32; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
I also reproduce this on Linux and already in 3.5.0. Workaround is right-click - Size and change height/width there.
(In reply to Buovjaga from comment #5) > I also reproduce this on Linux and already in 3.5.0. Workaround is > right-click - Size and change height/width there. Thank you and Steven for confirming. I don't know the criteria for classifying a bug's importance or whether it actually affects the likelihood of the bug being fixed, but I would say this is more than a minor problem, for one major reason: tables in frames are currently the *only* way to insert tables into footnotes. The proposed workaround is cumbersome and time-consuming, requiring multiple guesses to format the table properly. (A more reasonable workaround is to adjust the table outside of the frame, and then insert it into the frame, although this too is cumbersome, since it requires manually sizing the table to match the ultimate size of the frame in the footnote.) Until support for tables in footnotes is added, I would argue that this bug is at least of "normal" importance. Thank you again for your attention.
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b285cf49dffe8a74f0ba54b88b781db6a68a4f3b tdf#157833 tdf#155692 sw: fix hit area to resize row/col It will be available in 24.8.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.
Fixed in master, started backport to 24.2. @William Friedman, all: thanks for your bug report and feedback! Commit description: df#157833 tdf#155692 sw: fix hit area to resize row/col Fix 1) missing or too narrow hit area (tdf#157833), and 2) not recognized click inside hit area (tdf#155692). It was impossible or very hard to resize text table columns and rows using the mouse: 1) Double arrow, i.e. "resize row/col" mouse pointer shows the hit area of text table row/column borders. This was missing or was very narrow with normal zoom, because of an obsolete constant for low resolution displays. Change this constant used in IsSame() with scale-dependent values to support the same hit area on different zoom levels and with different screen resolutions. 2) Especially on bigger zoom, "resize row/col" mouse pointer, i. e. the visible hit area didn't guarantee drag & drop any more because of too small hit area in pixels in the svruler code base: clicking on not exactly center of the hit area resulted selection of cells or the cell content instead of drag & drop the border, violating WYSIWYG. Enlarge the default 1 pixel to 5 pixels to cover the whole hit area. Note: only for resizing table borders inside the document, not on the horizontal and vertical rulers.
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/03b53833c09a3870306034cd084f106d02966b34 tdf#157833 tdf#155692 sw: fix hit area to resize row/col It will be available in 24.2.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.