Freeze nsIExternalHelperAppService. Eclipse and the embedding examples make use of nsIHelperAppLauncher. Also, this IDL file contains three interfaces, which should each have their own file, according to http://www.mozilla.org/projects/embedding/HowToFreeze.html.

>Freeze nsIExternalHelperAppService. >Eclipse and the embedding examples make use of nsIHelperAppLauncher. so which of the two do you want to freeze?

Biesi, you're too quick for me! Changing summary accordingly. Also, might as well use this bug to freeze nsIHelperAppLauncherDialog.

heh. sorry for being quick ;) hm.. there's no nsIHelperAppLauncherService... do you mean *Dialog? some comments on nsIHelperAppLauncher: - I'd kinda like to change nsIHelperAppLauncher slightly (add a method and a property), see patch in bug 57342 - nsIHelperAppLauncher should probably use a lowercase cancel method instead of the current uppercase one - the rememberThisPreference arguments are currently ignored, as is the chosen passed application (iirc) - setWebProgressListener: not sure why this exists - closeProgressWindow: doubtful that this actually ever called; mozilla does not require calling it anyway (i.e. no leaks even if not called)

These apis are generally in pretty bad shape, still... I know they're rather critical, but I'd hate to freeze them as-is.

It would be wise for us to seriously consider supporting interfaces in use by Eclipse, even if that means freezing them as obsolete interfaces. I hear your concerns about freezing poorly engineered interfaces, but compatibility is important.

I agree, but we have dozens of bugs in these interfaces. The only way we can freeze them, in my opinion, is to freeze them, stop using them internally, and start using some other interfaces....

nsIHelperAppLauncher also makes use of nsIMIMEInfo, which would also need to be frozen. That's bug 162116.

-> me for now

-> default owner

We no longer freeze interfaces.