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)
Tracking
()
RESOLVED
FIXED
People
(Reporter: matus, Assigned: kevin)
References
Details
Attachments
(1 file)
2.25 KB,
patch
|
Details | Diff | Splinter Review |
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...
Updated•20 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 1•20 years ago
|
||
*** Bug 248083 has been marked as a duplicate of this bug. ***
Comment 2•20 years ago
|
||
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 ;-)
Comment 3•20 years ago
|
||
*** 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!
Comment 6•20 years ago
|
||
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; }
Comment 7•20 years ago
|
||
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
Updated•20 years ago
|
Flags: blocking-aviary1.0?
Comment 8•20 years ago
|
||
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.
Comment 10•20 years ago
|
||
miahz, pretty sure you have to request review so that the patch can be checked in
Comment 11•20 years ago
|
||
Comment on attachment 159960 [details] [diff] [review] patch: super-duper tabs fix How's it look, Ben?
Attachment #159960 -
Flags: review?(bugs)
Assignee | ||
Comment 12•20 years ago
|
||
I'm going to look at this tomorrow
Updated•20 years ago
|
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Comment 13•20 years ago
|
||
not a blocker but fix it if you want.
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
Comment 14•20 years ago
|
||
(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.
Updated•20 years ago
|
OS: Windows XP → All
Version: unspecified → 1.0 Branch
Comment 15•20 years ago
|
||
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)
Comment 16•20 years ago
|
||
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
Comment 17•20 years ago
|
||
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.
Comment 18•20 years ago
|
||
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.
Comment 19•20 years ago
|
||
(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.
Comment 20•20 years ago
|
||
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
Comment 21•20 years ago
|
||
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.
Assignee | ||
Comment 22•20 years ago
|
||
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.
Comment 23•20 years ago
|
||
This bug is still present: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050116 Firefox/1.0+
Comment 24•20 years ago
|
||
(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?
Comment 25•20 years ago
|
||
classic. :)
Comment 26•20 years ago
|
||
Reopening, this is still visible using classic style on Windows XP. Using trunk build 20050117.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 27•19 years ago
|
||
*** Bug 290956 has been marked as a duplicate of this bug. ***
Updated•19 years ago
|
Version: 1.0 Branch → Trunk
Comment 28•19 years ago
|
||
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.
Comment 29•19 years ago
|
||
*** Bug 297407 has been marked as a duplicate of this bug. ***
Comment 30•19 years ago
|
||
Shouldn't Kevin review this bug?
Comment 31•19 years ago
|
||
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.
Comment 32•19 years ago
|
||
*** Bug 297689 has been marked as a duplicate of this bug. ***
Comment 33•19 years ago
|
||
*** Bug 303391 has been marked as a duplicate of this bug. ***
No longer blocks: 303391
Comment 34•19 years ago
|
||
This is fixed now that bug 308396 has landed.
Updated•19 years ago
|
Status: REOPENED → RESOLVED
Closed: 20 years ago → 19 years ago
Resolution: --- → FIXED
Updated•19 years ago
|
Attachment #159960 -
Flags: review?(bugs)
You need to log in
before you can comment on or make changes to this bug.
Description
•