Description: When multiple collapsed groups exist within a spreadsheet and form controls or images are hidden within these groups, saving and reopening the file will cause these form controls or images to move down in rows or even disappear. Steps to Reproduce: 1. Group a few lines (select lines and press F12 or via Data->Group and Outline->Group) 2. Create a second group of lines after the first. 3. Add image or form control (e.g. checkbox) to second group 4. Anchor image or form control to cell 5. Collapse both groups 6. Save and exit Actual Results: On reopening of file: form control or image has moved down a certain number of lines. If it moved enough lines to exit the group it was in, it is no longer visible. Expected Results: Image or form control should remain anchored to the original cell. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.5.2.2 (X86_64) / LibreOffice Community Build ID: 50(Build:2) CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+wayland) Locale: de-DE (en_US.UTF-8); UI: en-US 7.5.2-1 Calc: threaded
Created attachment 186680 [details] Test Spreadsheet To test, open the file, collapse the groups and save. Reopen file and expand groups: Checkbox has moved from A4 to A6 Collapse Groups again and save. Reopen file and expand groups: Checkbox has moved from A6 to A10 Collapse Groups again and save. Reopen file and expand groups: Checkbox has moved from A10 to A16 Collapse Groups again and save. Reopen file and expand groups: Checkbox is gone. (It is actually in A30 but invisible.)
After some more testing it seems it isn't directly related to the use of groups but instead by hidden rows in general. If x amount of rows are hidden plus the row with the element itself while saving, after opening the element will have moved down by x rows.
Bibisected with linux-64-7.1 to 1cb6bb9576871ff5d56c9810ff1791abc3dd64fd tdf#117948 Do not treat hidden rows as zero in ODF export Repro also on Windows Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 3ec73488e447a693a14a773a7fb96938036c0324 CPU threads: 2; OS: Windows 10.0 Build 22621; UI render: default; VCL: win Locale: en-US (en_FI); UI: en-US Calc: threaded
I cannot reproduce the problem. Tested with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 4829a85d0753c93419bd46b1d50bcfa6f0f3f1da CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL threaded
This one is slightly tricky to reproduce. Please note the following detail. 1. Open attachment 186680 [details] from comment 1. On the left side, there are 2 groups marked with numbers (1, 2) tiny icons and with 2 "minus" tiny icons. 2. Press the _upper_ "minus" icon. The icon turns into a "plus" tiny icon. 3. Press the _lower_ "minus" icon. Both icons are now "grouped" as one "plus". 4. Save and close the file. 5. Open the file. Press on the "plus" icon, and then on the next "plus" icon. Note that there is no change in the location of the original "checkbox" in cell A4 in the main area. You can repeat the exact procedure several times, and there will be no change. STR: But... If you just invert the order at least once of those steps 2 and 3, then the "checkbox" will be moving down the column (seen after reopening and un-grouping). It is enough to invert the order once. The next times you repeat the procedure, you can do it in the same order as described above, and the "checkbox" will continue moving down each time you save, close and reopen the file. Similarly, it is enough to use the numeric tiny icons at least once (instead of the "minus" tiny icons), then save and close. When you open the file again, the "checkbox" shows up at a lower location in the column.
Thank you for the detailed description. I can reproduce the problem now. The Problem is not restricted to form controls but can be seen with ordinary shapes too. If the shape is hidden with collapsed bottom group, its position relative to the page is not adapted, when the top group is collapsed. The same problem exist, if you do not use groups but hide the rows manually. The same problem exist with columns. Unfortunately I have no idea yet how to fix it.
It seems to be a problem in ScXMLExport::WriteShapes() method. I have not yet a solution but will try to fix it.
Regina Henschel committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/800f9233513a45aa8f8950cf929fd44cb9381d72 tdf#154821 improve shape export with hidden row/col It will be available in 7.6.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.