348935 - scroll left button, scroll right button, all tab button edge lines extend partway down into "white strip"

Status: RESOLVED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Peter Kasting]

In the hovered and non-hovered states, the tab strip scroll buttons now have edge lines that extend partly, but not completely, through the "white strip" at the bottom of the tab strip.  This looks very odd, like they're not full buttons, or their bottoms have been whitewashed, or something.

See https://bugzilla.mozilla.org/attachment.cgi?id=234113 for a screenshot of the left tab strip scroll button hover state on Linux.

Comment 1

[Peter Kasting]

Followup: This screenshot of Luna: http://steelgryphon.com/random/example.png
... makes me think this behavior is sort of intentional, but there's some breakage right now.  For example, in that screenshot, the All Tabs menu line _does_ extend all the way through the strip.  Also, the tabs and buttons look as if they're meant to "sit in" the white strip, but if so, then the white area should end at the bottom of the tab, not flow up into it to an equal height with the strip in the non-tab area.

If ASCII art works:

   | TAB |
---|     |---
   |xxxxx|
STRIP
-------------

The section marked "xxxxx" is currently the STRIP color.  I think it should be the TAB color, or else the lines of the tab (or other buttons) should not extend down into the strip.

Comment 2

[Peter Kasting]

A mozillazine forum member suggested that the All Tabs button was misplaced, and that that pushed the bottom of the tab strip down by two pixels or so, which would account for a lot of problems, such as the unnaturally large white strip, the partial lines into the strip, and the odd looking vertical position of the All Tabs menu normally and hovered.  (See second paragraph of bug 348929 comment 0.)

Comment 3

[ronin.achilles]

Attachment: Tabstrip on Mac vs Win

Attached an image of Tabstrip implementation on Mac vs Windows. It clearly shows that the 'mysterious' white strip is actually by design and rightly implemented in Mac but something went wrong on Windows. Also notice that the 'AllTabs' menu button is also perfectly aligned in Mac as against Windows where it seems to be 1-2 pixel lower than the tabs.
This also means that somewhere we do have a solution for this problem (since it looks perfect on Mac), so please could someone fix it before Beta2.

Comment 4

[ronin.achilles]

(In reply to comment #3)
> Created an attachment (id=234398) [edit]
> Tabstrip on Mac vs Win
> 

From the comparison between Mac and Windows it seems like if the Top border of the  white strip is shifted down by 2 px, the problem will be fixed.

Comment 5

[Peter Kasting]

This is almost certainly caused by the same thing as bug 348983; marking depends.

Comment 6

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

for this problem on winstripe (thanks for the ascii art, pkasting!)

   | TAB |
---|     |---
   |xxxxx|
STRIP
-------------

I have a fix, which is to slightly modify http://lxr.mozilla.org/mozilla1.8/source/toolkit/themes/winstripe/global/icons/tabbrowser-tabs-bkgnd.png)

but it depends on a couple other fixes in my tree which I need to land first.

I'll attach as screen shot of how things look and my never version of tabbrowser-tabs-bkgnd.png

Comment 7

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

Attachment: slightly modified version of tabbrowser-tabs-bkgnd.png

Comment 8

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

Attachment: screen shot (with the new image being used)

Comment 9

[Peter Kasting]

(In reply to comment #8)
> Created an attachment (id=235513) [edit]
> screen shot (with the new image being used)

This looks much better insofar as the tab lines now do not extend weirdly into the strip.  I am concerned about whether the tab controls (scrollbuttons/All Tabs menu) are fixed by this image change.

Also, in your screenshot, we still have something like bug 348983: it looks like there's an extra 2 vertical pixels of white space between all the tabs and the divider line they're supposed to sit on.  However, since I've just said that's a separate bug, I assume it can be fixed elsewhere.  (Compare with http://wiki.mozilla.org/Image:Fx2-new-theme-in-xp-v1.jpg .  I wonder if that bottom divider line will be removed underneath the active tab as in that screenshot and non-branch Firefoxes?)

Comment 10

[Peter Kasting]

(In reply to comment #9)
> (In reply to comment #8)
> > Created an attachment (id=235513) [edit]
> > screen shot (with the new image being used)
> 
> I am concerned about whether the tab controls (scrollbuttons/All
> Tabs menu) are fixed by this image change.

I can now confirm that these buttons' images are NOT fixed by this change.  They still extend partway into the strip.

Bug 350352 is related.

Comment 11

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

I have landed some new images and css changes to fix this on winstripe as part of bug #350139

Comment 12

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

I've landed the fix for winstripe / pinstripe (see bug #350139), but this bug is about the buttons, not the tabs.

Comment 13

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

i think that they should integrate into the white strip as the active tab does, and they should appear active (100% opacity) or not appear at all if there are no tabs to scroll to...

Comment 14

[Dão Gottwald [:dao]]

(In reply to comment #13)
> i think that they should integrate into the white strip as the active tab does

Definitely not those who don't use the active tab's background (bug 350687 comment 6), because they won't match the white strip.

Comment 15

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

I believe that tomorrow's windows build will not have this issue, due to the landing for bug #351775.

mac may still need a little bit of polish, as I think the left, right and all tabs bleed 1px into the top of the strip.

Comment 16

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

the original issue is no longer a problem on winstripe, so marking fixed.

I'm going to log a new bug on what (I think) still needs work on pinstripe (with some screen shots), but it may not be a blocker.

Comment 17

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

> I'm going to log a new bug on what (I think) still needs work on pinstripe
> (with some screen shots), but it may not be a blocker.

see bug #352626, which is now fixed.