576424 - We need to know when sessionstore is available

Status: RESOLVED FIXED

(Firefox Graveyard :: Panorama, defect)

Description

[Ian Gilman [:iangilman]]

Sessionstore is not available immediately when TabCandy starts up, and we're doing a 100ms timeout to wait for it, but really we should be waiting on some indicator or event, rather than assuming 100ms will do it. 

I suppose the interface for this can be: 

Storage.onReady(callback);

Comment 1

[Ed Lee :Mardak]

Pretty sure session-store sends out a notification when it's ready. We'll need to add an observer to watch for it (assuming we load before it). Or alternatively we can just have something in the tabcandy code get called from sessionstore.

Comment 2

[Raymond Lee [:raymondlee]]

The  only session-store notification is sent out to indicate that all initial browser windows have opened. 
https://developer.mozilla.org/en/Observer_Notifications
sessionstore-windows-restored

I think it might be better to have session store to call tabcandy code.

Comment 3

[Raymond Lee [:raymondlee]]

Attachment: Patch

The session store would fire a "sessionstore-window-loaded" notification after it's setup for a window.  The tab candy observes that topic and loads the appropriate code.

Comment 4

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(In reply to comment #3)
> Created an attachment (id=455622) [details]
> Patch
> 
> The session store would fire a "sessionstore-window-loaded" notification after
> it's setup for a window.  The tab candy observes that topic and loads the
> appropriate code.

I don't see a need for another topic. The browser sends a notification for "browser-delayed-startup-finished", which is fired after sessionstore is init'ed. I don't think you need to go through sessionstore.

Or maybe you should just do something from delayedStartup yourself.

(In reply to comment #2)
> https://developer.mozilla.org/en/Observer_Notifications

Just FYI, that list is not kept up to date (though it really should be).

Comment 5

[Raymond Lee [:raymondlee]]

Attachment: Patch

Thanks Paul for pointing out the "browser-delayed-startup-finished" topic.

Comment 6

[Ian Gilman [:iangilman]]

Is it possible to know if that event has already fired? 

One scenario I want to support is being able to refresh the tab candy page. This may not be a shipping feature, but during development it's quite useful. Unfortunately, this patch breaks that functionality, as the event never fires after the refresh (since the browser has already started up long before). 

Beyond that, I figure doing that check before waiting for the event is more robust than just assuming it hasn't fired yet.

Comment 7

[Ian Gilman [:iangilman]]

Raymond, I've refactored your fix in: 

http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central/rev/57d2d128c3ab

I hope you don't mind... just trying to keep the UI code cleaner by encapsulating the implementation at a lower level. 

I've also prepared it for being able to know if it's already ready. See line 54 of storage.js. Can you please fill out the missing functionality? To test, use the "refresh" command on the "dev menu" in the lower right of the TabCandy interface.

Comment 8

[Raymond Lee [:raymondlee]]

Attachment: Patch 2

Yes, it's better to encapsulate in a lower level.  Here is another patch.

Comment 9

[Ian Gilman [:iangilman]]

Cool. Patch applied: 

http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central/rev/b2f8b5c7cd04

Comment 10

[(no longer active)]

Mass moving all Tab Candy bugs from Mozilla Labs to Firefox::Tab Candy.  Filter the bugmail spam with "tabcandymassmove".