Closed Bug 115528 Opened 23 years ago Closed 16 years ago

Adobe needs frozen interfaces for its SVG plugin to be able to expose methods [eg: getSVGDocument()] to scripts

Categories

(External Software Affecting Firefox :: Other, defect, P3)

Product:
External Software Affecting Firefox
Component:
Other
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: mr, Assigned: arun)

References

Details

(Keywords: arch, meta, topembed-)

Attachments

(1 file)

2wayscripting.doc
33.50 KB, application/octet-stream
Details 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120
BuildID:    2001112012

I'm using the Adobe SVG plugin for Linux (mozilla 0.96)
 http://www.adobe.com/svg/viewer/install/old.html 
and want to access the embeded SVG document
handle from HTML:

<html>
<body>
<embed src="systemInfo.svg" type="image/svg-xml" name="fritz" />

<script language="Javascript1.2">
function oi() {
          var svgdoc = document.embeds["fritz"].getSVGDocument();
          alert(svgdoc);
       }
    </script>

<form>
<input type="submit" onClick="javascript:oi();" />
</form>

</body>
</html>


The svg is diplayed, but when i click on the button
i get an error:

  ERROR: document.embeds.fritz.getSVGDocument() is not a function


It seems that the surrounging HTML document can't access the
SVG document.
Vice versa, if i want to access the browser DOM from within
the SVG javascript, 'top' or 'window.parent' are all undefined.

Having no communication possibility between HTML-javascript
and SVG-javascript makes it quite useless.

SVG demo code to embed:
<svg width='400' height='400' onload="on_load(evt)">
   <script><![CDATA[
   	function on_load(evt)  {
   		svgdoc = evt.getCurrentNode().getOwnerDocument();
         !!! How to put this variable into global scope
             to access it from my surrounging HTML ???
      }
   ]]></script>
</svg>


Reproducible: Always
Steps to Reproduce:
1.Load the html code from the description into mozilla
2.Any access of document.embeds["fritz"].getSVGDocument() gives an error
3.This is an error according to:
http://www.w3.org/TR/1999/WD-SVG-19991203/struct.html#GetSVGDocumentMethod

Actual Results:  Javascript error:
ERROR: document.embeds.fritz.getSVGDocument() is not a function



Expected Results:  The SVG DOM should be accessable from HTML-Javascript
Is this supposed to go to the SVG component?
No... This is to do with plugins. Is document.embeds.foo supported? Don't you
need document.getElementById("fritz")?

This is really an adobe support thing, I suspect, since they're the SVG
providers in this case.

I don't know if document.parent is supported, but thats definately an adobe issue.
Also, you probably want .ownerDocument to get from teh SVG document to the
original document, assuming that that is supported.
plugins.  If the plugin has a function we can't call, this sounds like a plugins 
bug.  The plugin getting back to the parent document DOM would be the 
responsibility of the plugin and a part of the plugins API.
Assignee: jst → av
Component: DOM Other → Plug-ins
QA Contact: gerardok → shrir
Hi,

the following snippet is from the svg-developers mailing list,
Peter seems to be the developer of the Adobe SVG plugin.

regards

Marcel

> > i'm using the Adobe SVG plugin for Linux (mozilla 0.96)
> > and want to access the embeded SVG document
> > handle from HTML:
> > 
> > ERROR: document.embeds.fritz.getSVGDocument() is not a function
> > How can i access SVG from outside HTML and vice verca?

> The plugin is optimized fpr 0.9.1 (pretty old). In other versions 
> mozilla's DOM support won't work properly. Try the 0.9.1.


It's not so much "optimized", it is compiled with 0.9.1
headers (0.9.1 was chosen because it is what NN 6.1 is based
on, and NN 6.1 was the latest Netscape release when v3
shipped). Mozilla releases are binary incompatible with
each other (most interfaces we use were not frozen,
including plug-in and DOM interfaces), so it is not
possible to get good browser integration and work in both
0.9.1 and 0.9.6. Looking back it seems like supporting
Mozilla was (and probably still is) premature. For instance,
they decided to deprecate their "new" plug-in architecture
and have not even figured out what is going to replace it.
Also, no plug-in SDK was ever released. Mozilla might
getting close to being a usable browser, but sadly enough,
it is getting worse and worse as plug-in host.

Peter
Hi again,

here is a simple demo to test the SVG access.

Download Adobes SVG plugin for Linux from:
  http://www.adobe.com/svg/viewer/install/old.html

1. With mozilla 0.96 every SVG-HTML and vice versa
   access is broken

2. With mozilla 0.91 the getSVGDocument() works fine,
   but not the rest.
   (After 3 reloads getSVGDocument() fails as well)

Use the two files below, load embed.html into mozilla
and the alert messages show the broken situation of the
Javascript objects.

If of interest, i can provide another testcase.

thanks,

Marcel


-------- Copy into embed.html -------------------
<html>
<body>
   <embed src="test.svg" type="image/svg-xml" name="mySVG" />
   <script language="Javascript1.2">
      function check() {
         var embedWindow = document.embeds["mySVG"];
         alert("html: document.embeds['mySVG']=" + embedWindow);
         
         if ((typeof embedWindow.getSVGDocument) == "undefined")
            alert("html: ERROR svgdoc.getSVGDocument()=undefined");
         else {
            var svgdoc = embedWindow.getSVGDocument();
            alert("html: embedWindow.getSVGDocument()=" + svgdoc);
         }
      }
   </script>
   <form>
      <input type="button" value="Check SVG Access" onClick="javascript:check();">
   </form>
</body>
</html>
--------- embed.html END ----------------------

--------- copy into test.svg ------------------
<svg width='200' height='100'>
   <script><![CDATA[
      /*
      NOTE:
      Mozilla 0.91 with Adobe SVG plugin does support:
      ->  Accessing the embeded SVG from outer HTML with
          document.embeds["mySVG"].getSVGDocument()
          OK: xpconnect wrapped HTMLEmbedElement
      Mozilla 0.* with Adobe SVG plugin do NOT support:
      ->  Exporting the svgdoc handle to the outer HTML
      ->  Reported to bugzilla # 115528
      */
   	function show(evt) {
   		svgdoc = evt.getCurrentNode().getOwnerDocument();
         alert("svg: svgdoc=" + svgdoc);
         var owner = svgdoc.ownerDocument;
         alert("svg: ownerDocument=" + owner);
      }
   ]]></script>
   <g id='xy'>
      <text id='texte' x='50' y='40' onclick='show(evt)'
            style='text-anchor:left;font-size:12;font-family:Arial;fill:red'>
         Click me for SVG embeded info
      </text>
   </g>
</svg>
--------- test.svg END ----------
OK then.

Marking INVALID - this isn't a mozilla issue.

The plugin API stuff is being deprecated (replaced with just using XPCOM
directly), but if people file specific bugs on using frozen interfaces which
broke, then they will probably be looked at.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Here is the response of Peter (the Adobe SVG plugin writer?)

Is there a solution for this issue?
Can IE provide some ideas for a plugin interface?

thanks again,

Marcel


> > By all means, grab your nearest Mozilla developer and
> > offer it to him to freeze as many interfaces as you
> > think he can!
> > 
> > Peter

> 
> 
> OK, the nearest Mozilla developer reponded:
> 
> "... just use XPCOM directly ..."
> 
> i don't know the XPCOM stuff, but is this
> a base for you?


We use XPCOM as a base for Mozilla plug-ins. Unfortunately
they have just deprecated XPCOM plug-in architecture. If they
pull it off from their codebase, v3 will not work on Linux
at all (but will probably work on Windows without scripting).

We could write XPCOM component (that probably what he meant
by using XPCOM directly), but then we would break NN4x (and
all non-NN, non-IE browsers on Windows and Mac). Also to
do it literally without any tricks would bloat our DLL about
400k (to put that in perspective, this is the size of the
complete JavaScript interpreter).

Also they have a nasty habit of changing interfaces without
changing interface IIDs (IID is basically a "name" of the
interface that other components can use to find it). This
means that even if we write binary-only XPCOM component, we
are limited to only frozen interfaces. Some of interfaces
that we need are not frozen (and it is not clear if they are
going to be frozen).

We also could use NN4x architecture with new XPCOM hacks
(that is the recommended way to write plug-ins since this
fall - of course we already followed one "recommended" way),
but that does not provide enough interfaces for us. For instance,
there is no way to evaluate scripts in the context of a specific
object and get back a result. Also there is no access to HTML
DOM (and these things were supported through NN4x LiveConnect).
It also would bloat us the same 400k.

I am not even talking about windowless plug-ins, sharing
DOM tree between plug-in and host or some extra goodies that
broiwser can provide, like timers (all of those things work
very well in IE).

Mozilla just does not take plug-ins seriously. That's where
the problem is.


> 
> Can we expect another Linux/mozilla AdobeSVG plugin
> in the near future?


As usual, this is not a sort of comment that you can expect
from us.

Peter
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
I'm ccing beard and dougt to comment more on the plugins stuff, and jst for the
specific interfaces you seem to want, but:

"Also they have a nasty habit of changing interfaces without
changing interface IIDs (IID is basically a "name" of the
interface that other components can use to find it). This
means that even if we write binary-only XPCOM component, we
are limited to only frozen interfaces. Some of interfaces
that we need are not frozen (and it is not clear if they are
going to be frozen)."

By definition, only frozen interfaces will not change....
by definition, interfaces which are not frozen are subject to change, sorry! I
think what you're really hoping is that we freeze the interfaces that you require...

what interfaces do you feel need to be frozen, maybe we can work something out?
we're freezing interfaces about as fast as we can (we're up to 62 frozen
interfaces to date) but we're freezing the ones that we think embedddors will
need, maybe plugin developers require a slightly different set of interfaces?

cc'ing chak ("Mr. Freeze") because he's organizing the freezing effort
Oh, and:

> > By all means, grab your nearest Mozilla developer and
> > offer it to him to freeze as many interfaces as you
> > think he can!
> > > > Peter

was left out of the original comment. :)

All the W3C dom APIs are now frozen, I believe. Which unfrozen interfaces are
you using that you'd like to be frozen? Maybe the subset of those interfaces
which you require could be exposed in other ways?

(Its probably easier if peter cc's himself to this bug directly...)
http://www.mozilla.org/projects/embedding/EmbedInterfaceFreeze.html shows our
current interface freeze status.
[Yes, the core DOM interfaces are frozen - i need to update the doc to reflect this]

Please provide any interfaces you want to tracked via this doc and i'll be happy
to add them to it.
I'm CC'ing Peter S., the developer of the Adobe SVG plugin mentioned, separately
via e-mail -- there doesn't appear to be a bugzilla account in his name.
Peter, yes: as you observed, we've deprecated the XPCOM Plugin API (nsIPlugin
and peers) and yes, we have "clipped the wings" of XPCOM developers by now
obliging all new plugins to use the old NPAPI (Nav 4.x style API -- see
http:/mozilla.org/projects/plugins/).  The reasons for doing this are clearly
that we could not guarantee binary compatibility, and that the nsIPlug* family
of interfaces didn't accomplish quite what we set out to do.  They also used
heuristics that we discourage, including older entry points via MACROs.  This is
not an example of us "not taking plugins seriously."  For use in commercial
browser software, we want to hold XPCOM till we can freeze APIs that we would
like to encourage others to use.  Other applications that pull source (e.g OeOne
platform) use the subset of XPCOM ifaces in that pull, and thus don't face the
constant change that we do.  An understanding of the technical limitations that
Adobe SVG faces by being forced to use NPAPI would be great -- what are the
limitations of the scriptable solution via XPT and nsIClassInfo
(http://mozilla.org/projects/plugins/scripting-plugins.html) and what more does
Adobe SVG group require?
I am an Adobe SVG viewer developer and Marcel Ruff asked to
add my comments to this bug.

First of all, the fact that getSVGDocument() is not
working is obviously a plug-in bug. Unfortunately, as
I explain later, I do not see how it can be fixed on
the plug-in side, so maybe this bug should be changed
to a feature request for a comprehensive plug-in
architecture.

The fact that "new" plug-in architecture is being deprecated
without anything comparable to replace it means that we
will not be doing any development on our Mozilla plug-ins.
NN4.x architecture with extra XPCOM NPP_GetValue calls is
not going to cut it for us. We need access to the Mozilla
DOM and scripting engine. So in its current state NN4.x is
not an option for us. We might still go back to it, but that
would mean that we would basically give up on scripting in
Mozilla environment for the time being.

Also, we cannot expose all our APIs through XPCOM because
SVG DOM uses a lot of multiple inheritance and that means
a lot of extra virtual functions that have to be defined
(or platform-specific dirty tricks in assembler). Just
take a look at IDL file in SVG spec and add core DOM, CSS
and SMIL to that. I do not think anyone exposes that many APIs.
My experiments suggest that the size of the XPDOM glue code
for currently implemented subset of SVG DOM would be around
400k. This is not acceptable (and we've done probably only
about a half of SVG DOM APIs). We pulled full COM support
from our ActiveX control for the same reason. In COM world
we could use OLE automation (IDispatch interface) intstead.
Unfortunately, XPConnect does not give us such option.

So instead of going through XPConnect, we go the other way
around: we expose all of our APIs directly through JavaScript
(jsapi.h). But to do that we need access to some of Mozilla
scripting interfaces (listed below). Ironically, this path
is much easier to use then XPCOM and glue code needed is
tiny.

Suggestion that we should do XPCOM module instead of the
plug-in might work but we need to figure out these issues:

* Is it possible to write XPCOM module without explicit linkage
  with other Mozilla DLLs? We must have plug-in DLL that works
  in all browsers, so the same DLL must be able to serve as NN4.x
  plug-in and ActiveX control as well.

* Are enough interfaces frozen to even try doing it?

* Is there any sample code for such plug-in-like XPCOM module?

X11 support. Long-term requirement is that our plug-in can
work in all browsers, at least without scripting. Right now I
do not see any way to do it other then going back to NN4.x (But
even then I do not understand what the current status is.
Previously Mozilla docs claimed that it is not possible for
plug-ins to work in both Netscape and Mozilla because of
gtk<->motif conflict. Have that changed?). The best option
would be to have some sort of plug-in skeleton code that would
work expose both NN4.x and Mozilla (kind of like
BackwardAdapter.cpp).

Other issue:

> Comment #9 From Bradley Baetz 2001-12-18 11:56 :
>
> I'm ccing beard and dougt to comment more on the plugins stuff, and jst for 
the
> specific interfaces you seem to want, but:
>
> "Also they have a nasty habit of changing interfaces without
> changing interface IIDs (IID is basically a "name" of the
> interface that other components can use to find it). This
> means that even if we write binary-only XPCOM component, we
> are limited to only frozen interfaces. Some of interfaces
> that we need are not frozen (and it is not clear if they are
> going to be frozen)."
>
> By definition, only frozen interfaces will not change....

I understand that. But if you'd change their IIDs every
time you change interface, there would be a safe way to
use them, because QueryInterface would fail if interface was
changed and plug-in could try to do something reasonable.
Why even bother using XPCOM for your internal classes
otherwise? You could have used straight C++ instead, if there
is no binary compatibility anyway. Somehow I do not have
this problem with Microsoft, maybe that's because they freeze
almost all or all interfaces very quickly.

Here is the list of interfaces that we currently use (well,
actually those are just all words that start with "nsI" in out
code):

nsIComponentManager
nsIDOMDocument
nsIDOMElement
nsIDocument
nsIFactory
nsIFile
nsIGenericFactory
nsIID
nsIInputStream
nsIJRILiveConnectPlugInstPeer
nsIJRILiveConnectPlugin
nsIJRILiveConnectPluginInstancePeer
nsIMemory
nsIPlugin
nsIPluginInstance
nsIPluginInstancePeer
nsIPluginInstancePeer2
nsIPluginManager
nsIPluginStreamInfo
nsIPluginStreamListener
nsIPluginTagInfo
nsIPluginTagInfo2
nsIPrincipal
nsIScriptContext
nsIScriptContextOwner
nsIScriptGlobalObject
nsIScriptObjectOwner
nsIScriptObjectPrincipal
nsIScriptablePlugin
nsIServiceManager
nsISupports
nsIURI
nsIXPConnect
nsIXPConnectJSObjectHolder

Peter
*** Bug 114090 has been marked as a duplicate of this bug. ***
1. I'm morphing this bug.
2. That list is long, can you look into shortenning it?
3. can you indicate what you need specifically from 
nsIPluginInstancePeer2 and nsIPluginTagInfo2? (making us start a 3 worries me)
4. nsIXPConnect and nsIXPConnectJSObjectHolder might worry me (or others), can 
you provide info about them? (if this info needs to be confidential I'm sure we 
can have some netscape people open a confidential bug where the details can be 
discussed and then have conclusions copied here).
5. I know that some of the things you've listed are freezing, frozen, talking 
about freezing, or talking about not freezing.
6. Confirming bug based on the following statement (which i hope is an accurate 
summary of what has been said earlier): Adobe needs help to deliver a 
scriptable svg plugin.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: meta
Summary: getSVGDocument() does not work → Adobe needs frozen interfaces for its SVG plugin to be able to expose methods [eg: getSVGDocument()] to scripts
Another thing that worrys me is nsIGenericFactory.  This implies that there is
more going on in this plugin than just requiring a set of frozen interface. 
More specifically, exactly what imports does this plugin have from XPCOM?  
dropping into the 1.1 milestone
Priority: -- → P3
Target Milestone: --- → mozilla1.1alpha
I do not think working on this bug is very productive. Since the
whole Mozilla plug-in architecture (as it was in 0.9.1) is
now deprecated, it is highly unlikely that we will do any more
work on it. It seems that we should go back to NN4.x and remove
scripting support.

Peter Sorotokin
Adobe Systems Inc.
This is reiteration of the problems with NN4.x approach.

1. How can we create our own JavaScript "global" object (SVG Viewer has its 
own "window" object)?
2. How can we execute scripts in the context of that object and get results 
back?
3. How can we call arbitrary JavaScript methods and invoke functions?
4. Naive XPCOM approach does not scale for the size of SVG DOM. It would 
require half a megabyte of "glue" code to dispatch XPCOM calls to our 
implementation. We are not looking into making XPCOM our "native" framework.
In IE/COM world we solve this problem by not providing any custom interfaces, 
just IDispatch.

Peter
Attached file 2wayscripting.doc — 
This draft article (save as 2wayscripting.doc) describes how to call scripts
directly from a plugin. I have also checked in working code that uses this
technique here:

mozilla/modules/plugin/samples/4x-scriptable
mozilla/modules/plugin/samples/4x-scriptable/script-test.html

I plan to turn this article into a web page REAL SOON NOW.
the least you could do was hit "save as.." and store it in html :)
I am sorry, but while this is somewhat workable, I have a
strange feeling that I have been there before (with Mozilla
plug-in architecture). This is a pile of hacks that looks very
frigile. The approach of "you can't do that, but you can write
this hack that will do what you want" is fundamentally wrong.
We tried it with v3 plug-in and it has not worked. So until
Mozilla has a solid plug-in architecture (NN4.x-based or not)
*and* I am sure it addresses *all* our needs, I will oppose any
new development (not that I am the one who decides this anyway,
but I still have my vote). Again, it is not that we need all
that much, we could do *all* of that in NN4.x and it is just
a really *tiny* fraction of what ActiveX controls can do inside
Windows IE (in a very straighforward and stable manner).

*** Bug 146809 has been marked as a duplicate of this bug. ***
For reference, these are the interfaces from Peter's list that are still
unfrozen: (or at least lack an @status FROZEN in the .idl/.h)
nsIDocument         - unfrozen
nsIGenericFactory   - unfrozen
nsIJRILiveConnectPlugInstPeer - unfrozen
nsIJRILiveConnectPlugin - unfrozen
nsIJRILiveConnectPluginInstancePeer - unfrozen
nsIPlugin           - unfrozen
nsIPluginInstance   - unfrozen
nsIPluginInstancePeer - unfrozen
nsIPluginInstancePeer2 - unfrozen
nsIPluginManager    - unfrozen
nsIPluginStreamInfo - unfrozen
nsIPluginStreamListener - unfrozen
nsIPluginTagInfo    - unfrozen
nsIPluginTagInfo2   - unfrozen
nsIPrincipal        - unfrozen
nsIScriptContext    - unfrozen
nsIScriptContextOwner - unfrozen
nsIScriptGlobalObject - unfrozen
nsIScriptObjectOwner - unfrozen
nsIScriptObjectPrincipal - unfrozen
nsIScriptablePlugin - unfrozen
nsIXPConnect        - unfrozen
nsIXPConnectJSObjectHolder - unfrozen


just filed bug 147083, bug 147084 and bug 147085 about interfaces to be frozen.

will file more about the others tomorrow or so.
Depends on: 147083, 147084
Filed Bug 147144, Bug 147145, Bug 147146 for more interfaces

I think I got them all now...
Depends on: 147144, 147145, 147146
nsIPlugin* interfaces are deprecated, just not marked. See bug 83189.
Depends on: 83189
No longer depends on: 147083
ok, shaver has believed forever, and I for a while, that we should create a 
cookie cutter interface that we can freeze for each specific plugin that has 
needs.

suppose we call it nsIAdobeSVGFriendly, and it contains methods that proxy to 
all the methods adobe's svg plugin needs.

so what we need is a list of all the specific methods of the aforementioned 
interfaces that you need, as well as any unfrozen mozilla datastructures.

With this, we'll create nsIAdobeSVGFriendly (and friends if we can't easily fit 
everything into one interface) and nsAdobeSVGFriendly (and friends) and things 
for the datastructures.

I'm certainly open to suggestions for interface/class/structure names (or 
conventions)

If at some future point an SVG plugin needs more interfaces, we'll make 
nsIAdobeSVGFriendly2 and stick the extra stuff there. And then the plugin can 
use QI to check for availability. The plugin should probably do this at 
registration (get supported mime types) if it absolutely needs 
nsIAdobeSVGFriendly2, in which case it would report it doesn't support anything 
and set its plugin description to

"This plugin needs a newer Gecko derivative, please contact your vendor or 
visit <a href=\"http://www.adobe.com\">adobe</a> to get an older plugin. <a 
href=\"http://www.adobe.com/svg/outdatedBrowser\">More information</a> is 
available."
Keywords: arch, helpwanted
... fwiw any of mozilla.org, adobe, or a vendor could provide this glue.  I'd 
suggest that we work in extensions/plugin-glue/adove/svg, but if Adobe needs to 
ship with multiple xpcom components which implement the glue it needs for each 
of various versions of mozilla (0.9.2,0.9.4,0.9.7,1.0,1.1) it could do that.   
And adobe could and probably should publish the interface that a given plugin 
release requires so that if some strange vendor that wants to use a plugin and 
needs to implement their own glue can do so.
So what's the scoop here, just wondering if this should be closed or discussed
further. (Trying to get my bugs in order ;-)
I like the idea in the last few comments of provding a frozen glue interface for
SVG.

--->reassign to Arun

I think we need a meeting with the SVG plug-in folks to plan how to resolve this
issue. Perhaps we can come up with a set of FROZEN interfaces that SVG can
safely use or some other creative idea.
Assignee: av → aruner
OS: Linux → All
Hardware: PC → All
*** Bug 164954 has been marked as a duplicate of this bug. ***
batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Keywords: topembed
Keywords: topembed → topembed-
Blocks: grouper
*** Bug 210061 has been marked as a duplicate of this bug. ***
*** Bug 210061 has been marked as a duplicate of this bug. ***
retargeting
Target Milestone: mozilla1.1alpha → Future
Target Milestone: Future → mozilla1.1alpha
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040514] (<-- 1.7rc2 !)
(W98SE)

Got
{{
Error: document.svgMap.getSVGDocument is not a function
Source File:
http://www.agence.francetelecom.com/racine_boutique/siteNegus/JS/carto.js
Line: 263
}}
from
<http://www.agence.francetelecom.com/racine_boutique/siteNegus/DPT_75/CT_75056.htm?commune=Paris&insee=75056&desc=&espace=res>


[Microsoft Internet Explorer, version 5 (5.00.3105.0106) (128b, SP1)] (W98SE)

Works fine.
Target Milestone: mozilla1.1alpha → ---
*** Bug 270239 has been marked as a duplicate of this bug. ***
is bug 147145 the only thing left that is blocking this?

wbat other interfaces does Adobe need frozen for their SVG plugin to expose methods?
IMHO this could be marked invalid or fixed, as the root cause is in a software
product (ASV) which was publicly discontinued [1].

[1] http://www.adobe.com/svg/eol.html
Yes, it's a dead issue from looking at the spawned bugs. The idea of creating a interface that could be frozen for functionality needed is probably a good one and if someone agrees they should probably create a bug to describe what such an interface(s) should look like.
Status: NEW → RESOLVED
Closed: 23 years ago → 16 years ago
Resolution: --- → WONTFIX
I don't think we need or want XPCOM interfaces for this any more. The scriptable plugin API (NPAPI) should provide everything that is necessary to solve this bug in both directions.
Component: Plug-ins → Other
Product: Core → Plugins
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: