169513 - Add the means to obtain the DOM from a plugin

Status: RESOLVED FIXED

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

Description

[Adam Lock]

Plugins should be able to get at the DOM in some easy fashion, such as via
NPN_GetValue.

Apparantly it is possible to obtain the DOM through a tortuous hack involving a
call to NPN_GetURL, supplying a javascript: url to set a property back on the
plugin but it's nasty.

Comment 1

[rubydoo123]

Setting out to 1.4, this is something that we should investigate and spec out.

Comment 2

[Arun Ranganathan]

Adam,

By "it's nasty" I'm assuming you mean:
http://mozilla.org/projects/plugins/bi-directional-plugin-scripting.html .  In
addition to NPN_GetURL, there's one other proposal on the table, but it might
not be exactly what you want.  What kind of work does this block?  Could you
give us some clues as to where this would be useful?  If this blocks any of the
projects you are working on, we ought to think about re-prioritization.

Comment 3

[Adam Lock]

Some controls ask my ActiveX plugin if it implements IHTMLDocument /
IWebBrowser, for the purposes of calculating base urls properly, navigating etc.
In order for the plugin to provide this support I need to obtain the equivalent
interfaces from from Mozilla.

I don't see a way of doing this, short of the hack. It seems to me that
obtaining the DOM is something all kinds of plugins will want to do and in fact
it was possible under LiveConnect but not now. A new property on NPN_GetValue
could solve that.

Comment 4

[Peter Lubczynski]

The XPCOM plugin API does provide a way of getting to the DOM node of the
element which started the plugin:

nsCOMPtr<nsIPluginInstance> inst = mPluginInstance
nsCOMPtr<nsIPluginInstancePeer> pip;
inst->GetPeer(*getter_AddRefs(pip));
nsCOMPtr<nsIPluginTagInfo2> pti2 = do_QueryInterface(pip));
if (pti2) {
  nsCOMPtr<nsIDOMElement> e;
  pti2->GetDOMElement(getter_AddRefs(e));
}

Also, is this needed in full-page mode?

Comment 5

[Adam Lock]

I thought the XPCOM plugin api was deprecated though? If plugin vendors are
expected to code to the NPAPI it makes sense that we expose the DOM in a sane
manner to them.

I don't know offhand what the situation should be for fullpage plugins. The
plugin viewer class does appear to create a DOM document so perhaps it should be
accesible from there too, or at least the DOM window.

Comment 6

[Peter Lubczynski]

We can add that code in the 4x layer and return pointers through NPN_GetValue. 

How about adding these variables: 
NPNVDOMElement   
NPNVDOMDocument
NPNVDOMWindow

--->taking bug

Comment 7

[Adam Lock]

This sounds like a good and simple way to do it

Comment 8

[Arun Ranganathan]

Ian Oeschger should be in the loop, since at some point (when ready!) these
should work their way into the official write-up of the Plugin API:
http://devedge.netscape.com/library/manuals/2002/plugin/1.0/
Cc'ing Oeschger

Comment 9

[Peter Lubczynski]

Attachment: patch v.1

First patch implementing new NPAPI variables to get to the DOM.

Comment 10

[Adam Lock]

I've tested the NPNVDOMWindow so far and it works great.

I don't see anything wrong with the other two values from an API perspective but
I will have to exercise the code to say if it works properly. I'll report back...

Comment 11

[Adam Lock]

NPNVDOMElement works too so fom my perspective as a NPAPI client this patch
works fine. If you wish to consider to moving the functionality out of
NPN_GetValue and into something more specialised (e.g. NPN_GetInterface) then
feel free to do so but it satisfies my requirements in its current form.

r=adamlock

Comment 12

[Patrick C. Beard]

Comment on attachment 100675 [details] [diff] [review]
patch v.1

sr=beard

BTW, you could slightly optimize this at the expense of clarity:

+	 *(nsIDOMElement**)result = e.get();
+	 NS_ADDREF(*(nsISupports**)result);

could be written as:

+	 NS_ADDREF(*(nsIDOMElement**)result = e.get());

Saves an extra derefernce of the result pointer.

Comment 13

[Peter Lubczynski]

changes made and patch checked into trunk, marking FIXED.

/cvsroot/mozilla/modules/plugin/base/public/npapi.h
new revision: 3.24; previous revision: 3.23

/cvsroot/mozilla/modules/plugin/base/src/ns4xPlugin.cpp
new revision: 1.93; previous revision: 1.92

We should probably document these new npapi variables for NPN_GetValue:
+  NPNVDOMElement     = 11,   /* available in Mozilla 1.2 */
+  NPNVDOMDocument    = 12,
+  NPNVDOMWindow      = 13

Comment 14

[rpotts (gone)]

It seems like NPNDOMDocument is not strictly necessary... Given a DOMNode you
can obtain its document via the 'ownerDocument' property --  this is part of the
DOM 1 spec.

Since Node.ownerDocument is already a public API do we really need to expose
another accessor via the plugin API ?

I think that exposing the DOMElement and its corrosponding window is probably
enough...

-- rick

Comment 15

[Peter Lubczynski]

Attachment: remove NPNVDOMDocument patch

ah, no need to expose the document. Here's a patch to remove the bloat.

Comment 16

[av (gone)]

Comment on attachment 103578 [details] [diff] [review]
remove NPNVDOMDocument patch

r=av

Comment 17

[rpotts (gone)]

Comment on attachment 103578 [details] [diff] [review]
remove NPNVDOMDocument patch

sr=[e-mail]

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 103578 [details] [diff] [review]
remove NPNVDOMDocument patch

a=roc+moz for trunk

Comment 19

[Christopher Blizzard (:blizzard)]

This has approval.  If it doesn't get checked in by the early morning tree
closure on Nov 5, 2002 it's going to have to wait until after the branch is cut.

Comment 20

[Peter Lubczynski]

attachment 103578 [details] [diff] [review] landed on 10/29/2002 14:54:
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/modules/plugin/base/public&command=DIFF_FRAMESET&file=npapi.h&rev1=3.24&rev2=3.25&root=/cvsroot

....however why does LXR not reflect this:
http://lxr.mozilla.org/mozilla/source/modules/plugin/base/public/npapi.h#358

Comment 21

[timeless]

that's bug 177522. feel free to complain. i've done all i can.