This is spun out from bug 1398416. Background: In that bug, we call
PlacesSearchAutocompleteProvider.parseSubmissionURL from the muxer, and that method depends on
PlacesSearchAutocompleteProvider being initialized, but the muxer doesn't call
PlacesSearchAutocompleteProvider.ensureReady anywhere. So the muxer try-catches its call and depends on the fact that other parts of the urlbar trigger a
PlacesSearchAutocompleteProvider initialization at some (early) point. We could have called
ensureReady right before
parseSubmissionURL, but we didn't want to make
muxer.sort async due to a single one-time initialization.
However, the only thing
parseSubmissionURL ultimately depends on is search service initialization, and unlike the other
PlacesSearchAutocompleteProvider methods, it's sync and doesn't init the search service itself. Also, there's only one other caller of
PlacesSearchAutocompleteProvider.parseSubmissionURL, in UnifiedComplete's search-restyling logic (which is disabled).
There are a couple of actions here:
PlacesSearchAutocompleteProvider.parseSubmissionURL and instead call
- Make sure we initialize the search service at some point before the muxer calls
Services.search.parseSubmissionURL. There are at least a few options:
- Introduce an async
muxer.init method that the default muxer would use to init the search service.
- Do it as part of the very first query in the urlbar (e.g., in
- The muxer isn't the only consumer of the search service in the urlbar. There's also the other methods of
PlacesSearchAutocompleteProvider and the value formatter. So maybe the urlbar should init the service early on, so that each consumer doesn't need to do it. That seems tricky though because we'd still want to do it lazily, and it would still be async, so consumers likely still couldn't avoid awaiting a promise.