Steps to reproduce: 1. Open attachment 153993 [details] from bug 127412 2. Select shape 3 3. Ctrl + X 4. Ctrl + V -> The shape is not pasted on the same position. Pasting it again would paste it in the same position. Reproduced in Version: 6.4.0.0.alpha1+ Build ID: 498c2d3944b666c2f016b65903001920db2cb2a4 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=9835a5823e0f559aabbc0e15ea126c82229c4bc7 author Miklos Vajna <vmiklos@collabora.co.uk> 2014-10-04 19:37:55 +0200 committer Miklos Vajna <vmiklos@collabora.co.uk> 2014-10-04 20:18:01 +0200 commit 9835a5823e0f559aabbc0e15ea126c82229c4bc7 (patch) tree 12b77a17bf437e248ef02cc06634ab1dc458a99c parent ad5e8b30ac66a00d0110fcdaf4d064181247585b (diff) sw textboxes: reimplement ODF import/export Bisected with: bibisect-44max Adding Cc: to Miklos Vajna
For the record, it doesn't happen with shape 1
Hmm, do you have a strong view on this? :-) Here is what I see. Writer has two rules in action here: 1) If you cut a shape and paste it, the anchor of the pasted shape will be changed according to where is the blinking cursor by the time you do the paste. 2) If you delete a shape, the cursor will be relocated to the document model position which is closest to the x,y position of the shape which is deleted or cut. Now, with these rules in mind, here is what happens in the non-textbox case (shape with simple text): you cut the shape, 2) figures out that the empty paragraph at the top left corner is the only valid doc model position, so places the cursor there. You paste and 1) figures out the anchor should be where the cursor is, which is (in this case) same as what was before the cut. Here is what happens in the textbox case (shape with complex text): you cut the shape, 2) figures out that "shape 2" has a Writer paragraph in it, which is the closest doc model position to the (now cut) shape, and relocates the cursor there. Then 1) decides the pasted position the same way: this means that the position is more towards the left and bottom edge of the document, since the x and y pos of the shape 2 text and the body paragraph is not the same. In short: in the past rule 2) was not relevant (editeng text positions are not considered on shape cut) and position was determined according to 1). Now 2) is relevant and applied, so the effect of 1) is different. I can "fix" this "regressions" by not allowing the cursor to jump to an in-textbox Writer paragraph on shape cut, but then somebody will say that: in the past 5 years, rule 2) was respected in the context of textboxes as well, and now this is broken. So I'm leaning towards this is not a bug. Does that make sense?
Forgot to add: you can get the old behavior easily without a code change: manually change the cursor pos to be in the body text after cut. If I make that the default, I somewhat break rule 2), which is working correctly today, and this has been the case since 2014. I.e. we have conflicting requirements here, and I'm not really sure it makes sense to re-visit how this resolution is made given that there is no clear good and bad answer here -- my take would be that if this is already a bit non-intuitive, then don't make the situation worse by choosing a different, yet similarly non-optimal other resolution. ;-)
Hi Miklos, Thanks for the great explanation. Now I have a better understanding on how the positioning after pasting works. As you said in comment 4, the issues described is not reproducible if the cursor is changed. Besides, as you also said, changing its behaviour might lead to other complains from users used to the current behaviour. Happy to close this as RESOLVED NOTABUG