1736722 - Windows uses expensive COM IVirtualDesktop APIs on UI thread during startup

Status: NEW

(Core :: Widget: Win32, task, P2)

Description

[David Parks [:handyman]]

The nsIWidget methods GetWorkspaceId and MoveToWorkspace are (on Windows) backed by very expensive COM calls (IVirtualDesktop). These calls happen on the UI thread. I don't have time estimates but they are slow enough that they cause bugs in interacting with the OS, like bug 1661127. It is usually a bad idea to do system COM operations on the UI thread. It certainly slows initial browser launch.

Bug 1661127 was resolved with a simple, imprecise cache for the value in GetWorkspaceId, which works because that method is excessively used. It is essentially called for any window event that might indicate the window has moved (to another virtual desktop or not).

Unfortunately, the cache doesn't help at startup since it obviously isn't populated. We could (but don't) try to cache the value off-thread in the constructor, but this would be a kludge to avoid the real issue, that we don't need to read the workspace while the browser is starting since the user doesn't have time to move the window anyway.

We call both GetWorkspaceId and MoveToWorkspace during startup to restore windows to their right virtual desktop. So that's at least two expensive calls per window. And GetWorkspaceId is called more than once (but the new cache reduces that cost).

I tried basic things to get SessionSaver/SessionStore to only require getCurrentState to actually use COM to fetch a desktop ID value when truly needed, but the caching strategy there is complex and my attempts ended up not always updating when needed. We should find a way to allow these calls to at least be asynchronous and off-UI-thread during startup (for both methods)