Out of the discussion of bug 227796, we decided it was best for embedding clients (Seamonkey, Firebird, Camino, for example) that want to use XPInstall for the XPInstall FE to be implemented as a XPCOM component. Native FEs like Camino can implement this component and use it to drive native widgetry, XUL FEs like Seamonkey and Firebird can use it to drive a XUL/JS FE.

Shove this out a bit.

confirmInstall will catch the first InstallTrigger.install() callback: - push in front the current installation and stop the current one (recursive call allowed) - if no runnning installation, store the calling window for the second callback openProgressDialog will catch the second Installtrigger.install() callback: - open the installation dialog using the stored window in the first call - of got recursive call call setProgressDialog function of the installation dialog

(In reply to comment #0) > Out of the discussion of bug 227796, we decided it was best for embedding > clients (Seamonkey, Firebird, Camino, for example) that want to use XPInstall > for the XPInstall FE to be implemented as a XPCOM component. Native FEs like > Camino can implement this component and use it to drive native widgetry, XUL FEs > like Seamonkey and Firebird can use it to drive a XUL/JS FE. This not really required as it is possible to implement the "@mozilla.org/embedui/xpinstall-dialog-service;1" and then drive completelly the two dialogs used during the installation. I'm close to finish the port of Inno Setup under Mozilla1.6. You install the installer which then can be used to install multiple package based on various parameters (like Inno Setup) e.g. Module Selection, etc..