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

RESOLVED WONTFIX

Status

()

Firefox
Installer
--
enhancement
RESOLVED WONTFIX
12 years ago
4 months ago

People

(Reporter: BesTo, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
Summary:
".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

Comment 2

12 years ago
Maybe a right click submenu "Install in"?
Also see bug 313471 which conflicts to some extent with this bug.

Comment 4

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

Comment 5

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

Comment 6

12 years ago
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

12 years ago
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.

Comment 9

12 years ago
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
(Reporter)

Comment 10

12 years ago
(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.
(Reporter)

Updated

12 years ago
Depends on: 314042

Comment 11

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

Comment 12

12 years ago
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

Comment 15

12 years ago
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

12 years ago
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.

Updated

12 years ago
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
Blocks: 357052

Updated

11 years ago
Duplicate of this bug: 372134

Updated

11 years ago
Duplicate of this bug: 372134
See also: bug 231876 (WONTFIX).
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?
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
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.
Status: NEW → RESOLVED
Last Resolved: 4 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.