428382 - Choosing an helper application involve using a file pick in /usr/bin

Status: RESOLVED DUPLICATE of bug 397700

(Firefox :: File Handling, defect)

Description

[Hubert Figuiere [:hub]]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.13) Gecko/20080316 SUSE/2.0.0.13-0.1 Firefox/2.0.0.13
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.13) Gecko/20080316 SUSE/2.0.0.13-0.1 Firefox/2.0.0.13

When one want to open a dowload using a helper application that hasn't been "registered" with Mozilla, we get presented with a file picker (gtk) that open /usr/bin

It is completely user unfriendly.

freedesktop.org has developed a spec for .desktop that allow user friendly list of applications. Let's use that.

I have implemented an XPCOM widget that implement this in Gtk, like it is done in Nautilus. Will attach patch for review / comment.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Hubert Figuiere [:hub]]

Attachment: First version of the patch

This is the first version of the patch for FireFox 3.0.0b5

I'm sure it has some pitfall and I don't expect it to be ready for inclusion now.

Known issues: 
-the build system patch is rough
-the dialog is a copy-paste of LGPL licensed code from Nautilus 2.22 formerly in eel
-it add a dependency on gio which is part of the last stable release of glib.
-it add a dependency on eel-2.22 which is know to be API/ABI unstable.
-it directly implement it in the widget library while I'm sure to would be preferrable to have it as a separate component.

I'm just solliciting feedback for the idea and the code, to push this towards the Mozilla code base.

Comment 2

[Hubert Figuiere [:hub]]

I didn't find bug 370380 prior to filing this. Looks like I have taken a completely different approach.

Comment 3

[Hubert Figuiere [:hub]]

change component

Comment 4

[Michael Ventnor]

(In reply to comment #1)
> Created an attachment (id=314945) [details]
> -the dialog is a copy-paste of LGPL licensed code from Nautilus 2.22 formerly
> in eel

Can't have that. The MPL is more liberal than the LGPL so we can only accept code that is under MPL, BSD, or one of those very liberal licenses. Plus adding functions with "nautilus" in their name makes us look bad :)

I'm also scared of these added dependencies. I added the print dialog without needing to bring in eel or anything else (except for GTK 2.10 cutoff) so isn't there a way to avoid this?

+// one of these retard headers.
+extern "C" {
+//#include <eel/eel-open-with-dialog.h>
+}

Watch your bloody language ;)

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

Using freedesktop specced stuff sounds good for this in principle, and having a separate application picker like this could work in the short term.  In the slightly longer term, I think this code really wants to be integrated with the existing, new application picker (nsIContentDispatchChooser), which is already used for protocol handlers, and will hopefully someday be used for MIME content-handlers as well.  So if you're up for a challenge, you could consider hacking on the MIME forward migration and just skip the intermediate step...

Comment 6

[Mike Hommey [:glandium]]

I'd say this a duplicate of bug #397700, and should be reimplemented using nsIMIMEInfo.possibleLocalHandlers. Since I'm currently in the nsMIMEInfoUnix code, I'll do it.