Description: Image moves the wrong direction (jump right when pressing down) Steps to Reproduce: 1. Open the attached file 2. Scroll to the last page 3. Select the image belleten" 4. Press arrow down twice -> image jump to the right Actual Results: Image moves to the right Expected Results: Down Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: 52820b52b3bca45e2db527d1cc5f4488b2e0b9d0 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 no repro with Version: 7.0.0.0.alpha0+ (x64) Build ID: 27aa4b16bf704d0246595750daf57b57ff2577b3 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
Created attachment 163349 [details] Example file ODT for export to DOC
Created attachment 163350 [details] Example file DOC exported with 7.1
The initial range is wrong (mixed doc/odt together) Pressing down working properly in 4.2 with the DOC file going wrong in 4.4.7.2
Bibisected with Linux 44max to https://git.libreoffice.org/core/commit/3c873206a9450058a11ab87cab5942d319c75c82 fix picture jumping to incorrect X position after dragging Adding Cc: to Luboš Luňák I just used the attached DOC when I tested. The image to be moved is Image24, which is the cover of a book with the title Belleten.
Dear Telesto, 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
repro 7.6+ I imagine the difference is some compatibility flag relating to wrapping, as well as having multiple flies to contend with when the anchor moves down to the next empty paragraph.
Reproduced with DOC exported with recent trunk build: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: fd69b546ad36452560cb11ccb28e78632d65f045 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Does not happen if saved as DOCX.
It think this is also a duplicate of bug 139232. The issue happens in all formats, but in this particular case, the DOC export filter changes some properties, e.g. the anchoring of drawing object "Şekil7" changes from "To Paragraph" to "To Character". There's likely various other changes happening, but can't pinpoint what exactly it is. In any case, one can test with: - save as DOC - save DOC as ODT - move the picture in that new ODT: also reproduced *** This bug has been marked as a duplicate of bug 139232 ***