461585 - Request for an event be sent when session/window load is complete and for a way to determine the reason a tab was restored (load or restoration of closed tab)

Status: NEW

(Firefox :: Session Restore, enhancement)

Description

[Michael Kraft [:morac]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1

In the Session Manager extension, I currently use the SSTabRestored event to trigger a reload of the tab if a reload option is set.  I only want this to trigger on a session load.  I do not want it to trigger for restored closed tabs.

Previously I used a tab value to determine if the tab was allowed to restore or not, but this required hooking into the undoCloseTab functionality in Firefox which was very messy and could easily break stuff.

I now count the number of tabs that should be restored and only reload that number of tabs.  Theoretically there should be a SSTabRestored event for every tab in the session, but I've found that that isn't always the case.

I've found that an SSTabRestored event is not sent:
1. If the user closes the window or tabs while the restore is in progress.
2. For blank tabs in Firefox 3.1 nightlies.


I can work around #2 above by checking if the tabs have entries lengths (messy but it works), but there is no reliable way to work around problem #1 since if closed fast enough there isn't even a close event notification.  Additional problems occur if the user decides to recover a closed tab while the load is taking place since that causes an additional SSTabRestored event to be triggered which also throws off my count.

There should be an event that gets sent once the session load has completely finished. 

There should also be a way to differentiate tabs restored by loading a session or tabs restored from a closed state.

Reproducible: Always

Comment 1

[Simon Bünzli]

We could probably refine the code we already use to dispatch the "sessionstore-windows-restored" notification on startup to be always sent after setBrowserState (with the notification's data allowing to distinguish between the two cases). The best we'll be able to reasonably offer will be a notification when all the tabs have started loading their content. Will that be late enough?

As for the second request, have you tried using setTabValue during the SSTabClosing event for marking the tab as closed and then proceed depending on getTabValue during SSTabRestoring/SSTabRestored (not forgetting to deleteTabValue that marker afterwards)?

Comment 2

[Michael Kraft [:morac]]

The "sessionstore-windows-restored" might be good enough though I'm not entirely certain.  As it is now I listen to both the SSTabRestoring and SSTabRestored events.  I don't really care about the SSTabRestoring event, but I use it to set a tab value which I then read in SSTabRestored.  If the tab value is already set in SSTabRestoring, which occurs if the user interrupts the load process (usually by closing the tab), then I can tell it's not part of the original load.  Unfortunately, with a larger number of windows/tabs loaded this only really has about a 60% success rate since the user can close the tabs before the loading even starts.  

I haven't tried using the SSTabClosing event, but I'll give it a try.  I guess it depends on whether or not my code has time to register for the event and if it triggers when tabs are closed "very very fast".

I was trying to limit the number of events I register for since I don't really care about tabs closing the vast majority of the time, so I'd say 95% of the time it would just be a waste of CPU cycles.

Comment 3

[Simon Bünzli]

(In reply to comment #2)
> the user can close the tabs before the loading even starts.

Note that the user can also reopen closed tabs before the session is completely restored, so for what I understand as your use case the difference between "session is loading" and "no session is loading" won't be good enough, anyway.

> I guess it depends on whether or not my code has time to register for the
> event and if it triggers when tabs are closed "very very fast".

Register during a window's "load" event should be soon enough for catching all of those (and then you're guaranteed to get SSTabClosing for each and every opened tab).

> I was trying to limit the number of events I register for since I don't really
> care about tabs closing the vast majority of the time, so I'd say 95% of the
> time it would just be a waste of CPU cycles.

You could try to add/remove your SSTabClosing event listener depending on when you really need it - then again, I doubt that anybody is going to notice those CPU cycles you're using at all.

Comment 4

[Michael Kraft [:morac]]

(In reply to comment #3)
> Note that the user can also reopen closed tabs before the session is completely
> restored, so for what I understand as your use case the difference between
> "session is loading" and "no session is loading" won't be good enough, anyway.
> 

I'm currently manually injecting tab value data into the session at load time so I know which tabs are loaded.  This value is then deleted when SSTabRestoring is called and another value is set which is then checked and deleted at SSTabRestored.  Originally I just set a value that was read in SSTabRestored, but then I hit the close/reopen issue.  In any case, knowing when the load cycle has finished (or finished starting) would allow me to disregard reopened tabs at a later time without resorting to potentially problematic things like timers or the like.

> Register during a window's "load" event should be soon enough for catching all
> of those (and then you're guaranteed to get SSTabClosing for each and every
> opened tab).
> 

Okay I'll try this.  Unfortunately this means that people running Firefox 2.0.0.x (and for some reason some people refuse to upgrade to Firefox 3.0.x) can still be affected by this but oh well.