[Session Restore] Async APIs for session restore

NEW
Unassigned

Status

()

Firefox
Session Restore
5 years ago
4 months ago

People

(Reporter: Yoric, Unassigned)

Tracking

(Blocks: 2 bugs)

unspecified
Points:
---
Dependency tree / graph
Bug Flags:
firefox-backlog -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [e10s])

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.
Blocks: 669034
No longer depends on: 838577
Blocks: 932266

Updated

4 years ago
Whiteboard: [e10s][Async] → [e10s]

Updated

4 years ago
Flags: firefox-backlog?
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 :)
Flags: firefox-backlog? → firefox-backlog-
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.
You need to log in before you can comment on or make changes to this bug.