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.

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.

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.

That works fine (for me) with
LibO 3.6.0.0.beta3 (Build ID: 3e2b862)
on WinXP 32b (tested: Writer, Calc, Impress).

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.

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.

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.

(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.

(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) ...

(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)

(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 ... ;-)

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.

(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.

*** Bug 52135 has been marked as a duplicate of this bug. ***

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 ...

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.

Reproducable with LibreOffice 3.6.0.2 (=release candidate 2) (Build ID: 815c576).

(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;

(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.

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.

(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.

(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 ...)

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.

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.

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.

(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!

This looks sufficiently fixed now to me.

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

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!

"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.