No way for plugins to access browser services

RESOLVED DUPLICATE of bug 386773

Status

()

--
blocker
RESOLVED DUPLICATE of bug 386773
18 years ago
9 years ago

People

(Reporter: steve.katz, Assigned: serhunt)

Tracking

Trunk
mozilla1.0
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
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).

Comment 1

18 years ago
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

18 years ago
Patrick, George, how critical is this?
Target Milestone: --- → mozilla0.9.1

Comment 3

18 years ago
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

18 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

18 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 6

18 years ago
Moving to m0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 7

18 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.

Comment 8

18 years ago
Moving to m0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
(Assignee)

Comment 9

18 years ago
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

18 years ago
No
(Assignee)

Updated

17 years ago
Target Milestone: mozilla0.9.4 → mozilla1.0

Comment 11

17 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
Last Resolved: 17 years ago
Resolution: --- → WONTFIX

Comment 12

17 years ago
v
Status: RESOLVED → VERIFIED

Comment 13

9 years ago
https://developer.mozilla.org/en/NPN_PluginThreadAsyncCall
Status: VERIFIED → RESOLVED
Last Resolved: 17 years ago9 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.