Download it now!
Bug 56427 - UI Cell 'Background Colour' button retains colour of 'last picked' when 'No Fill' is selected
Summary: UI Cell 'Background Colour' button retains colour of 'last picked' when 'No F...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.6.2.2 release
Hardware: x86 (IA32) Windows (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-26 15:16 UTC by David Clayton
Modified: 2014-05-15 14:27 UTC (History)
4 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 David Clayton 2012-10-26 15:16:12 UTC
Steps:
1) On a new worksheet select a block of cells
2) 'Background Colour' Button - select a colour eg Blue
3) select a cell in the colour block
4) 'Background Colour' Button - select 'No Fill'
5) Select a blank cell in worksheet.
6) Behaviour: 'Background Colour' Button retains the 'Blue' colour indicator making the user believe that if the button is pressed, it will fill the cell with 'blue' (as it would had 'No Fill' not been last selected...it would still action a Blue fill)

Suggested behaviour - selecting 'No Fill' makes the 'Background Colour' Button indicator go transparent / white / or have a cross. This would give the user reassurance that the next 'press' of the button will action 'No Fill'.
Comment 1 David Clayton 2012-10-26 15:24:31 UTC
As a comparison, try two cells with text in each, use the change font colour button, change the colour, then go back and select 'Automatic' - Notice how the font colour button indicator goes transparent.
Comment 2 Julien Nabet 2012-10-28 10:25:34 UTC
On pc Debian x86-64 with 3.6 sources updated today, I don't reproduce this.
David: just for the test, could you give a try to prerelease 3.6.3 (see http://www.libreoffice.org/download/pre-releases/)?
Comment 3 David Clayton 2012-10-29 09:32:12 UTC
Tested and confirm that behaviour exists in 3.6.3.2 on Windows 7x32.
Comment 4 Julien Nabet 2012-10-29 21:43:46 UTC
Put back the original version when the bug has been found.
With Windows Vista and 3.6.2.2, I don't reproduce this.

Rainer: if you have some time, could you give it a try. I must be something (as some other bugs these days... :-()
Comment 5 David Clayton 2012-10-30 15:55:14 UTC
If its specific to Windows 7x32 - both of the machines tested are on SP1 and are fairly current with updates. Java version 7.9.
Comment 6 Winfried Donkers 2013-04-23 07:56:34 UTC
I confirm this bug with version 3.6.5 and 4.0.2 on Windows XP.
The bug only occurs with Windows, I cannot reproduce the behaviour with Linux.

When the last applied colour is 'no fill', the button shows the one before last applied colour, where it should show the last applied colour.

With Writer, this problem also occurs with background colour, but not with highlight colour.
Comment 7 Winfried Donkers 2013-05-02 10:47:21 UTC
(In reply to comment #6)
> When the last applied colour is 'no fill', the button shows the one before
> last applied colour, where it should show the last applied colour.
> 
> With Writer, this problem also occurs with background colour, but not with
> highlight colour.

The bitmap of the button does change, though, when 'no fill' is selected: the border of the colour area was the same colour as the area and after selecting 'no fill' the border becomes black, but the area keeps showing the last applied colour.
(Noted with version 4.0.3.2 on Wondows XP)
Comment 8 Maxim Monastirsky 2014-05-15 14:27:33 UTC
Can't reproduce anymore with the latest master under WinXP/Win7/Fedora. Feel free to reopen if you still able to reproduce the bug with master.