97488 - Modify 4x scriptable plugin sample to use nsIClassInfo

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[av (gone)]

After bug 96917 we can use simpler and cleaner mechanism to add scriptability to
legacy plugins and make it a preferred way for the task. The sample code in
modules/plugin/samples/4x-scriptable needs to be changed to reflect this.

Comment 1

[John Bandhauer]

The following is text I sent to av (and others) about the patch that I'll attach
to this bug. The change to nsIClassInfo.idl mentioned below has already been
checked in. I imagine av has other changes to add to the sample and might want
to modify the changes in my code before checkin. I'm just attaching it here for
visibility.

..................................................................

The plugin implementors need only inherit from the mixin and add
the nsIClassInfo case to their QueryInterface implementation.

We need to distribute nsIClassInfo.idl and
nsIProgrammingLanguage.idl.

I had to reorder nsIClassInfo to move a new post-6.1 method to
the end of the interface. We need to get that change into the
trunk soon if we are going to go this route. I hope we can
consider nsIClassInfo sort of frozen. If we need to add
additional methods in the future then we might have to rev its
iid - and have callers check for both :(  Or even add a constant
to the possible flags so that a given implementation can signal
that it has the 'new' methods. Yuk!

The two flags that matter for us are DOM_OBJECT and
PLUGIN_OBJECT. 

DOM_OBJECT is the magic cookie that makes the caps system
consider this scriptable without limitation. We discussed adding
a new defined name (but using the same number for b/w
compatibility) so that we wouldn't have plugins claim DOM-ness.
But, I'm thinking it just does not matter.

PLUGIN_OBJECT is something that jst and I came up with that ought
to be returned from any plugin that *does* implement
nsIClassInfo. If makes DOM and xpconnect do the right thing in
terms of not sharing plugin JS prototypes. It really only matters
when there are multiple plugins on the same page *and* they share
the same nsIClassInfo object pointer (which is not the case with
this mixin class anyway). Still, it is harmless and a good thing
to put out there as a flag that plugins with classinfo ought to
expose.

I've tested this with 6.1 and the trunk.

Comment 2

[John Bandhauer]

Attachment: suggested diff to the sample upon which the fix might be based

Comment 3

[av (gone)]

Attachment: second try -- essentially the same patch, with interface name more to standard

Comment 4

[av (gone)]

If nobody objects I'll check this in today.

Comment 5

[av (gone)]

Done. 

I have also updated the article (http://mozilla.org/docs/scripting-plugins.html)
but not really sure when it is going to pick it up. There is still no stand
alone SDK type sample, so the article has only a reference to the this sample
code in the repository for now.

Comment 6

[shrirang khanzode]

v