Here's a profile: https://perfht.ml/2VTGlot

There's about half a second of jank here when I pressed a keyboard button for the first time in this session.

Here's the important stack:

areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
areDirectoryEntriesWriteable
getElevationRequired
aus_gCSUS
get
getCanStageUpdates
get canStageUpdates
XPCWrappedJS method call
get updateStagingEnabled
get isReadyForRestart
check
checkForBrowserUpdate
isActive
tryMethod
InterpretGeneratorResume
AsyncFunctionNext
promise callback

This is from a local build with a relatively new profile, built from https://hg.mozilla.org/mozilla-central/rev/47426d145e24.

This is where the URL bar code hands off to the updater: https://searchfox.org/mozilla-central/rev/b8fbb6ead517720daf0b0211115f407b4b951c74/browser/components/urlbar/UrlbarProviderInterventions.jsm#681

Yeah, that makes sense. I'll see what we can do. Ideally the updater service or whatever is doing the sync IO would stop doing that!

Maybe we could skip serving the update interventions until the update svc is ready, if I/O is not evitable?

Seems similar to bug 1620576 where the urlbar was also triggering main thread I/O from the update service.

I don't see any way to fix this while preserving update checks except for practically rewriting AppUpdater.jsm to use async file IO (i.e., OS.File). The stack in comment 0 is checking whether staging is possible. We could rewrite only that stack to use async IO, but then some other stack will probably show up in different circumstances since the updater does sync IO all over the place. Then we'll fix that, and so on.

There's not really a notion of the updater being ready and waiting until then. For example, the staging result is cached when it's first calculated, but the only things that cause it to be calculated are checking for updates, logging the update status, and handling a downloaded update. In the case of this bug, we're checking for updates. So the only way to avoid that is to hope that some other part of the browser checked for updates before we did.

The only quick fix I can think of is to have the urlbar do an initial update check on idle and just not serve the update intervention until then.

If we're OK with the urlbar having out of date update info, then we could avoid having it do update checks at all. It could just listen for checks. Firefox checks for updates every 12 hours by default, so maybe that's OK. (Users who have disabled automatic update checks will be out of luck, but if they've disabled checks, they might be OK with not seeing the update intervention anyway.) We would probably still want to address the case where Firefox starts but doesn't immediately do a check. We could persist the previous update check result in a pref or file, and the urlbar could use that persisted result until the next check happens.

Oh, another quick fix would be to not check for updates until the update intervention is triggered. That might even be the right thing to do regardless... But it would probably also mean that the first update intervention the user sees would be out of date and incorrect, since the check wouldn't have time to complete and we don't have a dynamically updating UI.

Edit: And obviously that would just postpone the jank until then. But better than at the first urlbar use.

As a quick fix to bug 1632918, don't check for app updates until the user
triggers the update intervention. There will still be some jank, but it'll be
postponed until the user types a phrase that triggers the intervention, which is
much better than at the first urlbar use. To avoid the problem where we wouldn't
show an intervention at all the first time the update intervention is triggered
since the updater status in that case will be CHECKING, add an updater listener
to wait for the check to finish and add our result then.

We should look into a better long-term fix, like making the updater's IO async
or not checking for updates at all inside urlbar.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=23091faf05c06a3f65abc0db1f5f07ef30c6e4d3

https://treeherder.mozilla.org/#/jobs?repo=try&revision=8e2c70f6b725dbcb437733d7862f13b93d29202f

https://hg.mozilla.org/mozilla-central/rev/86ddde685cfa