User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:35.0) Gecko/20100101 Firefox/35.0 Build ID: 20140918030202 Steps to reproduce: Went into fullscreen mode, moved the mouse to the top of the screen to see the titlebar. Actual results: Menu and titlebar slide down, but the titlebar has no background. The window controls and text are still visible. See attached screenshot. Expected results: A grey background should be behind the titlebar text / controls. This has been happening for about a week on Nightly, haven’t had time to test older builds but I will do if no-one else can reproduct. I’m running Yosemite Public Preview 3 (14A361p) on a mid-2012 Macbook Air (11").

For what it's worth, this started happening in Yosemite DP7 (build 14A343f). It doesn't happen in DP6 (build 14A329f) or earlier. So this is very likely to be an Apple bug.

> So this is very likely to be an Apple bug. We'll still have to work around it, though. Especially since it doesn't appear to effect Safari or Chrome.

I disagree it is a duplicate of 1070664 which I submitted. This bug describes only a transparent styling problem. The problem is more severe. I wasn't able to return out of fullscreen mode and had to kill the browser. Similar in styling different in function.

I'll get to this eventually. But in the meantime, do you have any idea what might be going on here, Markus?

Not really, no.

I just updated to build 14A329f of Yosemite. No issue with Firefox titlebar becoming transparent now. Maximize button is working. Interestingly after I leave fullscreen mode the window buttons look cut in half. When I hover over window buttons they appear as expected.

Updated to 14A379b build if 10.10. The same issue. Firefox version: 34.0a2 (2014-09-30)

[Tracking Requested - why for this release]: Serious visual and/or functional issues on 10.10, rumored to be released in October. (In reply to andoriyu from comment #10) > Updated to 14A379b build if 10.10. Is this the GM candidate that Apple released yesterday, or not yet?

>Is this the GM candidate that Apple released yesterday, or not yet? No, it's Beta 4.

The GM candidate is build 14A379a. I’m on Beta 4 which is build 14A379b, so I guess that’s basically the same but developer / public? Either way, I’m still getting the same issue (as per comment #10) in the latest Nightly.

I just tested in the GM candidate (build 14A379a) and this bug is still there. And yes, the closeness of the build numbers suggest that the differences between the GM candidate and Beta 4 are trivial. Like I said above, I'll get to this when I can ... but it won't be before next week. Fixing this will require considerable skill at reverse engineering -- to find out what Apple's bug is and how to work around it.

I wonder if this has to do with NSWindow's titlebarAppearsTransparent as "documented" on page 121-123 of this massive PDF (sorry, Apple's decision, not mine): http://devstreaming.apple.com/videos/wwdc/2014/220xx01yweszmjv/220/220_adopting_advanced_features_of_the_new_ui_of_os_x_yosemite.pdf

I wonder if it's related, but sometimes my title bar gets stuck in slide-down position until I click something on it.

(In reply to comment #15) It's possible. Thanks for mentioning it. That info may be useful when I get to this.

This is definitely an Apple bug, and still happens in Yosemite GM Candidate 3. But I think I've found a way to hack around it. I'll say more next week, and hopefully post a patch. > I wonder if this has to do with NSWindow's titlebarAppearsTransparent No, as it turns out. But your suggestion got me to search through a class-dump of the AppKit framework for "transparent", which (after some trial and error) allowed me to figure things out.

All windows on all versions of OS X have a "frame view" -- a single NSView containing the entire frame, including the titlebar and its contents. It's always the superview of the "content view" (-[NSView contentView]). On Yosemite the frame view (via the NSThemeFrame class) has two new properties (titlebarView and titlebarContainerView), which are used to display the titlebar in fullscreen mode. Both of these objects can be "transparent" or not. In Safari they're not. But in Firefox (for some reason) they are, and that is what causes this bug. My workaround is to make sure they're not transparent in Firefox in fullscreen mode. I've started a set of tryserver builds: https://tbpl.mozilla.org/?tree=Try&rev=f4da6ff224e4

Comment on attachment 8504315 [details] [diff] [review] Fix/workaround Landed on mozilla-inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/4734fcb664c9

Steven, is this upliftable to early beta, or is that too scary?

> Steven, is this upliftable to early beta, or is that too scary? I don't think it's particularly scary, but I'd prefer to wait a few more days (until Monday or Tuesday of next week) to request uplift for beta and aurora. But by waiting will I miss an important "release"?

(In reply to Steven Michaud from comment #23) > > Steven, is this upliftable to early beta, or is that too scary? > > I don't think it's particularly scary, but I'd prefer to wait a few more > days (until Monday or Tuesday of next week) to request uplift for beta and > aurora. > > But by waiting will I miss an important "release"? Nope! Beta 2 go to build is Tuesday. Even if this only hits in beta 3 (end of next week) I don't think that's a disaster. :-)

Comment on attachment 8504315 [details] [diff] [review] Fix/workaround Approval Request Comment [Feature/regressing bug #]: Yosemite Apple bug [User impact if declined]: Nasty UI flaw in fullscreen mode [Describe test coverage new/current, TBPL]: Baked for a week on m-c with no problems reported [Risks and why]: Low risk. Very simple change tailored precisely to working around Apple's bug. [String/UUID change made/needed]: None

Comment on attachment 8504315 [details] [diff] [review] Fix/workaround Taking for beta as 34 is the first Firefox release after Yosemite's release. Beta+ Aurora+

Comment on attachment 8504315 [details] [diff] [review] Fix/workaround Landed on aurora and beta: https://hg.mozilla.org/releases/mozilla-aurora/rev/bd565604c982 https://hg.mozilla.org/releases/mozilla-beta/rev/a026594416c7

Would this be something for the release notes? I believe that many users would appreciate to see that this have been fixed.

> Would this be something for the release notes? I suspect that's overkill. Even topcrasher fixes (which are much more important) generally don't make it into release notes, as far as I know.

Verified as fixed using: FF 34.04 FF 35 Aurora Build Id: 20141028004002 FF 36 Nightly Build Id: 20141028030204 OS: Mac Os X 10.10

We ended up putting in a catch-all note for Yosemite visual fixes, attached to bug 1040250