Created attachment 161751 [details] Anchored image bug test data. 01=before, 02=after Reproduction procedure (attached ImageAnchorTest01.ods is a readymade sample): (1)In the middle of an .ods sheet, paste an image. Set its anchor mode to "To Cell". (2)Choose a destination column which is in the lefhand side from the image. We'll call this "Destination". (3)Resize the source or destination column's width to make their width's different from each other. (4)Select another column(s) and copy or cut it. We'll call this "Source". (5)Select the destination column and paste into it. Result: Calc does adjust the destination column width to the source width. The images on the righthand side of the destination column should shift their X-coordinate for the same amount. But the current version has a bug that they stay on the same X-coordinate, which means they now anchor to a different position inside the cell, or worse, stuck to another cell. Attached ImageAnchorTest02.ods demonstrates how it moves (or rather, "fail to move when it should"). Reprducibility: 100%
I can confirm the error. I make column B must wider than usual. Then I copy column K to B. The column width of B shrinks to adapt to the content. The image is not moved and is in an inconsistent state. The anchor of the image is still at E2 but the image is drawn at cell I2. I have tested it with Version: 7.0.0.2 (x64) Build ID: c01aa64b6c3d89ebe5fe69c28c7adb24eb85249c CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Raster; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL
Dear zzz, 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
Tested with Version: 7.4.1.2 (x64) / LibreOffice Community Build ID: 3c58a8f3a960df8bc8fd77b461821e42c061c5f0 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: en-US Calc: CL Result: Problem remains with same symptom. Additional observation: (A). After step (5), if you immediately perform another width change on any column (for example, make column M wider), then the image will jump to the "correct" (expected) position. (A-2). Same "jump" is observed if you change the height of any row (for example, make row 9 wider). (B). But if you save the file immediately after step (5), the "wrong" position will be saved. So when you re-open that saved file, the image is still on the "wrong" position. The image stays there even if you make column M wider; unlike above test (A), it will not "jump back" to the expected position no more.