Closed Bug 383224 Opened 13 years ago Closed 13 years ago

Remove XPInstall bits from the Download Manager


(Toolkit :: Downloads API, defect)

Not set





(Reporter: sdwilsh, Assigned: sdwilsh)





(3 files)

Follow-up from Bug 382825.  I do not beleive that the download manager is actually handling XPI downloads correctly.  I'm still trying to make sense of what the old code did and why I have yet to come across a downloads.rdf with some xpinstall file in it.
It doesn't matter actually, because nothing uses it!  Patch in just a bit :)
Summary: Download Manager doesn't properly handle XPInstall Files → Remove XPIntall bits from the Download Manager
Summary: Remove XPIntall bits from the Download Manager → Remove XPInstall bits from the Download Manager
Dave, can you double check for me that this doesn't break anything with the extension manager?  As far as I can tell it doesn't.
Attachment #268407 - Flags: review?(mano)
Attachment #268407 - Attachment description: v1.0 → v1.0 backend
Attachment #268646 - Flags: review?(enndeakin)
Done a bit of digging around to this and xpinstall opens a dialog to handle displaying progress of xpi downloads. Before Firefox 1 this was set to the download manager. By Firefox 1 it had changed to the new EM UI. It's all a little messy due to being on the avairy branch, but before the checking the pref used to choose the progress dialog was xpinstall.dialog.progress.type, after it was and for themes and extensions.

The opening of the progress dialog all happens from here

Slightly worrying is that if the progress dialog is already open then xpinstall sends out xpinstall-download-started to any registered observers and it looks like the DM is currently still registering itself for that.
Oh those preferences are for hte window type, s/.type// to get the prefs for the xul url.
Comment on attachment 268407 [details] [diff] [review]
v1.0 backend (checked in)

r=mano, please double-check that tb/sb don't default to this window for the xpi installation.
Attachment #268407 - Flags: review?(mano) → review+
Attachment #268646 - Flags: review?(enndeakin) → review+
I neglected to include the change in the public dir in the patch, so I fixed that before checking in.

Checking in toolkit/mozapps/downloads/content/download.xml;
new revision: 1.26; previous revision: 1.25
Checking in toolkit/mozapps/downloads/content/downloads.css;
new revision: 1.8; previous revision: 1.7
Checking in toolkit/mozapps/downloads/content/downloads.js;
new revision: 1.64; previous revision: 1.63
Removing toolkit/components/downloads/public/nsIXPInstallManagerUI.idl;
new revision: delete; previous revision: 1.3
Checking in toolkit/components/downloads/public/;
new revision: 1.5; previous revision: 1.4
Checking in toolkit/components/downloads/src/nsDownloadManager.h;
new revision: 1.29; previous revision: 1.28
Checking in toolkit/components/downloads/src/nsDownloadManager.cpp;
new revision: 1.92; previous revision: 1.91

Leaving open because rob_strong pointed out that I was missing a few other things still.
Attachment #268407 - Attachment description: v1.0 backend → v1.0 backend (checked in)
Attachment #268646 - Attachment description: v1.0 ui → v1.0 ui (checked in)
Attached patch v2.0Splinter Review
Attachment #269685 - Flags: review?(mano)
Blocks: 385875
Checking in toolkit/components/;
new revision: 1.68; previous revision: 1.67
Checking in toolkit/components/build/;
new revision: 1.49; previous revision: 1.48
Checking in toolkit/components/build/nsToolkitCompsModule.cpp;
new revision: 1.44; previous revision: 1.43
Checking in toolkit/components/downloads/src/;
new revision: 1.13; previous revision: 1.12
Checking in toolkit/mozapps/downloads/content/download.xml;
new revision: 1.28; previous revision: 1.27
Closed: 13 years ago
Resolution: --- → FIXED
Flags: in-testsuite-
Target Milestone: --- → Firefox 3 alpha6
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.