90272 - Can't access XPFE from plug-ins

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, enhancement)

Description

[CJS]

This a feature request rather then a bug report. Last week I set out to create a 
plugin for Mozilla which would install its own toolbar and scrollbars in the 
main browser window and render the image of an document (stored in an esoteric 
word processing format). I wanted to use the XPFE for everything so that I could 
share as much code for the plugin across different platforms, just as Mozilla 
itself does. After a week of research I've discovered that this isn't possible
because the traditional plugin API receives only a native window handeler and
I have it on authority from the XP GFX guys that its impossible to convert that 
into any sort of XP object. Therefore I'd like to request an enhancement to the 
plugin API that would pass an base XPFE object of some sort that would allow a 
plugin write to add XPFE widgets to the main browser window and/or draw graphics 
and text to the main browser using XP GFX functions. 

A plugin written in that matter would have to be rewritten for other browsers, 
but could be compiled for every platform Mozilla has been ported to with minimal 
effort. With the current API, you can write a plugin for multiple browsers but 
they can't be shared across platforms due to the differences in native widgets 
and rendering code.

Comment 1

[Boris Zbarsky [:bzbarsky]]

I think what you want is an XPCOM component.  You want to be using the new
XPCOM-component api, not the legacy 4.x-plugin API....

Comment 2

[CJS]

I can't tell if an XPCOM component is what I'm looking for or not. I've browsed 
the xpcom subdirectories, and the closest thing I can find to a plugin being 
implemented in XPCOM is the xmlterm program, and thats not really a plugin at 
all. Are there any examples in the source tree that show how to write a plugin 
with XPCOM? Or is this something that noone has ever done before?

Comment 3

[Boris Zbarsky [:bzbarsky]]

I presume you've looked at http://www.mozilla.org/docs/plugin.html ?

I think some people at Oeone (http://www.oeone.com/) have been working with
xpcom plugins...  I could try to look up an email of one of them if you'd like

Comment 4

[CJS]

Yep, I read that document. That API is just a C++ wrapper for the legacy 
plugin API. The SetWindow method, just like the SetWindow function of old, gets 
passed an nsPluginWindow structure, which is just some position information and 
a native window handle. I'm told that a native window handle can't be 
transformed into an XPFE object of any type, so you have to use native 
widgets/gfx to draw at this point.

Comment 5

[Boris Zbarsky [:bzbarsky]]

setting status to new.  Some people who may know something about implementing
xpcom plugins:

[e-mail]
[e-mail]

Just a thought.  The plugin should just be a component which implements the
plugin interfaces, right?  So if you choose to link against other Mozilla
headers as well (such as ones that let you use XUL) you should be OK....

Comment 6

[Peter Lubczynski]

I think you may be looking for this:
http://lxr.mozilla.org/seamonkey/source/xpcom/sample/

That is an XPCOM component sample (in Javascript too!) that you can build with
mozilla. From there, you can use macros like NS_WITH_SERVICE to get to whatever
browser services you need.

Comment 7

[av (gone)]

The 'traditional' plugin API now allows you to access the Mozilla service
manager which in turn will give you any available browser service (see bug
98285). Marking fixed now. Reporter, if this is not what you need please reopen.

Comment 8

[shrirang khanzode]

v