574681 - Tweak appearance of Firefox Button in Title Bar

Status: RESOLVED FIXED

(Firefox :: Theme, defect)

Description

[Peter Henkel [:Terepin]]

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

Comment 1

[Peter Henkel [:Terepin]]

Attachment: Current Firefox Button

Comment 2

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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

Comment 3

[Peter Henkel [:Terepin]]

Attachment: Current Firefox Button (Maximzied)

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

Comment 4

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Oh, it only looks like that when maximized.

Confirming.

Comment 5

[Hans Schmucker]

Attachment: Screenshot of maximized window with many tabs

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.

Comment 6

[Peter Henkel [:Terepin]]

That is covered in bug 574821.

Comment 7

[Hans Schmucker]

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

Comment 8

[Peter Henkel [:Terepin]]

I dunno. Will see after patch lands.

Comment 10

[Peter Henkel [:Terepin]]

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

Comment 11

[Peter Henkel [:Terepin]]

Attachment: Button stands out of the unmaximized window

Comment 12

[Peter Henkel [:Terepin]]

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

Comment 14

[Josh Tumath]

Should this depend on bug 575726?

Comment 15

[Peter Henkel [:Terepin]]

I was thinking about that too.

Comment 16

[imradyurrad]

Attachment: comparison

Comment 17

[Stephen Horlander [:shorlander]]

Attachment: Adjust Firefox Button to Match Design 1.0

Comment 18

[Stephen Horlander [:shorlander]]

Attachment: Screenshot of Patch 1.0

Comment 19

[ronin.achilles]

Yeah.. looks great now!

Comment 20

[ronin.achilles]

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.

Comment 21

[Darren Kalck [:D-Kalck]]

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

Comment 22

[ronin.achilles]

@Darren: They look aligned in the screenshot.

Comment 23

[Darren Kalck [:D-Kalck]]

@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

Comment 24

[Stephen Horlander [:shorlander]]

(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?

Comment 25

[ronin.achilles]

Attachment: Screenshot & Remaining issues with patch applied

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

Comment 26

[Dão Gottwald [:dao]]

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.

Comment 27

[Stephen Horlander [:shorlander]]

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

Comment 28

[Dão Gottwald [:dao]]

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

Comment 29

[Stephen Horlander [:shorlander]]

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

Comment 30

[Dão Gottwald [:dao]]

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

Comment 31

[Stephen Horlander [:shorlander]]

(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?

Comment 32

[ronin.achilles]

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.

Comment 33

[[not reading bugmail]]

(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.

Comment 34

[imradyurrad]

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

Comment 35

[Dão Gottwald [:dao]]

(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.

Comment 36

[imradyurrad]

Dao, we need review+!

Comment 37

[Darren Kalck [:D-Kalck]]

Attachment: Border darker than control buttons

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.

Comment 38

[Darren Kalck [:D-Kalck]]

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

Comment 39

[Josh Tumath]

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.

Comment 40

[Darren Kalck [:D-Kalck]]

(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;
}

Comment 41

[Dão Gottwald [:dao]]

(In reply to comment #36)
> Dao, we need review+!

Stop spamming this bug.

Comment 42

[imradyurrad]

(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.

Comment 43

[Peter Henkel [:Terepin]]

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

Comment 44

[ronin.achilles]

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

Comment 45

[Peter Henkel [:Terepin]]

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

Comment 47

[imradyurrad]

Mark as dupe of 571784

Comment 48

[Peter Henkel [:Terepin]]

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

Comment 49

[imradyurrad]

(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.

Comment 50

[Alex Faaborg [:faaborg] (Firefox UX)]

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).

Comment 51

[Jim Mathies [:jimm]]

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.

Comment 52

[Jim Mathies [:jimm]]

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.

Comment 53

[Tiago Sá]

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).

Comment 54

[redsign]

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.

Comment 55

[Stephen Horlander [:shorlander]]

(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.

Comment 56

[Jim Mathies [:jimm]]

(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.

Comment 57

[redsign]

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.

Comment 58

[Stephen Horlander [:shorlander]]

Attachment: 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?

Comment 59

[Jim Mathies [:jimm]]

(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

Comment 61

[Tiago Sá]

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?

Comment 62

[Jim Mathies [:jimm]]

(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?

Comment 63

[Csaba Kozák [:WonderCsabo]]

Attachment: Fx button seems floating with Persona

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

Comment 64

[Josh Tumath]

(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.

Comment 65

[Jim Mathies [:jimm]]

(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.

Comment 66

[Jim Mathies [:jimm]]

(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

Comment 67

[Csaba Kozák [:WonderCsabo]]

(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?

Comment 68

[Josh Tumath]

(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. ;-)

Comment 69

[Stephen Horlander [:shorlander]]

(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

Comment 70

[Jim Mathies [:jimm]]

(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?

Comment 71

[Stephen Horlander [:shorlander]]

(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 :)

Comment 72

[Jim Mathies [:jimm]]

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.

Comment 73

[Darren Kalck [:D-Kalck]]

Will it land soon ?

Comment 74

[Thomas Seguin]

(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.

Comment 75

[Dão Gottwald [:dao]]

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

Comment 76

[Dão Gottwald [:dao]]

(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

Comment 77

[pal-moz]

Attachment: screenshot

(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.

Comment 78

[Peter Henkel [:Terepin]]

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

Comment 79

[ronin.achilles]

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

Comment 80

[Darren Kalck [:D-Kalck]]

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

Comment 81

[ronin.achilles]

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

Comment 82

[u310142]

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

Comment 83

[Asa Dotzler [:asa]]

Attachment: screenshots on Windows 7 of Firefox 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.)

Comment 84

[Peter Henkel [:Terepin]]

Use bug 594037.

Comment 85

[imradyurrad]

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

Comment 86

[Jim Mathies [:jimm]]

(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.

Comment 87

[imradyurrad]

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

Comment 88

[Benjamin Xiao]

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.

Comment 89

[Benjamin Xiao]

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

Comment 90

[Darren Kalck [:D-Kalck]]

See comment #26

Comment 91

[Benjamin Xiao]

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.

Comment 92

[Peter Henkel [:Terepin]]

Agree, it should go away.

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

Comment 93

[Csaba Kozák [:WonderCsabo]]

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

Comment 94

[Alex Faaborg [:faaborg] (Firefox UX)]

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).

Comment 95

[Benjamin Xiao]

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.

Comment 96

[Exactly {Clear}]

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 .

Comment 97

[Benjamin Xiao]

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.