1427700 - Firefox has other file associations than xdg-open, and checkbox to always use this program when correcting it is grayed out

Status: RESOLVED FIXED

(Firefox :: File Handling, defect, P5)

Description

[u580221]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180102110609

Steps to reproduce:

Firefox has other file associations than xdg-open, and checkbox to always use this program when correcting it is grayed out. This means 1.) nonsense programs are opened, e.g. libreoffice for .zip which makes it crash on large zips which can even mean data loss if other relevant office files are open, 2.) there is no easy way to fix it even once the user is aware.

Steps to reproduce:
1. Install libreoffice on Fedora 27
2. Install firefox on Fedora 27 (official mozilla build, rather than the packaged one)
3. Download a .zip and see what program firefox offers to open it with


Actual results:

.zip is opened with libreoffice, and the dialog that asks me what to open it with won't let me change that default either


Expected results:

Default is what xdg-open does, if it's not the checkbox to change and fix it permanently must never be grayed out with no visible explanation. That's just plain confusing and frustrating

Comment 1

[u580221]

As far as I'm aware this is not a recent regression or anything, only now the default association was so bad (libreoffice, which likes to crash and cause me lost work) that it became an actual issue rather than just a nuisance.

Comment 2

[u580221]

.rpm files are opened with libreoffice as well. is there no way to fix this?

Comment 3

[Adrian Florinescu [:aflorinescu]]

I couldn't reproduce this issue on ubuntu 16.04 / Fedora 23. Sorry, I don't have a Fedora 27 to confirm the issue there. Could you please confirm if this behavior is a regression? - aka what is the behavior with Beta58 or Release57?

For now, lets move the bug to the right component.

Comment 4

[u580221]

Sorry, I somehow missed the needinfo mail.

No, this is not a regression, this has been wrong since FOREVER. Just recently though it started opening .zips with libreoffice though which has caused me a few nasty crashes while I was editing text documents, so it was bad enough that I thought I really have to make a ticket.

Also, I'm pretty sure I saw this on other linux distributions as well... in fact as a year long firefox user, I cannot remember a time where Firefox would ever default to the xdg-open programs for EVERYTHING. Sure, for some stuff, but some others would always be off with some random program picks that made no sense.

It seems it picks something detected on a not entirely wrong mimetype (.rpm is a .zip internally after all, and some office files are an archive too) but simply picks the wrong out of the possible choices.

Comment 5

[u580221]

Sorry, I guess .rpm could also be a tarball. But it's an archive, right? Anyway, I'm just trying to guess here what the problem could be, I don't have an actual clue what's going wrong...

Comment 6

[:Paolo Amadini]

Thanks for the information, Jonas.

I also don't know why the default application detection is wrong, ideally Firefox should make the same choice as if the file was saved and then you clicked it in the file manager. I get this is is not what's happening, right? Maybe Jan has some suggestions for things you could try.

As for the checkbox, it's grayed out when the server sends a generic MIME type. In other words, I'd expect some links would allow the application to be changed and others won't, depending on the server. Actually, there are bugs on file for us to allow using the checkbox in more cases than we currently do, although in the long run we would like to get a correct default based on operating system settings and not have to show this dialog at all.

Comment 7

[u580221]

> I get this is is not what's happening, right?

In my particular case, for a download with .zip ending and a mime type set to regular archive, firefox will suggest libreoffice (which is a pretty stupid choice). So yea, it's definitely not working right, although I can't say why. And xdg-open picks the archive application just fine, so it shouldn't be a generic misconfiguration of the system I hope.

Comment 8

[u580221]

.rar now offers me "calibre" (an ebook reader!!). xdg-open association: GNOME file-roller (archiver).

I don't know what file type the server sent, but I'm pretty certain it's not something that indicates an ebook format. (It's a generic download website, nothing ebook specific - I'd be surprised if the webserver was configured to know any ebook-specific niche formats at all)

This is like, not even slightly wrong. 90% of the suggestions are gross nonsense. Surely this could be done better, e.g. by delegating to xdg-open if firefox can't implement a reasonable mechanism here?

Comment 9

[kolubat]

Here's a thread discussing this bug from a few years ago.

Their workaround was to make sure there is only one possible app configured to open any given MIME type, because otherwise an arbitrary one from the list (rather than the default) is selected by Firefox.

https://support.mozilla.org/en-US/questions/1084109

Comment 10

[u580221]

Well that sounds like a big bug then. Why on earth would I want any random application that might be able to open zip files instead of the proper default one? It would be nice if this could be implemented properly, and firefox could actually check for the proper default application instead of this "uuuhhh I'll just pick any random one" nonsense.

Comment 11

[u580221]

(Sorry if I sounded a bit rant-y/frustrated - but libreoffice or calibre launching for zip files is just pretty annoying, especially since half of the time I press enter too quickly and it actually launches before I can stop myself, which in case of libreoffice can even lead to crashes.)

Comment 12

[kolubat]

This is indeed frustrating. The page I linked says "21 have this problem" (presumably how many people bothered to click a button on it) and "3652 views", so I don't think we're particularly alone in this regard...

Comment 13

[u580221]

Still in present. Please note this is also a kind of a security problem, since if a super complex application like LibreOffice gets picked, the risk of an infection/intrusion is much higher than let's say, a file archiver that is meant to handle a .zip properly. I mean even just the crash I saw which led me to report this is kind of a Denial of Service / Data Loss (other open documents) issue already.

Is Mozilla aware of how many people have this issue? Is there a way to make someone aware?

Comment 14

[Jan Horak [:jhorak]]

Attachment: gio-test.py

Firefox uses GIO to get default handler app, the xdg-open can use different handler for the same file. It is basically what default application you set in Nautilus and should be stored in .config/mimeapps.list if overridden from default handler.

To check for the default handlers on your system, please download attached script and run it with filename as a parameter (.zip for example or on which you have difficulties with) and check the output.

The script requires python and pygtk2 installed.

For example, my output on .zip file looks like:
Absolute path:               /home/jhorak/Downloads/ESPlorer.zip
MIME type from extension:    application/zip
Content type from MIME type: application/zip
Default Handler app:         Archive Manager
Default Handler app command: file-roller %U
All possible handlers:
   Engrampa Archive Manager : engrampa %U
   Archive Manager : file-roller %U
   Archive Mounter : /usr/libexec/gvfsd-archive file=%u
   Files : nautilus --new-window %U

xdg-open check
output of: xdg-mime query filetype /home/jhorak/Downloads/ESPlorer.zip
   application/zip

output of: xdg-mime query default application/zip

   org.gnome.Nautilus.desktop

The first part is what Firefox use.

Comment 15

[kolubat]

I've been investigating this a bit. Do you (people seeing this issue) use KDE SC 4, have KDE SC 4 components installed, or have the kioclient package (as opposed to the kde-cli-tools package) installed? If so, does opening the files with the kde-open command (not kde-open5) show the same issue? Thanks.

Comment 16

[kolubat]

To clarify my question, does kde-open [file] have a different result from open [file], kde-open5 [file], or xdg-open [file]?

Comment 17

[u580221]

@kolubat: I don't have kde-open or kde-open5 installed on any of my machines.

@Jan Horak: The reason I haven't responded earlier is I have been waiting for the issue to occur again. Right now, the .zip handler looks just fine:

$ ./gio-test.py Spectral_SC.zip 
Absolute path:               /home/jonas/Downloads/Spectral_SC.zip
MIME type from extension:    application/zip
Content type from MIME type: application/zip
Default Handler app:         Archive Manager
Default Handler app command: file-roller %U
All possible handlers:
   Archive Manager : file-roller %U
   Engrampa Archive Manager : engrampa %U
   Archive Mounter : /usr/libexec/gvfsd-archive file=%u
   Files : nautilus --new-window %U

xdg-open check
output of: xdg-mime query filetype /home/jonas/Downloads/Spectral_SC.zip
   application/zip

output of: xdg-mime query default application/zip

   org.gnome.Nautilus.desktop



.. and when I open it in firefox, it will open file roller. However, I recently had a .zip that would open with VLC(!) and then a few days later with file-roller, without any changes to the file. It is really unpredictable. And .zip does definitely NOT open reliably with file-roller in Firefox. About 50-70% of the .zip files do. Some do not (and _all of those_ open with file-roller when opened in nautilus, so this is most likely a firefox issue.)

Comment 18

[u580221]

Attachment: beforedownloadnonsense.png

Comment 19

[u580221]

Attachment: afterdownloadnonsense.png

Comment 20

[u580221]

Ok, I managed to capture this nonsense with a download offered here on my webserver: https://www.jtwrites.net/temp/thonios_website.zip

Mime-type of the download is application/octet-stream, which triggers the faulty behavior.

Download popup / before download: suggests "gnome-font-viewer". See beforedownloadnonsense.png screenshot. If firefox can't guess it here due to the generic mimetype and not having downloaded the file yet, just picking complete nonsense as an application is not reasonable or expected behavior...

Clicking download in download list after download: opens up in VLC(!). The .zip actually contains an .mp3 and VLC appears to be smart enough to open it up, but again this is NOT the proper file association and therefore absolutely not what should happen. See afterdownloadnonsense.png screenshot.

The output of your script:

$ ./gio-test.py ../thonios_website.zip 
Absolute path:               /home/jonas/thonios_website.zip
MIME type from extension:    application/zip
Content type from MIME type: application/zip
Default Handler app:         Archive Manager
Default Handler app command: file-roller %U
All possible handlers:
   Archive Manager : file-roller %U
   Engrampa Archive Manager : engrampa %U
   Archive Mounter : /usr/libexec/gvfsd-archive file=%u
   Files : nautilus --new-window %U

xdg-open check
output of: xdg-mime query filetype /home/jonas/thonios_website.zip
   application/zip

output of: xdg-mime query default application/zip

   org.gnome.Nautilus.desktop



Also, feel free to download the .zip and examine it, or try for yourself.

Comment 21

[Jan Horak [:jhorak]]

Hm, interesting. The "which is:" text in the screenshot shows "unknown", which is returned by g_content_type_from_mime_type("application/octet-stream"). Then Firefox should lookup application/zip but for some reason it does not. 

In my case the "Zip archive (8.8 MB)" is shown. Some servers sends Content-Type: application/octet-stream, others Content-Type: application/zip (like this one [1]), that's why it works for you sometimes.

There's actually usable logging module for this stuff:
export MOZ_LOG HelperAppService=5
# then run firefox in terminal and check output
firefox

Could you please attach part of the log which is written to output when trying to download badly handled file?

Also output of (but there should not be any entry):
grep -r "application/octet-stream" /usr/share/applications
grep -r "application/octet-stream" ~/.local/share/applications/


[1] https://minecraft.curseforge.com/projects/an-epic-desert-adventure/files/680680

Comment 22

[u580221]

Is there a log file somewhere? I can't see anything interesting in the terminal:

[jonas@falcon ~]$ cd firefox/
[jonas@falcon firefox]$ export MOZ_LOG HelperAppService=5
[jonas@falcon firefox]$ ./firefox
Fontconfig error: failed reading config file
VLC media player 3.0.2 Vetinari (revision 3.0.2-0-gd7b653cf14)
[00005582b4e5f9e0] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
QObject::~QObject: Timers cannot be stopped from another thread

(After downloading the file again, and then opening it which incorrectly opens VLC as before)

This is the output of the grep commands you requested:

[jonas@falcon ~]$ grep -r "application/octet-stream" /usr/share/applications
[jonas@falcon ~]$ grep -r "application/octet-stream" ~/.local/share/applications/
[jonas@falcon ~]$

Comment 23

[u580221]

I corrected the export, but it still doesn't seem to work as far as the logging is concerned:

[jonas@falcon firefox]$ export MOZ_LOG="HelperAppService=5"
[jonas@falcon firefox]$ ./firefox
VLC media player 3.0.2 Vetinari (revision 3.0.2-0-gd7b653cf14)
[000055caa33449e0] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
QObject::~QObject: Timers cannot be stopped from another thread
^C
[jonas@falcon firefox]$ echo $MOZ_LOG
HelperAppService=5
[jonas@falcon firefox]

(Sorry if I'm missing something obvious, I'm not very experienced with firefox debugging)

Comment 24

[Jan Horak [:jhorak]]

Oh, sorry, that was really my fault, please run Firefox like
export MOZ_LOG=HelperAppService:5
firefox

Comment 25

[u580221]

Attachment: firefox.log

Ok, I attached the log as "firefox.log". In firefox, I did the following steps:

1. Opening firefox
2. Entering https://www.jtwrites.net/temp/thonios_website.zip into the URL bar and pressing enter (a download box up with "gnome-font-viewer" as default)
3. Clicking "Save File" and pressing "OK"
4. Clicking the downloads toolbar button, and clicking the file entry to launch it with the default application (which opens up the .zip with VLC)

Comment 26

[kolubat]

This could perhaps be related to these other issues: https://bugzilla.mozilla.org/show_bug.cgi?id=497081 https://bugzilla.mozilla.org/show_bug.cgi?id=1440619

The reason I asked about the KDE SC 4 apps is that I've noticed that the weirdness I've seen recently has been because I unreasonably expect file associations to follow KDE SC 4's associations, rather than KDE Plasma / Frameworks 5's associations, which is what xdg-open and Firefox use. I'm not sure why SC 4 uses a different set of filetype associations than the standard, but that's not Firefox's problem.

Since training myself to set the filetype associations in the (Plasma 5) System Settings app, in addition to through the (KDE SC 4.7, I don't care for the newer ones) Dolphin file manager app, I've found Firefox's behavior to follow my desires so far.

(Downloads from the "Save Page WE" extension recently started asking me where to save them every time, which is weird, but I think that's probably an unrelated bug in the extension.)

Comment 27

[u580221]

I don't use KDE, and I don't plan to do so any time soon.

Comment 28

[kolubat]

@jonas: I don't think you understood my comment, but it wasn't relevant to you.

@everyone:

To summarize and clarify my previous comment:

My input on this report was irrelevant to the reporter's situation, as we were dealing with two separate problems that had the same symptom.

The app association issues *I* have had were apparently results of the now-outdated KDE SC 4 being weird, and are reasonable and expected behavior for Firefox, consistent with how modern KDE does things.

I now understand and am happy with Firefox's file handling.

Comment 29

[Jan Horak [:jhorak]]

Attachment: example.zip

Comment 30

[Jan Horak [:jhorak]]

Attachment: Bug 1427700 - Don't return valid HandlerApp for the application/octet-stream content type;

When server set Content-type:application/octet-stream to the file there is a chance on some Linux
distros that "unknown" file handler is selected to open the file which leads to strange list
of application handlers.

The logic leads to nsOSHelperAppService::GetFromType where the nsGNOMERegistry::GetFromType
is called which could return useless "unknown" handler app.

Review commit: https://reviewboard.mozilla.org/r/244676/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/244676/

Comment 31

[Martin Stránský [:stransky] (ni? me)]

Comment on attachment 8976579 [details]
Bug 1427700 - Don't return valid HandlerApp for the application/octet-stream content type;

https://reviewboard.mozilla.org/r/244676/#review250814

Comment 32

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e933d5d558ec
Don't return valid HandlerApp for the application/octet-stream content type; r=stransky

Comment 33

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/e933d5d558ec

Comment 34

[u580221]

Thanks so much for working on this :-) I haven't reported this for a long time for whatever reason, and somehow expected it'd be complicated to fix. Silly me making nonsense assumptions

Comment 35

[u580221]

Has the fix for this shipped? Strangely enough, I still get offered gnome-font-viewer for .zip downloads which I assume are sent with the binary blob mime type, even now in current mozilla build nightly / firefox 68 (on Fedora Linux 23)