This is a meta bug about freezing the non-frozen interfaces in use by Eclipse SWT v3. We should maybe just freeze these interfaces as is, or we should hurry up and provide alternatives / make any necessary alterations. Here's the list, based on grepping their source code: nsIAppShell nsIBaseWindow nsIContentViewer nsIContentViewerContainer nsIDocumentLoaderFactory nsIInputStreamChannel nsIPromptService nsIWebNavigation nsIWebProgress nsIWebProgressListener Many of these are already status UNDER_REVIEW, and many of these interfaces are usedby gtkmozembed and mfcembed.

> nsIInputStreamChannel before freezing this, it should be documented that setURI can only be called before the channel has been opened (as that seems to be the current behaviour) What does eclipse need nsIDocumentLoaderFactory for? nsIWebNavigation should maybe consider changing its loadURI function to take an AString, an nsIURI, or a (non-opened) nsIChannel (if the latter most paramters could be eliminated) nsIWebProgress needs more documentation before considering freezing it.

nsIAppShell is not *ever* going to be frozen, it's an internal interface that should probably be deCOMified, and which has some odd behavior differences across platforms. Please indicate which APIs you are using and why you need them; perhaps we can separate what you need into another freeze-able interface, or provide an embedding shim that can be safely frozen.

(In reply to comment #2) > nsIAppShell is not *ever* going to be frozen, it's an internal interface that > should probably be deCOMified, and which has some odd behavior differences > across platforms. Please indicate which APIs you are using and why you need > them; perhaps we can separate what you need into another freeze-able interface, > or provide an embedding shim that can be safely frozen. bsmedberg: don't worry man! i'm not going to freeze something that shouldn't be frozen. i can't tell you why eclipse is using any of these interfaces, but i hope to investigate and find out. please re-read the summary of this bug. i'm proposing that we need to either freeze these interfaces or find / create alternatives. that's what this bug is about.

nsIPromptService is going to be replaced.

I think that we have plans to merge some of the content viewer and document viewer interfaces into a single (freezable) interface...

It appears that Eclipse is using the following interfaces nsIContentViewer nsIContentViewerContainer nsIDocumentLoaderFactory nsIInputStreamChannel for all the wrong reasons. Basically, they are using those interfaces to load a chunk of HTML, which they have in the form of a java.lang.String instance. A cheap alternative solution for them might be to construct a data: URL instead, and just call nsIWebNavigation::LoadURI. So, I think we can safely ignore those interfaces here.

> nsIPromptService is going to be replaced. I think we should seriously consider freezing nsIPromptService as is since compatibility with older releases is important, and this is an interface that embedders absolutely need. As for nsIBaseWindow, I suspect we may want to freeze it too without modifications to the vtable. Although, in that case, we may want to rename it to something like nsIEmbedBaseWindow, and have the embedding/browser code map that onto nsIBaseWindow. nsIAppShell is another tricky interface to deal with. Unfortunately, embedders need to call the Create and Spinup methods in order to get things rolling (under GTK at least). I'm not sure what we want to do about nsIAppShell going forward. Bottom line: We must not screw over existing embedders even if it means carrying around more cruft than we really like.

> So, I think we can safely ignore those interfaces here. ... > We must not screw over existing embedders even if it means carrying > around more cruft than we really like. Those statements are at odds aren't they? Hmm... I'll get in touch with the Eclipse folks to see how they feel about moving to the data: URL solution. Hopefully, it'll do the trick, and hopefully they won't care if older versions of Eclipse are incompatible with future versions of Mozilla (assuming bz's plan to change the content viewer interface happens).

I filed a bug on Eclipse to use a data: URL instead. See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=76635

(In reply to comment #6) > for all the wrong reasons. Basically, they are using those interfaces to load a > chunk of HTML, which they have in the form of a java.lang.String instance. A > cheap alternative solution for them might be to construct a data: URL instead, > and just call nsIWebNavigation::LoadURI. if they use nsWebBrowser, they could use nsIWebBrowserStream... although that only exists since 1.7, iirc. (In reply to comment #7) > > nsIPromptService is going to be replaced. > > I think we should seriously consider freezing nsIPromptService as is since yeah, I agree. the (impl of the) new interface will need some way to show the stuff it looks up in the stringbundle anyway. do note the end of bug 228207 comment 0.

oh... I guess nsIWebBrowserStream isn't frozen either. it should be! :) (maybe it should inherit from nsIOutputStream though, or implement that interface at least, to be able to pass it to places that want an outputstream?)

Just a suggestion. A soft way to help embedders working cross Mozilla versions would be to give us a standard/frozen way to query the Mozilla version (1.7.2 for example. It would be really cool if we could also get details like if it's built against GTK2 or GTK1.2 for example). We could then work out some of the minor or less minor variations that inevitably occur in the real world. e.g. GTK provides 'constants' like gtk_major_version, gtk_minor_version. It is inevitable to have a few really weird situations that an embedder must absolutly workaround for in a particular version because for some reason it has become the most critical use case to support... When an unfrozen XPCOM listener interface has been changed to take an XPCOM object of one type to take an XPCOM of another type, we can query the interface supported by the given argument and determine which version of the interface we are using. Having the Mozilla version number would make it easier and more general. If you can suggest a safe way to determine the Mozilla version - from within Mozilla after NS_InitEmbedding for example, please let me know. Thanks!

Chris, Yeah, I have wanted to add something like that too. I'm not sure yet how best to expose that.

> nsIWebBrowserStream... although that only exists since 1.7, iirc. hmm, looks like I was wrong there - seems to only exist on trunk... > query the Mozilla version (1.7.2 easiest to implement of course would be an |const char* NS_GetGeckoVersion();| implemented as |return MOZILLA_VERSION;|

> easiest to implement of course would be an |const char* NS_GetGeckoVersion();| > implemented as |return MOZILLA_VERSION;| yeah, but we need to expose other things like the windowing system. i'd rather expose a method that allows us to return various strings... maybe a nsIProperties singleton or something simpler. However, whatever it is it should probably be callable prior to NS_InitXPCOM2 since initializing XPCOM creates an event queue on the calling thread, and that might invoke code that lives in the windowing system.

> nsIAppShell is another tricky interface to deal with. Unfortunately, embedders There are some serious issues here that need to be settled. The Create() method is absolutely bogus and has got to go. It is a no-op on GTK/win, it really is a static initializer that is meant for XUL app initialization of GTK/etc. If we can find a library to export a symbol from, I want a frozen GFX_init() symbol which can be called 1) before XPCOM startup and 2) would not be called by embedders, because they have already initialized GTK/whatever. This is something I need to solve in the 1.8 timeframe, if at all possible, because it affects what I'm doing with command line handling. Spinup is a problem I don't have a solution for ;)

Per https://bugs.eclipse.org/bugs/show_bug.cgi?id=76635, Eclipse is no longer using: nsIContentViewer nsIContentViewerContainer nsIDocumentLoaderFactory nsIInputStreamChannel That's great news, except that they are now using nsIDocShell::loadStream as a replacement. They weren't happy using a 'data:' URL since they want to load unknown HTML blobs as 'file:/' so that the HTML blobs can load other localfile resources. Unfortunately, they have a simple setText API that they are trying to support which does not afford them a way to associate a URL with the HTML blob. We need to freeze nsIWebBrowserStream for 1.8, so they can use that instead.

It is looking less and less likely that I will find the time to freeze all of the interfaces on this list. I would greatly appreciate any help with this effort. Christian? Boris? Anyone?

nsIFilePicker has joined the list of unfrozen interfaces that eclipse needs to use.

-> nobody

We don't freeze interfaces anymore.