So we can remove the sync init path, switch the API calls (mostly get*) to be async (keeping note of https://searchfox.org/mozilla-central/source/toolkit/mozapps/extensions/internal/XPIProvider.jsm#178, which we could, but probably dont want to use)
Florian has some thoughts here.
(In reply to Mike Kaply [:mkaply] from comment #1) > Florian has some thoughts here. Yeah, I probably have lots of thoughts, as I remember discussing related topics with both you and Mike de Boer, but it would be easier to answer a more specific question. Now that legacy add-ons are out of the picture, the most obvious remaining user of the sync init that I can think of is the user entering a word in the urlbar and pressing enter very quickly after startup (same applies to the searchbar, but it's not visible by default anymore). Passing a search term from the command line (ie. from another application or the operating system) is likely another one, but I suspect it's less common (although I haven't looked at data to back this claim). Somehow we'll probably want to make introduce a way to initialize the search service that's halfway between the current async init and the current sync init, ie. we would do the I/O asynchronously, but not wait for the results of network requests. I think bug 1492475 is going in this direction already.
Was splitting these out, but this work is being done in 1492475
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1492475
You need to log in before you can comment on or make changes to this bug.