Open With Helper Application dialog is file browser

RESOLVED DUPLICATE of bug 397700

Status

()

Firefox
General
RESOLVED DUPLICATE of bug 397700
6 years ago
5 years ago

People

(Reporter: Daniel, Unassigned)

Tracking

10 Branch
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1 Iceweasel/7.0.1
Build ID: 20111004070756

Steps to reproduce:

Click on a file download link that will cause the "What should Firefox do with this file?" dialog to open. Select the "open with" radio, then choose "Other" from the menu.


Actual results:

A file browser opens, exactly like the one launched by File -> Open file / Ctrl+o


Expected results:

This is a terribly inefficient means of choosing an application. There should at least be a field where the user can type in the name of the executable. In the event that the user does not know what the executable's file name is, the user probably isn't going to know where to look for it on the disk. Furthermore, if the user doesn't know the name of the executable, the user shouldn't have a reason to be clicking on other in the first place since it doesn't suggest any applications by description. When I open /usr/bin in a graphical file chooser like this, it takes almost 15 seconds for the directory to be read before I can even select a file. It would take a fraction of that time to simply type the name of the program.
I'm seeing this now that I updated to Ubuntu 11.10. I'm using nightlies provided by Mozilla.

I think it's time our nightlies were compiled with GIO turned on...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Though, you're seeing it on Iceweasel... Hmm, glandium, are you compiling Iceweasel with GIO support yet?

Reporter, what distro (and distro version) are you using?
(In reply to Reed Loden [:reed] (very busy) from comment #2)
> Though, you're seeing it on Iceweasel... Hmm, glandium, are you compiling
> Iceweasel with GIO support yet?

I switched it on recently (7.0.1-3) but I don't think you'll get anything other than the file browser until bug 397700 is fixed.

> Reporter, what distro (and distro version) are you using?

Seeing the buildid, I'd say 7.0.1-2.
(In reply to Mike Hommey [:glandium] from comment #3)
> (In reply to Reed Loden [:reed] (very busy) from comment #2)
> > Hmm, glandium, are you compiling
> > Iceweasel with GIO support yet?
> 
> I switched it on recently (7.0.1-3) but I don't think you'll get anything
> other than the file browser until bug 397700 is fixed.

I assume the GIO code in http://mxr.mozilla.org/mozilla-central/source/uriloader/exthandler/unix/nsGNOMERegistry.cpp should be supporting more than just the file browser.
(Reporter)

Comment 5

5 years ago
I reported this bug while using Debian testing, although I'm still seeing this behavior in Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2.
dbb008, if you can find libmozgnome.so in the firefox install and run ldd on it, are there some dependencies reported not found?

The configure arguments from about:buildconfig may also be interesting.
Version: 7 Branch → 10 Branch
(Reporter)

Comment 7

5 years ago
apt-file actually finds several matches to "libmozgnome.so". Here's the most sensible one

ldd /usr/lib/firefox-10.0.2/components/libmozgnome.so
	linux-vdso.so.1 =>  (0x00007fffb2d4d000)
	libxpcom.so => not found
	libmozalloc.so => not found
	libplc4.so => /usr/lib/x86_64-linux-gnu/libplc4.so (0x00007fed4a233000)
	libnspr4.so => /usr/lib/x86_64-linux-gnu/libnspr4.so (0x00007fed49ff8000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fed49df4000)
	libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0x00007fed49bc5000)
	libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007fed49974000)
	libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007fed4967e000)
	libnotify.so.4 => /usr/lib/x86_64-linux-gnu/libnotify.so.4 (0x00007fed49475000)
	libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007fed49133000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fed48e2c000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fed48a8c000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fed4886f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fed4a65a000)
	libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007fed4866b000)
	libdbus-glib-1.so.2 => /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x00007fed48444000)
	libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007fed48201000)
	libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007fed47ffc000)
	libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fed47df3000)
	libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fed47bb7000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fed479af000)
	libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007fed4778f000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fed47577000)
	libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fed47359000)
	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fed4713d000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fed46eb9000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fed46ca3000)
Thanks, Daniel.  I think Mike is right and this is a duplicate of bug 397700.

I had assumed this was some regression from dropping gnomevfs, but I assume "Other" has always used the file browser.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 397700
You need to log in before you can comment on or make changes to this bug.