Closed
Bug 64794
Opened 24 years ago
Closed 15 years ago
No way for plugins to access browser services
Categories
(Core Graveyard :: Plug-ins, defect)
Core Graveyard
Plug-ins
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 386773
mozilla1.0
People
(Reporter: steve.katz, Assigned: serhunt)
Details
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).
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?).
Comment 4•24 years ago
|
||
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.
Reporter | ||
Comment 5•24 years ago
|
||
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.
Comment 7•24 years ago
|
||
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.
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
Reporter | ||
Comment 10•23 years ago
|
||
No
Comment 11•23 years ago
|
||
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
Closed: 23 years ago
Resolution: --- → WONTFIX
Comment 13•15 years ago
|
||
Status: VERIFIED → RESOLVED
Closed: 23 years ago → 15 years ago
Resolution: WONTFIX → DUPLICATE
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•