114331 - Installer should find previously installed xul software and install it

Status: VERIFIED WONTFIX

(SeaMonkey :: Installer, enhancement)

Description

[Jonadab the Unsightly One (Nathan Eady)]

When a new (or otherwise different) version is installed, the
installer should find items/components/applications that have
been previously installed by the user and either automagically
install them in the newly-installed version, or offer to do so.

Reproducability:  100%  (Last tested with 2001120603 build.)

Steps to Reproduce:
1.  Install some very useful additional componenet, such as 
    the Preferences Toolbar (URL given in the URL field).  
2.  Download another version of Mozilla, such as the latest 
    nightly, the latest release, a commercially branded
    version, or whatever.
3.  Install the version you downloaded in step 2.

Expected Results:
    The Preferences Toolbar (or whatever) should be
    installed in the new version.

Actual Results:
    It isn't; hope you bookmarked the URL where you
    found the useful component...

This gets really old, repeatedly downloading and 
installing the same item over and over and over again.

I'm using Windows 95 OSR2, but I so strongly suspect
that this transcends platform, that I went ahead and 
marked it All/All, unless someone claims this works
on another platform.  

Severity is arguable here; could be anything from
normal to enhancement, depending on how you look
at it; feel free to adjust that.

Comment 1

[Daniel Veditz [:dveditz]]

If you install into the same directory you should find the old components on
windows (on Linux and Mac you need to wait for the "surgical upgrade" bugs to
get fixed). Does this not work?

Comment 2

[Jonadab the Unsightly One (Nathan Eady)]

> If you install into the same directory

Ah.  No, I haven't been installing into the same directory.  
Nor do I want to, and various documents at mozilla.org 
suggest that testers not do so: not doing so is stated as
a requirement for using PatchMaker, for one thing.  

How difficult would it be to get the installer to copy
over things from the previous install directory?

Comment 3

[Daniel Veditz [:dveditz]]

Pretty close to magic.

- On Mac and Linux have no clue where other installation dirs might be, on
windows at least could use the windows registry.

- Installer would need to know how to read the chrome registry in those other
installations

- Out of the installed packages it would have to have some idea which ones came
with Mozilla and which ones were "extra".

- Of the "extra" ones it would have to somehow deduce which ones were pure
chrome, because if there were any binary components (e.g. Netscape's IM, early
versions of Chatzilla) the copied-over chrome wouldn't work.

- Somehow it has to know which packages are safe to copy over, because as XUL
and other APIs change old packages quickly stop working on new versions --
sometimes to the extent of hanging or crashing Mozilla even if the feature isn't
explicitly used (thanks to navigator overlays).

Mozilla is not at the state where we can even think about doing something like
this in the installer, but there are two options you can pursue in the meantime:

1) convince chrome authors to install as "profile" chrome rather than "global"
chrome. The downside is that on multi-profile installations there will be
multiple copies of the package, but on the upside people/profiles not interested
in the package will not pay the cost of the extra chrome (there are measurable
performance and footprint costs associated with each .jar that's opened).
Package installs could even ask at install time which to choose.

2) work with the core XUL/chrome registry folks and package authors on some sort
of "chrome path" concept (similar to the work going on to allow multiple
component directories) so that chrome can be installed globally to some 3rd
location that will be preserved. If necessary the installer can be taught to
look up that path and propogate to the new installation if it's not some system
thing like an environment variable.

Finally, if you have a set of things you're always installing you can simplify
that process in a couple of ways. Easiest to set up would be to download the
.xpi files you like (download, not install) into a directory that you can visit
after each install and just click on all the links without having to track down
each site. Slightly harder to set up, but less work after each install, would be
to write a launching script and load that page:

  var packages = {
    "inspector"    : "http://some/url/for/inspector.xpi",
    "local chrome" : "file:///c|/extras/mypackage.xpi",
    // more...
  }

  InstallTrigger.install(packages);

The name of each property in the packages object is arbitrary as long as they're
unique, it just shows up in the confirmation dialog for your benefit. Results
are dumped to install.log, although if you want to see them you could write a
callback function

   function installCallback( url, status ) {
     if ( status != 0 )
       alert( "package "+url+" failed: "+status );
     // you can obviously get fancier than this
   }

   InstallTrigger.install(packages, installCallback);

Comment 4

[Grace Bush]

verified