Closed
Bug 80171
Opened 23 years ago
Closed 23 years ago
Clicking xpi file w/o mime info fails to recognize and install
Categories
(Core Graveyard :: Installer: XPInstall Engine, defect)
Core Graveyard
Installer: XPInstall Engine
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.2
People
(Reporter: jimmykenlee, Assigned: slogan)
References
Details
(Keywords: regression, Whiteboard: fix available)
Attachments
(1 file)
1.02 KB,
patch
|
Details | Diff | Splinter Review |
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)
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.
Severity: critical → major
Keywords: nsbeta1,
regression
Comment 2•23 years ago
|
||
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•23 years ago
|
||
I am aware of no change that could have this impact.
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.
Updated•23 years ago
|
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•23 years ago
|
||
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.
This still works for me on today's builds. Try clicking on a test from http://www.mozilla.org/quality/smartupdate/xpis/
Comment 10•23 years ago
|
||
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•23 years ago
|
||
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.
Summary: Clicking on xpi file using mime support fails to install → Clicking xpi file w/o mime info fails to recognize and install
Reporter | ||
Comment 12•23 years ago
|
||
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•23 years ago
|
||
Comment 14•23 years ago
|
||
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•23 years ago
|
||
*** Bug 79617 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 16•23 years ago
|
||
r=syd
Comment 17•23 years ago
|
||
*** Bug 83863 has been marked as a duplicate of this bug. ***
Comment 18•23 years ago
|
||
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.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Assignee | ||
Comment 19•23 years ago
|
||
Patch works, we'll get this into 0.9.2
Comment 20•23 years ago
|
||
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.
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•23 years ago
|
||
nav traige team: Reassigning to syd to get the patch reviewed and checked in
Assignee: law → syd
Comment 23•23 years ago
|
||
*** Bug 84350 has been marked as a duplicate of this bug. ***
Comment 24•23 years ago
|
||
*** Bug 84697 has been marked as a duplicate of this bug. ***
Comment 25•23 years ago
|
||
Will this fix the problem with local (from disk) installation of xpi files?
Assignee | ||
Comment 26•23 years ago
|
||
Yes, I suppose it it time to get this patch landed...
Comment 27•23 years ago
|
||
*** Bug 84960 has been marked as a duplicate of this bug. ***
Comment 29•23 years ago
|
||
*** Bug 85291 has been marked as a duplicate of this bug. ***
Comment 30•23 years ago
|
||
*** Bug 85566 has been marked as a duplicate of this bug. ***
Comment 31•23 years ago
|
||
*** Bug 85657 has been marked as a duplicate of this bug. ***
Comment 32•23 years ago
|
||
*** Bug 85975 has been marked as a duplicate of this bug. ***
Comment 33•23 years ago
|
||
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•23 years ago
|
||
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 36•23 years ago
|
||
sr=mscott
Comment 37•23 years ago
|
||
a=blizzard on behalf of drivers for the trunk
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 38•23 years ago
|
||
fix checked in
Comment 39•23 years ago
|
||
verified on all platforms trunk/branch 200106250x
Status: RESOLVED → VERIFIED
Updated•9 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•