There are a many file formats which Firefox is a more than adequate viewer for. When a user has downloaded a file and clicks to open that download from any of our download views, unless configured otherwise we should open compatible files in a new tab in their current browser window.

This list could grow, but as a starter maybe the following file types:
.html
.xml
.svg
.gif
.png
.jpg

See bug 1191591 where we have done this for downloaded PDF documents.
This is not the same as registering Firefox as a handler for these formats with the OS, and would not preclude the user from opening a downloaded file in their application of choice.

Adding bug 1639069 to the see-also list. 1639069 might arguably block this bug if there were concerns about breaking user work flows.

Related is https://bugzilla.mozilla.org/show_bug.cgi?id=1627676 that should help us understand extensions of downloaded files.
My top priorities would be to address file extensions that would point to other browsers where we can do as good of a job:

• .xml and .svg (currenlty IE sets itself as default)
• webp (currently CHrome sets itself as default)
• shtml (currently Brave sets itself as default)
• xht and xhtml (currently IE and Edge set themselves as default)

I summarized what I saw with other browsers on https://docs.google.com/document/d/1BFpd1mNdok0ZbhlKEgExEZKPEmlmQRath_s1AmPtVug/edit

I think the right way to fix this is for the dialog to check the mimetype with the category manager. Specifically:

Services.catMan.getCategoryEntry("Gecko-Content-Viewers", mimetype)

will return a contract ID if we support viewing the mimetype, and an exception (non-NS_OK result) if not.

In theory, what with everything else in place, this should now be relatively straightforward to fix...

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

I think the right way to fix this is for the dialog to check the mimetype with the category manager. Specifically:

Services.catMan.getCategoryEntry("Gecko-Content-Viewers", mimetype)

Which dialog are you refering to here? I ask because most of the work for bug 1639069 was in getting params to the launchDownload in DownloadIntegration.jsm and special-casing application/pdf to open directly into a tab (handleInternally).

I had thought of an explicit list of mimeTypes (perhaps as well as not instead of the category manager check) just to avoid surprises and make it easier to know what we expect to happen, and perhaps respond to user feedback on the download behavior specifically. Or is the PDF case substantially different?

(In reply to Sam Foster [:sfoster] (he/him) from comment #4)

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

I think the right way to fix this is for the dialog to check the mimetype with the category manager. Specifically:

Services.catMan.getCategoryEntry("Gecko-Content-Viewers", mimetype)

Which dialog are you refering to here?

The unknown content type dialog (which offers "open" and "save" actions).

I ask because most of the work for bug 1639069 was in getting params to the launchDownload in DownloadIntegration.jsm and special-casing application/pdf to open directly into a tab (handleInternally).

Right, instead of hardcoding application/pdf, I think the above expression will return true for both application/pdf and for a bunch of other things.

I had thought of an explicit list of mimeTypes (perhaps as well as not instead of the category manager check) just to avoid surprises and make it easier to know what we expect to happen, and perhaps respond to user feedback on the download behavior specifically. Or is the PDF case substantially different?

I don't think PDF is substantially different, though I could imagine that there would be people who'd be upset if we did this for images or some types of text/html files that they expect to open in external viewers/editors, that offer functionality which Firefox doesn't. Still, as long as we continue honouring file choices, that should be OK.

Note that in addition to this though, we'd need to update the preferences so we represent the associations involved. Though it gets a bit messy between having both a "do we ask the user when downloading" and "what is the default action" property of each mimetype/extension combination to represent in the prefs... (right now, if we always ask then that's what we'll show, and it's not obvious you could alter the default action and then alter it back to "always ask" to get the desired behaviour from a download view while maintaining choice when initially downloading, if that's what you want (e.g. because you want to pick the file saving destination)).

Adam, can you confirm which file types we're targeting for FX 81?

Link to PI request

(In reply to Rachel Tublitz [:rachel] from comment #6)

Adam, can you confirm which file types we're targeting for FX 81?

To answer this immediate question, I'm planning on .xml (text/xml, maybe application/xml if I can get both working), .svg, (image/svg+xml) and .webp (image/webp). I don't plan on doing .shtml, .xht, .xhtml currently, as I don't have a good way of distinguishing their handler from that for .html, generally.

Also attempts some of the refactoring proposed in bug 1638913, moving
the type-specific checks out of toolkit, which is also also used
further down this patch stack.

I didn't fold PDF into this part as it has different conditions for showing
the radio button vs. viewing internally from the downloads list.

Depends on D86650

Depends on D86651

Removes the need for applications-file-ending-with-type, and avoids
replicating applications-type-*-with-type for every internally
handled file type.

Depends on D86652

I also added types from the list of extensions we register to support on
Windows, in shared.nsh SetStartMenuInternet.

Depends on D86653

Adding "leave open" here to avoid the bug closing because the other commits aren't landing yet, by the looks of it.

https://hg.mozilla.org/mozilla-central/rev/82be6da5a371

I was worried that this would also run into the issues in bug 1633790 (infinite tabs if Firefox is the default and set to open in default) and bug 1555637 (extra copy saved but no view if Firefox is the default and set to always save), but I wasn't able to reproduce those with XML, SVG, WebP, AVIF, or other types, with or without these patches. I suspect that there's a difference in running the document loader for these documents vs. the stream converter for pdfjs, but I haven't dug into it.

Backed out 4 changesets (bug 1639067) for XPCshell failures in tests/unit/test_getMIMEInfo_pdf.js. CLOSED TREE

Log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=313255439&repo=autoland&lineNumber=3972

TV failures:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=313256018&repo=autoland&lineNumber=2149

Push with failures:
https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&revision=1e400fafd80b3071c118ece6645754aab3488f2c

Backout:
https://hg.mozilla.org/integration/autoland/rev/d9cde14e8ec0f383e9bd45407d8b3e68643115b9

Sorry, I should have caught that test_getMIMEInfo_pdf.js failure. I think the TV failure is bug 1641774, I'll include a fix for that as well.

https://hg.mozilla.org/mozilla-central/rev/b34389aab2a8
https://hg.mozilla.org/mozilla-central/rev/9cf29f703679
https://hg.mozilla.org/mozilla-central/rev/a9eafc98de77
https://hg.mozilla.org/mozilla-central/rev/70af71248a58

Does this regress session restore?

I "Open in Nightly"'d something and after a session restore I just have a "file not found" tab.

Seems to be saving to a file to a temp directory which is deleted when Firefox exits.

That's a good point. We have bug 1632274 to resolve this with PDFs, but I hadn't thought about it becoming an issue with these other types.

(In reply to James May [:fowl2] from comment #23)

Does this regress session restore?

I "Open in Nightly"'d something and after a session restore I just have a "file not found" tab.

Seems to be saving to a file to a temp directory which is deleted when Firefox exits.

It's possible to work around this somewhat by setting pref browser.helperApps.deleteTempFileOnExit false in about:config, but that isn't a solution in general.

I am worried about the potential for data loss by changing the default option in the unknown content type dialog, I opened bug 1659737 to remove the "Open in Nightly" option for these types until we decide what is intended here.