Closed Bug 1100401 Opened 10 years ago Closed 8 years ago

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


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




Tracking Status
firefox51 --- fixed


(Reporter: stef, Assigned: mstange)


(Blocks 1 open bug)


(Keywords: regression, Whiteboard: tpi:+)


(6 files)

When recent nightly on OS X 10.10 asks about default browser, default action button looks strange, as on screenshot:

If I move cursor over it, button gets normal (blue) background at the white label text becomes readable.
Gijs, is this a known Yosemite issue?
Flags: needinfo?(gijskruitbosch+bugs)
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.
Blocks: theme-yosemite
No longer blocks: 1086958
Flags: needinfo?(gijskruitbosch+bugs)
WFM on the latest nightly with Polish locale on Yosemite.
If I run "/Applications/ -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.
It is also possible to get unfocused window while starting Firefox normally, just click somewhere during startup…
Confirmed on non-focused Nightly window on Yosemite.
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 ( ) 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)
Component: General → Widget: Cocoa
Flags: needinfo?(mstange)
Product: Firefox → Core
Version: unspecified → Trunk
Attached image 100401.png
Spotted another occurrence, after creating new profile in profile manager.
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.
Flags: needinfo?(mstange)
Modal dialogs after disabling e10s in preferences in nightly seem to be also affected.
Summary: Strange setDefaultBrowserConfirm button state before hover → Dialog default button has invisible text / missing blue background until hovered
Closed: 10 years ago
Resolution: --- → DUPLICATE
This isn't a strict dupe because it predates the regressor of bug 1106906, but it might get fixed in the same bug.
Resolution: DUPLICATE → ---
Depends on: 1106906
Did bug 1106906 get fixed before branching? Would be a bummer if we shipped Firefox 37 with this regression.
(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.
I don't see this being fixed in nightly(20150126030202).
Markus, do you have time to look into what's going on here, too? :-)
Flags: needinfo?(mstange)
I can't reproduce this. :(
If I do "/Applications/ -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.
Flags: needinfo?(mstange)
Markus, did you try to create new profile?
That did it! Thanks.
Assignee: nobody → mstange
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).
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.
Priority: -- → P3
Whiteboard: tpi:+
Sorry to everyone for letting this bug slide for so long. It's really quite embarrassing.
Comment on attachment 8787703 [details]
Bug 1100401 - Keep the default button's background appearance in sync with the text color.

I had trouble repdroducing the issue locally, but the patch makes sense.
Attachment #8787703 - Flags: review?(spohl.mozilla.bugs) → review+
Pushed by
Keep the default button's background appearance in sync with the text color. r=spohl
Closed: 10 years ago8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
You need to log in before you can comment on or make changes to this bug.