1) Use Australis build 2) Put the History button onto the navbar 3) Enter full-screen mode 4) Click the History button 5) Dismiss the panel After step 5 the Firefox window disappears entirely, leaving an OS X space/desktop showing that native brushed-metal background that full screen apps get. Hovering at the top of the screen doesn't bring back the menubar. I ended up having to restart the browser.

This sounds a bit like bug 757618, which I fixed a while ago. So this bug may be a variant of that bug. Does the OS X version (10.7 or 10.8) make a difference here?

The weirdest thing is, I can't reproduce this on my own build but I can reproduce on nightly. Doing a clobber now to see if that helps.

(In reply to :Gijs Kruitbosch from comment #2) > The weirdest thing is, I can't reproduce this on my own build but I can > reproduce on nightly. Doing a clobber now to see if that helps. I've now figured this difference out, at least: the 10.6 SDK (which we use for nightlies etc.) has this issue. I rebuilt with that, and I could reproduce. Normally I use the default for Mountain Lion, which I guess is the 10.8 SDK, and that doesn't have this issue. This makes me very sad, because I suspect it might be hard for us to fix it front-end-side, and Cocoa code scares me. Steven, any idea what may be wrong and/or how to debug this? Note that even without fullscreen, the steps in comment 0 make the browser window disappear, and the popup sticks around when you get the window to show up again.

> 2) Put the History button onto the navbar How do you do this?

(In reply to Steven Michaud from comment #4) > > 2) Put the History button onto the navbar > > How do you do this? 2a) click the menubutton, click 'customize' at the bottom. 2b) drag the history widget (clock) to the navbar

I'm currently building on OS X 10.8 with the 10.7 SDK. But I think the following is the real bug: 1) Add the History button to the navbar. 2) Click on the History button, wait a second or two, then click again. The browser window closes! And clicking on the UX icon in the Dock doesn't make it reappear -- you need to do Cmd+n or do File : New Window. Something like this happens all the way back to the 2013-05-03 UX nightly -- in which the patch for bug 865374 was (re)landed.

(In reply to Steven Michaud from comment #6) > I'm currently building on OS X 10.8 with the 10.7 SDK. > > But I think the following is the real bug: > > 1) Add the History button to the navbar. > 2) Click on the History button, wait a second or two, then click again. > > The browser window closes! And clicking on the UX icon in the Dock doesn't > make it reappear -- you need to do Cmd+n or do File : New Window. > > Something like this happens all the way back to the 2013-05-03 UX nightly -- > in which the patch for bug 865374 was (re)landed. Actually, cmd+tab + cmd+tab re-shows the window (which seems to only be hidden?) - but the panel you opened this way never goes away anymore. :-(

> I'm currently building on OS X 10.8 with the 10.7 SDK. Even the bug I described in comment #6 doesn't happen with this build. I still think we must be doing something wrong, though ... though I have no idea what it might be. Someone needs to check our html/xul/xml/xbl code to find out exactly what actions are taken on clicking the History button.

I'd bet this is related to bug 891424 on mozilla-central.

In reply to Steven Michaud from comment #9) > I'd bet this is related to bug 891424 on mozilla-central. Yes, was about to comment the same. Mike thinks that's possibly caused by bug 869151. I'll see if I can quickly run a local backout of that and see if this goes away.

https://bugzilla.mozilla.org/show_bug.cgi?id=869151#c22 sounds very suspicious given what we're seeing.

Bug 891424 has an r+ed patch, which should land soon on mozilla-central. Please test if the patch fixes this bug.

(In reply to Steven Michaud from comment #12) > Bug 891424 has an r+ed patch, which should land soon on mozilla-central. > > Please test if the patch fixes this bug. It doesn't seem to. Clobbering to be sure.

(In reply to :Gijs Kruitbosch from comment #13) > (In reply to Steven Michaud from comment #12) > > Bug 891424 has an r+ed patch, which should land soon on mozilla-central. > > > > Please test if the patch fixes this bug. > > It doesn't seem to. Clobbering to be sure. Not fixed even after a clobber. :-\

Have an incomplete fix/workaround for this on our end, will try to polish and put something up soonish

(In reply to :Gijs Kruitbosch from comment #16) > Created attachment 774760 [details] [diff] [review] > Using history widget in full-screen mode results in empty full-screen space Steven, this seems to fix the issue. We use level=top for the main menupanel as well, so I think this is fine, but perhaps this helps you in figuring out what the real problem is here?

(In reply to comment #17) I'll need to spend a lot more time to figure out the implications of your workaround, and where the real problem is. I'm not sure when I'm going to have that time, so a reasonable workaround is very welcome (one that doesn't have other side effects). That this bug only happens when compiling with the 10.6 SDK suggests it might be an OS bug. But our support for Apple's native fullscreen mode is pretty rickety -- both in widget code and in cross-platform code. So I wouldn't be surprised to find that this bug is our fault, after all. (For an example of a bug (or at least a design flaw) in cross-platform support for fullscreen mode, see bug 752294 comment #5.)

You might want to see if the latest patch in bug 891424 fixes this (without the workaround), try build here http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/tnikkel@gmail.com-b2313bd7ab33/try-macosx64/

(In reply to Timothy Nikkel (:tn) from comment #20) > You might want to see if the latest patch in bug 891424 fixes this (without > the workaround), try build here > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/tnikkel@gmail.com- > b2313bd7ab33/try-macosx64/ That patch has now landed, so one could see if the work around here is still needed.

Australis merged to 29, so 28 is unaffected.

(In reply to :Gijs Kruitbosch from comment #23) > Australis merged to 29, so 28 is unaffected. Right, we still need a way to track this so we know to test it though. Is it okay to update the target milestone to 29 in this case?

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #24) > (In reply to :Gijs Kruitbosch from comment #23) > > Australis merged to 29, so 28 is unaffected. > > Right, we still need a way to track this so we know to test it though. Is it > okay to update the target milestone to 29 in this case? I guess so. The problem is that we didn't do it for any of the merged australis csets. There was a (brief, admittedly) discussion about this with fx-team and/or sheriffs, and we decided it wasn't worth the bother. Does this affect QA to an extent that we should re-evaluate that decision?

(In reply to :Gijs Kruitbosch from comment #25) > Does this affect QA to an extent that we should re-evaluate that decision? It increases the risk of some bugs that are actually fixed in Firefox 28 not getting QA attention in time because I'm now distracted looking at bugs like these. If the code landed doesn't actually exist in the version indicated by Target Milestone then Target Milestone should be changed to reflect that. Of course this is just my personal opinion.

Verified with latest builds of Nightly and Aurora.