384974 - Tabs occasionally get visually funky

Status: RESOLVED FIXED

(Camino Graveyard :: Tabbed Browsing, defect)

Description

[Chris Lawson (gone)]

Attachment: screenshot of strange tab rendering

See attached screenshot. This only started happening fairly recently, since around the time Stuart landed more tab tracking rect stuff. I haven't found reliable steps to reproduce yet, but it definitely happens every so often and then immediately goes away on changing tabs.

Comment 1

[froodian (Ian Leue)]

I bet it's a regrssion from bug 374623.  I haven't checked to see if the time-frame for that matches Stuart's work, but it looks a lot like bugs I saw during dev versions of that patch.  Just to be sure, you're seeing this in real builds, right (not just your builds)?

Comment 2

[Chris Lawson (gone)]

Yeah, that's about the time I started seeing this in trunk nightlies. (I'm not running a debug build at the moment, nor have I been when I've seen this.)

cl

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: also funky

I've seen this once, too, in official branch nightlies.  I forget exactly what I did to "cause" it, but apparently I did remember to take this screenshot :p

Comment 4

[philippe (part-time)]

I've seen that regularly on trunk, mostly with my home-made builds.

STR
1. open n-1 number of tabs, with 'n' the total number of tabs possible without triggering the scroll arrows.
2. command-click a link to open a link in a new tab from any of the open tabs.
3. repeat to open another tab (triggers the scroll mechanism)
At this point I see that kind of overlap (I think it is an overlap).
Clicking on the right most tab or the right scroll arrow restores the tab(s).

Comment 5

[froodian (Ian Leue)]

Philippe, do you keep your window a certain width, or can you repro this with any window-width?

Comment 6

[philippe (part-time)]

My window is generally about 1100px wide. I don't resize it that often (mostly in the range 900~1100px). But yeah, I've seen that at various window widths.

I should add, my home-made builds have a wider than default minimum width (150 instead of 100 in BrowserTabBarView.mm). (that is why I didn't report the issue yet.)

Iirc, that funky behaviour changed when something changed with the arrows on the right side.
I did repro it for sure with an official build.

Comment 7

[Stuart Morgan]

Attachment: fix

Definitely a regression from the frame size change.

Comment 8

[philippe (part-time)]

(In reply to comment #7)
> Created an attachment (id=271180) [details]
> fix

I've been using this patch for a couple of days, and this sure fix the funky behaviour on my side.

Comment 9

[Håkan Waara]

Comment on attachment 271180 [details] [diff] [review]
fix

I think it would be nicer to just init the overflow buttons once and for all in awakeFromNib:, and remove ensureOverflowButtonsInitted.

Comment 10

[Stuart Morgan]

I open lots of windows I never open tabs in, and more that I never open more than a few tab in. Lazy resource loading is generally a good thing.

Comment 11

[Håkan Waara]

Comment on attachment 271180 [details] [diff] [review]
fix

Yeah, I guess it would be cleaner code-wise but not as efficient.  

However, the NSImage instance would only be loaded once (if it's in memory along with the rest of the nib) right?

I couldn't find any other places where overflow buttons would not be ensured to be initialized before needed, so looks good to me.

Comment 12

[Stuart Morgan]

Landed on trunk and MOZILLA_1_8_BRANCH.