Open Bug 775114 Opened 14 years ago Updated 3 years ago

File-handler bindings for the main file types should happen no matter how user installs Firefox on 64-bit Linux

Categories

(Firefox :: File Handling, defect)

x86_64
Linux
defect

Tracking

()

People

(Reporter: ioana_damy, Unassigned)

Details

Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0 Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0 STR: 1. Load ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central/ in a Firefox tab. 2. Click a tar.bz2 file. On Ubuntu 12.04 64-bit: The user is only offered two options: to save the file or cancel the operation. On all the other OSs the user has the option of opening the file. On Ubuntu 12.04 32-bit: The user is offered the option to open the file. When the user selects this option he has to manually browse for the Archive Manager and select it. When the user selects to open a tar.bz2 archive in Google Chrome, it automatically opens the archive with the Archive Manager used by default in Ubuntu.
This issue also reproduces on Firefox 4.0, so it's not a regression.
I've encountered this numerous times but only with applications installed by extracting to my home folder. Applications installed via Software Centre have the correct file-handler bindings. Can you please confirm how you are installing Firefox and Chrome?
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #2) > I've encountered this numerous times but only with applications installed by > extracting to my home folder. Applications installed via Software Centre > have the correct file-handler bindings. Can you please confirm how you are > installing Firefox and Chrome? I can confirm that the applications installed via Software Centre have the correct file-handler bindings. But shouldn't the other option bind right at least for the main file types? There are no file-handler bindings for that case (I didn't find any while exploratory testing anyway). The worst case scenario for me is when I download a file (let's say a simple jpeg), then I click it in the Download Manager to open it. The lack of bindings has become very obvious and obnoxious for me as a user in this case.
Summary: The archive manager used by default by Ubuntu is not detected by Firefox when neccesary → File-handler bindings for the main file types should happen no matter how user installs Firefox on 64-bit Linux
Another problem was that on Ubuntu 32-bit, the user was offered the option to open the tar.bz2 file although he did have to choose manually the app to open it with. On Ubuntu 64-bit, the user was not offered this option at all.
This is a problem I've personally encountered for ages with Ubuntu. I believe this might have more to do with how Ubuntu handles application installs. I think installing applications through Software Centre or Synaptic do a lot of the bindings and integrations automagically, whereas simply extracting an application tarball to your home folder does not. FWIW, I've encountered this with other applications as well, not just Firefox. I'm inclined to mark this bug INVALID but please comment further if you think this is a bug we can fix.
If it works for Firefox installed from the Ubuntu Software Centre but not for a mozilla.org build of Firefox, then this is probably due to the lack of gio support in the official builds (see bug 713802). I'm not sure if gnomevfs actually works in newer distro's, and it's probably not installed by default anyway....
(In reply to Chris Coulson from comment #6) > If it works for Firefox installed from the Ubuntu Software Centre but not > for a mozilla.org build of Firefox, then this is probably due to the lack of > gio support in the official builds (see bug 713802). I'm not sure if > gnomevfs actually works in newer distro's, and it's probably not installed > by default anyway.... Yes, I've never encountered this with the Software Centre installed versions of Firefox -- only the ones I've downloaded from mozilla.org. Does this make this WONTFIX? INVALID?
Product: Core → Firefox
Version: Trunk → unspecified
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.