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.
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.
Summary: Tab strip scroll buttons' edge lines extend partway down into "white strip" → Tab strip buttons' edge lines extend partway down into "white strip"
Target Milestone: --- → Firefox 2
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.)
Flags: blocking-firefox2? → blocking-firefox2+
Whiteboard: [Fx2 theme change]
Created attachment 234398 [details] 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.
(In reply to comment #3) > Created an attachment (id=234398)  > 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.
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
Status: NEW → ASSIGNED
(In reply to comment #8) > Created an attachment (id=235513)  > 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?)
(In reply to comment #9) > (In reply to comment #8) > > Created an attachment (id=235513)  > > 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.
I have landed some new images and css changes to fix this on winstripe as part of bug #350139
Depends on: 350139
Whiteboard: [Fx2 theme change] → [Fx2 theme change][fixed on winstripe, still need to fix pinstripe]
I've landed the fix for winstripe / pinstripe (see bug #350139), but this bug is about the buttons, not the tabs.
OS: Linux → All
Hardware: PC → All
Summary: Tab strip buttons' edge lines extend partway down into "white strip" → scroll left, scroll right, all tab button edge lines extend partway down into "white strip"
Whiteboard: [Fx2 theme change][fixed on winstripe, still need to fix pinstripe] → [Fx2 theme change]
12 years ago
Summary: scroll left, scroll right, all tab button edge lines extend partway down into "white strip" → scroll left button, scroll right button, all tab button edge lines extend partway down into "white strip"
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...
(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.
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.
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
12 years ago
> 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.
You need to log in before you can comment on or make changes to this bug.