Closed Bug 1100401 Opened 5 years ago Closed 4 years ago

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

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla51
Tracking Status
firefox51 --- fixed

People

(Reporter: stef, Assigned: mstange)

References

(Blocks 1 open bug)

Details

(Keywords: regression, Whiteboard: tpi:+)

Attachments

(6 files)

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.
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/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.
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 ( 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)
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.
Duplicate of this bug: 1108394
Summary: Strange setDefaultBrowserConfirm button state before hover → Dialog default button has invisible text / missing blue background until hovered
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1106906
Duplicate of this bug: 1110815
This isn't a strict dupe because it predates the regressor of bug 1106906, but it might get fixed in the same bug.
Status: RESOLVED → REOPENED
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/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.
Flags: needinfo?(mstange)
Markus, did you try to create new profile?
That did it! Thanks.
Assignee: nobody → mstange
Status: REOPENED → ASSIGNED
Duplicate of this bug: 1127950
Duplicate of this bug: 1147350
Duplicate of this bug: 1175284
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.
Duplicate of this bug: 1179185
Duplicate of this bug: 1179725
Duplicate of this bug: 1271253
Duplicate of this bug: 1206761
Priority: -- → P3
Whiteboard: tpi:+
Duplicate of this bug: 1292210
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.

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

I had trouble repdroducing the issue locally, but the patch makes sense.
Attachment #8787703 - Flags: review?(spohl.mozilla.bugs) → review+
Pushed by mstange@themasta.com:
https://hg.mozilla.org/integration/autoland/rev/b462b3ebc32c
Keep the default button's background appearance in sync with the text color. r=spohl
https://hg.mozilla.org/mozilla-central/rev/b462b3ebc32c
Status: ASSIGNED → RESOLVED
Closed: 5 years ago4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
You need to log in before you can comment on or make changes to this bug.