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.
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)?
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
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).
Philippe, do you keep your window a certain width, or can you repro this with any window-width?
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.
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?
Attachment #271180 - Flags: review? → review?(nick.kreeger)
(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 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.
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 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+
Landed on trunk and MOZILLA_1_8_BRANCH.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Keywords: regression → fixed18.104.22.168
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.