Tabs occasionally get visually funky

RESOLVED FIXED

Status

Camino Graveyard
Tabbed Browsing
--
major
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: Chris Lawson (gone), Assigned: Stuart Morgan)

Tracking

({fixed1.8.1.6})

Details

Attachments

(3 attachments)

(Reporter)

Description

11 years ago
Created attachment 268887 [details]
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

11 years ago
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)?
(Reporter)

Comment 2

11 years ago
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
Created attachment 268894 [details]
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

11 years ago
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

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

Comment 6

11 years ago
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.

Updated

11 years ago
Blocks: 374623
(Assignee)

Comment 7

11 years ago
Created attachment 271180 [details] [diff] [review]
fix

Definitely a regression from the frame size change.
Assignee: nobody → stuart.morgan
Status: NEW → ASSIGNED
Attachment #271180 - Flags: review?
(Assignee)

Updated

11 years ago
Attachment #271180 - Flags: review? → review?(nick.kreeger)

Comment 8

11 years ago
(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

11 years ago
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.
(Assignee)

Comment 10

11 years ago
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

11 years ago
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.
Attachment #271180 - Flags: review?(nick.kreeger) → review+
(Assignee)

Updated

11 years ago
Attachment #271180 - Flags: superreview?(joshmoz)

Updated

11 years ago
Attachment #271180 - Flags: superreview?(joshmoz) → superreview+
(Assignee)

Comment 12

11 years ago
Landed on trunk and MOZILLA_1_8_BRANCH.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Keywords: regression → fixed1.8.1.6
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.