User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a6pre) Gecko/20100625 Minefield/3.7a6pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a6pre) Gecko/20100625 Minefield/3.7a6pre 1. It is a bit high than it needs to be; it's cuted from top edge of the window. 2. "Connect" the button from top edge of the window. Reproducible: Always

In my opinion, it's at the right height, it just needs to lose the rounded corners up on the top.

I should post this screenshot as well, where you can clearly see that is not displayed correctly.

Oh, it only looks like that when maximized. Confirming.

This doesn't just affect the Firefox button: everything is moved up a few pixels, meaning that the tab bar overlaps with the min/max/close buttons. For now, could we just pad the window top when maximized? Apparently Windows crops 8 pixels that would have to be added.

That is covered in bug 574821.

Thank you Peter. Isn't this bug a dupe then?

I dunno. Will see after patch lands.

Reopening: 1. Make Firefox Button to look like standard title bar button (meaning the white line around it) 2. Button stands out of the unmaximized window

3. Move button in maximizied window little to the right.

Should this depend on bug 575726?

I was thinking about that too.

Yeah.. looks great now!

Stephen - just one point... right now in maximized state, the button touches the left corner of the screen, while to be more consistent with Control Buttons, it should have 2-3 px padding there; just like the Control Buttons have this padding to their right side.

I think that the bottom of the button should be aligned with the control buttons, so the button should be 1 pixel higher.

@Darren: They look aligned in the screenshot.

@ronin, I applied the patch for aero, my minefield didn't look like the screenshots : - When hovered the button has less gloss than the screenshot - When active, the button do not loose it's rounded border etc. - The button is 1px higher on the screenshot

(In reply to comment #23) > @ronin, I applied the patch for aero, my minefield didn't look like the > screenshots : > - When hovered the button has less gloss than the screenshot > - When active, the button do not loose it's rounded border etc. > - The button is 1px higher on the screenshot It needs bug 576312 to fix the margin. Could you attach what yours looks like?

Screenshot with Patch 1.0 applied... also showing the remaining margin/border/padding issues.

Comment on attachment 455615 [details] [diff] [review] Adjust Firefox Button to Match Design 1.0 Why does this remove the border radius in the active state? Doesn't seem to make sense.

It should be flush with the menu so they look more connected with no breaks.

We should probably shift the menu then. Changing the button shape seems both unusual and unnatural.

Unusual perhaps. It doesn't really strike me as unnatural.

So, is there a reason not to take the usual path?

(In reply to comment #30) > So, is there a reason not to take the usual path? By "usual path" do you mean not slightly change the button shape? If so then yes. As I said above it would be nice if the button and the menu were butted up flat against each other which isn't possible with the corner radius. So removing the radius on press accomplishes this. It is a mild stylistic change. Is there a reason not to?

IMO losing the radius and making it flush with the menu looks good even if its unconventional. Frankly wont make much of a difference one way or the other... but a straight fit look better. Just my 2 cents.

(In reply to comment #20) > Stephen - just one point... right now in maximized state, the button touches > the left corner of the screen, while to be more consistent with Control > Buttons, it should have 2-3 px padding there; just like the Control Buttons > have this padding to their right side. @Stephen, This looks strange without maximized mode also being consistent.

After the things in Comment 23 are fixed, will this be landing or is there something else not complete?

(In reply to comment #31) > (In reply to comment #30) > > So, is there a reason not to take the usual path? > > By "usual path" do you mean not slightly change the button shape? Yes, no dynamic button shape change and shifting the menu popup as we've done before in similar cases.

Dao, we need review+!

I did a mistake when applying the patch, now the only remaining issue is the left padding when the window is maximized. The borders when inactive looks like the screenshot provided by Stephen. Another issue (see screenshot) is that the white border (around the black one) looks brighter on the control buttons.

I forgot to mention that the border radius should be set to 5px (like the control buttons).

It might be good to add the -moz-transition property. I know transitions aren't supported for gradients yet, but it could be added for when they are.

(In reply to comment #20) > Stephen - just one point... right now in maximized state, the button touches > the left corner of the screen, while to be more consistent with Control > Buttons, it should have 2-3 px padding there; just like the Control Buttons > have this padding to their right side. something like this should fix the problem : #main-window[sizemode="maximized"][chromemargin^="0,"] #appmenu-button { margin-left: 2px; }

(In reply to comment #36) > Dao, we need review+! Stop spamming this bug.

(In reply to comment #41) > (In reply to comment #36) > > Dao, we need review+! > > Stop spamming this bug. I only commented twice. =( Excuse me if I just want to see this get done.

No, patch is still mising one part from comment 40 (buttton is touching the edge).

Requesting to Block Beta2. The freeze is on June 19th.

Requesting to block beta3+. We need to land this along with bug 560507, so we can have "the basics" done.

Mark as dupe of 571784

No, this bug is about Firefox Button. That bug is about Firefox Menu.

(In reply to comment #48) > No, this bug is about Firefox Button. That bug is about Firefox Menu. My mistake. I'm the one that added the attachment.

Keeping this separate from the beta 4 work in bug 583386, this needs to block (ideally we could get Stephen's changes in for Beta 3).

https://bug575870.bugzilla.mozilla.org/attachment.cgi?id=462504 For consideration, when the user has customized the height of the titlebar, we might want to stretch the button.

https://bug575870.bugzilla.mozilla.org/attachment.cgi?id=464286 Another minor tweak might be needed on non-english systems. The fonts seem to effect the height of the button.

We might also want to support titlebar heights (at least on Windows 7, that's where I tested it) bellow 23, or whatever it is. I think it's clear to all that the Firefox button is too far away from the tabs in comparison to Alex's mockups. That's not due as much to the system's settings, but more to the fact that the title bar is at least 23px high. We may want to make that value a bit smaller, so users can have a Firefox 4 that looks like the mockups (in that region of the window, I mean).

The default for Windows 7 is 21 pixels and for Vista 19 pixels, afaik. But I agree, it looks odd with that big gap. Also because of the tab bar looking the same as the titlebar itself now it looks like one very huge bar. That's why I think we should respect the mockups here. It just looks better.

(In reply to comment #51) > https://bug575870.bugzilla.mozilla.org/attachment.cgi?id=462504 > > For consideration, when the user has customized the height of the titlebar, we > might want to stretch the button. Yes. We should probably match the Firefox button to the other titlebar buttons.

(In reply to comment #54) > The default for Windows 7 is 21 pixels and for Vista 19 pixels, afaik. But I > agree, it looks odd with that big gap. Also because of the tab bar looking the > same as the titlebar itself now it looks like one very huge bar. That's why I > think we should respect the mockups here. It just looks better. Honestly I have the opposite opinion. I feel it should respect the titlebar height settings properly. new vs. old: https://bug575870.bugzilla.mozilla.org/attachment.cgi?id=463538 tabs on bottom w/notepad: https://bug575870.bugzilla.mozilla.org/attachment.cgi?id=463568 UX folks can make the decision though, this should be easy to tweak. The thing we have to remember though is that the height changes based on user settings, and I think we want to continue to support these variable heights.

Ok so we want to respect the system concerning the height of the title bar but get rid of the title bar text. Isn't that illogical? Do we want to have a title bar that looks native or do we want to have a title bar that fits Fx design the best way? At the moment we have something between that and a lot of unused space. And yes the "old" title bar really looked bad because it was to small and there wasn't any margin at all. Have a look at the mockups it is something between the old way and the standard title bar that we have now.

(In reply to comment #56) > UX folks can make the decision though, this should be easy to tweak. The thing > we have to remember though is that the height changes based on user settings, > and I think we want to continue to support these variable heights. We want to match to mockups which are designed to find a middle ground between space efficiency and window dragging. Which is around 3px from the top of the tab to the bottom of the button. Actually that might be 2px since the shadow extends out 2px I think. Is it possible to reduce that space and yet still respect the relative increase to the titlebar size?

(In reply to comment #58) > Created attachment 464518 [details] > Titlebar Margin > > (In reply to comment #56) > > UX folks can make the decision though, this should be easy to tweak. The thing > > we have to remember though is that the height changes based on user settings, > > and I think we want to continue to support these variable heights. > > We want to match to mockups which are designed to find a middle ground between > space efficiency and window dragging. Which is around 3px from the top of the > tab to the bottom of the button. Actually that might be 2px since the shadow > extends out 2px I think. > > Is it possible to reduce that space and yet still respect the relative increase > to the titlebar size? Hopefully it's possible to modify the pre-defined minimum height somehow via css here - http://mxr.mozilla.org/mozilla-central/source/browser/themes/winstripe/browser/browser.css#160 or we can just tweak the height value calculated here - http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/nsNativeThemeWin.cpp#1872

After submitting this [ https://bugzilla.mozilla.org/attachment.cgi?id=469167 ] attachment to bug 576960, I came here and read the comments, so I'm thinking this: Right now, after 575870 landed, the title bar is equal to system setting plus 1 pixel. It's obviously something that doesn't look like the mockups, so I think what we should do is make the title bar be equal in height to system setting minus 5 (which, according to my calculations, is the correct eight to match the mockups). I suppose this is the place to suggest it?

(In reply to comment #61) > After submitting this [ https://bugzilla.mozilla.org/attachment.cgi?id=469167 ] > attachment to bug 576960, I came here and read the comments, so I'm thinking > this: > > Right now, after 575870 landed, the title bar is equal to system setting plus 1 > pixel. It's obviously something that doesn't look like the mockups, so I think > what we should do is make the title bar be equal in height to system setting > minus 5 (which, according to my calculations, is the correct eight to match the > mockups). I suppose this is the place to suggest it? The 1px thing needs to be addressed in that bug. It's not an issue here since it applies to the whole window. So we should work on getting the spacing shorlander wants. Stephen, with a default titlebar spacing on a normalized window, how much space should sit between the bottom of the fx button and the top of the next level of content?

If i apply a persona, the window's top border disappears, and the Fx button seems floating.

(In reply to comment #63) > Created attachment 470320 [details] > Fx button seems floating with Persona > > If i apply a persona, the window's top border disappears, and the Fx button > seems floating. The issue is related to the title bar, not the Firefox button itself. The problem is that the Persona is covering the border of the window, and needs to be moved down by about 2 pixels.

(In reply to comment #64) > (In reply to comment #63) > > Created attachment 470320 [details] [details] > > Fx button seems floating with Persona > > > > If i apply a persona, the window's top border disappears, and the Fx button > > seems floating. > > The issue is related to the title bar, not the Firefox button itself. The > problem is that the Persona is covering the border of the window, and needs to > be moved down by about 2 pixels. We might be able to use one of the background-image moz extensions to push the image down by 1 or 2 px. The fx button offset is in winstripe's browser.css and can be changed.

(In reply to comment #65) > We might be able to use one of the background-image moz extensions to push the > image down by 1 or 2 px. link: https://developer.mozilla.org/en/css/background-image

(In reply to comment #64) > > > The issue is related to the title bar, not the Firefox button itself. The > problem is that the Persona is covering the border of the window, and needs to > be moved down by about 2 pixels. Should i report it to another bug? If yes, wich one?

(In reply to comment #67) > (In reply to comment #64) > > > > > > The issue is related to the title bar, not the Firefox button itself. The > > problem is that the Persona is covering the border of the window, and needs to > > be moved down by about 2 pixels. > > Should i report it to another bug? If yes, wich one? Most likely bug 513170. ;-)

(In reply to comment #62) > Stephen, with a default titlebar spacing on a normalized window, how much space > should sit between the bottom of the fx button and the top of the next level of > content? Should be 3 pixels between the white border of the caption buttons and the darker border of the tab as seen here: https://bug574681.bugzilla.mozilla.org/attachment.cgi?id=464518

(In reply to comment #69) > (In reply to comment #62) > > Stephen, with a default titlebar spacing on a normalized window, how much space > > should sit between the bottom of the fx button and the top of the next level of > > content? > > Should be 3 pixels between the white border of the caption buttons and the > darker border of the tab as seen here: > https://bug574681.bugzilla.mozilla.org/attachment.cgi?id=464518 This would be for the os default titlebar height correct? If a user has increased their titlebar height, it would be 3px plus the additional user defined space?

(In reply to comment #70) > This would be for the os default titlebar height correct? If a user has > increased their titlebar height, it would be 3px plus the additional user > defined space? Correct :)

Ok, so the open question is, how can we take the minimum widget size defined by theme code for -moz-window-titlebar / -moz-window-titlebar-maximized, subtract a number of pixels off of it, and then apply that back on the titlebar element, preferably without involving any script.

Will it land soon ?

(In reply to comment #17) > Created attachment 455615 [details] [diff] [review] > Adjust Firefox Button to Match Design 1.0 Stephen: Doesn't using a transparent background for the button break usability? I think it is easier to identify Firefox Windows with the orange background.

merged to tip and checked in: http://hg.mozilla.org/mozilla-central/rev/ca371593d433

(In reply to comment #72) > Ok, so the open question is, how can we take the minimum widget size defined by > theme code for -moz-window-titlebar / -moz-window-titlebar-maximized, subtract > a number of pixels off of it, and then apply that back on the titlebar element, > preferably without involving any script. filed bug 593950

(In reply to comment #52) > https://bug575870.bugzilla.mozilla.org/attachment.cgi?id=464286 > > Another minor tweak might be needed on non-english systems. The fonts seem to > effect the height of the button. build : http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1283857294/ nothing changed. XP SP3 Home (Japanese) need more height.

Same here. Wasn't it suppose to be tweaked in today's nightly build?

I am not seeing any change even in the latest hourly...

I tried : ftp://ftp.mozilla.org/pub/firefox/tinderbox-builds/mozilla-central-win32/1283857294/firefox-4.0b6pre.en-US.win32.zip And it works. Windows 7

Ok finally.... with this build: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1283867116/firefox-4.0b6pre.en-US.win32.installer.exe

There seems to be a slight delay when going from an inactive to an active button.

This screenshot shows the Firefox button in all of it's various states: maximized window, restored window, focused window, unfocused window, and button highlighted. It appears that in restored window, the button needs to be moved one pixel to the left (to match the window controls placement) and that in the maximized window, the button needs to be moved one pixel to the right (to match the windows controls placement.)

Use bug 594037.

I know I'm asking too much here, but is it possible to get the windows 7 color shifting animation/effect?

(In reply to comment #85) > I know I'm asking too much here, but is it possible to get the windows 7 color > shifting animation/effect? File a bug. I'd love to see gradual glow effects on this as well. I'd mark it as polish though.

Filed bug 594151. Didn't know what to title it =/

I think the mouse over highlight when the window is inactive should be one pixel shorter on the right side. Currently it looks like its overflowing the border.

What's with the button turning square on mouse-click? It looks odd to me.

See comment #26

I agree with Dao, changing the button shape on mouse-click is extremely strange and no other application I know of does this. It looks like a completely different button entirely instead of looking like the original button in a depressed state.

Agree, it should go away. Anyway, what was the reason to show hotkey for New Tab? I thought they were suppose to be removed.

Yeah, it's inconsistent, and looks quiet weird.

I kind of like the menu connecting with the button on downclick, but I think we need to draw the menu 1 pixel higher so that we don't see the outer glow of the button. (also I'm mostly indifferent on which approach we use).

It just doesn't seem consistent with existing UI behavior. Buttons shouldn't change shape when you press them, they should just look like they're indented. We don't need this extra "button is flush with corresponding menu" in order to remind us that the menu that just appeared belongs to the button that we just pressed. Everyone should get the idea. The rounded corners on the Fx button are also appealing, which I am sure that's why they were chosen in the first place. Rounded corners is always a sign of "modern" UI design. Changing Fx button to be completely rectangular on mouse-click just makes it feel like it jumped back a few years into the Win98/2k era.

i'd rather remove the rounded corners in Tabs, Naw Tab Button, and menu Button . rounded corners just dont look smooth on Windows, and arent perfect on Macs . its somthing that you cant fix cuz no OS does it right as far as i know .

What's wrong with the rounded corners on the native widgets in Windows? They look fine to me, so do the Mac buttons. No OS has had square buttons since Win2K, and with support for that OS being phased out soon, I see no reason for Fx to adhere to such old UI looks. Having had time to play and get used to the new Fx button, I still say that it looks off to me. There is a distinct disconnect between its appearance on mouse-click and is appearance in normal state. I don't feel that its the same button. It makes the UI feel like it's not polished enough.