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