Closed Bug 313468 Opened 18 years ago Closed 6 years ago

".xpi" should be associated with something useful in windows-explorer


(Firefox :: Installer, enhancement)

Windows XP
Not set





(Reporter: BesTo, Unassigned)



".xpi" should be associated with firefox in windows-exlorer
What about other applications that also use xpi's like xulrunner, thunderbird, etc. ?

Changing component since the EM doesn't manage file associations that would be set during an install
Severity: normal → enhancement
Component: Extension/Theme Manager → Installer
QA Contact: extension.manager → installer
Maybe a right click submenu "Install in"?
Also see bug 313471 which conflicts to some extent with this bug.
Same reporter, this bug should be closed as the other one is more interesting.
*** Bug 313471 has been marked as a duplicate of this bug. ***
Well, my goal is to have the XPI handler be much smarter in general, and reuse the "XPI" mimetype and extension for xulapps. So when Firefox encounters an XPI, it will look for an application.ini as well as install.rdf, and inspect whether the bundle is an extension or an application (or both); then it will take the appropriate action of installing the extension (to Firefox, or Thunderbird, or whatever), or installing the xulapp. UI spec still needs to be written.
And it really doesn't matter to me what process does this (some xulrunner app would be fine) as long as it's visually seamless from the user's perspective.
Component: Installer → Extension/Theme Manager
QA Contact: installer → extension.manager
Benjamin - I agree wholeheartedly regarding making the internal handling of xpi's smarter but the original request is quite different than your comment. In relation to the original request of associating xpi's with Firefox on Windows do you think this should be done? If so, then this should probably be done during install. If not, then this bug's summary should either be morph'd or it should be closed and a new one opened with the correct info.
1) we're definitely not going to do this for Firefox 1.5
2) we can use/morph this bug as needed on the trunk to associate whatever process we end up deciding to use
Summary: ".xpi" should be associated with firefox in windows-exlorer → ".xpi" should be associated with something useful in windows-exlorer
(In reply to comment #1)
> What about other applications that also use xpi's like xulrunner, thunderbird,
> etc. ?
Also reopend my other bug #313471 as it can be an better and powerfuller long-term solution.
Depends on: 314042
*** Bug 313471 has been marked as a duplicate of this bug. ***
Some other applications, like Flock, register .xpi for themselves, so Mozilla should do something about that.

Probably there should be small application "Mozilla extension installer" which checks whether application for that .xpi exists and then starts it with parametars which will install .xpi.
Benjamin, Robert, what's the status of this bug? Were any decisions (or design docs) made?
I planned on looking at this when xullrunner is the platform Firefox is running on along with adding well known extension install locations for apps. So, no progress from me for 1.8.1
Hey all, this is Rob from Songbird. Sorry if this is too long or the wrong venue. Corrections warmly welcomed. 

Background: We're readying an update our Songbird public SVN to 0.2 alpha in prep for a July-ish 0.2 "Developer Preview" launch on Windows, Mac OS X and Linux. A key objective is supporting XPI extensions across all platforms. 

Requirements: Songbird 0.2 needs to provide users the same one-click XPI extension installation experience as Firefox extension installation regardless of XPI source including Firefox or other browsers via an Songbird-specific XPI link. Likewise, upon a Songbird user's click of a Firefox-specific XPI link, Songbird redirects to Firefox. 

This requirement is sufficiently complex that it may need to be addressed from more than one approach to resolve most cases. 

* Songbird-specifc mime-type on Songbird XPIs
Upon installation Songbird registers a Songbird XPI OS-level mime-type to be determined. On we will shortly host a Songbird extensions collection that generates that Songbird-specific mime-type on XPI downloads. Additionally, we will document/share this mime-type info with Songbird XPI developers so that most Songbird XPIs are served with an appropriate mime-type.

We believe that most Songbird users will install most of their extension from Songbird's extension site either within Songbird or Firefox, so this is a good partial fix. Moreover, it's easier for us to set on a user's machine at Songbird install time and to control on our Web site.

* XULRunner XPI Handler

The idea, as I understand it, is that the single XULRunner instance manages all extensions. Specific XULRunner clients access their extensions through this handler.  Sounds great to us. =)

* Register a protocol?

Another solution is to register a protocol, e.g., songbird:// This is an interesting option in a number of ways, most of them beyond the scope of this discussion. =)

Feedback on these is warmly welcomed.  In the desktop media player space, the mime-type/extension mapping wars over media formats have yet to be fully resolved. I'm certain we can avoid all that if we address the issue openly and conclusively before users ever need know. 
What about a pragmatic solution:

1) Add a new "Save" button (right beside "Install Now" and "Cancel") to the "Software Installation" dialog that pops up when Firefox (or any other .xpi-enabled software) wants to install a xpi.
2) Print in bold something like "Click 'Install Now' to install the extension for Firefox. If you want to install this extension for a different application, click 'Save'."

Personally, I think a central xulrunner component that manages all extensions is out of scope and overblown. When I look for an extension I'm quite aware of what application it is supposed for. Thus, a well placed Save button will do the job for me.
Summary: ".xpi" should be associated with something useful in windows-exlorer → ".xpi" should be associated with something useful in windows-explorer
Over to OS Integration... the app sets the associations and not the EM.
Component: Extension/Theme Manager → OS Integration
QA Contact: extension.manager → os.integration
Here are some of my thoughts as to how to solve this issue. Note that I am not in any experienced in cross-application integration nor in OS-integration, so some of my suggestions may not be fully feasible.

1. The file icon might use the Mozilla icon as a basis rather than relying on app-specific icons (even though those are probably more well-known).
2. The application would be a small application that detects for xpi-enabled application install points and provides a selection.
3. XPI-enabled applications would host something like this in the registry:
%HKEY_SYSTEM_ROOT%/Applications/XPI/ (or whatever the proper one is)
 +-- Firefox
       +-- Display Name: Firefox
       +-- Binary Location:  C:\Program Files\Mozilla Firefox\firefox.exe
       +-- Options: { ??? }
And running would use {Binary Location} {Options} {path\to\file.xpi}

As a final note, could file association be included in the summary of the bug?
As I commented here :
it could be associated to the new Profile Manager Bug 214675
I don't think this bug should be fixed but if it were it would be handled by the installer.
Component: Shell Integration → Installer
I don't think this should be done either; allowing for simple installation of addons from the local file system seems like too much of a footgun, and workarounds exist for anyone who needs it.
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.