Doesn't allow easy selection of alternate external programs

[Alex Mauer]

Binary package hint: firefox

If I try to open a file that firefox cannot natively read, it offers to open with an external program. Unfortunately, it gives only two options: a default, and "other" which requires browsing through the filesystem to find the application manually.

It would be much better if it would instead give a list of all apps which can handle the file's MIME type or the URL's protocol.

at the least it should be possible to somehow set a different application as the "default".

[Freddy Martinez (freddymartinez9)]

Is this an upstream issue?

[Alex Mauer (hawke)]

Bug #13373 is very similar, but it only discusses how the single default should be selected by the system (not by the user). Then it goes off on a tangent about a file picker.

It is also related to the specification https://launchpad.net/ubuntu/+spec/default-applications-firefox which is claimed as "implemented".

However, the implementation of this specification is incomplete in that it only shows the single default application that gnome would use if the user double-clicked on the file, rather than also providing the list of alternate applications that the user would get if they right-clicked on the file in e.g. nautilus.

Since there is an approved high-priority specification in Ubuntu to provide this, I think it is not [only] an upstream bug.

[Alex Mauer (hawke)]

What info is needed?

[Hilario J. Montoliu (hjmf) (hmontoliu)]

El sáb, 24-03-2007 a las 17:30 +0000, Alex Mauer escribió:
> What info is needed?

"Needs info" is an state. More info at
https://wiki.ubuntu.com/MozillaTeam/Bugs/States

[Alex Mauer (hawke)]

I know it's a state. Most packages use that to indicate that the bug reporter should provide more information, not that the packagers need to research it. Thanks for the link though, it explained the situation well.

[Alexander Sack (asac)]

On Sat, Mar 24, 2007 at 06:13:02PM -0000, Alex Mauer wrote:
> I know it's a state. Most packages use that to indicate that the bug
> reporter should provide more information, not that the packagers need to
> research it. Thanks for the link though, it explained the situation
> well.
>

Its to indicate that we still need info ... this can be the bug
reporter, but it can be work from bug triagers as well. This bug need
a decision of whether enough information for processing is there.

I will do this next time I come around.

Thanks for offering help though,

 - Alexander

[Alexander Sack (asac)]

AFAIK, upstream already works on this on trunk.