68506 - npsimple needs a custom factory and module

Status: VERIFIED WONTFIX

(Core Graveyard :: Plug-ins, defect, P3)

Description

[Braden]

I haven't been able to get npsimple working, either in 0.7 or current builds.
The plugin appears to register okay, but SimpleTest.html just shows a blank area.

Comment 1

[sean echevarria]

I think that on windows, SimpleTest.html doesn't work either.  Try
SimpleScriptableTest.html in the same directory.

Comment 2

[Braden]

SimpleScriptableTest.html is not working either on Linux.

When npsimple was working, both of these would produce a box with the GTK
background drawn. Now, that doesn't happen. I just see the page background color
in there area where the plugin should be.

Comment 3

[Braden]

I actually get a segfault when viewing either SimpleTest.html or
SimpleScriptableTest.html.

Comment 4

[karnaze (gone)]

Moving to mozilla0.9

Comment 5

[Arun Ranganathan]

Can someone verify this in latest builds?

Comment 6

[Peter Lubczynski]

cc:ing some people

Comment 7

[Arun Ranganathan]

This is probably tied in with Shaver's changes to nsIGenericFactory.h , a 
recently hot topic :-)
peterl, av, do you think we ought to change npsimple so that as an example it 
doesn't rely on this?

Comment 8

[Braden]

How long ago did Shaver make those changes? I can't check this with a current
build right now, but I have gotten a plugin working with the GenericFactory
macros using 0.8.0. I believe the problems with npsimple had to do with treating
the plugin window as a GdkSuperWin; when I treated it instead as a GdkWindow in
my plugin, it worked.

That said, the GenericFactory stuff is kind of a quick-and-dirty way of
implementing an XPCOM plugin; ideally, the plugin will provide its own factory
implementation which implements nsIPlugin. However, I've had some issues getting
that working recently, too...

Comment 9

[Peter Lubczynski]

Not sure what to do with this. Re-assign to Shaver as it looks like he knows 
what's up. Please move milestone if needed.

Comment 10

[Mike Shaver (:shaver emeritus)]

Sorry, Charlie, not my bug.

Write a custom factory and module for the plugin.  Pretend, as I instructed Jeff
Price, that NS_IMPL_GETMODULE and its ilk don't exist.

(I think my changes went in around 0.8.1 or so, but really, it's all a blur.)

Comment 11

[Marek Z. Jeziorek]

moving to 0.9.3 per PDT triage

Comment 12

[Peter Lubczynski]

We should get our examples correct! Is this still a mozilla0.9.3 blocker? Moving
to mozilla0.9.4, please correct me if I'm wrong.

Shaver or Waterson: could you please point me in the direction of a sample
module which takes the approach that should be applied here. I'm not clear as to
what I have to do and I want to get this right.

Also, looking for an example in LXR, I still see many modules, even newer ones,
using NS_IMPL_GETMODULE:
http://lxr.mozilla.org/seamonkey/source/modules/libpr0n/src/ImageFactory.cpp

Is this needed only for the static build? I going to get questions on this but
I'm not totally clear WHY this was done. Do you know of a bug #, faq, or
newsgroup post which I can educate myself with? Thanks!

Comment 13

[Chris Waterson]

Yeah, converting everything to NS_IMPL_NSGETMODULE helped make the static build 
work. Asking a plugin author to use this macro would be good for consistency's 
sake, even though we'd probably never statically link a plugin with mozilla. 
(But who knows -- maybe some embedded configuration could include statically 
linked plugins...)

Comment 14

[Braden]

Note Shaver's comment above re. NS_IMPL_GETMODULE. You *can* implement a plugin
like this (through the odd quirk that plugins aren't technically required to
implement nsIPlugin), but many plugins will need the functionality nsIPlugin
provides. Implementing nsIPlugin is really the Right Way to do it, and a proper
fix to the sample plugin ought to reflect this.

Comment 15

[Braden]

Peter: Basic design here: your nsIModule implementation will serve as a factory
for nsIPlugins, which will in turn serve as a factory for nsIPluginInstances.
The nsIPlugin implementation is a "class object" for the nsIPluginInstance objects.

Comment 16

[Peter Lubczynski]

--->Andrei

Can this be part of your SDK update?

Comment 17

[Braden]

Now that the XPCOM-based plugin API is deprecated, I suppose there's no point in
improving an example's use of that API.

-> WONTFIX

Comment 18

[shrirang khanzode]

v