349187 - Tabs are all the same height, the selected tab should be 1px "taller" than the others

Status: RESOLVED WONTFIX

(Firefox :: Tabbed Browser, defect)

Description

[hhh]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060817 BonEcho/2.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060817 BonEcho/2.0b1

The active tab no longer sits higher than inactive tabs, making it  much harder to distinguish between the two.

Reproducible: Always

Steps to Reproduce:
1. Open a few tabs.
2. Click between a few inactive tabs.
3. 

Actual Results:  
Tab height remains the same between all tabs.

Expected Results:  
The active tab should be a few pixels taller than inactive ones to provide another visual clue as to which is which.

Comment 1

[Peter Kasting]

Confirming, but possibly WONTFIX.

Comment 2

[Thomas Rutter]

The icon and text on the active tab sits higher than the other tabs, but the top of the tab remains level with them.  So the text and icon are closer to the top of the tab when they are the active tab.

Confirming, but I think it looks good like this.

Comment 3

[Peter Kasting]

Requesting blocking based on bug 348967 comment 14.

Comment 4

[(not reading, please use [e-mail] instead)]

morphing summary and taking, based on bug 348967 comment 14

beltzner suggests this change be made for all platforms.

Comment 5

[(not reading, please use [e-mail] instead)]

Attachment: screen shot after the patch

Comment 6

[(not reading, please use [e-mail] instead)]

Attachment: patch, but will depend on changes in bug #348967

Comment 7

[Peter Kasting]

(In reply to comment #5)
> Created an attachment (id=235452) [edit]
> screen shot after the patch

In Fx 1.5, the extra vertical height was used to make the top of the tab have a different color, which made it stand out more.  In this screenshot, where that isn't done, the different is extremely subtle.

Should such a change be added?  (Perhaps there is a bug on this already, or this should be filed as a separate bug and not rolled in here.)

Comment 8

[(not reading, please use [e-mail] instead)]

>In Fx 1.5, the extra vertical height was used to make the top of the tab have a
>different color, which made it stand out more.  In this screenshot, where that
>isn't done, the different is extremely subtle.
>
>Should such a change be added?  (Perhaps there is a bug on this already, or
>this should be filed as a separate bug and not rolled in here.)

I asked beltzner this same question, and his decision was to make winstripe and pinstripe act the same:  selected tab is taller (by 1px), brighter (opacity 100%), but unlike 1.5, no focus color at the top.

See his irc comment which I've pasted here:
https://bugzilla.mozilla.org/show_bug.cgi?id=348967#c20

Comment 9

[(not reading, please use [e-mail] instead)]

Attachment: to get the close button of the selected tab in the right spot

Comment 10

[(not reading, please use [e-mail] instead)]

Attachment: the last patch also gets the close button in the correct spot (for the selected tab)

Comment 11

[(not reading, please use [e-mail] instead)]

Comment on attachment 235477 [details] [diff] [review]
to get the close button of the selected tab in the right spot

no ready for review yet, as the text and favicon are 1 px too low, too.

Comment 12

[(not reading, please use [e-mail] instead)]

according to mconnor (and the mockups, see http://wiki.mozilla.org/FX2_Visual_Update/Default_Theme_Update), we should keep all the tabs (including the selected one) the same height, and rely on the contrast to indicate which tab is selected.

the plan is mconnor and beltzner to weigh in here, but it seems likely this bug will be marked WONTFIX.

Comment 13

[Mike Connor [:mconnor]]

-> beltzner until we decide once and for all 

Comment 14

[Peter Kasting]

(In reply to comment #12)
> according to mconnor (and the mockups, see
> http://wiki.mozilla.org/FX2_Visual_Update/Default_Theme_Update), we should keep
> all the tabs (including the selected one) the same height, and rely on the
> contrast to indicate which tab is selected.

Note that it works a lot better in the mockups, which isn't what our current solution looks like.  I don't know if there's a bug on "Make our tab strip look like the mockup."  If there is, and it's going to be fixed, then yes, maybe making the tab taller isn't as important.

Comment 15

[Justin Dolske [:Dolske]]

It seems a wee bit silly to use a 1-pixel shift to mark the active tab... It's barely perceptible on a modern display, and that's assuming you have good eyesight. If the tab height is to be a visual cue, it would probably need to be about .5em to make it obvious and noticeable. [But there's nothing wrong with carefully aligning things precisely to the pixel.]

Comment 16

[:Gavin Sharp [email: [e-mail]]]

*** Bug 351429 has been marked as a duplicate of this bug. ***

Comment 17

[Dão Gottwald [:dao]]

Attachment: almost working themes/winstripe/global/browser.css

There are many illogical margins in themes/winstripe/global/browser.css. Here's mine, which rises the active tab by 2px. Though it has the problem that the tab strip grows when the scroll arrows appear. That's a regression that was fixed before, but I don't know how.

Comment 18

[ronin.achilles]

(In reply to comment #17)
> Created an attachment (id=236814) [edit]
> almost working themes/winstripe/global/browser.css
> 
> There are many illogical margins in themes/winstripe/global/browser.css. Here's
> mine, which rises the active tab by 2px. Though it has the problem that the tab
> strip grows when the scroll arrows appear. That's a regression that was fixed
> before, but I don't know how.
> 

Seth had fixed that regression in Bug 348967. 

Comment 19

[(not reading, please use [e-mail] instead)]

note:  this is assigned to beltzner so that he (and mconnor) can decide if we should do this or not.  (see comments #12 and #13)

fwiw, my understanding is we are going to be following the mockup, and relying on the color (or opacity of color) of the tab images in order to indicate which tab is selected.

Comment 20

[Dão Gottwald [:dao]]

(In reply to comment #17)
> Created an attachment (id=236814) [edit]
> almost working themes/winstripe/global/browser.css

See also attachment 236835 [details].

(In reply to comment #18)
> Seth had fixed that regression in Bug 348967.

Yes, I found that later, but I don't quite understand it (looks more like a workaround than a fix to me). He added some of those margins that seem illogical to me, but that are not the only ones that I've removed.

Comment 21

[Mike Beltzner [:beltzner, not reading bugmail]]

I've been convinced that a 1px move wouldn't add a lot of value, and since updating the tabstrip in recent nightlies, it's far easier to discern the selected tab from background tabs, so this now becomes a WONTFIX.

Dao: thanks for the work, but I think we've fixed the requirement through other means. 

Comment 22

[Dão Gottwald [:dao]]

(In reply to comment #21)
> I think we've fixed the requirement through other means.

Please see bug 350690. With semi-transparent tab images, there will be less contrast (and I hope you agree that they have to be semi-transparent).