Bug 128654 - EDITING: textboxes not pasted on the same position
Summary: EDITING: textboxes not pasted on the same position
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4 all versions
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2019-11-07 16:38 UTC by Xisco Faulí
Modified: 2019-11-08 08:56 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Xisco Faulí 2019-11-07 16:38:13 UTC
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
Comment 1 Xisco Faulí 2019-11-07 16:40:30 UTC
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
Comment 2 Xisco Faulí 2019-11-07 16:42:25 UTC
For the record, it doesn't happen with shape 1
Comment 3 Miklos Vajna 2019-11-07 17:33:23 UTC
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?
Comment 4 Miklos Vajna 2019-11-07 17:37:11 UTC
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. ;-)
Comment 5 Xisco Faulí 2019-11-08 08:56:45 UTC
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