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

Extension migration from FF2 to FF3 and changes to nsIProxyObjectManager

34 views
Skip to first unread message

tx.c....@gmail.com

unread,
Sep 19, 2007, 11:51:49 AM9/19/07
to
In our current extension, we have code like the following to ensure
that code is run on the UI thread. The code below is an over-
simplification of the actual algorithm, just trying to show use
pattern. Decision was made to use this pattern based on
http://www.mozilla.org/projects/xpcom/Proxies.html and ease of coding.

In FF2, nsIProxyObjectManager.h defines appropriate macros for being
able to find the proxy manager (NS_XPCOMPROXY_CONTRACTID) or also
gives visibility to NS_GetProxyForObject().

--- example code begin

int MyObject::notify( unsigned long cmd ) {
nsresult rv;
nsCOMPtr<nsIProxyObjectManager> spProxyManager;
spProxyManager = do_GetService(NS_XPCOMPROXY_CONTRACTID, &rv);

nsCOMPtr<IMyObject> prox;
spProxyManager->GetProxyForObject(
NS_UI_THREAD_EVENTQ,
NS_GET_IID(IMyObject),
(IMyObject*)this,
PROXY_ASYNC | PROXY_ALWAYS,
(void**)&prox );

prox->processCommand( cmd );

}

--- example code end

In FF3, now it appears that these are trying to be "hidden" (use is
discouraged?)
- NS_XPCOMPROXY_CONTRACTID now defined in nsXPCOMCIDInternal.h
- NS_GetProxyForObject is now hidden behind #ifdef
MOZILLA_INTERNAL_API

In FF3, is there a new preferred way for communicating from worker
threads to the main thread? If so, is there a sample extension that
is already using this model?

Benjamin Smedberg

unread,
Sep 19, 2007, 7:49:59 PM9/19/07
to
tx.c....@gmail.com wrote:

> In FF3, now it appears that these are trying to be "hidden" (use is
> discouraged?)
> - NS_XPCOMPROXY_CONTRACTID now defined in nsXPCOMCIDInternal.h

This is not hidden/discouraged. This is the header file we use for contracts
that are not frozen. Go ahead and use it with the ordinary cautions about
that it may change in future releases and your code may stop working.

> - NS_GetProxyForObject is now hidden behind #ifdef
> MOZILLA_INTERNAL_API

This is correct: you cannot link against this method. However, you can use
regular XPCOM calls to do the work, e.g.

nsCOMPtr<nsIProxyObjectManager> proxyObjMgr =
do_GetService(NS_XPCOMPROXY_CONTRACTID);
if (!proxyObjMgr)
return NS_ERROR_FAILURE;

nsCOMPtr<nsIFoo> proxyObject;
nsresult rv = proxyObjMgr->
GetProxyForObject(targetThread, NS_GET_IID(nsIFoo),
object, nsIProxyObjectManager::INVOKE_ASYNC,
getter_AddRefs(proxyObject));

--BDS

Chris

unread,
Sep 20, 2007, 12:58:13 PM9/20/07
to
Would the following also work?

class MyEvent : public nsRunnable {
private:
unsigned long m_cmd;
nsCOMPtr<IMyObject> m_spMyObject;

public:
MyEvent( unsigned long cmd, IMyObject *pObj )
:m_cmd(cmd),
m_spMyObject(pObj) {}
NS_IMETHOD Run() { m_spMyObject->processCommand(m_cmd); }
}

int MyObject::notify( unsigned long cmd ) {

MyEvent *pMyEvent = new MyEvent( cmd, this );
NS_DispatchToMainThread(pMyEvent);
}

0 new messages