Thanks for refiling.

I dug into this, and it appears that in Tahoe (versus Sequoia) the macOS [NSColor windowBackgroundColor] now reports FFFFFF (eg all white) while before it reported something like F7F7F7 (very light gray).

The OS X code in doUpdateSettings() passes that window background color to the global style settings with:

    aStyleSettings.BatchSetBackgrounds( aWindowBackgroundColor, false );

which then uses that color to set a couple things, including SetFaceColor(). Which makes a bit of sense, as "face" here likely means window backgrounds.

Then the toolbar button paints its background with RenderTools::DrawSelectionBackground(), which checks the face color like so:

    bool bBright = ( rStyles.GetFaceColor() == COL_WHITE );

and yes, since the face color is FFFFFF (white) this evaluates bBright to TRUE. 

DrawSelectionBackground() starts off using the hi light color as the button press color:

    // colors used for item highlighting
    Color aSelectionBorderColor(pPaintColor ? *pPaintColor : rStyles.GetHighlightColor());
    Color aSelectionFillColor(aSelectionBorderColor);

but later does this:

            else if (bBright)
            {
                aSelectionFillColor = COL_BLACK;

            ...

        rRenderContext.SetFillColor(aSelectionFillColor);

and that's how we end up with black.

In Sequoia, because the NSColor windowBackgroundColor is not quite white, we don't get to the same place.

I don't know how far back not-quite-white windowBackgroundColor goes in MacOS but probably a ways back. I can check on 10.5/ppc on Monday.

Patrick, any thoughts on what we should do here? I presume the bBright code is there for a reason... We just got tripped up by Tahoe again I guess?

(In reply to dcbw@libreoffice.org from comment #1)
> Patrick, any thoughts on what we should do here? I presume the bBright code
> is there for a reason... We just got tripped up by Tahoe again I guess?

Not sure if this is too hacky, but the following debug patch works in my local build without having to mess with the bBright code. Note: this bug doesn't appear in Dark Mode since [NSColor windowBackgroundColor] returns 0x1e1e1e:

diff --git a/vcl/osx/salframe.cxx b/vcl/osx/salframe.cxx
index ca5938b48431..5573984367e8 100644
--- a/vcl/osx/salframe.cxx
+++ b/vcl/osx/salframe.cxx
@@ -1628,6 +1628,9 @@ SAL_WNODEPRECATED_DECLARATIONS_POP
     Color aWindowBackgroundColor(getNSBoxBackgroundColor([NSColor windowBackgroundColor]));
     Color aUnderPageBackgroundColor(getNSBoxBackgroundColor([NSColor underPageBackgroundColor]));
 
+    if (aWindowBackgroundColor == COL_WHITE)
+        aWindowBackgroundColor = Color(0xf7, 0xf7, 0xf7);
+
     // Background Color
     aStyleSettings.BatchSetBackgrounds( aWindowBackgroundColor, false );
     aStyleSettings.SetLightBorderColor( aWindowBackgroundColor );

Created attachment 204938 [details]
LibreOffice 25.8.3 on macOS 26.2.

Created attachment 204939 [details]
LibreOffice 25.8.4 on macOS 26.2

I hope I am in the correct bug – to me it seems the problem runs much deeper than just some color setting. Updating from 25.8.3 to 25.8.4 (on the same machine without updating anything else, just checked it) breaks the UI completely, compare the attached screenshots (completely wrong styling of most UI components).

(In reply to Patrick (volunteer) from comment #2)
> (In reply to dcbw@libreoffice.org from comment #1)
> > Patrick, any thoughts on what we should do here? I presume the bBright code
> > is there for a reason... We just got tripped up by Tahoe again I guess?
> 
> Not sure if this is too hacky, but the following debug patch works in my
> local build without having to mess with the bBright code. Note: this bug
> doesn't appear in Dark Mode since [NSColor windowBackgroundColor] returns
> 0x1e1e1e:

Yeah I thought about something like this too, and that's probably what I'll end up going with. But I wonder if something in Tahoe changed WRT window backgrounds as materials instead of plain colors?

---

After staring at the code for a couple of days I think I have a better solution, which is to make the bBright code not check COL_WHITE but check GetHighContrastMode() instead which was its original intent.

> 
> diff --git a/vcl/osx/salframe.cxx b/vcl/osx/salframe.cxx
> index ca5938b48431..5573984367e8 100644
> --- a/vcl/osx/salframe.cxx
> +++ b/vcl/osx/salframe.cxx
> @@ -1628,6 +1628,9 @@ SAL_WNODEPRECATED_DECLARATIONS_POP
>      Color aWindowBackgroundColor(getNSBoxBackgroundColor([NSColor
> windowBackgroundColor]));
>      Color aUnderPageBackgroundColor(getNSBoxBackgroundColor([NSColor
> underPageBackgroundColor]));
>  
> +    if (aWindowBackgroundColor == COL_WHITE)
> +        aWindowBackgroundColor = Color(0xf7, 0xf7, 0xf7);
> +
>      // Background Color
>      aStyleSettings.BatchSetBackgrounds( aWindowBackgroundColor, false );
>      aStyleSettings.SetLightBorderColor( aWindowBackgroundColor );

(In reply to dcbw@libreoffice.org from comment #6)
> Yeah I thought about something like this too, and that's probably what I'll
> end up going with. But I wonder if something in Tahoe changed WRT window
> backgrounds as materials instead of plain colors?

From what I can see, the system color is retrieved in getNSBoxBackgroundColor() in vcl/osx/salframe.cxx. That was added before my time so I don't know why NSBox was used. I assume that it was a roundabout way to convert a catalog NSColor to an RGB color.

> After staring at the code for a couple of days I think I have a better
> solution, which is to make the bBright code not check COL_WHITE but check
> GetHighContrastMode() instead which was its original intent.

Your solution looks good to me and fixes the bug in my local build.