Until the custom window work can be completed the Firefox button can't go into the titlebar on non-aero environments. This includes XP and Aero Basic. Until then it should appear to the left of the tabstrip.

Needs an owner: dao, gavin, sdwilsh?

Dao: what is the value of WINSTRIPE_AERO when the environment is Aero Basic (which isn't the same as Aero Opaque)

WINSTRIPE_AERO corresponds to >=Vista. @media not all and (-moz-windows-compositor) corresponds to non-glass.

I don't have a non-aero test setup and I'm not sure how to disable glass, so I just hacked the patch manually to remove the @media condition, so that I could test the net effect on non-aero platforms. With that change, when I use Alt to trigger the menubar I get this: http://grab.by/580Y Is that a problem with the patch, or just some dependence on other non-aero styling that I didn't take into account?

(In reply to comment #5) > Is that a problem with the patch, or just some dependence on other non-aero > styling that I didn't take into account? I suspect it has to do with the fact that the button shows up when the menuBar is turned off, and ALT has the effect of turning the menuBar on, but am not sure.

Yes, I know; I'm asking whether that case not being handled is a bug with the styling, or a bug with my testing.

(In reply to comment #5) > I don't have a non-aero test setup and I'm not sure how to disable glass, so I > just hacked the patch manually to remove the @media condition, so that I could > test the net effect on non-aero platforms. With that change, when I use Alt to > trigger the menubar I get this: Assuming that you are on Windows 7, change your theme to Windows 7 Basic to disable glass. To do this, right click on the desktop, and click personalize.

I don't have access to any Windows 7 machines, just Vista/XP (I should fix that!). I see the same thing without any patch tweaking on Vista with glass disabled (by RDC): http://grab.by/5892

This reduces the button height and makes the negative margin depend on the font size.

Could moving the menu button into the tab strip confuse users? The button looks a bit like a (smallish) tab.

Comment on attachment 453988 [details] [diff] [review] patch >diff --git a/browser/themes/winstripe/browser/browser.css b/browser/themes/winstripe/browser/browser.css >+ #navigator-toolbox[tabsontop="true"] > #toolbar-menubar[autohide="true"] ~ #TabsToolbar { >+ -moz-padding-start: 10em !important; Using #toolbar-menubar[inactive] instead gives a nicer appearance when the menu is shown, but I guess the tabstrip moving is a bit distracting? Is the idea that if bug 513162 is reverted, we can just remove the |@media not all and (-moz-windows-compositor)| conditional and use this everywhere?

(In reply to comment #12) > (From update of attachment 453988 [details] [diff] [review]) > >diff --git a/browser/themes/winstripe/browser/browser.css b/browser/themes/winstripe/browser/browser.css > > >+ #navigator-toolbox[tabsontop="true"] > #toolbar-menubar[autohide="true"] ~ #TabsToolbar { > >+ -moz-padding-start: 10em !important; > > Using #toolbar-menubar[inactive] instead gives a nicer appearance when the menu > is shown, but I guess the tabstrip moving is a bit distracting? Yeah, I don't think we want to resize the tab strip when pressing Alt. In any case, this is expected to be a temporary solution only. > Is the idea that if bug 513162 is reverted, we can just remove the |@media not > all and (-moz-windows-compositor)| conditional and use this everywhere? Yep.

(In reply to comment #13) > In any case, this is expected to be a temporary solution only. What's the plan for non-glass or XP? Are we eventually going to get titlebar drawing support there too?

(In reply to comment #15) > (In reply to comment #13) > > In any case, this is expected to be a temporary solution only. > > What's the plan for non-glass or XP? Are we eventually going to get titlebar > drawing support there too? bug 574454