Closed Bug 147085 Opened 23 years ago Closed 22 years ago

Freeze nsIDocument

Categories

(Core :: DOM: Core & HTML, defect, P4)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: Biesinger, Unassigned)

References

(
URL
)

Details

Adobe SVG Plugin requires nsIDocument to be frozen.
Changing QA Contact
QA Contact: petersen → amar
Reporter please use bugzilla helper to report a bug. The URL for that is http://mozilla.org/quality/help/bugzilla-helper.html Thanks
Priority: -- → P4
eh the fields from bugzilla helper make no sense for this bug it occurs in every mozilla version up to now, and always "reproducible". For your pleasure, I can add an URL. Steps to reproduce are "look at nsIDocument.h, notice the missing @status FROZEN" - well, it's a source code issue. The interface nsIDocument, used by Mozilla, should be frozen, so that people who use it can be assured that it will not change. In this specific case, this is relevant for Adobe's SVG Plugin.
URL: http://lxr.mozilla.org/seamonkey/sour...
Actually, this should go to dom anyway.
Assignee: attinasi → jst
Component: Layout → DOM Other
QA Contact: nobody → gerardok
Why does the Adobe SVG plugin need nsIDocument? Can they use something else? Should we freeze a subset of nsIDocument and derive nsIDocument from that subset?
cc'ing peter, who said that Adobe needs a frozen nsIDocument could you answer the question in comment 5?
Holy something, we are soooo not freezing nsIDocument any time soon, no way.
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
I think this bug is clearly a wontfix. Freezing internal interfaces is not the way embedding APIs should be designed.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
It sems that the best course for us is to remove support for Mozilla scripting engine in Adobe SVG Viewer then and go all the way back to NN 4.x plug-in model. At least the plugin will work.
Building an embedding API by looking at what interfaces you use and freezing the entire interface is the wrong way to do things. Information on what features you use on these interfaces might lead to an API that you can use, but there's no way we're going to freeze everything just so you can use a few things.
David, I am not questioning Mozilla team decision on that one. I am simply stating that it is not technically feasible for Adobe SVG plug-in to support scripting through the browser's JavaScipt in Mozilla at this time and it does not make sense for us to revive our way of doing it in the last version of the plug-in (it still works if recompiled with new headers, but "WONTFIX" on this bug means that we cannot do in the production quality plug-in). This is unfortunate, but at least it should stabilize things a lot. If everyone involved agrees that we need to have this support in future, we can revisit this issue from a different perspective (which probably will not involve freezing nsIDocument if it creates problems for you).
Why don't you just provide information on why you're using nsIDocument?
There is quite a bit of info on that in the discussion on bug 115528. We cannot use XPConnect because it will result in a very bloated code (SVG DOM is very big) and it is not powerful enough to replace LiveConnect. There might be some hacks that we can do to make LiveConnect somewhat working, but unless we are reasonably sure that it will work as good as IE and it won't be deprecated (as Mozilla plug-in architecture was), we probably do not want to spend time experimenting with it. We can bind directly to SpiderMonkey APIs, but then we need an access to it and it is apparently not possible without going through some internal interfaces. SpiderMonkey APIs are also probably considered to be internal by Mozilla anyway. What we want is basically soft binding, like IDispatchEx allow in COM world or how APIs are exposed to JavaScript through SpiderMonkey. We also want more stable APIs to the scripting engine, like creation of our own global object and attaching our custom methods to it or executing JavaScript in the given context and getting back results or setting script variables. XPConnect just tries to abstract us away from the script engine and we don't want that.
So the only method on nsIDocument that you're using is GetScriptGlobalObject?
Unless I'm misinformed, the SpiderMonkey API's are about as frozen as API's get, so I don't see any problem with embedders or plugin writers using that API and trusting that it won't change. Embedders and plugins can also access the raw JSObject for any XPCOM object in Mozilla using XPConnect, there's no need to call nsIDocument::GetScriptGlobalObject(). The JS context where JS is currently executing is also available through the nsIJSContextStack service that XPConnect exposes. Now all (or any?) the XPConnect interfaces are not officially frozen, but I would guess that by now most, if not all, could be officially frozen so that embedders and plugin developers can rely on them not changing. The one thing that's missing is the ability to get the JSContext in which a JSObject originated from (i.e. what nsIScriptGlobalObject::GetContext() does), is that something that the SVG plugin would need (I can't think of why that would be needed at this moment though)?
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.