Closed Bug 576424 Opened 13 years ago Closed 13 years ago

We need to know when sessionstore is available


(Firefox Graveyard :: Panorama, defect)

Not set


(Not tracked)



(Reporter: iangilman, Assigned: raymondlee)



(2 files, 1 obsolete file)

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: 

Assignee: nobody → raymond
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.
The  only session-store notification is sent out to indicate that all initial browser windows have opened.

I think it might be better to have session store to call tabcandy code.
Attached patch Patch (obsolete) — Splinter Review
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.
(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)

Just FYI, that list is not kept up to date (though it really should be).
Attached patch PatchSplinter Review
Thanks Paul for pointing out the "browser-delayed-startup-finished" topic.
Attachment #455622 - Attachment is obsolete: true
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.
Raymond, I've refactored your fix in:

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.
Attached patch Patch 2Splinter Review
Yes, it's better to encapsulate in a lower level.  Here is another patch.
Cool. Patch applied:
Closed: 13 years ago
Resolution: --- → FIXED
Mass moving all Tab Candy bugs from Mozilla Labs to Firefox::Tab Candy.  Filter the bugmail spam with "tabcandymassmove".
Product: Mozilla Labs → Firefox
Target Milestone: -- → ---
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.