Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Creating a global function

2 views
Skip to first unread message

Ulrich

unread,
Dec 30, 2009, 5:37:36 PM12/30/09
to
Hi,
I am new to developing firefox extensions.
I want to create an extension that executes some functions
(xmlhttprequests, etc.) in the background. They should update data
that my extension displays. The problem is that I do not want to
execute these functions for every single window, because that would
waste resources, especially if a user opens and closes windows often.
So I need a way to run them globally.

My current implementation of the extension looks like this and does
not include such a "global function".

var myextensionname = {
onLoad: function()
{
//do stuff
},

onUnLoad: function()
{
//do stuff
},

// some other interesting functions
}
window.addEventListener("load", function(e) { myextensionname.onLoad
(); }, false);
window.addEventListener("unload", function(e)
{ myextensionname.onUnLoad(); }, false);


Now I want to declare a "global function" somefunction() that should
be called on application startup. It will then make an asynchronous
xmlhttprequest which will, after being successful, execute somefunction
() again via setTimeout(). And so on.
So the whole thing should run in the background as long as firefox is
running. Even if the user opens a second browser window and closes the
first one.

My second problem is that these background workers should also fire
events so that my normal functions can update the window contents with
the new data.

I would like to know the best way to implement this. Is this
documented somewhere or are there examples?

Kind regards,
Ulrich

Ulrich

unread,
Jan 2, 2010, 7:10:07 AM1/2/10
to
I have finally found some documentation after reading this thread:
http://forums.mozillazine.org/viewtopic.php?f=19&t=367298
I am now using an XPCOM object that has a function startup(data) which
is called from my onLoad function when the user opens a window. After
the first call, it sets a variable firstrun to true, so that it is
only started once. The startup-function in the XPCOM object then
starts a thread which does the background work.

But one problem is left. The background thread is doing some work,
that may take longer than a few seconds. If the user quits firefox
while the background thread is running, firefox will wait until the
background thread finishes. Calling nsIThread shutdown() on
application shutdown does not work, because shutdown() does not kill
the thread. Is there a function to kill a thread, or isn't that
possible?

Eric Jung

unread,
Jan 4, 2010, 3:54:08 PM1/4/10
to dev-ext...@lists.mozilla.org
On Sat, Jan 2, 2010 at 7:10 AM, Ulrich <miere...@googlemail.com> wrote:
> I have finally found some documentation after reading this thread:
> http://forums.mozillazine.org/viewtopic.php?f=19&t=367298
> I am now using an XPCOM object that has a function startup(data) which
> is called from my onLoad function when the user opens a window. After
> the first call, it sets a variable firstrun to true, so that it is
> only started once. The startup-function in the XPCOM object then
> starts a thread which does the background work.
>
> But one problem is left. The background thread is doing some work,
> that may take longer than a few seconds. If the user quits firefox
> while the background thread is running, firefox will wait until the
> background thread finishes. Calling nsIThread shutdown() on
> application shutdown does not work, because shutdown() does not kill
> the thread. Is there a function to kill a thread, or isn't that
> possible?
>

You might find it easier to use a singleton JS module instead of a
singleton XPCOM component. Concerning killing of the thread, thread
manangement from extension javascript has been notoriously difficult
in the past. It might be easier (albeit not more performant) for your
thread to periodically check if any navigator:browser windows are open
and, if not, fall through:

var wm = Components.classes["@mozilla.org/appshell/window-mediator;1"]

.getService(Components.interfaces.nsIWindowMediator).getMostRecentWindow("navigator:browser");

if (wm) { /* do stuff */ } else { /* end */ }

Eric

Neil

unread,
Jan 4, 2010, 4:21:51 PM1/4/10
to
Eric Jung wrote:

>It might be easier (albeit not more performant) for your thread to periodically check if any navigator:browser windows
>

No! DOM objects, including windows, may only be used on the main thread.

--
Warning: May contain traces of nuts.

Ulrich

unread,
Jan 5, 2010, 6:58:53 AM1/5/10
to
On Jan 4, 9:54 pm, Eric Jung <eric.j...@yahoo.com> wrote:
>
> You might find it easier to use a singleton JS module instead of a
> singleton XPCOM component.
Well, I have imlemented the whole XPCOM component in the meantime, but
it is good to know for the future.

> Concerning killing of the thread, thread
> manangement from extension javascript has been notoriously difficult
> in the past.

"Difficult" means it is possible? I could only find the function
shutdown(). In the XPCOM component, I observe "quit-application" and
when the app quits, I tried to use this.mythread.shutdown(), but this
waits for the thread to finish (which could take some time). I've also
tried this.mythred = null: same problem.
The thread would only be used for some XML processing, so a hard kill
would be no problem.

> It might be easier (albeit not more performant) for your
> thread to periodically check if any navigator:browser windows are open
> and, if not, fall through:
>
> var wm = Components.classes["@mozilla.org/appshell/window-mediator;1"]
>
> .getService(Components.interfaces.nsIWindowMediator).getMostRecentWindow("navigator:browser");
>
> if (wm) { /* do stuff */ } else { /* end */ }

Good idea. I could also use a global variable "this.stopThread" in the
XPCOM component and set it to true in my observer. It works. But
killing the thread would be better.

Kind regards,
Ulrich

Neil

unread,
Jan 5, 2010, 7:28:31 PM1/5/10
to
Eric Jung wrote:

>This is only checking the existence of the window, not manipulating it or its contents in any way. Are you saying even that won't behave on a worker thread?
>
>
Just looking at a window adds a reference to it, which is already unsafe.

0 new messages