Bug Hunting Session
Bug 45260 - EDITING: Pasted object not same position w.r.t. original object if border thickness greater 0
Summary: EDITING: Pasted object not same position w.r.t. original object if border thi...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
3.5.0 Beta1
Hardware: All All
: medium major
Assignee: Muthu
URL:
Whiteboard: target:3.7.0 target:3.6.0.2 target:4....
Keywords: regression
: 51150 51260 (view as bug list)
Depends on:
Blocks: mab3.5
  Show dependency treegraph
 
Reported: 2012-01-26 01:11 UTC by Joel
Modified: 2014-06-22 13:39 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample Document (18.49 KB, application/vnd.oasis.opendocument.chart)
2012-04-20 01:41 UTC, Rainer Bielefeld Retired
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joel 2012-01-26 01:11:37 UTC
When I copy and paste an object, I expect the pasted object to be in the same positionas the original. This, however, is not true if the object's border has a thickness greater than 0.

To reproduce: Draw an ellipse, set border thickness e.g. to 1.00 cm, then copy/paste and the pasted object will be pasted with a shift of -0.5cm/-0.5cm.

(It's trivial, but this was always one detail why I liked OO/LibO so much more than MS products, so I file it as a minor bug.)
Comment 1 pafal 2012-02-23 01:37:12 UTC
The same behaviour in 3.5.0rc3. Copy/paste moves the pasted object although the snap to grid is ON.
Comment 2 Rainer Bielefeld Retired 2012-04-20 01:40:23 UTC
[Reproducible] with "LibreOffice 3.5.2.2 German UI/Locale [Build-ID: 281b639-6baa1d3-ef66a77-d866f25-f36d45f] on German WIN7 Home Premium (64bit):

1. open attached "BUGTEST3.odg" 
2. Click one of the yellow thick lines
3. <control+x> for cut
4. <control+v> for paste
   Expected: now line is at the same place as before
   Actual: for me some mm shifted to left and some mm to top

Same in Current 3.6 Master

Works fine with 3.4.5, so REGRESSION.

[Reproducible] with server-Installation of  "LibreOffice 3.5.0 Beta1 - WIN7 Home Premium (64bit) German UI [Build-ID: 7362ca8-b5a8e65-af86909-d471f98-61464c4] Windows_Release_Configuration  11-Dec-2011 06:51" 

Still worked fine with 3.5.0 Beta0


AFAIR in that area we had the fix for Bug 42227. I have a very vague suspect that the problem might be related to the commit.

For some use this might be a minor problem, but for many others (like mine) it makes DRAW unusable, for example if you create complex objects by copy 7 paste / rotate / flip or if you simply want to get the object into a different layer and and and ...

@Radek:
Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug
Comment 3 Rainer Bielefeld Retired 2012-04-20 01:41:21 UTC
Created attachment 60369 [details]
Sample Document

See Comment 2 how to use!
Comment 4 Rainer Bielefeld Retired 2012-04-20 01:42:10 UTC
Version due to research results
Comment 5 Rainer Bielefeld Retired 2012-05-29 23:27:24 UTC
We need a fix!
Comment 6 Björn Michaelsen 2012-05-30 01:10:41 UTC
regression against 3.4, needs a bibisect.
Comment 7 Roman Eisele 2012-05-30 01:42:30 UTC
(In reply to comment #6)
> regression against 3.4, needs a bibisect.

Maybe not necessary: according to comment #2, it "worked fine with 3.5.0 Beta0", but according to comment #4 (both by Rainer), 3.5.0 Beta 1 is broken; so the regression must have been introduced with Beta 1.
Comment 8 Roman Eisele 2012-05-30 01:54:12 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > regression against 3.4, needs a bibisect.
> 
> Maybe not necessary: according to comment #2, it "worked fine with 3.5.0
> Beta0", but according to comment #4 (both by Rainer), 3.5.0 Beta 1 is broken;
> so the regression must have been introduced with Beta 1.

Sorry, forget my comment! I just wanted to emphasize that the range of commits to check can already be narrowed by the relatively short timeframe from beta 0 to beta 1, because I thought that it was easy to miss this little, but important point.
Comment 9 Rainer Bielefeld Retired 2012-05-30 02:22:45 UTC
Please never change NEW to NEEDINFO! 
<https://wiki.documentfoundation.org/QA-FAQ#How_to_use_Status_or_Keyword_NEEDINFO>

Again and again I stumble upon bugs where no bugfix progress is coming, seems because developers see NEEDINFO and think no action is required until status is back to NEW (may be because queries are used that sort out NEEDINFO bugs or whatever else). 

Of course there is some sense in "redirecting" a Bug from the direct bugfixing process to an additional QA loop for bibisect or similar, but before that is common sense, has been announced, added to the manuals and so on this ded-end-street-danger is too big.

And BTW, I can reproduce the problem with LibO 3.5.3.2 on Ubuntu Linux 12

My Bibisect knowledge is not very up to date, I alos doubt that we really have Bibisect Versions between 3.5.0Beta0 and Beta1 (where the bug appeared due to Comment2)? It seems <https://wiki.documentfoundation.org/Bibisect> is not up to date concerning available versions? And concerning <http://dev-builds.libreoffice.org/bibisect/>?
Comment 10 Björn Michaelsen 2012-05-30 02:50:54 UTC
@Rainer: NEEDINFO makes a lot of sense when additional info can be provided by non-developers (which is a bigger crowd) to keep devs on the bugs that need direct code manipulation (and we also have enough of those). If you want to metadiscuss this, lets do on the qa mailing list, NOT in the bug. However, I dont think we need to tie down such common sense in documentation -- it will just scare away newcomers.

Anyway, 3.5 Beta1 is before 3.5 branchoff, so a bibisect might help as Beta0->Beta1 seems small enough, but its still 696 commits.
Comment 11 Björn Michaelsen 2012-05-30 05:18:19 UTC
38 commits in sd, most related to impress210
Comment 12 Muthu 2012-06-19 03:29:33 UTC
giving this one a try...
Comment 13 Muthu 2012-06-20 02:44:40 UTC
Odd...the width of the line is lost if an object is copied from draw and pasted to impress....
Comment 14 Radek Doulik 2012-06-20 02:51:32 UTC
might be regression of BorderLine changes when BorderLine2 API was introduced. I fixed similar problem recently with http://cgit.freedesktop.org/libreoffice/core/commit/?id=ea923cd424f6426d69a7fb375f5ac9e19ec2246a
Comment 15 bfoman (inactive) 2012-06-20 07:46:03 UTC
*** Bug 51260 has been marked as a duplicate of this bug. ***
Comment 16 Cor Nouws 2012-06-20 15:04:12 UTC
(In reply to comment #15)
> *** Bug 51260 has been marked as a duplicate of this bug. ***

My analyses was simple: the X-pos and Y-pos are reduced with half the line width.
Comment 17 Cor Nouws 2012-06-20 15:07:54 UTC
(In reply to comment #14)
> might be regression of BorderLine changes when BorderLine2 API was introduced.
> I fixed similar problem recently with
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=ea923cd424f6426d69a7fb375f5ac9e19ec2246a

Look forward to test this.

I also noticed that with the export to .png (I did not test others) a line width > 0 results in a different position in the resulting graphic. 
Did not test this thoroughly by now, but from my head, I think that in that case, the X-pos and Y-pos are increased with half the line width..
Comment 18 bfoman (inactive) 2012-06-20 15:25:02 UTC
*** Bug 51150 has been marked as a duplicate of this bug. ***
Comment 19 Rainer Bielefeld Retired 2012-07-01 07:45:50 UTC
Cann't see any NEEDINFO requirement.

I was not able to reproduce png observations in Comment 17  with "LibreOffice  3.5.5.2.  German UI/Locale [Build-ID: 24b32b4-b87ec2e-85c8e98-87a4e20-9a1b8c1] on German WIN7 Home Premium (64bit)
Comment 20 Muthu 2012-07-11 10:00:53 UTC
Debugged this problem:
Copy uses BoundRect() 
http://opengrok.libreoffice.org/xref/core/sd/source/ui/view/sdview2.cxx#133
while Paste uses SnapRect()
http://opengrok.libreoffice.org/xref/core/sd/source/ui/view/sdview3.cxx#631
And both have a comment warning it shouldn't be changed to other :(
[But, changing one of them to use common Rect() fixes the issue]
Comment 21 Not Assigned 2012-07-12 13:46:23 UTC
Muthu Subramanian committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e647cc9d895005c5bed2fec98c73ca28ccd925ae

fdo#45260: Objects having line thickness misplaced while pasting.
Comment 22 Muthu 2012-07-12 13:49:58 UTC
Decided to revert the affected commit partially to fix this as
http://cgit.freedesktop.org/libreoffice/core/commit/?id=e647cc9d895005c5bed2fec98c73ca28ccd925ae

Can somebody verify this, please? Thank you!
Comment 23 Rainer Bielefeld Retired 2012-07-14 16:49:19 UTC
Works fine during a quick test with attached sample document (and new DRAW document) and with parallel installation of Master "LOdev " 3.7.0.0.alpha0+   - WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 25608fb]" (tinderbox: 2008R2@20, pull time 2012-07-14 00:31:17)

Can we get tht for 3.6?
Comment 24 Not Assigned 2012-07-16 10:05:35 UTC
Muthu Subramanian committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c35c4769d8cabe0f01ef9911056d7a9d1d2f4b04&g=libreoffice-3-6

fdo#45260: Objects having line thickness misplaced while pasting.


It will be available in LibreOffice 3.6.
Comment 25 Muthu 2012-07-16 10:19:07 UTC
[Fridrich helped cherry pick this to 3.6, so it should be available there. Thanks!]

Resolving this fixed.
Comment 26 pafal 2014-05-07 08:56:04 UTC
In reaction to the bug hunting session, I have tried the very long term bugs still present in OO/LO. This is one of them. Using the release version 4.2.2.1, this bug appears again! It even does not matter if the border thickness is greater than or equal to zero:

- start LO
- draw a rectangle
- select it
- ctrl+c
- ctrl-v (the copied object becomes selected)
- check position and size (both position coordinates are at 0.01 offset)
Comment 27 Joel Madero 2014-05-07 17:45:34 UTC
Please don't reopen really old bugs that have been closed for a long time as fixed. Instead report a new bug. Thanks
Comment 28 Commit Notification 2014-05-09 20:49:55 UTC
Andras Timar committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=de8f5f2af78877bc63b462195ce63341f6ba7817

Revert "fdo#45260: Objects having line thickness misplaced while pasting."



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 29 Commit Notification 2014-05-15 11:51:02 UTC
Andras Timar committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1677cffc602e15968ffb76ee0d5fd0ebcdac6b3c&h=libreoffice-4-2

Revert "fdo#45260: Objects having line thickness misplaced while pasting."


It will be available in LibreOffice 4.2.5.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 30 Cor Nouws 2014-06-22 13:39:10 UTC
OK :)