21977 - Updating SeaMonkey with update.html does not install properly

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect, P2)

Description

[Jimmy Lee]

Build: 1999-12-14-08-M12(MAC)

1. Install 1999-12-14-08-M12(MAC)
2. Launch the browser
3. Open ftp://sweetlou/products/client/seamonkey/macos/8.x/ppc/
4. Select any directory that is more recent that 1999-12-14-08-M12 and open
5. Open update.html
6. Click Launch XPInstall with Navigator, Mail, and Aim selected

RESULT:
The files are installed into a folder named "Netscape Folder" that is a
subdirectory of the currently installed copy of SeaMonkey.

EXPECTED RESULT:
Install script instructs files to be installed into the same directory as the
currently running SeaMonkey to schedule a replacement of files.

Comment 1

[Jimmy Lee]

Reassigning to Samir as he requests.

Comment 2

[Samir Gehani]

The problem is that these .xpis were written to work with the install wizard,
and thus, create a subfolder called "Mozilla Folder" or "Netscape Folder"
depending on the installer incarnation used. We need to parse install script
args (wizard passing in a symbolic string like "WIZARD" and trigger page passing
in nothing) to determine at install script run time whether to ask
addDirectory() to create the afore mentioned subfolder. The fix is
scattered and straight forward but this probably won't be considered dogfood.
Accepting for M13.

Comment 3

[Daniel Veditz [:dveditz]]

The windows install does not have this problem, that is, the same XPI files
work in both the wizard and from the update page. Before complicating the
install script with arguments check with Sean to see if the win-install design
might work on the Mac too.

Comment 4

[Samir Gehani]

Windows folks expect the binaries to be installed in the selected target folder.
Mac folks, on the other hand, expect a nice little subfolder to be created for
them under the selected target folder. Thus, we create the subfolder on mac but
not windows. Sean suggested a cleaner fix: take the subfolder param in the
config.ini. This allows third party .xpis to be dropped in to the install wizard
or pointed to from a trigger page alike.

Comment 5

[Samir Gehani]

Moving M13 bugs due to Samir's vacation

Comment 6

[leger]

Putting on pdt+ radar for beta1.

Comment 7

[Michael La Guardia]

We don't need this for beta.  Having the xpi files available from a SmartUpdate 
site is gravy, and I'm sure the Netcenter folks would be happy to know they 
don't have to create one.

Taking internal (call me paranoid).

Removing PDT+ for reconsideration.

Comment 8

[Daniel Veditz [:dveditz]]

You're paranoid :-)

Comment 9

[Samir Gehani]

Yes, I agree that since the beta1 keyword really implies "Netscape beta", not 
"Mozilla beta", this bug should not have been recommended for beta1 in the first 
place. This is because external users couldn't (in theory) have a 
Netscape branded Seamonkey to upgrade *from* in the first place. (And I doubt 
we'll support a Mozilla  to Netscape upgrade.) Revoking the beta1 keyword 
altogether. 

Comment 10

[Daniel Veditz [:dveditz]]

A quibble, but "beta1" is not necessarily restricted to Netscape. Conceivably 
mozilla.org could go through the PDT- bugs and add MOZ+ if they wanted.

As to the particular bug -- this is a package/script problem? If it's not an 
engine problem then I agree it's not beta. I must have confused this with a 
different bug.

Comment 11

[Cathleen]

jimmy can you verify if this is still a problem?

Comment 12

[Samir Gehani]

Yes, this is still a problem.  Simple fix.  

Comment 13

[Samir Gehani]

OK, so the correct fix is to have the wizard create the subfolder so we don't 
mess up the getFolder() targets.  Not as trivial.  Needed for nsbeta2; hence, 
nominating.

Comment 14

[Michael La Guardia]

putting on nsbeta2+ radar.  Will become minus on 6/15

Comment 15

[Samir Gehani]

This is fixed but because we can't trigger using ftp we are blocked from testing 
it.

Comment 16

[Samir Gehani]

QA,
In order to test it move the update.html and xpi dir to your own http server.  
The update.html file contains relative URLs so we should be able to test this 
successfully.  (Sorry, for the lie about being blocked form testing it in my 
last comment.)

Comment 17

[Jimmy Lee]

Build: 2000-06-02-08-M16(MAC)

It bloody works from http.  Marking Verified!

Comment 18

[Samir Gehani]

That is to say, the .xpi are updated.  There is still a bug in update.html that 
we don't specify the "xpi" directory.  We modified Jimmy's update.html locally.  
Still need to check that fix in.  Jimmy, can you log a bug against moi about 
thsi problem: "Add xpi subdir in update.html" or some such summary.  (Note, ftp 
is still broken so even with the change to update.html we won't be able to 
update from sweetlou which runs only an ftp server I believe.)