Created attachment 74776 [details]
When copying shapes from one drawing to another using the clipboard, colors of the shapes are changed as illustrated in the screencast: http://youtu.be/cT4xWtDoJVo
This happend on Fedora17+updates running XFCE.
Version: Version 220.127.116.11.alpha0+ (Build ID: 9601a571d42b0199bdccf2256fc8be82e14af8a)
Date: Fri Feb 22 23:19:22 2013 +0200
Bodhi Linux 2.2
Major (loss of data)
Medium (default is high, downgraded to medium as there is an easy workaround just setting the color again)
5655f1571312ca27537c9c147c69d6431986b76d is the first bad commit
Author: Bjoern Michaelsen <firstname.lastname@example.org>
Date: Tue Dec 11 08:13:31 2012 +0000
Author: Markus Maier <email@example.com>
AuthorDate: Thu Nov 29 16:10:23 2012 +0000
Commit: Caolán McNamara <firstname.lastname@example.org>
CommitDate: Thu Nov 29 17:35:25 2012 +0000
add sort tab page .ui
:100644 100644 7a4fdcf1d95f530a3149d02b8fe7971875973e76 42f18f15fb3370ca3f85d6a637b17ae05b10996f M autogen.log
:100644 100644 5f05b5eaceb8a57fa910addc049fe1ff83b05b8a 820b9e1d79db3dba2880de552a311faa29bbf809 M ccache.log
:100644 100644 613cffd64bfbd22a56a066164e70370f23603226 8a6e4f4cb7119b66a81a7c836167c86a3bc97882 M commitmsg
:100644 100644 70bef30ec00af18be350b77f58e9c5bf02a109b4 2482442714ae1b18d33e19012abd7640f509afb4 M dev-install.log
:100644 100644 709b8855043c670f0ccb34fe1427dccea58ff66a 95a1b31e755e1b56e4b0dc135d0b2769194481b9 M make.log
:040000 040000 0e347c259b7b09c8cdb9b92ea62838dd657d0fb7 2ce4b89c04c797a3f31ec93b5ce499f4d0c9abd4 M opt
# bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# good: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c
git bisect good 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9
# good: [f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a] source-hash-a581d31b227623e09d2970a91214fda398f98eda
git bisect good f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a
# good: [114fd3b76bcba890e6d702d00cef910f1493c262] source-hash-64ab96cd15e52da88781e720d6f031dbcd0ba902
git bisect good 114fd3b76bcba890e6d702d00cef910f1493c262
# good: [47498a36f7af8f54e6e3dda89cd4708802a409e6] source-hash-19f4ebd8a54da0ae03b9cc8481613e5cd20ee1e7
git bisect good 47498a36f7af8f54e6e3dda89cd4708802a409e6
# good: [66083171ba534818399937597388d325091fffab] source-hash-9d83ad0e99ab182506be99f7d6a2bec7f6fbe8c6
git bisect good 66083171ba534818399937597388d325091fffab
# bad: [8407d6926d9fa83ebbd8e03de319ea63df131753] source-hash-3d4288c1c0b593421c7f6619c88584bdb7c53337
git bisect bad 8407d6926d9fa83ebbd8e03de319ea63df131753
# good: [ec7d01ea25190e36518df830ed84b791b2417e2e] source-hash-c33019b36d613f951787ce9836e34d74bfbd6a1b
git bisect good ec7d01ea25190e36518df830ed84b791b2417e2e
# bad: [5655f1571312ca27537c9c147c69d6431986b76d] source-hash-b67a51b40a4876f4bd97a2917103112006710b0c
git bisect bad 5655f1571312ca27537c9c147c69d6431986b76d
@Clemens - when you report bugs please (even for incredibly simple bugs) write out steps how to reproduce in an easy to read method, makes it much easier for QA to work and much easier for devs to see the issue.
@Joel: Thats why I added the video. instead of complex textual description, its easily understandable what I did and what happend watching the video.
Previously I filed bugs with textual descriptions - which caused confusion. Textual description can be interpreted in many different ways...
Thanks for bisecting :)
I can confim this on Libre Office V18.104.22.168.
The colours change between copying from one drawing and paste it into another one. I have to copy and paste a very big block diagram into a new form.
Unfortunately large parts of the drawing are change the color. Outline blue (!) and black to grey e.g.
Perhaps the fill color will be mixed with the line-colour? Wrong size/handling of the colourtable? Maybe this helps.
Libre Office 3.6.6 is not affected by this bug. This is a regression between LibO 3.6 and 4.0.
One thing I have discovered:
After copy and paste in libO 4.0.x the color has changed. If I correct this manually and save the file, close LibO, reload the new saved drawing and copy and paste it into a new drawing the colors does NOT change anymore.
Is this a bug with the embedded color palette between different LibO-Series?
The bug is also reproducable in Libre Office V4.1.0 beta 1.
The regression here is because we have changed the default background color of a shape (from light blue to darker blue).
The underlying cause is that styles are matched only by name on pasting (at least in Draw/Impress. I am not sure how Writer handles it). Because every drawing has a style named Default, it is used even if it is not the same as the Default style in the the original drawing.
So, this is not really a regression, because it has always been broken. The brokenness is just more visible now.
Actually this is only part of the picture. The second part, reported in bug#62175, is that custom styles are not copied with shapes, only with whole slides.
Retested, persisting. Adjusting hardware to all since reported on Linux and now reproduced on OSX.
Freeing bug since it has been assigned for over 2 years. David, retake if you still want to work on this.
Build ID: e07ffae5046e9c91ef96026435cab84c3bcb4534
CPU Threads: 4; OS Version: Mac OS X 10.11.3; UI Render: default;
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2016-02-08_23:39:45
Locale: de-DE (de.UTF-8)
Whiteboard:bibisected is Keyword:bibisected now.
Regression introduced in range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=c33019b36d613f951787ce9836e34d74bfbd6a1b..b67a51b40a4876f4bd97a2917103112006710b0c
still confirm for example from attach, but if i'm copying shape between two drawing in modern version of LO there isn't that problem.
Dear Clemens Eisserer,
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!