324447 - contents of tab move up a pixel as it closes

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 1

[Daniel C]

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).

Comment 2

[Martijn Wargers (dead)]

Attachment: 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.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

(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?

Comment 4

[Martijn Wargers (dead)]

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.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

(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?

Comment 6

[Martijn Wargers (dead)]

Attachment: patch2

This fixes it for me and is safe.

Comment 7

[Martijn Wargers (dead)]

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

Comment 8

[Martijn Wargers (dead)]

Comment on attachment 210585 [details] [diff] [review]
patch2

I need approval for the 1.8.1 branch, right?

Comment 9

[:Gavin Sharp [email: [e-mail]]]

Checked in on the 1.8 branch.
mozilla/toolkit/themes/winstripe/global/browser.css; new revision: 1.9.4.5;

Comment 10

[Tracy Walker [:tracy]]

Verified with Windows, Mac and Linux 2.0b1rc3 builds