Bug 51943 - OSX: Text color setting is broken
Summary: OSX: Text color setting is broken
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
3.6.0.0.beta2
Hardware: Other Mac OS X (All)
: high major
Assignee: Thorsten Behrens (CIB)
URL:
Whiteboard: target:3.7.0 target:3.6.0
Keywords: regression
: 52135 (view as bug list)
Depends on:
Blocks: mab3.6
  Show dependency treegraph
 
Reported: 2012-07-10 12:52 UTC by Florian Effenberger
Modified: 2012-07-25 08:49 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot showing the difference between colors in icons and text (54.81 KB, image/png)
2012-07-11 09:12 UTC, Petr Mladek
Details
MS Word 2010 (Starter) colour selectors (7.24 KB, image/png)
2012-07-11 13:01 UTC, Stefan Knorr (astron)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Effenberger 2012-07-10 12:52:53 UTC
Using writer, setting the text color is broken.

- Setting any text color other than the pre-defined red does not have any impact
- Removing the red text color does not work either

The same is true for setting the text background:

- Setting any background color other than the pre-defined yellow does not have any impact
- Removing the yellow text color does not work either
Comment 1 Roman Eisele 2012-07-10 14:09:47 UTC
REPRODUCIBLE with
* LibreOffice 3.6.0.0.beta3 (Build ID: 3e2b862),
* LibreOffice 3.6.0.0.beta2 (Build ID: f010139)
both with German langpack installed, on MacOS X 10.6.8 German.

Just create a new Writer document, type some text and try to set the text color and/or the background color. As Florian Effenberger wrote, it is not possible to set any other text color/background color than the pre-defined "Red" text color and "Yellow" background color (and even this does not work always in my tests). And if you have set the text color to Red or the background color to yellow you can't reset them to black and transparent respectively anymore.

Regression.
Comment 2 Roman Eisele 2012-07-10 14:24:44 UTC
Also reproducible with Impress (selecting a text color is impossible) and Calc (setting cell text and background color does not work anymore).

IMHO the complete color selection popup menu (the color table which pops up when you click on the arrow at the right side of the color control or do a long click on the color control) does not work anymore -- you can select any color, but nothing happens. Even selecting the two pre-defined emphasize colors (red for the text and yellow for the background) does not work anymore if you open the popup color table and then click on the color spec for red and yellow respecively; it works ONLY when I just make a single click on the color control itself, to select these pre-defined emphasize colors directly.

So, the bug is probably not in any of our main Components (Writer etc.), but in the code of the color selection control itself.
Comment 3 Nathan Wells 2012-07-10 14:33:43 UTC
I cannot duplicate this on Windows 7 64-bit LibO Version 3.6.0.0.beta2 (Build ID: f010139)

I can change color and everything fine.
Comment 4 manj_k 2012-07-10 14:43:44 UTC
That works fine (for me) with
LibO 3.6.0.0.beta3 (Build ID: 3e2b862)
on WinXP 32b (tested: Writer, Calc, Impress).
Comment 5 Niklas Johansson 2012-07-10 14:54:46 UTC
Cannot reproduce with LibreOffice 3.6.0.0.beta3 on Windows 7 (64 bit, Swedish). Swedish language pack.

Reproduced with LibreOffice 3.6.0.0.beta3 on Mac OS X 10.5.8
Not present in LibreOffice 3.5.4.
Comment 6 Petr Mladek 2012-07-11 09:03:44 UTC
I am able to reproduce this partly with Version 3.6.0.0.beta3 (Build ID: 3e2b862) on Linux (SLED11-SP1, x86_64, official upstream beta3 build).

I can change all colors in existing text. I am unable to change "highlighting" color for newly created text.

Steps to reproduce:

1. open new Writer document
2. select any "highlighting" color in the toolbar
3. write any text

Result: The background of the newly written characters is white

Expected result: The background of the newly written characters should be the 
                 selected color.


Observation: The toolbar icon shows the selected color in the box under the 
             picture. It shows yellow and ans some dark red by default even when
             it print black letters on white background.
Comment 7 Petr Mladek 2012-07-11 09:12:30 UTC
Created attachment 64100 [details]
Screenshot showing the difference between colors in icons and text

The text is black on white background. The icons suggest that it should be dark red on yellow background.

I wonder if it might help to unwind the whole mess.
Comment 8 Winfried Donkers 2012-07-11 09:26:32 UTC
(In reply to comment #6/#7)

I did some changes on the code this winter and changed the default colours of the buttons on request of Stefan Knorr.
The colours on the buttons are set to default colours or set to the last applied colour, which may be different than the text colour. This is done on purpose for the split button to have effect (apply default/last used colour directly).
Example: type 'long text' in black, select 'long' apply (background/highlight/font colour and 'long' gets that colour; when you place the cursor back after 'text' and continue typing, the text is black and the button stays you colour).

With Libo 3.6.0beta3 on WindowsXP I see no problems (although I did not test every button/colour/text combination).

I am willing to help/assist with this problem, but can only build with openSUSE (11.4/12.1) or test daily builds with Windows XP.
Comment 9 Roman Eisele 2012-07-11 09:34:26 UTC
(In reply to comment #6)
> I am able to reproduce this partly with Version 3.6.0.0.beta3 (Build ID:
> 3e2b862) on Linux (SLED11-SP1, x86_64, official upstream beta3 build).

So we have 
* a big bug on MacOS X (text/higlighting color changing
  almost completely broken),
* a small bug on Linux (unable to change "highlighting" color
  for newly created text),
* no problem at all on Windows?!

> Observation: The toolbar icon shows the selected color in the box under the 
>              picture. It shows yellow and ans some dark red by default even
>              when it print black letters on white background.

The same is true on MacOS X; just like on Petr's screnshot.


(In reply to comment #8)
> I did some changes on the code this winter and changed the default colours of
> the buttons on request of Stefan Knorr.
> The colours on the buttons are set to default colours or set to the last
> applied colour, which may be different than the text colour. This is done on
> purpose for the split button to have effect (apply default/last used colour
> directly).

Does this mean that Petr's observation is not a bug, but a feature? ;-)
OK, maybe this is even better, we just have to get used to it.
So let's concentrate on the indisputable bug(s) ...
Comment 10 Winfried Donkers 2012-07-11 09:55:44 UTC
(In reply to comment #9)
> So we have 
> * a big bug on MacOS X (text/higlighting color changing
>   almost completely broken),
> * a small bug on Linux (unable to change "highlighting" color
>   for newly created text),
> * no problem at all on Windows?!
I think the small bug on Linux is a feature too: The split button has three functions;
-when no text is selected, you can select a colour. the mouse cursor changes to a paint can (in Windows, my Linux machine here is building, which takes hours) and any selection you make will be coloured.
-give the selected text the default/last used colour (left side of button)
-give the selected text the colour chosen from the pallet (right side of button)
Comment 11 Roman Eisele 2012-07-11 12:41:08 UTC
(In reply to comment #10)
> I think the small bug on Linux is a feature too [...]

OK; so what is left seems to be yet another MacOS X-only problem.

@Thorsten Behrens:
This is yet another MacOS X-only bug, and you are our MacOS expert, therefore I add your address to the CC list of this bug. Please have a look at it, and please (I know there are many other bugs, I know ...) try to do it soon, because this is a really annoying regression which makes changing the text color or text highlight color impossible on MacOS X. It is embarrassing to ship 3.6 with such an obvious regression, so we should try to fix this soon.

@Winfried Donkers,
@Caolán, Cédric, Michael Stahl:
Please try to help Thorsten with this issue, if possible, because there are already so many MacOS X-only issues assigned or CCed to him (not to mention the Impress etc. issues) that he will hardly find time to fix them all ... ;-)
Comment 12 Stefan Knorr (astron) 2012-07-11 13:01:48 UTC
Created attachment 64106 [details]
MS Word 2010 (Starter) colour selectors

Just adding to comment 8 here:
Yes, what Petr observed is indeed intended as a time-saving feature with which you can quickly select a useful new text/highlight colour. This feature has also been available in MS Office for quite some time – see attached screenshot. There's one difference between LibreOffice and MSO, though, and that is that MSO doesn't preselect a new paragraph background colour – I'm not sure why.

(Yes, this means that the colour selectors aren't indicators any more, but then again, the actual (usually clearly visible) text/highlight colour should serve be the ultimate indicator.)

---

Regarding the "little bug on Linux" mentioned in the previous bug: that clearly is intended behaviour, although, I don't really know if it is still sensible – personally, I find the "paint can" mode rather counter-intuitive. In any case, it should be discussed in a different bug.
Comment 13 Winfried Donkers 2012-07-12 07:51:32 UTC
(In reply to comment #11)

> @Winfried Donkers,
> @Caolán, Cédric, Michael Stahl:
> Please try to help Thorsten with this issue, if possible, because there are
> already so many MacOS X-only issues assigned or CCed to him (not to mention the
> Impress etc. issues) that he will hardly find time to fix them all ... ;-)

@Thorsten:
If I can be of help, tell me. Unfortunately I do not have (access to) a MacOSX machine, I build on openSUSE.
Comment 14 manj_k 2012-07-16 20:52:27 UTC
*** Bug 52135 has been marked as a duplicate of this bug. ***
Comment 15 Michael Meeks 2012-07-19 16:16:29 UTC
Stephan - here is one that (I hope) is relatively simple, and is crying out for someone with a debuggable mac build :-)  if you're interested. It'd be nice to set the text color in writer on Mac for 3.6.0 ...
Comment 16 baifcc 2012-07-19 23:30:51 UTC
Wow, didn't expect so many replies.

Ever since Prelease 3.6 (beta to RC1), this bug seem to be reproducible on Mac version. for MSWIN version, and Linux version, we're OK.
Comment 17 Jorendc 2012-07-21 09:57:25 UTC
Reproducable with LibreOffice 3.6.0.2 (=release candidate 2) (Build ID: 815c576).
Comment 18 Jorendc 2012-07-21 09:58:22 UTC
(In reply to comment #17)
> Reproducable with LibreOffice 3.6.0.2 (=release candidate 2) (Build ID:
> 815c576).

I'm sorry, forgot the specs:

Mac OSX 10.7.4 Dutch; No language pack;
Comment 19 baifcc 2012-07-23 06:35:13 UTC
(In reply to comment #18)
> (In reply to comment #17)
> > Reproducable with LibreOffice 3.6.0.2 (=release candidate 2) (Build ID:
> > 815c576).
> 
> I'm sorry, forgot the specs:
> 
> Mac OSX 10.7.4 Dutch; No language pack;

Tested the same, Mac OSX 10.7.4 EN, No language pack.

LibreOffice 3.6 RC2, Mac Intel.
Comment 20 Thorsten Behrens (CIB) 2012-07-24 07:20:36 UTC
Some random findings so far:
* this is a focus problem - the popup window gets closed, because it's loosing
  focus when the click comes - _before_ the main loop even sees the mouse click
* the reason for loosing the focus is - keyboard focus is on the outer popup
  window, not on the inner SvxColorWindow_Impl one
* setting SAL_FLOATWIN_NOAPPFOCUSCLOSE=1 in the env cures the problem (by 
  preventing vcl mainloop to handle focus lost as a reason to close a popup)
* so does setting flag FLOATWIN_POPUPMODE_NOAPPFOCUSCLOSE at the float win

Setting hard focus to the inner window looks promising so far.
Comment 21 Thorsten Behrens (CIB) 2012-07-24 07:30:58 UTC
(In reply to comment #20)
> Setting hard focus to the inner window looks promising so far.
>
Or not. But I at least found a workaround for this bug - keyboard navigation works in the popup, i.e. you can move around via cursor keys, and select a color by pressing return.
Comment 22 Roman Eisele 2012-07-24 07:48:15 UTC
(In reply to comment #21)
> Or not. But I at least found a workaround for this bug - keyboard navigation
> works in the popup, i.e. you can move around via cursor keys, and select a
> color by pressing return.

Confirmed -- works fine for me. Good finding! (But I'm not sure if "ordinary" users will be happy when we force them to use the keyboard instead of the mouse ;-) So we still need a fix, but maybe not in 3.6.0, in 3.6.1 may be sufficient ...)
Comment 23 Not Assigned 2012-07-24 11:35:02 UTC
Thorsten Behrens committed a patch related to this issue.
It has been pushed to "master":

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

Fix fdo#51943 - prevent lose focus event to close popup.
Comment 24 Not Assigned 2012-07-24 11:41:09 UTC
Thorsten Behrens committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

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

Fix fdo#51943 - prevent lose focus event to close popup.


It will be available in LibreOffice 3.6.1.
Comment 25 Not Assigned 2012-07-24 15:48:39 UTC
Thorsten Behrens committed a patch related to this issue.
It has been pushed to "libreoffice-3-6-0":

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

Fix fdo#51943 - prevent lose focus event to close popup.


It will be available already in LibreOffice 3.6.0.
Comment 26 Roman Eisele 2012-07-24 16:02:52 UTC
(In reply to comment #25)
> Thorsten Behrens committed a patch related to this issue.
> It has been pushed to "libreoffice-3-6-0": [...]
> It will be available already in LibreOffice 3.6.0.

@Thorsten:
Wow, thank you very much for fixing this and pushing it even to 3.6.0! So even our initial 3.6 release will look much better. I am eager to confirm that everything works again ... Thanks again!
Comment 27 Thorsten Behrens (CIB) 2012-07-24 16:07:54 UTC
This looks sufficiently fixed now to me.
Comment 28 Thorsten Behrens (CIB) 2012-07-24 16:10:08 UTC
To document that here as well - this regression was caused by the fix for bug 48096 which in turn fixed a regression caused by toolbar-decorations-svx.diff
Comment 29 Roman Eisele 2012-07-25 06:09:35 UTC
VERIFIED/FIXED with LOdev 3.7.0.0.alpha0+ (build ID: c549e1e; installation file: master~2012-07-25_02.21.07_LibO-Dev_3.7.0.0.alpha0_MacOS_x86_install_en-US.dmg).

Works fine in latest master build on MacOS X 10.6.8 (Intel). Thank you again very much for fixing this!
Comment 30 Roman Eisele 2012-07-25 08:49:04 UTC
"Assigned" this bug posthumously to Thorsten Behrens who fixed it:
(a) to honor the merits of fixing it,
(b) in order to make it easier to find experts for that kind of problem.