contents of tab move up a pixel as it closes

VERIFIED FIXED in Firefox 2 alpha2

Status

()

Firefox
Tabbed Browser
VERIFIED FIXED
13 years ago
12 years ago

People

(Reporter: dbaron, Assigned: Martijn Wargers (zombie))

Tracking

({perf, regression, verified1.8.1})

2.0 Branch
Firefox 2 alpha2
x86
Linux
perf, regression, verified1.8.1
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

13 years ago
When closing a tab, its contents move up one pixel before disappearing.

Steps to reproduce (that make the problem more visible):
 1. open a new Firefox window
 2. open two new tabs with the same page in them (so you have 3 tabs total)
 3. switch to the third tab
 4. close it
Actual results:
 4. you see the page move up a pixel and then down again
Expected results:
 4. the page should not have moved at all since both tabs have identical contents

Steps to reproduce (that show it's the tab being closed that jitters):
 1. open a new Firefox window and load three tabs, with different pages in the last two
 2. switch to the last tab
 3. close the last tab
Actual results:
 3. you see the page in the third tab move a pixel up before it disappears
Expected results:
 3. the page in the third tab doesn't move before disappearing

This is a regression from Ben's tab browser landing (bug 308396) at 2006-01-20
15:04.

This is probably not only a visual problem -- it likely has measurable performance implications.

It's possible that this bug is only present given certain sizes of system fonts (e.g., it could be related to changes in the tab layout caused by the appearance/disappearance of the close box, if the close box is larger than the fonts used in the tab labels).  But that's just a guess at something to try if it turns out to be hard to reproduce -- I actually suspect it's not related to the close box since it happens both with small and large numbers of tabs.
Keywords: regression

Comment 1

13 years ago
I think I see this. Another way to look at it:

Open 2 tabs.
Focus the 2nd one.
Observe the pixel thick strip at the bottom of the tab bar.
Keep watching it as you close the current tab.

Expected results: It stays there.
Actual results: It disappears (causing content to move up 2 pixels) then reappears  (forcing the content back again).
(Assignee)

Comment 2

13 years ago
Created attachment 210537 [details] [diff] [review]
patch

Well, something like this fixes the issue mentioned in comment 1.
I can't see the issue in comment 0, but maybe that would also be fixed by this patch.
(In reply to comment #2)
> Created an attachment (id=210537) [edit]
> patch

Doesn't this regress bug 324449? Seems like it effectively backs out the patch from that bug. Could you explain why it fixes this bug?
(Assignee)

Comment 4

13 years ago
Yes, probably, I saw even worse things, so the patch isn't any good. It also didn't fix the case when you have 2 tabs open and you drag the one before the other.

I think it fixes the bug because currently when you close the active tab there is -for a brief moment- a situation where no tab is selected. It seems like the active tab is determining the height of the tabbar when there are only 2 tabs open.
(In reply to comment #4)
> I think it fixes the bug because currently when you close the active tab there
> is -for a brief moment- a situation where no tab is selected. It seems like the
> active tab is determining the height of the tabbar when there are only 2 tabs
> open.

Ah, I see. Maybe the padding or minimum height of the tab bar could be tweaked?
(Assignee)

Comment 6

13 years ago
Created attachment 210585 [details] [diff] [review]
patch2

This fixes it for me and is safe.
Attachment #210537 - Attachment is obsolete: true
Attachment #210585 - Flags: review?(mconnor)
(Reporter)

Updated

13 years ago
Flags: blocking1.9a1?
Flags: blocking-firefox2?
(Reporter)

Updated

13 years ago
Keywords: perf

Updated

13 years ago
Attachment #210585 - Flags: review?(mconnor) → review+
(Assignee)

Comment 7

13 years ago
Checking in toolkit/themes/winstripe/global/browser.css;
/cvsroot/mozilla/toolkit/themes/winstripe/global/browser.css,v  <--  browser.css

new revision: 1.12; previous revision: 1.11
done
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
(Assignee)

Comment 8

13 years ago
Comment on attachment 210585 [details] [diff] [review]
patch2

I need approval for the 1.8.1 branch, right?
Attachment #210585 - Flags: approval-branch-1.8.1?(mconnor)

Updated

13 years ago
Attachment #210585 - Flags: approval-branch-1.8.1?(mconnor) → approval-branch-1.8.1+

Updated

13 years ago
Flags: blocking1.9a1?
Flags: blocking-firefox2?
Assignee: nobody → martijn.martijn
Checked in on the 1.8 branch.
mozilla/toolkit/themes/winstripe/global/browser.css; new revision: 1.9.4.5;
Keywords: fixed1.8.1
Target Milestone: --- → Firefox 2 alpha2
Version: unspecified → 2.0 Branch
Verified with Windows, Mac and Linux 2.0b1rc3 builds 
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1 → verified1.8.1
You need to log in before you can comment on or make changes to this bug.