157522 - additionally installed software (gestures, extensions...) are lost after 'update'

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect)

Description

[Damir Perisa]

when you install the newest nightly-build over the yesterday-build, all 
additional software (gestures and other usefull things) are disabled and
need to be re-installed - not so themes

this problem is minor, because most users dont install each day the newest
build, but the management of add-ons may be enhancable to keep great ones (like
gestures from optimoz or other usefull extension) like themes 
while 'updating' to the newest build

Comment 1

[Vidar Haarr (not reading bugmail)]

Correct.
This is because themes are installed in the profile directory (c:\docs and
settings\<profile>\App Data\Mozilla\... on winxp/2k), and other installed
software is installed in the mozilla application directory.

Should this be 'Installer: XPInstall Engine' ?

Comment 2

[Daniel Veditz [:dveditz]]

No, the engine has nothing to do with this. The engine does what it's told, and
it's doing that correctly. It's the native install wizard that's making this
choice (it doesn't on windows, for example).

This is a result of the "fix" for bug 140104 (and many similar, like bug
130088). This problem cannot be solved by the install team alone since we're
zapping stuff to work around problems with the chrome/component system. For most
of the developers if it works in a clobber build then problem's solved, not much
thought is given to upgrade incompatibilities.

There's no near-term fix for this. I'll confirm this and leave it open as a dupe
magnet, but we really need the chrome system to gracefully handle missing
overlays and allow uninstallation of old overlays.

(note that on Mac and Linux this is the way things have always been. We never
attempted an upgrade install in the first place, the old installation was always
deleted first.)

Comment 3

[Damir Perisa]

Is it possible to create a new option 
(e.g. in the Preferences-SoftwareInstallation) 
where you can choose where you want to install new addons per default; either in
the chrome-system/browser-installation or in the user-profile(like themes are
linked)?

Comment 4

[Daniel Veditz [:dveditz]]

Actually I take back most of my comment 2, the fix for bug 140104 shouldn't have
removed any package that was installed with the DELAYED_CHROME style which is
most of the ones I see, unless we're also deleting installed-chrome.txt for some
reason.

Which we in fact do with [Delete File2] in config.it :-(

Not sure why, maybe the fix for this is as easy as removing that section.

Comment 5

[Daniel Veditz [:dveditz]]

*** Bug 157609 has been marked as a duplicate of this bug. ***

Comment 6

[Charles Rosendahl]

I am raising the priority of this problem, as it is not a minor issue.  Bug
140104 combined with the following code fragment (I think) wipe out all
installed packages and forces a reinstallation of all of packages.

xpinstall/src/nsRegisterItem.cpp:
293        if (NS_SUCCEEDED(rv))
294         {
295             rv = startupFile->Exists(&bExists);
296             if (NS_SUCCEEDED(rv) && !bExists)
297                 rv = startupFile->Create(nsIFile::DIRECTORY_TYPE, 0755);
298             if (NS_SUCCEEDED(rv))
299             {
300                 rv =
startupFile->AppendNative(NS_LITERAL_CSTRING("installed-chrome.txt"));
301                 if (NS_SUCCEEDED(rv))
302                 {
303                     rv = startupFile->OpenNSPRFileDesc(
304                                     PR_CREATE_FILE | PR_WRONLY,
305                                     0744,
306                                     &fd);
307                 }
308             }
309         }
310
 
In a corporate environment where it is possible that custome applications have
been created using the XUL framework, the current situation discourages anyone
from upgrading to a newer client should they have chrome package extensions
installed.

Perhaps it is as easy as creating a separate, install independent file such as
delayed-chrome.txt that is never wiped out during installs and has nothing to do
with the browser itself.

Comment 7

[Daniel Veditz [:dveditz]]

That fragment is innocent, as I mentioned in comment 4 it's the [Delete File2]
section of config.it that's to blame. If we remove that we save any chrome
installed with the DELAYED_CHROME style which writes to installed-chrome.txt.
Most chrome packages use that style because of a mysterious -239 error on Linux
(for a large number of people) if they do not.

Comment 8

[dprice (gone)]

Attachment: patch

Here's the patch Dan asked for.  Can somepoint me to a test case?

Comment 9

[dprice (gone)]

a gremlin stole 4 characters from me!  It should read...
Can someone point me to a test case?

Comment 10

[dprice (gone)]

Attachment: the right patch

Comment 11

[Daniel Veditz [:dveditz]]

Comment on attachment 92268 [details] [diff] [review]
the right patch

sr=dveditz, but where's the ns-tree patch?

Comment 12

[dprice (gone)]

Attachment: patch 1 - ns changes

Comment 13

[Daniel Veditz [:dveditz]]

Comment on attachment 92319 [details] [diff] [review]
patch 1 - ns changes

sr=dveditz

Comment 14

[Tuukka Tolvanen (sp3000)]

*** Bug 158986 has been marked as a duplicate of this bug. ***

Comment 15

[Asa Dotzler [:asa]]

Comment on attachment 92268 [details] [diff] [review]
the right patch

a=asa (on behalf of drivers) for checkin to 1.1

Comment 16

[Vidar Haarr (not reading bugmail)]

Should this be rel-noted ?

Comment 17

[Daniel Veditz [:dveditz]]

We don't normally relnote bug fixes, the list would be thousands long.

Comment 18

[dprice (gone)]

on the trunk

Comment 19

[Grace Bush]

verified on builds for 8/6 branch and Mozilla 7/26 upgraded to 8/6 
verified code fix- chrome.txt not being deleted