Closed Bug 246186 Opened 20 years ago Closed 19 years ago

visual bug: opening a second tab makes tab panel 1 pixel higher

Categories

(Firefox :: Tabbed Browser, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: matus, Assigned: kevin)

References

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040608 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040608 Firefox/0.8

Mozilla Firefox 0.9rc:
When you open the second tab, the tab panel (the place where tab captions are)
gets one pixel higher then it is when you have only one tab opened. When you
close  all tabs but one, height gets one pixel lower again. It's quite
distracting (the whole borwsing area goes one pixel up/down while manipulating
tabs).

Reproducible: Always
Steps to Reproduce:
1. You have only one tab open.
2. Open a second tab, notice how tab captions grow 1 pixel in height and the
whole browsing area moves one pixel down.
3. Close the second tab, notice how tab captions loose 1 pixel in height, whole
browsing area goes 1 pixel up.

Actual Results:  
Various parts of firefox window were jumping up and down one pixel.

Expected Results:  
Tab captions' height should be constant and the browsing panel should not jump
up and down.

The new default theme is awful compared to the old one. I just hope it's because
it's not finished...
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 248083 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040620
Firefox/0.9.0+ (no themes/extensions)

Confirmed

In multiple tabs an extra pixel is added to separate the non-active tabs from
the active page.
A better manner would be to use a fixed height for the single tab and for the
active tab in a multi-tab row.
The passive tabs height should be reduced 1 pixel (at the bottom) and a 1 pixel
row should be added to separate it form the active page.
This is NOT theme related !
Very cosmetic bug, fix whenever someone has nothing better to do ;-)
*** Bug 248232 has been marked as a duplicate of this bug. ***
This bug is *not* simply cosmetic! It triggers any Javascript onResize, which
quite often results in pages being reloaded. This is extremely annoying,
especially with a slow connection.
Another really annoying result of this bug is that Firefox "forgets" which site
it is loading if you open a second tab while viewing a page using onResize. More
specically:

1) Open a page that causes a reload/refresh on resize, e.g. www.nfl.com
2) Click on any link (or enter a new one manually)
3) QUICKLY (depending on connection speed) press CTRL-T to open a new tab.

Step 3 results in a resizing of the first tab, which causes the onResize of the
old page to be triggered, causing it to reload - forgetting the new page it was
still trying to load.

This is really not just a cosmetic bug as some would suggest!
The addition of the following lines to userChrome.css has fixed the problem
for me (tested with 0.9.1, default theme):

#content .tabbrowser-strip {
  border-bottom: 1px solid ThreeDShadow;
  padding-bottom: 1px;
}
#content .tabbrowser-tabs {
  background: none !important;
}
#content .tabs-left,
#content .tabs-right {
  border-bottom-width: 1px !important;
}
#content tab {
  margin-bottom: 0 !important;
}
I can confirm that the userChome.css modification supplied by
psellhorst@yahoo.de   works with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7) Gecko/20040707 Firefox/0.9.2
Blocks: 244691
Flags: blocking-aviary1.0?
Not going to hold since it requires the tab bar to be visible which is not a
common setting, but reassigning to kevin. If there's a patch, renominate since
this should be simple. 
Assignee: bugs → webmail
Flags: blocking-aviary1.0PR-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-
Even more annoying to me than the one-pixel expansion of the tab bar, was the
way browser tabs "jumped" around when you switched among them.	So i went after
both problems while attempting to make normal tabs look like native Windows
Classic tabs, in similar fashion to bug 253661's menus.  As it turned out,
fixing the "nativeness" made the 1 pixel problem go away.  The browser tabs
behave slightly differently because of their flexible width.  So the before-
and after- rules had to be negated by restating the plain tab padding values,
which fixes the jumping problem.  This patch also gets rid of the weird looking
bottom-edge background image from the tab bar, and restores the normal bottom
border.
Flags: blocking-aviary1.0- → blocking-aviary1.0?
miahz, pretty sure you have to request review so that the patch can be checked in 
Comment on attachment 159960 [details] [diff] [review]
patch: super-duper tabs fix

How's it look, Ben?
Attachment #159960 - Flags: review?(bugs)
I'm going to look at this tomorrow
Flags: blocking-aviary1.0? → blocking-aviary1.0+
not a blocker but fix it if you want.
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
(In reply to comment #12)
> I'm going to look at this tomorrow

Is anybody reviewing this? Been waiting long time...

Sorry for the bugspam.
OS: Windows XP → All
Version: unspecified → 1.0 Branch
I'm with you, #14, a load of Winstripe fixes landed today, this easily could
have been one of them had it been reviewed. Those of us who browse with the tab
bar always open know that this bug is a bit more important than it seems on the
surface (the reloading of pages, etc., and I'm on dialup)
I believe that this is fixed in today's build. Probably a result of changes from
kevin's spit and polish checkins including (but not limited to) from bug 257480.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
using 2004101509-0.9+ bits on linux fc2, this looks fixed with the default
theme, as well as with charamel 1.0.7. still seems an issue with the qute 2.1.3
theme, but perhaps that's an issue with that particular theme.
I still see this in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3)
Gecko/20041015 Firefox/0.10.
(In reply to comment #16)
> I believe that this is fixed in today's build. Probably a result of changes from
> kevin's spit and polish checkins including (but not limited to) from bug 257480.

I don't think so.  In the latest hourly [Mozilla/5.0 (Windows; U; Windows NT
5.0; en-US; rv:1.7.3) Gecko/20041015 Firefox/1.0], it seems the same as before -
opening a new tab bumps the tab bar one pixel taller.  I don't think this was
part of that first batch of mass-checkins from "spit and polish."  Patch should
still be good.
For me it wfm now: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3)
Gecko/20041015 Firefox/0.10
This is still not fixed with the 17th on Windows 2000 [Mozilla/5.0 (Windows; U;
Windows NT 5.0; en-US; rv:1.7.3) Gecko/20041017 Firefox/1.0].  Tested with old
and fresh profiles.  Same as all the previous builds.  All you WFMs - can you
please reread the bug description and make sure you're not seeing the tab bar
vertically expand/shrink by one pixel when opening/closing the second tab?  I
haven't seen anything in the checkins that would have affected this, so i'm not
sure what would have changed to "fix" it.
I checked in new styles for the close tab button. The extra padding around the
button might appear to solve this .. I'm not seeing the problem using Luna on
XP, but I am still seeing the problem using the XP Classic theme. 
This bug is still present:  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8b) Gecko/20050116 Firefox/1.0+
(In reply to comment #23)
> This bug is still present:  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
> rv:1.8b) Gecko/20050116 Firefox/1.0+

You using classic or xp style?

classic.  :)
Reopening, this is still visible using classic style on Windows XP. Using trunk
build 20050117.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** Bug 290956 has been marked as a duplicate of this bug. ***
Version: 1.0 Branch → Trunk
This bug is still present for me. Fx 1.0.4; en-US; Windows 98SE, Classic style.
 It is fixed by the code in #6.  Thanks.
*** Bug 297407 has been marked as a duplicate of this bug. ***
Shouldn't Kevin review this bug?
Until I found this bug I had assumed this was a temporary themes problem!
I am currently running with just

tab[selected=true] {margin-top: 1px !important}

as my workround.
*** Bug 297689 has been marked as a duplicate of this bug. ***
Blocks: 303391
*** Bug 303391 has been marked as a duplicate of this bug. ***
No longer blocks: 303391
This is fixed now that bug 308396 has landed.
Status: REOPENED → RESOLVED
Closed: 20 years ago19 years ago
Resolution: --- → FIXED
Attachment #159960 - Flags: review?(bugs)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: