80171 - Clicking xpi file w/o mime info fails to recognize and install

Status: VERIFIED FIXED

(Core Graveyard :: Installer: XPInstall Engine, defect)

Description

[Jimmy Lee]

Build: 2001-05-10-06-trunk(WIN), 2001-05-10-04-trunk(MAC), 
2001-05-10-15-trunk(LINUX)

1. Open http://jimbob/jars
2. Click on any xpi file such as a_adddelregfile.xpi
3. Click OK button from Items to Install dialog

RESULT:
No Download dialog starts.  No installation occurs.

EXPECTED RESULT:
Download dialog appears.  Installation occurs.

NOTE:
Install does occur if started by trigger script. (http://jimbob/trigger3.html)

Comment 1

[Jimmy Lee]

Nominating for beta.  Changing severity from Critical to Major.  This is a 
regression.  This is loss of basic functionality. I wonder if this is related 
any to our loss of getting an install.log.

Comment 2

[Daniel Veditz [:dveditz]]

Doug, have any idea what might have changed recently that would break the 
XPInstall MIME type content handler? Bill, did you helper apps changes do 
anything there?

Comment 3

[Doug Turner (:dougt)]

I am aware of no change that could have this impact.

Comment 4

[Bill Law]

The helper app changes (particularly, fixes to the uriloader/exthandler code)
could be producing different behavior.  I'll try this out tomorrow and see what
I can find out.

Comment 5

[Daniel Veditz [:dveditz]]

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

Comment 6

[shrirang khanzode]

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

Comment 7

[Jimmy Lee]

Build: 2001-05-22-06-trunk(WIN), 2001-05-22-08-trunk(LINUX), 
2001-05-21-12-trunk(MAC)

Today I am unable to reproduce this problem.  I'm pretty sure yesterday worked 
as well.  I am able to install xpis by simply clicking on the individual file.

Comment 8

[Valdis Kletnieks]

Am still seeing the problem on the 20010524 nightly build, as reported in bug
80964.  Clicking on a .xpi link offers to save to disk, but the version that's
invoked from a .html works fine.

Comment 9

[Jimmy Lee]

This still works for me on today's builds.  Try clicking on a test from 
http://www.mozilla.org/quality/smartupdate/xpis/

Comment 10

[Valdis Kletnieks]

Testing the http:// .xpi's worked.  I wonder if I'm seeing the problem on the
one URL because it's ftp:// instead?  If fetching via FTP, you don't get the
HTTP/Mime stuff, so all Mozilla has to clue off is th e.xpi file name extension.

Now, a case could be made that if you're fetching via FTP, the auto-invocation
of a .xpi should be disabled - in which case somebody should remove the
reference to
ftp://ftp.netscape.com/pub/netscape6/english/6.0/unix/linux22/xpi/jre.xpi from
http://www.mozilla.org/releases/ (which is where I tripped over this issue).

Comment 11

[timeless]

http://ftp.netscape.com/pub/netscape6/english/6.0/unix/linux22/xpi/jre.xpi
appears to work, however if someone needs an ftp server then we're messing up.

The summary needs to be changed since we've combined the working mime mapping 
w/ the non working mime guessing.  I've made a change, feel free to try again 
if I messed up.

Comment 12

[Jimmy Lee]

Adding info.

I cannot reproduce this problem on Windows NT.  But I am able to reproduce this 
on Windows 98, Macintosh, and Linux.  It seems that any xpi from sweetlou 
behaves this way as I tried a few randomly in different directories.

Comment 13

[Bill Law]

Attachment: Simple fix

Comment 14

[Bill Law]

I attached the fix, which is trivial.  I just moved .xpi back to the pre-filled 
uri loader cache which enables us to map the extension to the mime-type (which 
then gets the content to the installer).

The drawback is that you won't be able to override this in prefs, but that's 
probably OK in this case.

I'm taking this back from Syd (but Syd, if you want to follow up with getting 
this patch reviewed and checked in, please grab it back).

Comment 15

[Bill Law]

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

Comment 16

[Syd Logan]

r=syd

Comment 17

[Boris Zbarsky [:bzbarsky]]

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

Comment 18

[Viswanath Ramachandran]

adding aruner and chrisn to comment on importance. if no data available to 
suggest importance of this for release, moving to m0.9.3. at least. 

Comment 19

[Syd Logan]

Patch works, we'll get this into 0.9.2

Comment 20

[Viswanath Ramachandran]

Syd - you shdnt be doing that without a justification. We agreed in the pdt 
meeting to move this off the stopper list. the bug already had a fix when we 
moved it. 

Comment 21

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Neither the http link nor the ftp link nor downloading the XPI to a file works
for me (on Linux, on my own opt build).  This prevents me from installing Java,
which means I can't test Java bugs (or use Java, but then again judging from the
bugs I'd like to test I suspect I still wouldn't want to do that).

Comment 22

[Paul Chen]

nav traige team:

Reassigning to syd to get the patch reviewed and checked in

Comment 23

[Matthias Versen [:Matti]]

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

Comment 24

[Matthias Versen [:Matti]]

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

Comment 25

[Dennis Haney]

Will this fix the problem with local (from disk) installation of xpi files?

Comment 26

[Syd Logan]

Yes, I suppose it it time to get this patch landed...

Comment 27

[Matthias Versen [:Matti]]

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

Comment 28

[Syd Logan]

r=syd (patch came from bill law)

Comment 29

[R.K.Aa.]

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

Comment 30

[R.K.Aa.]

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

Comment 31

[Boris Zbarsky [:bzbarsky]]

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

Comment 32

[Scott Tran (Wildcard)]

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

Comment 33

[Ben Bucksch (:BenB)]

Does the initial testcase <http://jimbob/jars> report "application/octet-stream"
as mimetype (I can't load it)? Then, this would be part of bug 67940. (Not
necessarily a dup, since we could special-case ".xpi" for now.)

The testcases at <http://www.mozilla.org/quality/smartupdate/xpis/> do deliver
"application/x-xpinstall" as mimetype, thus are inappropriate as testcase for
this bug (which explicitly states in the summary "Clicking xpi file w/o mime
info") - they should work in any case.

I'm relatively sure that xpis served via HTTP with mimetype
"application/octet-stream" did *not* trigger the install in Mozilla 0.6, if
clicked directly (not loaded using InstallTrigger scripts) - I specifically
asked my provider to add that mimetype for that reason.

Not that I would object a checkin - au contraire :).

Comment 34

[Aleksey Nogin]

Somewhat related - BTW, the
http://ftp.netscape.com/pub/netscape6/english/6.0/unix/linux22/xpi/jre.xpi URL
mentioned here is currently served with 
Content-type: text/plain
in the HTTP header. Any of netscape.com people on the CC list can get it fixed?

Comment 35

[Jacek Piskozub]

Mostfreq keyword added at 10 dups

Comment 36

[Scott MacGregor]

sr=mscott

Comment 37

[Christopher Blizzard (:blizzard)]

a=blizzard on behalf of drivers for the trunk

Comment 38

[Syd Logan]

fix checked in

Comment 39

[Grace Bush]

verified on all platforms
trunk/branch 200106250x