352859 - Notify at start and end of restore operation

Status: RESOLVED FIXED

(Firefox :: Session Restore, enhancement)

Description

[Eric Shepherd [:sheppy]]

It would be very helpful if there were events sent when restoring starts and stops.  For example:

SSRestoringBegin

<handle all restoring>

SSRestoringComplete

This would let extensions that need to behave differently on tab opens and closes while restoring know when restoring is underway so they can adjust their behavior appropriately.

Comment 1

[Simon Bünzli]

Two issues:
* These notifications would have to be global notifications and not tabbrowser specific events since during the restoration browser windows might be opened and closed.
* The end of the restoration process is quite difficult to track since individual tabs might be closed or additional tabs opened during the restoration operation (this also means that e.g. not every TabOpened event would have to be due to the restoration process between the two notifications).

All in all, I'm not sure whether such notifications would really bring additional value to the tab-specific SSTabRestoring and SSTabRestored events.

Eric: Can you specify a use case in which the existing events aren't enough (and which would not be bothered by the two issues mentioned above)?

Comment 2

[Eric Shepherd [:sheppy]]

Well, maybe there's another way to deal with what I'm trying to do that led me to file this suggestion.

If you have an extension that wants to be able to display different data in the status bar depending on which tab is visible, and have unique data for each tab, it's currently very difficult to initialize the tabs' values during the restore of a session.

The problem is that all tabs are being opened before SSTabRestoring is sent, which means that if you need to initialize tabs when they're opened, but initialize them differently depending on whether they're being restored or are actually new tabs, there's currently know way to know which scenario is the case, since looking in the session store data for the tab doesn't work since it's not restored yet.

This is a problem since (for example) in addition to tabs that are being restored, the "You've upgraded to a new version of Firefox" tab is also opened before the first SSTabRestoring, which means that you don't know which tabs are being restored and which are new.

In my case, I'm trying to write an extension that tags every tab in a window with a unique number that is never reused during the lifetime of the window, and is saved in the session store.  When restoring after a crash, I run into this problem where opening the upgraded Firefox tab is indistinguishable from opening the other tabs, so I don't know whether or not to assign it a new value or wait for the value to get restored when SSTabRestoring is sent.

Comment 3

[Simon Bünzli]

The notifications requested would not help in the case you mention since (1) during a session restoration, tabs may be reused instead of newly created and (2) as mentioned in comment #1, unrelated tabs may be opened before the restoration process is over.

You really have to assume a tab is new unless SSTabRestoring is dispatched for that tab (which BTW might happen several times for the same tab - when the tab is reused during more than one session restoration).

What might rather be useful is an event on a window when the window's features have been restored, so that extensions relying on get/setWindowValue know when to re-retrieve the values. That could happen on the first SSTabRestoring event as well, though.

Comment 4

[Simon Bünzli]

We now have a "sessionstore-windows-restored" notification which mostly indicates that the restore operation is about to end soon (you'll still get the tab specific events later, though) and which pretty much does what I've described as "might be useful" in comment #3.

Eric: Is there anything else to be done here?

Comment 5

[Eric Shepherd [:sheppy]]

Sounds good to me.  Thanks.

Comment 6

[Simon Bünzli]

Right, so one of the notifications is there and the other one can always be added in a new bug should a use case come up. -> FIXED