Due to the absence of IDL definitions of the interfaces that plugins and OJI plugins are expected to call to request browser services, nsISupports proxy functionality is broken. As a result, plugins that need to marshall data from their local threads into the main/ui thread (i.e all plugins) are incapable of doing so without using some kind of hack (such as the Java-Plugin's use of GTK event monitoring of pipes).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Patrick, George, how critical is this?
Target Milestone: --- → mozilla0.9.1
karnaze: I don't know how crucial it is. I'll ask the Java Plug-In group for their assessment; Steve Katz (the bug reporter) is part of that group. I know that Mozilla folks tried to IDL-ize the new-style Plugin interfaces months ago but we (Sun) vehemently asked them not to, because during that process some API(s) would have changed and therefore broken Java Plug-In. I'll see if Steve is willing to accept the trade-off, as I'm guessing an IDL-izing of the Plugin interfaces will introduce some API change (necessarily?).
Hmm, can't a plugin just use an nsIRunnable type interface, and have those calls proxied? That's what I'm doing in the MRJ plugin, and it works just fine.
Patrick, Where is what you are suggesting documented? Is this an exceptable/supported substitute for nsISupports proxies? They are what is documented as the "correct" way for threads to get called back in the main thread.
Moving to m0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Steven, there's no documentation, but it's what the MRJ plugin uses. A plugin could certainly implement the nsIRunnable interface, which is declared in mozilla/modules/oji/public/nsIThreadManager.h, and then calling nsIThreadManager::GetCurrentThread() to capture the main thread's ID (which is just an NSPR PRThread). To post a message to this thread, you then use nsIThreadManager::PostEvent(). This is all sugar over nsIEventQueue's. This code was written in the early days before XPCOM thread wrappers, and I notice that the thread ID typedef used by nsIThreadManager::GetCurrentThread() is inconsistent with nsIThreadManager::PostEvent(). Alas, somebody changed it in one place and forgot to change it in the other. I will file a bug on that.
Moving to m0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Reporter, can we say this is invalid, given there is a way to do what you need as per Patrick? Moving for now.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
The XPCOM plugin interfaces are now officially deprecated, and as such they will never be fully XPCOMized for proxying purposes. This is an unfortunate limitation, but one that can be worked around in other ways. On Mac OS X, I can use Carbon timers to get calls on the main event loop thread. However, there is no general XP solution to this problem.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → VERIFIED
Status: VERIFIED → RESOLVED
Last Resolved: 17 years ago → 9 years ago
Resolution: WONTFIX → DUPLICATE
Duplicate of bug: 386773
You need to log in before you can comment on or make changes to this bug.