Bug 838577 introduces async APIs for session restore. For the moment, these APIs can be used only by tests. With e10s, we need to offer only async APIs. We need to: - either publish these async APIs or some better-designed APIs; - convert clients to these new APIs.

The current approach is to support the old API and yet having an asynchronous sessionstore that is e10s compatible. Some of the existing methods are already async in that you will have to wait for an event or a notification to know when we're done. While this is certainly not ideal I don't think changing this and breaking tons of add-ons is worth investing time currently or in the near future. There are lots of other bigger sessionstore rewrites that would actually affect users and we should concentrate on those :)

I believe it would be interesting to expose an async "wait()" API that only resolves once all ongoing messages have been treated. For the rest, we can keep the current API for the time being.

(In reply to David Rajchenbach Teller [:Yoric] (please use "needinfo?" - I'll be away on April 9th-16th) from comment #2) > I believe it would be interesting to expose an async "wait()" API that only > resolves once all ongoing messages have been treated. For the rest, we can > keep the current API for the time being. Which messages exactly are you referring to?

For the moment, I mean doing something equivalent to `SyncHandlers.get(browser).flush()` (for all browsers).

Oh, yeah. We want to get rid of that in the future but I'm not sure that's an API we want to expose. We also have bugs open for all those places that call .flush().

I believe that the following is a useful pattern: 1. Programmatically cause some change in a tab. 2. ? 3. Get some part of the state of the browser. Since 3. is synchronous, the best we can do for the moment is to make it blocking. If we could have a step 2. that returns a promise once 3. is available without blocking, this would be nice. Not a priority, though.

If I'm understanding this bug correctly, there's no direct performance consequences to keeping things as they are. It can just be cumbersome to use the APIs. If I'm misunderstanding this and thus incorrectly triaging the bug for fxperf, please let me know.