1355061 - Interacting with statusbar items in the menubar blocks the UI thread for several hundred ms

Status: NEW

(Core :: Widget: Cocoa, defect, P2)

Description

[Florian Quèze [:florian]]

See this profile of clicking the microphone icon in the menubar: https://perfht.ml/2oR566A (I think the first 400ms of jank is clicking the microphone icon to show the popupmenu, and the second 400ms of jank is clicking a menu item).

If you need a test webrtc site to get the microphone icon to show up, you can use https://appr.tc/

Comment 1

[Markus Stange [:mstange]]

Native menus use a nested event loop, whose RunLoopMode is such that it does not process our Gecko event loop CFRunLoopSource, so no Gecko events are being processed while these menus are open. We might be able to register our CFRunLoopSource with a differen RunLoopMode mask. I don't know how valuable that would be. It might also cause lots of regressions.

Comment 2

[(no longer active)]

I think I agree with Markus.  I'm also not quite sure why this was marked as [qf:p1].  In my experience, OSX menu bar code can easily spend tens if not hundreds of milliseconds doing stuff regularly and there's not much that we can do about it.

I suggest we bump it down to [qf-].  Markus, do you agree?

Comment 3

[Markus Stange [:mstange]]

I think I was wrong about the nested event loops. The jank in this profile looks like it's coming from different sources.
The first piece of jank is compiling CoreImage shaders. This only needs to be done the first time such a popup is opened, and it's something we have no control over.
The second piece of jank is the blinking animation that is played if you click a menu item, and then the fade-out animation. The system chooses to block the main thread during those animations and there's nothing we can do about that.

Comment 4

[Florian Quèze [:florian]]

Here is a profile of the browser/base/content/test/webrtc/browser_devices_get_user_media.js test where this bug is the biggest source of jank: https://perfht.ml/2j3tKfU