1100401 - Dialog default button has invisible text / missing blue background until hovered

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect, P3)

Description

[Stefan Plewako [:stef]]

When recent nightly on OS X 10.10 asks about default browser, default action button looks strange, as on screenshot: https://bugzilla.mozilla.org/attachment.cgi?id=8523422

If I move cursor over it, button gets normal (blue) background at the white label text becomes readable.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Gijs, is this a known Yosemite issue?

Comment 2

[:Gijs (he/him)]

No, I didn't know about this. Not sure I can reproduce though - in my case, if the default browser prompt shows up, it is automatically focused, and the background of the button is always blue. Can someone provide more details about how to reproduce so that this isn't the case? Do you maybe have something like focus follows mouse or such turned on? I just tried in devedition (nightly is the default already on my yosemite machine, and I'm not aware of theming/widget differences with nightly as regards this issue), and can't reproduce.

Comment 3

[Bartosz Piec]

WFM on the latest nightly with Polish locale on Yosemite.

Comment 4

[Stefan Plewako [:stef]]

If I run "/Applications/FirefoxNightly.app/Contents/MacOS/firefox-bin -P nightly" in terminal, it launches nightly unfocused, behind terminal widow. Even if browser window gets (click on it, cmd-tab) focus (traffic lights have color) the dialog buttons remain as on screenshot.

Comment 5

[Stefan Plewako [:stef]]

It is also possible to get unfocused window while starting Firefox normally, just click somewhere during startup…

Comment 6

[Bartosz Piec]

Confirmed on non-focused Nightly window on Yosemite.

Comment 7

[:Gijs (he/him)]

Interestingly, if you cmd-tab there and back again, the issue disappears again. I'd love to use something like DOM Inspector to figure out what's going on, but if I use a commandline argument to start that on startup and then select DOM Inspector from exposé or by moving it so that I can focus it directly, focusing DOMI immediately fixes the issue as well.

From what I know of the CSS involved ( http://mxr.mozilla.org/mozilla-central/source/toolkit/themes/osx/global/button.css#21 ) it seems like :-moz-window-inactive isn't true when it should be in this case.

Markus, any idea what might cause that?

(FWIW, I do think this is a bit of an edgecase (how many people start Firefox in the background like this?), and it self-corrects, and likely never happens again after startup, so I'm not sure how much of a priority this should be... the only thing that makes this mildly more serious is that I suspect whatever the issue is may have a hand in things like bug 1056218 as well)

Comment 8

[Stefan Plewako [:stef]]

Attachment: 100401.png

Spotted another occurrence, after creating new profile in profile manager.

Comment 9

[Markus Stange [:mstange]]

We have some bugs about :-moz-window-inactive being wrong sometimes, or native-themed widgets looking wrong. I can't find any of them at the moment, though.

Comment 10

[Stefan Plewako [:stef]]

Modal dialogs after disabling e10s in preferences in nightly seem to be also affected.

Comment 14

[:Gijs (he/him)]

This isn't a strict dupe because it predates the regressor of bug 1106906, but it might get fixed in the same bug.

Comment 15

[Dietrich Ayala (:dietrich)]

Did bug 1106906 get fixed before branching? Would be a bummer if we shipped Firefox 37 with this regression.

Comment 16

[:Gijs (he/him)]

(In reply to Dietrich Ayala (:dietrich) from comment #15)
> Did bug 1106906 get fixed before branching? Would be a bummer if we shipped
> Firefox 37 with this regression.

No, but it just got uplifted. It would be good to see if this is fixed now, too.

Comment 17

[Stefan Plewako [:stef]]

I don't see this being fixed in nightly(20150126030202).

Comment 18

[:Gijs (he/him)]

Markus, do you have time to look into what's going on here, too? :-)

Comment 19

[Markus Stange [:mstange]]

I can't reproduce this. :(
If I do "/Applications/FirefoxNightly.app/Contents/MacOS/firefox -P", the profile chooser comes up, unfocused, with a white button and black text, as expected. If I focus the window, the button turns blue and the text turns white, also as expected.

Comment 20

[Stefan Plewako [:stef]]

Markus, did you try to create new profile?

Comment 21

[Markus Stange [:mstange]]

That did it! Thanks.

Comment 25

[Peter deHaan [:pdehaan]]

I can still reproduce this on FF Nightly 42.0a1 (2015-08-03) with the profile chooser dialog and OS X Yosemite (10.10.4).

Comment 26

[Lorenzo]

Found another case to reporoduce this bug, testetd with a blank Profile:

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:46.0) Gecko/20100101 Firefox/46.0

1. Open at least two tabs with the option "warn me when I attempt to close multiple tabs" enabled.

2. Focus any other window on your mac (not maximized, to be able to click the close button in step 3)

3. click the Firefox close button

4. Focus Firexfox

Bug-Result: The "close tabs" button has no blue background color as in hover-/focus-state but the font-color is withe insted of black as if the button would be hoverd/focused.

5. Focus any other window

6. Set your focus back to Firefox

Result: The button is now displayed properly


Printscreen-Note: The unfocused window is outgreyed

Btw: I can confirm the case in the Profile Manager described above.

Comment 27

[Lorenzo]

Attachment: 1_Screen Shot 2015-12-16 at 22.06.27.png

Comment 28

[Lorenzo]

Attachment: 2_Screen Shot 2015-12-16 at 22.07.01.png

Comment 29

[Lorenzo]

Attachment: 3_Screen Shot 2015-12-16 at 22.07.11.png

Comment 30

[Lorenzo]

Attachment: 4_Screen Shot 2015-12-16 at 22.07.26.png

Comment 36

[Markus Stange [:mstange]]

Attachment: Bug 1100401 - Keep the default button's background appearance in sync with the text color.

Review commit: https://reviewboard.mozilla.org/r/76394/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/76394/

Comment 37

[Markus Stange [:mstange]]

Sorry to everyone for letting this bug slide for so long. It's really quite embarrassing.

Comment 38

[Stephen A Pohl [:spohl] (OOO until 6/12)]

Comment on attachment 8787703 [details]
Bug 1100401 - Keep the default button's background appearance in sync with the text color.

https://reviewboard.mozilla.org/r/76394/#review74512

I had trouble repdroducing the issue locally, but the patch makes sense.

Comment 39

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b462b3ebc32c
Keep the default button's background appearance in sync with the text color. r=spohl

Comment 40

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/b462b3ebc32c