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

Status: RESOLVED WONTFIX

(Firefox :: Installer, enhancement)

Description

[Tobias B. Besemer [:BesTo] (QA)]

Summary:
".xpi" should be associated with firefox in windows-exlorer

Comment 1

[Robert Strong (they/them - no direct email)]

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

Comment 2

[Jos Vermeulen]

Maybe a right click submenu "Install in"?

Comment 3

[Robert Strong (they/them - no direct email)]

Also see bug 313471 which conflicts to some extent with this bug.

Comment 4

[Jos Vermeulen]

Same reporter, this bug should be closed as the other one is more interesting.

Comment 5

[Benjamin Smedberg]

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

Comment 6

[Benjamin Smedberg]

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.

Comment 7

[Benjamin Smedberg]

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.

Comment 8

[Robert Strong (they/them - no direct email)]

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.

Comment 9

[Benjamin Smedberg]

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

Comment 10

[Tobias B. Besemer [:BesTo] (QA)]

(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.

Comment 11

[Ray Booysen]

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

Comment 12

[Ivan Ičin]

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.

Comment 13

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Benjamin, Robert, what's the status of this bug? Were any decisions (or design docs) made?

Comment 14

[Robert Strong (they/them - no direct email)]

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

Comment 15

[Rob Lord]

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 Songbirdnest.com 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://xpirence.org/songbirdxpi/superbird.xpi. 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. 

Comment 16

[Keno Albrecht]

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.

Comment 17

[Robert Strong (they/them - no direct email)]

Over to OS Integration... the app sets the associations and not the EM.

Comment 20

[:Gavin Sharp [email: [e-mail]]]

See also: bug 231876 (WONTFIX).

Comment 21

[Joshua Cranmer [:jcranmer]]

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 2.0.0.6
       +-- 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?

Comment 22

[Antoine Turmel [:GeekShadow]]

As I commented here : http://jagriffin.wordpress.com/2011/01/11/profilemanager-1-0_beta1
it could be associated to the new Profile Manager Bug 214675

Comment 23

[Robert Strong (they/them - no direct email)]

I don't think this bug should be fixed but if it were it would be handled by the installer.

Comment 24

[Molly Howell (she/her) (no longer active)]

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.