Add the means to obtain the DOM from a plugin

RESOLVED FIXED in mozilla1.2beta



16 years ago
16 years ago


(Reporter: Adam Lock, Assigned: Peter Lubczynski)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [PL2:P3][DOM])


(1 attachment, 1 obsolete attachment)

2.01 KB, patch
av (gone)
: review+
rpotts (gone)
: superreview+
Details | Diff | Splinter Review


16 years ago
Plugins should be able to get at the DOM in some easy fashion, such as via

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

16 years ago
Setting out to 1.4, this is something that we should investigate and spec out.
Priority: -- → P3
Whiteboard: [PL2:P3][DOM]
Target Milestone: --- → mozilla1.4alpha

Comment 2

16 years ago

By "it's nasty" I'm assuming you mean: .  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

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

16 years ago
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;
nsCOMPtr<nsIPluginTagInfo2> pti2 = do_QueryInterface(pip));
if (pti2) {
  nsCOMPtr<nsIDOMElement> e;

Also, is this needed in full-page mode?

Comment 5

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

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

How about adding these variables: 

--->taking bug
Assignee: beppe → peterl

Comment 7

16 years ago
This sounds like a good and simple way to do it

Comment 8

16 years ago
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:
Cc'ing Oeschger

Comment 9

16 years ago
Created attachment 100675 [details] [diff] [review]
patch v.1

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

Comment 10

16 years ago
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...


16 years ago
Keywords: patch, review
Target Milestone: mozilla1.4alpha → mozilla1.2beta

Comment 11

16 years ago
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.



16 years ago
Attachment #100675 - Flags: superreview+

Comment 12

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


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

16 years ago
changes made and patch checked into trunk, marking FIXED.

new revision: 3.24; previous revision: 3.23

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
Last Resolved: 16 years ago
Keywords: review
Resolution: --- → FIXED

Comment 14

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

-- rick

Comment 15

16 years ago
Created attachment 103578 [details] [diff] [review]
remove NPNVDOMDocument patch

ah, no need to expose the document. Here's a patch to remove the bloat.
Attachment #100675 - Attachment is obsolete: true

Comment 16

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

Attachment #103578 - Flags: review+

Comment 17

16 years ago
Comment on attachment 103578 [details] [diff] [review]
remove NPNVDOMDocument patch
Attachment #103578 - Flags: superreview+
Comment on attachment 103578 [details] [diff] [review]
remove NPNVDOMDocument patch

a=roc+moz for trunk
Attachment #103578 - Flags: approval+
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 21

16 years ago
that's bug 177522. feel free to complain. i've done all i can.
You need to log in before you can comment on or make changes to this bug.