Closed Bug 594037 Opened 11 years ago Closed 10 years ago
Fine tuning of Firefox Button
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100907 Firefox/4.0b6pre Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100907 Firefox/4.0b6pre 1. Bug: In pressed state it turns into perfect rectangle. 2. Correction: Requires margin-left: 1px. Reproducible: Always
(In reply to comment #0) > 2. Correction: Requires margin-left: 1px. Damn: 2. Correction: Requires margin-left: 1px in maximized window.
(In reply to comment #0) > 1. Bug: In pressed state it turns into perfect rectangle. That is intended.
Discussed in bug 574681 comment 26.
Oh. Ignore point number one then. Just need that margin correction. 3. Bug: Oh and yes, the hover effect is indeed delayed, in both ways.
When aero is enabled, the button looks strange when the menu is shown, because of the 2 pixel border creating a gap. Could the bottom border be removed when the menu is shown?
It also appears to be taller than the other window controls.
In my case the button is taller because of regression in bug 578620.
The position of the Firefox button in a restored window is not quite correct. It needs to be moved to the left two pixels.
Assignee: nobody → dao
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #8) > In my case the button is taller because of regression in bug 578620. Ah, that is my problem as well.
Status: NEW → UNCONFIRMED
Ever confirmed: false
I'm not actually working on this...
Assignee: dao → nobody
Shouldn't be hard to fix this. Basically it needs only few margin corrections.
What's the reason of transparent FXB when window is unfocused?
The caption buttons is the reason.
So using the same logic as comment 14, wouldn't it make sense to use the same kind of shadow the caption buttons have then? The light upper part and the darker bottom part I mean, which make them look rounded (or triangle-shaped, because the shadow edge is very sharp). The Firefox button doesn't have such three dimensionality, just a soft gradient.
pino, the designer already considered that and opted to not be so glossy. It's an intentional distinction/deviation. So, it appears that the pressed state shape and the position of the button are wrong and there is no one signed up to fix it. Shorlander, do you consider this important enough to block the release?
(In reply to comment #16) > So, it appears that the pressed state shape Acording to Stephen, it isn't.
(In reply to comment #16) > Shorlander, do you consider this important enough to block the release? I don't think this should block release. However it should be a fairly simple patch so I plan to look at it when I get a moment if someone else doesn't pick it up first.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #12) > Shouldn't be hard to fix this. Basically it needs only few margin corrections. This is not true, I've tried making the margin adjustments and it is unable to draw in the left border area.
(In reply to Bug 574681 comment #82) > There seems to be a slight delay when going from an inactive to an active > button. I'm curious, if this can be fixed... Firefox feels rather slow, e.g. when Alt-Tab'ing to it, and something flashes in your peripheral vision.
Curious if the height mismatch was desired, or should I file a bug?
(In reply to comment #21) > Created attachment 473105 [details] > height comparison > > Curious if the height mismatch was desired, or should I file a bug? It is apparently caused by bug 578620.
FXB remains in inactive state.
When the Firefox window does not have focus, the border around the Firefox button is darker than the border around the window control buttons. It currently matches the window's outside black border I think, but the window controls have a slightly lighter border. Also, when the window does not have focus, the button contents should have a higher contrast stroke/outline to help visibility on lighter backgrounds. Does fine on darker backgrounds but needs help on light or white.
Also just noticed that if the Firefox menu is open when the window loses focus, the button stays orange instead of going transparent. steps: 1. click firefox button to open menu. 2. click taskbar or some other location to unfocus Firefox window. 3. see orange button. expected: button goes transparent like it does if the menu wasn't open when you de-focused the window.
Just noticed a small issue with the activation of the button's unfocused window appearance. The appearance of the button doesn't go into its unfocused state if you select another window whilst having the menu open. Also the button isn't activated when the mouse is at the top-left most pixel of a maximized window, nor is it activated at the left-most edge. This would be a major Fitts' Law benefit.
The border radius of the button should be increased slightly to matche the radius of the caption buttons.
What about a glow effect on hover (of course Win Vista and 7 only)?
(In reply to comment #28) > What about a glow effect on hover (of course Win Vista and 7 only)? I did some experimenting with implementing a glow effect with box-shadow, but it only renders to the right and bottom of the button.
(In reply to comment #27) > The border radius of the button should be increased slightly to matche the > radius of the caption buttons. Yes, it should be increased from 4px to 5px.
blocking2.0: --- → ?
Comment on attachment 472655 [details] screenshot comparing current Firefox button placement with design doc obsoleting outdated screenshots
Attachment #472655 - Attachment is obsolete: true
(In reply to comment #33) > Created attachment 503805 [details] > Fx button loses rounded corners when pressed I've just read the comments again, and found this is intended... Why? It looks very odd. Please obsolete the attachment if it's really intended. Sorry.
I have no idea what the actual goal of this bug is due to the chain of comments. Stephen/Dao: if you think this should block, please renominate.
blocking2.0: ? → ---
I can summarize what is still valid into one comment if you want. :)
(In reply to comment #35) > I have no idea what the actual goal of this bug is due to the chain of > comments. > > Stephen/Dao: if you think this should block, please renominate. I don't see anything listed here that blocks.
This bug lost its purpose.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.