Description: Anchors interacting with each other Steps to Reproduce: 1. Open the attached file 2. Select the image on the second page 3. Press arrow up 4. Image moves to third page 5. Press arrow up 8-10 times -> image back to page 2. 6. Press arrow down until positioned 7. File reload 8. Save as DOCX 9. File reload 10. Move the image up with arrow -> now it works Actual Results: Fuzzy, contrary logic to produce the intended result Expected Results: More behavior like RTF/DOCX Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 7.1.0.0.alpha0+ (x64) Build ID: 8700bace8c0714d853f5df6918ab9c8bb3d81f77 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 3.3.0
Created attachment 164652 [details] Example file
Delete the image on the third page and the problem goes away
Telesto, unfortunately nothing has happened with this bug report for more than half year. So I'd like to ask, if it is still valid. Could you please try to reproduce it with the latest version of LibreOffice? => NEEDINFO
Dear Telesto, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Still present Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: d5e55d204b71710eb5eb5d2c683dd6698626df3c 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
Dear Telesto, Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ? You can install it alongside the standard version. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
Dear Telesto, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp
Still around Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: c1c8ce3b0f1037bca4d500af2f39363cd9d38db6 CPU threads: 8; OS: Mac OS X 12.3.1; UI render: Skia/Metal; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
I confirm, that there is a problem, but it is different from what is described in original bug report. For example saving as docx and reloading doesn't sole the problem. So I would focus this report to the first problem described in comment 0 Steps: 1. Open attachment 164652 [details] 2. Select image on second page and press arrow up Actual result: Image jumps to second page Expected result: Image moves up Do you agree, Telesto? Version: 7.4.3.2 (x64) / LibreOffice Community Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL
Please be more specific about what is the expectation here. The image has non-trivial anchoring/positioning settings: to character, with offset relative to whole paragraph, vertically offset by 13.18 cm. When you press the arrow up key, what specifically should be the user expectation? a) anchor moves up, positioning does not change. This would not move the picture at all in this case, because the positioning is relative to paragraph; moving the to-character anchor one line up would still keep the anchor paragraph the same, so position would stay. Only multiple arrow ups would eventually move the anchor to the previous paragraph, with a big jump of position (because now it's relative to the new paragraph). b) positioning changes, anchoring stays. This would often cause surprise, because if you keep the anchoring, it could not move to another page, because an object is always on the same page as its anchor. c) both anchor and positioning change. Then how? Given the immense flexibility of the options, allowing you to create very powerful layout, how should we change them simultaneously when user does this press, in a sensible way? What happens now it the anchor moves near the current object position, and the position moves up - but now the object is part of another paragraph, the one below the previous anchor paragraph; it results in some complex re-arrangements, leading to the *whole paragraph* moving to the next page, and the object naturally follows (its not what the bug claims: not the image moves down, but the paragraph moves down). Without some real work on specifications how all this should be arranged together, it's impossible to "fix" this (well, maybe the jump of the whole paragraph looks strange - needs investigation, but that's unrelated to the key press itself, just the final anchoring/positioning combination).
Help says: "You can move an anchor or, keeping other object constraints in mind, position an object relative to the anchor's reference point by dragging the object."[1] I understand it in that way, that after moving up with arrow key or by dragging, anchor (to character) is still connected with the same character, while only position of object changes. But Anchor changes in current document (works as expected with image on page 1) [1] https://help.libreoffice.org/7.4/en-GB/text/swriter/guide/anchor_object.html?&DbPAR=WRITER&System=WIN
(In reply to Dieter from comment #13) > I understand it in that way, that after moving up with arrow key ... First of all, you can't read a text that only mentions dragging, as if it discusses anything related to keyboard movement ;) No, the help does not discuss keyboard at all. And also it explicitly mentions movement of the anchor; so I can't see how could that be read as if it guaranteed fixed anchor and changing position...
(In reply to Mike Kaganski from comment #14) > (In reply to Dieter from comment #13) > > I understand it in that way, that after moving up with arrow key ... > > First of all, you can't read a text that only mentions dragging, as if it > discusses anything related to keyboard movement ;) No, the help does not > discuss keyboard at all. You're right, but behaviour with draging is in this case the same. > And also it explicitly mentions movement of the anchor; so I can't see how > could that be read as if it guaranteed fixed anchor and changing position... Yes, but it implicitly mentions movement of the object: "position an object relative to the anchor's reference point by dragging the object." So my questions are: Do you agree, that different result between moving image on page one and image on page two indicates a bug? What is your expected result, if you select an image and press arrow key up?
(In reply to Dieter from comment #15) > Do you agree, that different result between moving image on page one and > image on page two indicates a bug? No. A bug (likely) is movement of the paragraph when the anchor moves into it, but it is unrelated to the different outcome of "moving image on page one and image on page two". It is some kind of layout problem likely. > What is your expected result, if you select an image and press arrow key up? My expected result is fixes of bug 141161 and bug 141162. That would mean that user can control what moves. Before that, I don't see how could anything be changed in a sensible way. After that, we can e.g. specify that arrow movement affects anchor, and arrow with some modifier affects positioning.
*** Bug 145592 has been marked as a duplicate of this bug. ***