Created attachment 111058 [details] Example drawing showing the behavior There are issues using the alternative (non-default) rectangle tool when switching between a color of black and none. Note that this does not affect the standard "Rectangle" tool. Also, this bug does not trigger once the rectangle contains text. Enabling the drop-down rectangle tool: 1. Open a new drawing 2. Tools->Customize 3. Change the "Toolbar" to "Drawing" 4. "Add..." 5. Choose category of "Drawing" 6. Scroll down in the commands list and choose the SECOND "Rectangle" tool. It should have the description, "Using Customize Toolbar, you can add the Rectangles toolbar." 7. Close 8. OK You'll now find a second "Rectangle" tool which has a drop down arrow next to it. Rectangles created with this tool are different objects than those created with the normal tool. Steps to reproduce: 1. Create a rectangle with the Rectangle tool (that has dropdowns) 2. Change fill color to "Black" 3. Change area/fill style to "None" Expected: Since we changed the rectangle to have a fill style of "None," we should be presented with an empty rectangle with a line for the border. Actual: The rectangle still appears to be black. It will remain this way until we move the rectangle. It will print this way as well. 4. (Continued from above) Move the rectangle to force it to update and show the new area/fill style of "None." 5. Change Area/fill Style to "Color" 6. Change Area/fill Style to "Black" Expected: Since we changed the rectangle to have a fill style of Black, we should now be presented with a filled black rectangle. Actual: We still have a None-filled rectangle until we move it. I've created/attached an example document with instructions. I've also bibisected. It looks like it started with the release of 4.1: 5c854a34fd0d2bb0c91532cf1d9a5159a43538af is the first bad commit commit 5c854a34fd0d2bb0c91532cf1d9a5159a43538af Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Wed Oct 16 21:23:53 2013 +0000 source-hash-1e1ac3ba37de4aaab3e7fada378ecd73ee2f5b6c commit 1e1ac3ba37de4aaab3e7fada378ecd73ee2f5b6c Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Wed Apr 3 10:05:44 2013 +0100 Commit: Gerrit Code Review <gerrit@vm2.documentfoundation.org> CommitDate: Wed Apr 3 13:31:41 2013 +0000 Updated core Project: help 20791d487f493ddd008553e9970a622362ca546c :100644 100644 50f4e9ba75a25076a5a659c89956b7dc5b930c85 040fc36dba4cb2380296230ff43e6ee9eccbf1fa M autogen.log :100644 100644 8afbf12103205097dc861165f3fc33b56534aecd 64d261b4291fe444b80068efa8911fe6b2d62e7d M ccache.log :100644 100644 94797030ce621b2b1f2179bb58b897b0e5316ff5 0b4a914f04a25007e396a9398d9f1ccd2ff689d1 M commitmsg :100644 100644 dda43735ac46dbc495bf483190c59e72f83a5690 2258d830f9c06110ec7004b59574916d64024245 M dev-install.log :100644 100644 f343d6f041f52d1deff85ef3a61be8fab56aafc8 bfefb4eceaffb811fd32c0d72218e57a26e19dc7 M make.log :040000 040000 8e0cee8999d95df003047726bb95d9d171a48aa3 a49659521c914bc0c75affec1b7e1c4373849fe6 M opt $git bisect log # bad: [c2069a369d738078124812312d51f21ea1ce2421] source-hash-f160e4935c474a5293b3d3c11b3d538efb4767a0 # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'last41onmaster' 'oldest' # good: [5bac99c03c8d9c687c11c53285a65e79af6c8ef5] source-hash-20d4cd5e08c1400fcc5ae5eb45861f429b914969 git bisect good 5bac99c03c8d9c687c11c53285a65e79af6c8ef5 # good: [a6c846ef193b8c57600975a405db417d0563d04c] source-hash-f6b4d0313dbaf1089254a1bfae9ccfbc3f413eb3 git bisect good a6c846ef193b8c57600975a405db417d0563d04c # good: [d81a010b5434259b55e61f45bc43f54cd902aaae] source-hash-66a63c1608cfd5e755fb141b636e4a84c118179a git bisect good d81a010b5434259b55e61f45bc43f54cd902aaae # bad: [45d6280795d38765e03f65b7acfae97289b378b9] source-hash-fe46fc0f27ad5dac188517ff3f76bb1604aeeac1 git bisect bad 45d6280795d38765e03f65b7acfae97289b378b9 # bad: [d552e9efbcd48d39c795daaae1a1f2de189f35f6] source-hash-001da6553adfcb160a08225fdd6aea478bd7dea9 git bisect bad d552e9efbcd48d39c795daaae1a1f2de189f35f6 # good: [3337b34c1312516a3730d0b780b11fceaa632683] source-hash-54aafdb04cf36eb2b2ddbbc2030d298f514a00e9 git bisect good 3337b34c1312516a3730d0b780b11fceaa632683 # bad: [3142334d94a2c49f484453556493532e4a994002] source-hash-0644a20605965b36fcc983e4c1158820fd858726 git bisect bad 3142334d94a2c49f484453556493532e4a994002 # bad: [c4dc144d0650a2a89e870d4906a68db5b2bc6769] source-hash-ae2c256e228b3d4d01e85abdbc797a907c7f6563 git bisect bad c4dc144d0650a2a89e870d4906a68db5b2bc6769 # bad: [5c854a34fd0d2bb0c91532cf1d9a5159a43538af] source-hash-1e1ac3ba37de4aaab3e7fada378ecd73ee2f5b6c git bisect bad 5c854a34fd0d2bb0c91532cf1d9a5159a43538af # first bad commit: [5c854a34fd0d2bb0c91532cf1d9a5159a43538af] source-hash-1e1ac3ba37de4aaab3e7fada378ecd73ee2f5b6c
Since this is a regression, but not something that most people will run into often, I set a keyword of "Regression" and changed the severity to "High"/"Minor."
Note I have found this bug also occurs on the Ellipse tool (that has the pulldown selection) in the same exact way as on the Rectangle tool with pulldown. So might need to change subject of bug. Confirmed in LO 4.3 in RHEL 6. I agree the bug is obscure and won't affect too many people, but it DOES affect me, since I put both of those "pull-down" versions of Rectangle and Ellipse on my toolbar, replacing the primitive default ones. One might argue that these aren't needed anymore because of the "Basic Shapes" tool. But then I could argue that the default, regular ellipse and rectangle tools can ALSO be considered redundant because they also exist in the Basic Shapes tool.
Source bisection reveals only a mystery. I can reproduce that the problem goes away before the indicated commit in the bibisect repo, but when built from source, the supposedly good commit still shows the bug.
On the second attempt I got closer to this one and narrowed it down to a small number of hard-to-build commits. I'm 99% certain that of those which remain, the below commit is the one that changed the behaviour. Adding Cc: to thomas-libo@arnhold.org. Could you possibly have a look at this? Thanks commit f98bee58fbf1e4862477fb6aa014447746f1ef9d Author: Thomas Arnhold <thomas@arnhold.org> Date: Wed Apr 3 01:47:25 2013 +0200 fdo#62525: use cow_wrapper for SdrFillAttribute Change-Id: I827e1edb2c6ec2fc3e16fde6f105063e59d40f66
Matthew: Sorry, I have no time for this. Please revert my commit manually and see if the problem goes away.
The bug occurs with all filled polygons or filled curve, whatever the method used to create it: - either with method of comment 1 - or Toolbar Drawing > Curve (or Lines) > Curve filled, or Polygon filled or Polygon 45° filled or freeform line filled - or draw a regular shape (rectangle, ellipse, basic shapes...) right click > Convert > To polygon or To curve 1. Once your shape is created, it has now green handle. 2. Change fill color to black (NO bug with other colors). => OK the shape is correctly filled with black 3. Change filling to None => Bug: shape keeps its black filling 4. Click on black and drag the shape => When clicking on black, nothing should happen as there is no filling. But shape is moved. On release, filling is updated to none. You can no more click inside the shape 5. Change filling to Color, Black => Bug: shape stays without filling. You cannot click inside the shape 6. Move the shape => Black filling appears again NO bug if some transparency is defined. Bug appears only between these two states (None <=> Color Black). If you change .SOC file, so Black is no more the first color (such as html.soc), the bug is still only with Black color. It seems that LibO get confused between no filling and (0,0,0) as code color. Change can be made with toolbar, sidebar, or Format > Area dialog UI. My hand made bibisection revealed: - NO bug with LibO 4.0.6 RC2 - bug with Version: 4.1.0.0.alpha1 Build ID: 67ce08e2c64a6615abc90d3a3c442f90d86fa69 I enhance severity to Normal, as there is much more ways to be impacted by the bug. A simple case: open PDF with Draw with some checkbox. If you want to fill checkboxes with black, they appear empty.
Update summary in a more general way
Thorsten Behrens committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=551c204740a37c8dbc7acd35bc9fe683ade3fe80 Fix tdf#87509 - default sdr attribute is special object. It will be available in 5.0.0. 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.
Thorsten Behrens committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=39e83a2fb113961711424f0416d34e4443ccdf8c&h=libreoffice-5-0 Fix tdf#87509 - default sdr attribute is special object. It will be available in 5.0.0.0.beta2. 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.
Thorsten Behrens committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=daa47bd04a32fa278bd0e1f6aa098c939e9339c1&h=libreoffice-4-4 Fix tdf#87509 - default sdr attribute is special object. It will be available in 4.4.4. 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.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
*** Bug 90744 has been marked as a duplicate of this bug. ***