240811 - Extension manager shows empty download window and doesn't install extension

Status: RESOLVED FIXED

(Toolkit :: Downloads API, defect)

Description

[Mike Pesce (:By-Tor)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040416 Firefox/0.8.0+ (scragz)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040417 Firefox/0.8.0+

When dragging and dropping or downloading an extension into Firefox, the
extension manager prompts to install the extension, but then only opens an empty
download window.  This leaves no way to install an extension in the 20040417 build.

Reproducible: Always
Steps to Reproduce:
1. Drag and drop or download extension
2.
3.

Actual Results:  
Empty download window with no action to install extension.

Expected Results:  
Extension should be installed.

Comment 1

[Gordon Griswold]

Attachment: After clicking "INSTALL" for an extension this is all you get!

The attachment is from "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.8a) Gecko/20040418 Firefox/0.8.0+" version of FFx, during an attempt to
install the "SmoothWheel" extension. No "success" or "Restart Browser" messages
and no extension installation.

Comment 2

[Mike Connor [:mconnor]]

so we're getting a "doXPIInstall is not defined" but I have no idea where that's
being called from (lxr doens't give me anything)

Comment 3

[Darin Fisher]

I can reproduce this in a CVS trunk build (20040418) of Firefox on Linux.

Comment 4

[betheking]

The file mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in
contains a few problems:

1) The pref "extensions.lastAppVersion" (referenced through the const
PREF_EM_LAST_APP_VERSION) does not exist. Adding it to firefox.js (in the
install directory) "fixes" the first problem (error at line 64).

2) Line 71 refers to a variable called ds, which isn't defined (only visible
once you fix the first problem). The method called,
getIncompatibleExtensionList, can't be found by lxr.mozilla.org (except at
nsExtensionManager.js.in:71 then)...

Comment 5

[David A. Cobb]

I've had the same problem on builds 04/17/2004 & 04/18/2004.
It does not depend on how the extension is loaded (unrelated to drag-n-drop), if
I click on of the .xpi links at mozdev.org, or if I try to open-file on a local
copy of an .xpi file, the download manager pops up but does nothing at all and
there is none of the usual dialog about where to install or requiring a restart.
 If I do restart the browser, the extension is not shown in Options/Extensions.

However, two extensions that were left in my profile from a prior state did show
in the Options/Extensions.

Build 04/16/2004 is OK in this regard.  This is a stopper for me; I won't
install a newer Firefox until this is fixed.

Comment 6

[Doug Halamay]

It seems that this checkin is the problem:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=ben%25bengoodger.com&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-04-16+21%3A41%3A00&maxdate=2004-04-16+21%3A41%3A59&cvsroot=%2Fcvsroot

I guess it's all up to Ben now...

Comment 7

[Peter Lairo]

I think this bug may be affecting the download manager too. When I download a
file, there is no progress meter, even though my firewall shows "traffic" from
firefox.

Should the summary be updated to include "download manager"?

Comment 8

[Peter Lairo]

Attachment: Screenshot showing non-functional Download Manger

Comment 9

[Cody 'codeman38' Boisclair]

I've noticed the same thing involving misleading progress in the download
manager, but I'm not entirely sure whether it's a result of this bug or
something different entirely... from what I recall, the download progress seems
to have been displaying wrongly before the extension installing bug even came about.

Comment 10

[Cody 'codeman38' Boisclair]

Actually, ignore the above comment; I was remembering things incorrectly. The
download progress bar seems to work properly in the 20040416 build.

Comment 11

[PikeUK]

(In reply to comment #7)
> I think this bug may be affecting the download manager too. When I download a
> file, there is no progress meter, even though my firewall shows "traffic" from
> firefox.
> 
> Should the summary be updated to include "download manager"?

That's Bug 240835 (which should be fixed in todays build).

Comment 12

[PikeUK]

I think this bug is another side-effect of the FTP Upload checkin, specifically
this:

http://bonsai.mozilla.org/cvsview2.cgi?subdir=mozilla/toolkit/components/downloads/public&command=DIFF_FRAMESET&file=nsIDownloadManager.idl&rev1=1.4&rev2=1.5

It works OK if you change the relevant lines of download.js at:

http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/downloads/content/downloads.js#585

to this:

var targetUrl = makeFileURL(localTarget);
var download =
gDownloadManager.addDownload(Components.interfaces.nsIXPInstallManagerUI.DOWNLOAD_TYPE_INSTALL,

  uri, targetUrl, displayName, iconURL, mimeInfo, 0, null);

This makes extension installation work again for me, I don't know if it's a very
good (or even correct) fix but doing something like that should work.

Comment 13

[Doug Halamay]

Attachment: Patch per Pike's comment

Thanks Pike!  I'm also not sure if this is a correct way to fix the problem,
but, as you said, it seems to work.

Comment 14

[Doug Halamay]

Comment on attachment 146788 [details] [diff] [review]
Patch per Pike's comment

Requesting review...

Comment 15

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 146788 [details] [diff] [review]
Patch per Pike's comment

r=[e-mail]

Comment 16

[Doug Halamay]

Do I need a sr for this (and if so, who should I request it from?), or should we
just wait on this until the new Extension Manager code is finished and hooked up?

Comment 17

[Ali Ebrahim]

(In reply to comment #16)
> Do I need a sr for this (and if so, who should I request it from?

No sr is required for changes to /mozilla/toolkit. See here:
http://www.mozilla.org/projects/firefox/review.html

Comment 18

[Doug Halamay]

Ok, then I guess the next logical question is...can someone check this in?

Comment 19

[Darin Fisher]

the patch is correct.  this bug is a regression caused by my patch for bug 24867

Comment 20

[Darin Fisher]

fixed-on-trunk

Comment 21

[Jesse Ruderman]

Does this bug also exist on the 1.7/0.9 branch?

Comment 22

[Mike Connor [:mconnor]]

http://bugzilla.mozilla.org/show_bug.cgi?id=24867#c197 indicates this isn't
going to land on the 1.7 branch, so no.

Comment 23

[Ali Ebrahim]

(In reply to comment #21)
> Does this bug also exist on the 1.7/0.9 branch?

No, I spoke to Darin today and found out from him that the patch that caused
this bug was checked into the trunk after 1.8a opened and was not checked into
the 1.7 branch. Hence my removal of the blocking0.9 flag.