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)

defect
Not set
blocker

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).
Marking NEW.
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
No
Target Milestone: mozilla0.9.4 → mozilla1.0
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
v
Status: RESOLVED → VERIFIED
Status: VERIFIED → RESOLVED
Closed: 23 years ago15 years ago
Resolution: WONTFIX → DUPLICATE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.