Closed Bug 284150 Opened 20 years ago Closed 20 years ago

installation broken when installing 1.0.1 over 1.0PR zip firefox folder

Categories

(Firefox :: Installer, defect)

1.0 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

VERIFIED INVALID

People

(Reporter: bugzilla, Assigned: bugs)

Details

this may or may not be an edge case, but filing because I can reproduce it.

0. grab a .zip (compressed, non-installer) of firefox 1.0PR: it can be either
unpatched or patched 0.10.1 version (bug still occurs with both).

1. decompress and launch 1.0PR --I've tried with both a fresh profile and an
existing profile I had created with ffox 1.0 (official release).

2. add some bookmarks, surf around and develop some global history, try out the
Find toolbar in a couple of pages. that all works fine.

3. go to install the 1.0.1 .xpi (click on
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/experimental/update/en-US-1.0-1.0.1.xpi)

4. run through the installer, but do a Custom installation so that you can
select the *same* folder you had installed 1.0PR at (in step 1).

5. after the installer completes, it won't autolaunch ffox, as expected, so
double-click the desktop icon to start ffox.

results: while ffox 1.0.1 did install (confirm by looking at about:), I see
these problems:

- all of the bookmarks are gone
- the default start (home) page is blank
- when I do load a page and try to use the Find toolbar, found items are *not*
highlighted anymore.
not sure if this should go into the Software Update or Installer component;
reassigned as needed.
just to clarify: the 1.0PR builds I had tested were from the releases/0.10 and
releases/0.10.1 directories.
Are you positive the profile itself is horked? That is, if you use the same
profile in a cleanly installed 1.0 or 1.0.1 it is irreparably damaged?

I suspect rather that a 1.0 installed over a 0.10 zip build would have the 1.0.1
over 1.0 problem in spades. 1.0.1 had a small number of fixes, there was one
teensy little interface change and look at the problems. Between 0.10 and 1.0
there were lots more changes and most likely many idl changes. We could do a
bonsai query if you're really curious.

Instead of just autocomplete.xpt being a problem, there would be a lot more
"old" .xpt files laying around with different interface versions than the true
ones in browser.xpt

It's very important to distinguish: is the *profile* horked as stated in the
summary, or is it simply a very broken build due to the unsupported install method?
(In reply to comment #3)
> Are you positive the profile itself is horked? That is, if you use the same
> profile in a cleanly installed 1.0 or 1.0.1 it is irreparably damaged?

I uninstalled firefox 1.0.1, then did a clean install of ffox 1.0, and using the
same profile my data reappeared (bookmarks fine, startpage fine) and the find
toolbar worked again. *whew*
Summary: installing 1.0.1 over 1.0PR zip firefox folder horks profile → installation broken when installing 1.0.1 over 1.0PR zip firefox folder
so, the profile is fine, it's the installation method I used which is broken.
This is basically invalid. zip "releases" are developer things, fine for
nightlies but should not go into the "release" directories because they get
grabbed by people who don't know the rules.

The rules are: Never put a zip build on top of another build (zip or not), never
put another release (zip or not) on top of a zip build.

In fact, the installer cleanups lag behind, people using nightlies would be
advised not to install on top of another build regardless of whether using the
zip or installer releases. Of course most of the time putting a build on top of
yesterday's build is just fine, but for every bustage-causing change there is
*the* day that change went in, and you never know which day it is ahead of time.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
QA Contact: bugzilla → installer
You need to log in before you can comment on or make changes to this bug.