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.
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).
(In reply to comment #2) > Created an attachment (id=210537)  > 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?
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?
Created attachment 210585 [details] [diff] [review] patch2 This fixes it for me and is safe.
Attachment #210585 - Flags: review?(mconnor) → review+
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
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)
Attachment #210585 - Flags: approval-branch-1.8.1?(mconnor) → approval-branch-1.8.1+
Assignee: nobody → martijn.martijn
Checked in on the 1.8 branch. mozilla/toolkit/themes/winstripe/global/browser.css; new revision: 184.108.40.206;
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.