Possibly triggered by bug 746421 - any chance you could confirm this using mozilla-inbound or local builds? I wonder if the tab-strip is looking at visual overflow rects somewhere (rather than frame dimensions) to determine whether things are overflowing.

Could this also be responsible for the behavior I'm seeing where the tab bar doesn't snap to the right when I close a tab? (Instead, it leaves a huge space until I manually scroll the remaining tabs right.)

Quite possibly.
It seems like the (mis)behavior is dependent on the length of the title of the rightmost (visible) tab... the tab bar is behaving as though it's using the full width of that tab's title to compute the amount of scroll that may be needed, even though the title is actually truncated to fit within the tab. So if I have a rightmost tab with a title that's only slightly longer than can be displayed, the tab strip scrolls to leave a small blank area at the right; but if my rightmost tab has a really long title, the amount of "overscroll" is correspondingly greater.

After a little more experimentation - the scrollable extent of the tab bar seems to be based on the "visual overflow" areas that would be computed for *all* the tabs (not just the rightmost one) if they were displaying their full titles. So a long (but truncated) tab title that's somewhere in the middle of the tab bar can still cause an excess scrollable extent, if it's long enough that its full form would project beyond the actual right edge of the last tab.
At this point, it seems to me that this indicates an error in the tab bar (it shouldn't be using untruncated title strings as a basis for computing the scrollable extent, as this doesn't at all reflect the actual size of the tabs). It may be that bug 746421 triggered this by causing more textboxes to report that they have an overflow of some kind, and this is making the tab bar try to take it into account (but it's doing so incorrectly), but I'm not sure bug 746421 by itself would cause these symptoms if the tab bar were using the right basis for its computations.

Created attachment 619426[details][diff][review]
patch
(In reply to Jonathan Kew (:jfkthame) from comment #7)
> At this point, it seems to me that this indicates an error in the tab bar
> (it shouldn't be using untruncated title strings as a basis for computing
> the scrollable extent, as this doesn't at all reflect the actual size of the
> tabs).
The tab strip uses an overflow:hidden frame which it doesn't compute the bounds for. I don't even know what DOM API it would use to do what you describe, or why such an API should exist in the first place.
It seems to me that bug 746421 just incorrectly didn't take cropping into account.

Hmm, I was just about to post the same patch as a possible workaround. Yes, I think bug 746421 should have used the cropped title.
However, I still think there's a deeper issue here; whether the tabs are considered to be scrollable should not depend on the "visual overflow" area but on the "scrollable overflow", which shouldn't have been affected by bug 746421 in the first place.

(In reply to Dão Gottwald [:dao] from comment #8)
> It seems to me that bug 746421 just incorrectly didn't take cropping into
> account.
Neil thought the same in bug 746421 comment 13. However, see also bug 746421 comment 14. So maybe there's more wrong here. My patch fixes the specific issue this bug was filed for, though, as far as I can tell.

Ah - on looking again, there's a different problem in bug 746421 - it actually stores the "ink bounds" as both visual *and* scrollable overflow, which doesn't seem right. And that would explain the problem here.

Created attachment 619432[details][diff][review]
patch, distinguish scrollable from visual bounds for nsTextBoxFrame
I think this fixes the overflow calculations in nsTextBoxFrame more correctly. Note that with the visual/scrollable distinction made properly, even using the uncropped title for the visual overflow calculation would no longer cause the tab-strip problem.

I am tempted to raise the severity here to blocker, except that the patch here does fix it so I am creating my own builds without this issue. Otherwise this would be enough to prevent me from using these builds myself.

Created attachment 619544[details][diff][review]
reftest for unwanted scroll-overflow due to cropped textbox label
OK, let's have a reftest as well. I don't really speak XUL, but after a little experimentation, this seems to work to verify that a cropped title doesn't lead to a spurious scroll-overflow area.