944555 - Tab menu is amazingly slow and scrolling is buggy

Status: RESOLVED WORKSFORME

(Firefox :: Tabbed Browser, defect)

Description

[Richard Newman [:rnewman]]

Sorry, too lazy to file these separately.

1. Open 30 tabs or so.
2. Click the 'v' menu in the tab strip.
3. Observe the horrific slowness as you move the mouse:
  * The cursor highlight runs like an injured tortoise after the hare-like pointer.
  * Visible beneath the menu is the link-hover pseudo-toolbar showing the destination URL. This lags, too.
  * Hover scrolling (i.e., hover over the up/down arrows at the top/bottom of the list is jerky and slow.

For extra emphasis if, like me, you're on a machine with enough horsepower to hide perf problems: start an eight-core build, then see how bad this gets.


Second issue: scrolling in this menu is incredibly unreliable. I've observed the following:

* The menu scrolls on its own, fighting with my mouse scrolls, even with my mouse pointer in the middle of the menu. It's as if it hasn't figured out that I'm no longer hovering over the 'up' bar, which you have to cross to get from the button to the middle of the menu. To get this to go away one has to point at the 'up' bar again.

* The menu scrolls in reverse, as if I were using an earlier release of Mac OS X -- finger scrolling up moved the menu up, not down. This went away when I closed the menu to file this bug.


Possibly related to Bug 943385, but my history menu doesn't have a scrollbar, so I can't verify.

* And, of course, scrolling is slow.

Comment 1

[:Gijs (he/him)]

The dumb thing is, I don't think we changed the tab dropdown menu at all. Can you try a holly build and see if you reproduce the same stuff there?

Comment 2

[Richard Newman [:rnewman]]

(In reply to :Gijs Kruitbosch from comment #1)
> The dumb thing is, I don't think we changed the tab dropdown menu at all.
> Can you try a holly build and see if you reproduce the same stuff there?

Will do (though probably after Thanksgiving).

It's quite possible that this is a long-standing issue; I'm simply forced to use it now that Vertical Tabs hasn't yet been updated to work with Australis.

Comment 3

[:Gijs (he/him)]

Hmm. On 10.9, I do also see a bunch of these warnings in my console when scrolling:

Jan  1 00:59:59 gkruitbosch-16516.local firefox[18825] <Error>: CGContextTranslateCTM: invalid context 0x0. This is a serious error. This application, or a library it uses, is using an invalid context  and is thereby contributing to an overall degradation of system stability and reliability. This notice is a courtesy: please fix this problem. It will become a fatal error in an upcoming update.

Furthermore, the menu has a weird scrollbar-like thing on the right which appears in the weirdest situations. Markus, would you know anything about that?

(I initially suspected we were getting scroll events from ourselves because the binding for that menu attaches a scroll handler - but it attaches it in a part of the tabstrip that doesn't capture scrolling in the menu (fortunately!).

My other suspicion is essentially just the DOMMenuActive/InActive stuff that calls XULBrowserWindow.setOverLink. Throttling that will probably help.

Comment 4

[:Gijs (he/him)]

At least here, I see the same stuff on beta (!) and Australis, so I'll move this. rnewman, if you see a marked difference on Australis vs. Holly, please re-add the blocking status.

(I do think we should fix this ASAP because it's pretty bad - even on a non-churning beefy MBP from earlier this year, I can see a small amount of lag)

Comment 5

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #3)
> My other suspicion is essentially just the DOMMenuActive/InActive stuff that
> calls XULBrowserWindow.setOverLink. Throttling that will probably help.

(I meant DOMMenuItem[In]Active, but whatever)


Oh. So it turns out that setOverLink isn't even simple. Worse, it adds a mousemove listener to the window. Yeah, I could see how that doesn't work well...

Comment 6

[Richard Newman [:rnewman]]

Clearing needinfo for me; I trust your testing, Gijs!

Comment 7

[Markus Stange [:mstange]]

I don't know why this has suddenly become so bad. A regression window would be very helpful.

We spend a lot of time in CGSDeviceLock / _CGSLockWindow / _CGSSynchronizeWindowBackingStore, which usually means that we're interleaving OpenGL drawing and unaccelerated drawRect drawing to the same window. But I don't think that's what's happening. Maybe the issue is that the main window is accelerated and the popup menu isn't, and drawing both at the same time is bad... if that's the case, we can probably only fix it by making popups accelerated.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Smooth for me on Windows. How's it for you on OSX, Richard?

Comment 9

[Richard Newman [:rnewman]]

Much better.