Bug 94319 - Copy/Paste of lines (and grouped object with lines inside) places the copy in unpredictable location
Summary: Copy/Paste of lines (and grouped object with lines inside) places the copy in...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
5.0.1.2 release
Hardware: Other All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 95833 (view as bug list)
Depends on:
Blocks: Paste
  Show dependency treegraph
 
Reported: 2015-09-17 18:22 UTC by MarjaE
Modified: 2019-12-07 03:43 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
One Document. (16.67 KB, application/vnd.oasis.opendocument.graphics)
2015-09-17 20:28 UTC, MarjaE
Details
test file analysing the problem (14.81 KB, application/vnd.oasis.opendocument.graphics)
2015-09-18 13:05 UTC, Cor Nouws
Details
Impress document to demonstrate the copy bug (38.86 KB, application/vnd.oasis.opendocument.presentation)
2015-11-17 15:31 UTC, bellgardt
Details
Test case (8.23 KB, application/vnd.oasis.opendocument.graphics)
2017-07-28 18:06 UTC, sergio.callegari
Details
Demo document fpr copy paste dosplacement of grouped objects (11.81 KB, application/vnd.oasis.opendocument.presentation)
2017-07-31 09:02 UTC, bellgardt
Details

Note You need to log in before you can comment on or make changes to this bug.
Description MarjaE 2015-09-17 18:22:08 UTC
Sometimes the copy appears directly on top of the original. Sometimes the copy appears at some distance, down and to the right. Sometimes the copy appears at such a distance, I have to scroll around to find it and drag it back.

I don't have any tips to reproduce this except to repeatedly copy and paste objects.

I have set a keyboard shortcut [command-d] to duplicate because it is more predictable than copy/paste, but it requires an extra dialogue box.
Comment 1 Cor Nouws 2015-09-17 18:43:06 UTC
Hi Marja,

Please try to give files with shapes to reproduce. If not: thanks for the effort, but it's not possible to fix anything, and we have to close as invalid.

Hope you understand.
Thanks - Cor
Comment 2 MarjaE 2015-09-17 20:28:41 UTC
Created attachment 118812 [details]
One Document.

I'm not sure why you're asking for a sample document. Doesn't this affect *every* draw document?
Comment 3 MarjaE 2015-09-18 00:21:05 UTC
After some more experimentation, it seems to be predictable, though still maddening.

If I copy and paste in affected files, the pasted object is placed about 50% farther from the upper left corner than the original object, and in the same direction as the original object.

If I copy and past in some other files, the pasted object is placed directly on top of the original object.
Comment 4 MarjaE 2015-09-18 00:28:06 UTC
If I paste objects from an affected file into a new file, and then copy and paste them again, they are moved away from the upper left corner, as I  described. If I paste objects from an unaffected file into that same file, and then copy and paste them again, they are placed directly atop the original.

In theory, if I recreated every single object from scratch, I might be able to work around this problem. But I'd rather have each object just behave normally.
Comment 5 Cor Nouws 2015-09-18 12:48:16 UTC
(In reply to MarjaE from comment #2)

> I'm not sure why you're asking for a sample document. Doesn't this affect
> *every* draw document?

Could be. Anyway, QA loves sample documents and useful descriptions as you've given in comment 3 ad 4 :) Thanks!
Will look at it.
Comment 6 Cor Nouws 2015-09-18 13:05:09 UTC
Created attachment 118823 [details]
test file analysing the problem

Hi Marja,

Please take a look at my file.
Do you think that it's correct to state that this is a problem with C&P of lines (and grouped object with lines inside)?
Comment 7 Cor Nouws 2015-09-18 13:07:29 UTC
No problem in 4.4.5.2, so a regression.
Comment 8 MarjaE 2015-09-18 15:56:05 UTC
(In reply to Cor Nouws from comment #6)
> Created attachment 118823 [details]
> test file analysing the problem
> 
> Hi Marja,
> 
> Please take a look at my file.
> Do you think that it's correct to state that this is a problem with C&P of
> lines (and grouped object with lines inside)?

Looks like it. Thank you. They aren't moving as far on your sample as they were on mine.
Comment 9 André Aichert 2015-10-29 10:14:48 UTC
Still reproducible. Both Draw and Impress.
Comment 10 bellgardt 2015-11-17 15:31:08 UTC
Created attachment 120597 [details]
Impress document to demonstrate the copy bug

I also observed the same bug in Impress and add this odp-document as another sample for completeness. All objects containing lines don't preserve their position after copy. But I didn't find any rules or the offset.
Comment 11 Cor Nouws 2015-11-23 09:22:01 UTC
*** Bug 95833 has been marked as a duplicate of this bug. ***
Comment 12 Cor Nouws 2015-11-23 09:22:49 UTC
See https://bugs.documentfoundation.org/show_bug.cgi?id=95833#c2

"However, I am possibly hitting the worst possible case of it, with objects getting pasted outside the drawing page and needing zoom out to realize that they got pasted."
Comment 13 James Murray 2015-11-30 16:02:04 UTC
I've hit this same bug too. It appears new as of 5.0.3.2, I was previously using a slightly earlier 5.0 release and doing lots of copy/paste and didn't observe it.

For me the pastes can appear wildly away from the current view, outside of the slide boundaries.
Comment 14 raal 2015-12-11 09:23:05 UTC
This seems to have begun at the below commit.
Adding Cc: to Caolán McNamara ; Could you possibly take a look at this one? Thanks

4a101ce68b02931a5486f32d1eb7acddbd13268d is the first bad commit
commit 4a101ce68b02931a5486f32d1eb7acddbd13268d
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Wed Jul 29 15:44:27 2015 -0700

    source sha:d1046e7c3f66e5f3384ee1ef534ef28346702fc6

    source sha:d1046e7c3f66e5f3384ee1ef534ef28346702fc6
	
	author	Caolán McNamara <caolanm@redhat.com>	2015-07-15 09:10:25 (GMT)
committer	Caolán McNamara <caolanm@redhat.com>	2015-07-15 12:11:14 (GMT)
commit	d1046e7c3f66e5f3384ee1ef534ef28346702fc6 (patch)
Resolves: tdf#63955 clip 19km long line to some sane limit

bibisect-win32-5.1
$ git bisect log
# bad: [a2ca6bb70db1ba8f306a617d92070351d9a3a624] source sha:8b5182155b6d35a1be64d37136584e30ea6a6ef8
# good: [c1efd324c6ad448ac9edb030dc9738b9e6899e4d] source sha:ab465b90f6c6da5595393a0ba73f33a1e71a2b65
git bisect start 'a2ca6bb70db1ba8f306a617d92070351d9a3a624' 'c1efd324c6ad448ac9edb030dc9738b9e6899e4d'
# skip: [1e602523875e23a7969d8c28276c82311eb2fa74] source sha:5b8e4f3d676eb0a026ce1eb4c1df2ec6e0736cb1
git bisect skip 1e602523875e23a7969d8c28276c82311eb2fa74
# good: [a83f3c3be6878a0416e48547e2ee1b40d616953f] source sha:aad27e89564752a2bee3da4558f4d276685ba50a
git bisect good a83f3c3be6878a0416e48547e2ee1b40d616953f
# skip: [55284040623ccb6b13d6254613f004becae9cff3] source sha:bd53697bab53d46df952eeb23b609c59adc330cc
git bisect skip 55284040623ccb6b13d6254613f004becae9cff3
# bad: [73fc8ee73c1c2ee0e85d4ba4f8059c64e6a7a69f] source sha:8cb1f9ac1ce90b324307711f752591a1acc9a6df
git bisect bad 73fc8ee73c1c2ee0e85d4ba4f8059c64e6a7a69f
# bad: [9a440205724ddea0a246ff448dd2b8ecb2a4fad9] source sha:c3a06bcac6536ccfcc49949492c98bfd82c68b52
git bisect bad 9a440205724ddea0a246ff448dd2b8ecb2a4fad9
# good: [5216590be93db937d9d6f5559d36dfad2b5856da] source sha:67941bd098dc8080c3381cf91aec12492656817e
git bisect good 5216590be93db937d9d6f5559d36dfad2b5856da
# good: [57f95b66c1608d57583558d48c922e9f0375f869] source sha:6793eaa4fa77292b23e9b86221e598f438d45b8e
git bisect good 57f95b66c1608d57583558d48c922e9f0375f869
# bad: [a3cbd1cecd6cb9bdc1dde91e5683636e6a517883] source sha:4ca2cf1b7e57c823e911bcbae0c87102a7c9851e
git bisect bad a3cbd1cecd6cb9bdc1dde91e5683636e6a517883
# good: [53cb97f01e82e20f0f444354ba7e65c878dfe424] source sha:7cedeaeba79bdd54b3bcbadb21c51cc535cf4a5d
git bisect good 53cb97f01e82e20f0f444354ba7e65c878dfe424
# good: [e413c6cb75514c79bdbab5b8309dfd376f6fb16f] source sha:2f0d1a23759c1b973593bfba642d01fb3df3c269
git bisect good e413c6cb75514c79bdbab5b8309dfd376f6fb16f
# good: [1b7a7177963a9ca57409400b74cd69cd8cd32f73] source sha:adfa89b5ffc3589b3a19a32e707a134cee232429
git bisect good 1b7a7177963a9ca57409400b74cd69cd8cd32f73
# bad: [0b898e7eebdd3e09fb176feb3fdd5dc7febeb2c2] source sha:d6790de07ff225f9e5b58152d01719e5fbe9e6cd
git bisect bad 0b898e7eebdd3e09fb176feb3fdd5dc7febeb2c2
# bad: [5f2b324761d1b07e78adc269f2fb796b1e3066d4] source sha:0789a1f8d62c2d9859f41473459252e706426c3a
git bisect bad 5f2b324761d1b07e78adc269f2fb796b1e3066d4
# bad: [4a101ce68b02931a5486f32d1eb7acddbd13268d] source sha:d1046e7c3f66e5f3384ee1ef534ef28346702fc6
git bisect bad 4a101ce68b02931a5486f32d1eb7acddbd13268d
# good: [31dd6c7fd2ee1ca25bb254d1ce18faf879d999b1] source sha:dffb58131f06fbe1aaeaa7b0d3ebe049d8384593
git bisect good 31dd6c7fd2ee1ca25bb254d1ce18faf879d999b1
# good: [01408893ffc11fbee6cd90dcc2e6d2ab679b4141] source sha:536051f8862203e0e115a5394a6379acd83cc8fe
git bisect good 01408893ffc11fbee6cd90dcc2e6d2ab679b4141
# first bad commit: [4a101ce68b02931a5486f32d1eb7acddbd13268d] source sha:d1046e7c3f66e5f3384ee1ef534ef28346702fc6
Comment 15 Robinson Tryon (qubit) 2015-12-13 10:30:19 UTC Comment hidden (obsolete)
Comment 16 Papipio 2016-07-23 05:32:07 UTC
Bonjour,

I have the same problem and because of that I loose much time (creating music scores ...).
Pasting a text zone is OK: the text is pasted just on the copied text and so easy to move horizntally or vertically. But, for example, a line seems to be pasted anywhere, sometimes even out of the page (!!), this is aberrant. There is no reason to paste an element anywhere else than to the position of the copied element.
There is no need for an example file, this is systematic.

And an element copied in one page must be pasted at the same position in another page.

I use LO 4.4.7.2 with Mageia Linux.

Pierre
Comment 17 Papipio 2016-07-23 05:37:15 UTC
Bonjour,

I have the same problem and because of that I loose much time (creating music scores ...).
Pasting a text zone is OK: the text is pasted just on the copied text and so easy to move horizontally or vertically. But, for example, a line seems to be pasted anywhere, sometimes even out of the page (!!), this is aberrant. There is no reason to paste an element anywhere else than to the position of the copied element.
There is no need for an example file, this is systematic.

And an element copied in one page must be pasted at the same position in another page.

I use LO 4.4.7.2 with Mageia Linux.

Pierre
Comment 18 Laurent BP 2017-07-28 16:06:25 UTC
NOT reproduced with:
- Version: 4.4.5.1
Build ID: 1b6df295803ea040dab1b48b5424da8d78d94cf0
Locale : fr_FR

Reproduced with:
- Version: 5.0.1.2
Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261
Locale : fr-FR (fr_FR)

NOT reproduced with:
- Version: 5.3.4.2 (x64)
Build ID: f82d347ccc0be322489bf7da61d7e4ad13fe2ff3
Threads CPU : 4; Version de l'OS :Windows 6.1; UI Render : par défaut; Moteur de mise en page : nouveau; 
Locale : fr-FR (fr_FR); Calc: group

==> works for me
Comment 19 sergio.callegari 2017-07-28 18:04:33 UTC
Still present in 5.4.0
Comment 20 sergio.callegari 2017-07-28 18:06:55 UTC
Created attachment 134948 [details]
Test case

Copy and paste arrow. At paste it appears at a position that is no more on grid.
Comment 21 Laurent BP 2017-07-28 18:37:33 UTC
Sorry, but I cannot reproduce the bug. My procedure:
- open attachment 134948 [details]
- clic on arrow
- Ctrl+C, Ctrl+V
I get two arrows exactly on the same place. My configuration:
Version: 5.4.0.3
Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c
Threads CPU : 4; OS : Windows 6.1; UI Render : par défaut; 
Locale : fr-FR (fr_FR); Calc: CL

@sergio: Could you detail your procedure?
Comment 22 sergio.callegari 2017-07-28 21:03:24 UTC
Arrow is at 49,28 mm (top left corner)

Copy, Paste

Copy of arrow is at 48,95, 28.05 mm

On 5.4.0.3 (from LibO DEB repo), Kubuntu Linux, LibO with KDE integration.

The fact that this issue is so erratic IMHO makes it even worse.

Ideally, objects should be pasted either in their original position or one grid step away from them (in case you want to make it more evident that a copy has been taken, to avoid users remaining with multiple copies of the same object stacked one onto the other).
Comment 23 bellgardt 2017-07-31 09:01:06 UTC
The test case now almost works form me in LO 5.4.0.3 (32-Bit-Version, Build-ID: 92c2794a7c181ba4c1c5053618179937228ed1fb) on Windows 7, 64bit, Intel System. The original arrow is at 4.9/1.8 cm, the copy at 4.9/1.81 cm.

But for grouped objects there is still a big displacement after copy pase (See following sample document). Left object: 6.34/8.85 -> 6.34/8.44 cm, right object: 15.54/8.04 -> 15.65/8.04 cm.
Comment 24 bellgardt 2017-07-31 09:02:26 UTC
Created attachment 135013 [details]
Demo document fpr copy paste dosplacement of grouped objects
Comment 25 Cor Nouws 2017-08-11 08:16:31 UTC
When I test attachment 118823 [details]  (from comment #6) it's obvious that there are only minor displacements in some situations, as bellgardt showed too.

This issue was about real huge wrong positions with lines/grouped objects.

So IMO we should close this issue as works for me, and open a new one with one or two test cases for the current problems.
Comment 26 sergio.callegari 2017-08-12 19:47:22 UTC
If you need grid aligment, it does not really matter if the skew is 0.1 mm or 20 cm. You'll need anyway to open a dialog and enter an on-grid position manually. For every paste action. Incidentally, whenever you build a diagram with connectors, you need accurate grid alignment otherwise the connectors will appear skewed. Hence, this issue is causing a degradation of the user experience for one significant usage case, drawings of diagrams using connectors, for which blocks are typically copied and pasted many times.
Comment 27 sergio.callegari 2017-08-12 19:50:51 UTC
In any case, it is definitely an option to open a new bug, possibly with a standard rather than major priority. Something like "copy+paste breaks objects alignment to grid requiring manual position editing".
Comment 28 Laurent BP 2017-08-12 21:42:18 UTC
(In reply to sergio.callegari from comment #26)
> If you need grid aligment, it does not really matter if the skew is 0.1 mm
For such application I would suggest Duplicate (Shift+F3) functionality: copies are placed as expected.
Comment 29 MarjaE 2017-08-12 22:20:03 UTC
On the Mac, it's Command-D. Shift-Fn-F3 is a contortion and isn't compatible with the Mac's version of Sticky Keys.
Comment 30 sergio.callegari 2017-08-12 22:44:38 UTC
No, really, it would be a weird flow...

Say you are building a diagram and you have like 5-7 different types of blocks and that altogether your diagram will include 30-100 blocks. The usual flow is to take them off a gallery and align them to the grid (because objects cannot be taken out of the gallery ready aligned to the grid) to then move them off the work area. Then you start building your diagram, copying the blocks you need where you think you need them and adjusting their positions with the arrow keys, so that they stay on grid until the result is visually pleasant.

Opening the duplicate dialog and editing it, in place of a CTRL-C, CTRL-V, some arrow key presses would be an overkill. Particularly if you need to place 100 objects overall from a set of 5-7 in positions you cannot exactly forecast in advance.

Incidentally, the 100 objects is the reason why having to re-adjust their position manually one by one is a big burden.

Now, all this is not unusual for those using LibO to design flowcharts (there are many galleries and templates of blocks, for it), or circuits (same) or logic circuits (same), etc.
Comment 31 QA Administrators 2018-11-15 03:43:17 UTC Comment hidden (obsolete)
Comment 32 bellgardt 2018-11-15 13:24:55 UTC
(In reply to QA Administrators from comment #31)
I tested the sample documents again using LO Version: 6.1.2.1
Build-ID: 65905a128db06ba48db947242809d14d3f9a93fe
CPU-Threads: 4; BS: Windows 6.1; UI-Render: Standard; 

Now several samples works for me. The test cases "One Document" and "test file ..." don't show any replacements after copy.

In "Impress document..." only the lowest object at the right side shows a  replacement from 15.1/13.52 to 14.99/13.51. 
"Test case" (demo.odg) has a replacement from 5.25/3.25 to 5.25/3.26. 
If the copied object is copied and inserted again, there a further replacements by 0.01 in x- or y-direction.  Is it by rounding errors? In any case I don't think is serious.

In "Demo doc...." (CopyPositionBug2.odp) the upper right object is moved from 12.24/3.64 to 12.31/3.64 and the lower left object from 5.34/8.85 to 6.34/8.45. The replace remains similar after pasted objects are copied and pasted again. In my opinion these big replacements are still bugs.
Comment 33 Lun 2018-11-29 09:46:05 UTC
Bug not reproducible in version 6.3.0.0.alpha0+ (x64)

Problem description: 
Copy-Paste displacement

Steps to reproduce:
1. Open "demo.odg" file from the attachment "Test case"
2. Copy the image
3. Paste

Current behavior:
The pasted image is exactly on the top of the original image.(No displacement)

Version: 6.3.0.0.alpha0+ (x64)
Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684
CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55
Locale: zh-TW (zh_TW); UI-Language: en-US
Calc: threaded

OS:Windows 10 Pro. 64-bit x64
Comment 34 bellgardt 2018-12-03 11:10:45 UTC
(In reply to Lun from comment #33)
> Bug not reproducible in version 6.3.0.0.alpha0+ (x64)
 Where can I get this version? On the server I only find 6.2-
Comment 35 Franklin Weng 2018-12-06 11:22:17 UTC
(In reply to bellgardt from comment #34)
> (In reply to Lun from comment #33)
> > Bug not reproducible in version 6.3.0.0.alpha0+ (x64)
>  Where can I get this version? On the server I only find 6.2-

https://dev-builds.libreoffice.org/daily/master/
Comment 36 QA Administrators 2019-12-07 03:43:02 UTC
Dear MarjaE,

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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug