Insert a form control and open the Control Properties dialog. Go to 'Anchor' field on tab 'General'. This field has two items: "To page" and "To cell". Problems: (A) That was correct in times of OpenOffice.org but is no longer correct for LibreOffice. LibreOffice has the three anchor types "To page", "To cell" and "To cell (resize with cell)". This are available in the 'Anchor' item in the context menu of a form control. (B) The item "To cell" is actual a "To cell (resize with cell)" but users do not know that. So they might try to force a size protect of the form control by the option "Size protect" in the "Position and Size" dialog. But that leads to inconsistent file markup. For details see the discussion in bug 154821 and my repair instructions in the ReleaseNotes 7.6. There are two ways to fix the problem: Remove the item from the Control Properties dialog or extend the item in the Control Properties to three entries. At least the text of the item should be changed to "To cell (resize with cell)".
The default is "To Page" so any renaming confusion requires some intentional adjustment before. However, I don't see what is resizing; in fact it appears to stick to the cell on insert row/col while otherwise To Page makes the form control sticky at the position. Ultimately I see no issue from UX POV.
(In reply to Heiko Tietze from comment #1) > Ultimately I see no issue from UX POV. The item "To cell" in the Control Properties dialog make the same as the "To cell (resize with cell)" item in the anchor list in the context menu. That is confusing and needs to be fixed. The UX question is, how to fix it: (a) Only rename "To cell" to "To cell (resize with cell)" in the Control Properties dialog. (b) Change the Control Properties dialog so that is has the same three options than the 'Anchor' item in the context menu. (c) Remove the 'Anchor' item in the Control Properties dialog.
(In reply to Regina Henschel from comment #2) > The item "To cell" in the Control Properties dialog make the same as the "To > cell (resize with cell)" item in the anchor list in the context menu. That > is confusing and needs to be fixed. "To Cell" does the same as "To Cell (Resize)" (I insert a checkbox into a cell and expect this form control to size with the cell; but it only moves on insert row/col). > (a) Only rename "To cell" to "To cell (resize with cell)" in the Control > Properties dialog. > (b) Change the Control Properties dialog so that is has the same three > options than the 'Anchor' item in the context menu. > (c) Remove the 'Anchor' item in the Control Properties dialog. My first choice would be c) since anchoring is not an intrinsic property (you also do not attach the anchor property to an image). But in this case we have to do the same on other modules too, meaning the anchor for forms in Writer.
(In reply to Heiko Tietze from comment #3) > "To Cell" does the same as "To Cell (Resize)" (I insert a checkbox into a > cell and expect this form control to size with the cell; but it only moves > on insert row/col). You are right. I inspect the object with the Development Tools and see 'Cell object' in Anchor and false in 'Resize with cell'. So that has been changed from older versions. But when you save and reload the file the anchor type is changed to "To Page". So there is something wrong with the 'Anchor' option in the Control Properties. That would speak for removing it there. The anchoring types persist, when they are set from the 'Anchor' item in the context menu.
(In reply to Heiko Tietze from comment #3) > > (c) Remove the 'Anchor' item in the Control Properties dialog. > My first choice would be c)... (In reply to Regina Henschel from comment #4) > That would speak for removing it there. Seems we are in agreement - and no one else hollered in. Let's remove the anchoring from the object properties and keep it only at the (general) object attributes.
Dear Regina Henschel, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
The solution has been to remove the item, but that is still not done. Tested in Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b1c0c4838d2e006ffa8e72516569ce8d13bdbe01 CPU threads: 32; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: threaded