https://bugs.documentfoundation.org/show_bug.cgi?id=170120

--- Comment #1 from [email protected] <[email protected]> ---
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?

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to