Comment 81 for bug 1811105

Hello,

I have tested with the latest Firefox 65 (64bits) right now with many type of files (mp3 / mp3/ txt, etc...) and all of them present the same issue.
For example for a PDF, on "open with entry", I have only 2 entries : "PDF viewer" (the default one of Linux Mint) and "other" option.
(If it can help, in this case if I select other, I have 6 entries, which are winebrowser / Document View / 2 entries of Image Magick / Master PDF editor)

But if you say that the issue is fixed on Firefox 66, it's a good news no ?

(In reply to :Gijs (he/him) from comment #68)

> (In reply to akred from comment #67)
>
> > Hello,
> >
> > As a user, do you know how we can help for the investigation ?
> >
> > Thanks
>
> It's still not clear why this is reproducing for some people and not others. It doesn't make a lot of sense to me that this is particularly bad for some users and doesn't happen at all for others; the effects described (hangs for minutes / lots of seconds) are too severe to be explained by purely performance differences between machines. So there must be some other difference; I just don't know what that is.
>
> It's also as-yet unclear what the connection is between the dbus disabling and the bugs that regressed and fixed this issue. That is, the regressing/fixing bugs change the <radio> elements in the dialog that pops up asking about saving/opening files. The dbus code is presumably only used for checking what the default handler app is on your OS (in the context of that dialog, that is; we obviously might use dbus for other stuff in other places).
>
> On builds where the issue is fixed (66 beta and 67 nightly), are there a lot of entries in the "open with" dropdown under the "open" option for files where this happens on broken builds, or something? Do all those entries show up when you download something with mimetype application/octet-stream as well, and in that case, are those downloads showing the same problem on affected/broken builds?