Description: Image refuses moving or jumps to unexpected position when attempting to move the image with arrow keys Steps to Reproduce: Created attachment 168488 [details] 1. Select image with green border and press arrow up (jump) 2. CTRL+Z 3. Select the image with red border and press arrow left (nothing happens) Actual Results: Jumps or refuses Expected Results: Should work more smooth (like 4.3 Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 7.2.0.0.alpha0+ (x64) Build ID: 315c7570c4a72f4c834086082825533b1e50d1bf 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 and in 4.4.7.2 but not in Version: 4.3.0.4 Build ID: 62ad5818884a2fc2e5780dd45466868d41009ec0
Created attachment 168492 [details] Bibisect log Bisected to: author Luboš Luňák <l.lunak@collabora.com> 2014-08-07 21:24:01 +0200 committer Luboš Luňák <l.lunak@collabora.com> 2014-08-07 21:46:51 +0200 commit 3c873206a9450058a11ab87cab5942d319c75c82 (patch) tree 080f74b74ea9cf7c239294235747dca531c5faba parent 5554be7f4cddcfeb450bfe41d0b588c8e8f6de76 (diff) fix picture jumping to incorrect X position after dragging If a picture anchored to character is dragged vertically, it can actually jump to the left, even though X should stay the same. This change basically reverts part of 5ddd93f4f90b3627a0ba63b62a5367c5e6c112a1. I haven't figured out how this GetBaseOfstForFly() actually works, but I'm reasonably sure that the relative X offset introduced by it in SwFlyAtCntFrm::SetAbsPos() is not undone anywhere in SwFlyFrm::ChgRelPos() or otherwise acted upon, it simply causes relative X position change, even though the absolute position remained the same. https://cgit.freedesktop.org/libreoffice/core/commit/?id=3c873206a9450058a11ab87cab5942d319c75c82
Anchor of image with green border is "To Paragraph"; anchor of amage with red border ist "To Character". If you change both anchors to "To Page" arrow keys work perfect. Anchors are the same in LO 4.3 (I can't test)? So I think we have differ between the characters and might have different expected results. Expected result for images with anchor to paragraph: UP / Down moves anchor one paragraph up / down (not sure about left / right arrow) Expected result for images with anchor to character Left / Right moves anchor one character left / right Up / Down moves anchor one line up / down cc: Luboš Luňák, because of comment 1
The problem is linked to the position and the wrap option of the first image, the one without colored border. If you move the first image down, then you can move both other images with the four arrow keys. If you change the wrap option of the first image from optimal to none, then you can move both other image with the four arrow keys. I think there is some contradictory constraints with the three images with wrap set to optimal and anchored to the same paragraph. Not sure if there is a bug there. Best regards. JBF
Definitely a regression here. In OOo 3.3 and LO 4.3.0.1, both images would react to arrow presses, in the right direction and with a sensible jump size. In a current trunk build, as described by Telesto: - arrow up (or down) on green picture jumps to right edge - arrow left on red picture does not move 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