There are at least five different ways in which one can save a file such as an image. However they all use different codepaths that determine the filename differently, and apply different validation rules to the filename.

1. Save As

• does use the filename from the content-disposition, but also uses the 'name' if it is not present.
• uses the document title if available
• replaces some invalid extensions but for other invalid extensions, just appends to the existing one (reallyapng.jpeg becomes reallyapng.png but image.pang becomes image.pang.png)
• strips out many illegal characters (more so than drag and copy)
• does not truncate long filenames (such that on Mac, the save button is just disabled and it is unclear why)

2. Subfiles saved from save document, complete:

• doesn't use the filename from the content-disposition
• replaces invalid extensions
• truncates long filenames to a maximum of 64 characters
• strips out almost all non-alphanumeric characters
• if the file already exists, adds a number such as '_001', '_002' etc. to the filename

3. Drag image to file system:

• doesn't use the filename from the content-disposition
• replaces invalid extensions
• strips out some illegal characters
• does not truncate long filenames
• Mac uses different but identical code for this

4. Copy/Paste image to file system

• doesn't use the filename from the content-disposition
• replaces invalid extensions
• strips out some illegal characters
• does not truncate long filenames

5. Content-disposition: attachment or download attribute

• filename from the content-disposition overrides the download attribute (this is the correct behaviour)
• doesn't replace invalid extensions
• strips out some illegal characters (a yet still different set than the other types)
• truncates long filenames to a maximum to 138(?) characters

There are other various minor differences. It would be good to unify all of these so that they same rules apply in each case.

Depends on D135950

Depends on D135951

Depends on D135952

Depends on D135953

Depends on D135954

Depends on D135955

Depends on D135956

Depends on D135957

Depends on D135958

No existing tests were modified by these changes, however some behaviour changes with regards
to filenames that currently have no automated tests is described below. Some of the following
might need further investigation to determine whether they are problems or not:

1. There are differences between the way that Save Page chooses whether the append the valid extension
   to an existing invalid extension versus replacing the invalid extension. Some types -- images and
   those listed in forcedExtensionMimetypes -- replace existing invalid extensions, whereas other
   types append to any existing invalid extension.
2. Some empty filenames resulted in filenames like '.jpg' or 'exe'. The behaviour here
   uses the default filename of 'index' instead, such that, for example, 'index.jpg' would be used.
   This has been applied to all cases, but probably needs some modification.
3. Save Page can use the web page title when saving a document. This should work but has not been
   tested much yet.
4. Invalid characters are now handled more consistently for all save types, so some variations
   of results will apply. For example, '*' is now replaced with a space. Some of the checks that
   DownLoadPaths.sanitize does are not yet added. In particular, string.CollapseWhitespace() only
   collapses ascii whitespace, but save as also collapses a wide variety of other whitespace
   characters.
5. Long filenames are always cropped at 64 characters. This should ideally be fixed to be
   platform-specific. (But save web page, complete currently used 64 characters on all platforms,
   other save types don't have any restriction at all.)
6. May wish to expose the sanitize function (SanitizeFilename) somehow so that DownloadPaths.sanitize
   can use the same method.

These differences can be checked by running the new test browser_save_filenames.js without any of
the patches applied.

Oddities (current behaviour and new):

• Plain text and binary types do not get their extensions checked for validity.
• When calling GetFromTypeAndExtension, the extension of image types is ignored. On Mac,
  at least, the extension is validated by checking if the specified extension would be
  handled by the same application as the primary extension. For me, this is Preview.app
  for any image extension. So this means that jpeg, for example, is treated as a valid
  extension for a png image.
• The test browser_test_data_text_csv.js has a case where there is no filename, so it defaults
  to the temporary file that was created when downloading.
• On Windows, when saving a file with no content type and an .exe extension, .txt is
  appended to the filename. This is done at a later step in validateLeafName in HelperAppDlg.jsm.
  This is special-cased (case 54) in the testcase.
• Windows does not have a application/x-javascript mime type handler specified by default so
  the mime code (in uriloader/exthandler/win) creates a mime info object where the primary
  extension is the extension you specified. When the extraMimeEntries gets checked, it adds
  the .js extension to the mime info object but at a lower priority. This means that the
  .js extension is never applied. This affects a number of testcases, for example, 23 and 24.
• Sniffing is done too generically in toolkit/components/mediasniffer/nsMediaSniffer.cpp and
  a file web_video1.ogv will be sniffed as application/ogg even though the extension implies
  it should be video/ogg. This doesn't cause any effect with the current patches however but
  was noticed as a issue to investigate further.
• Mac seems to use the extension .dms to refer to unknown binary files. This does happen in some
  situations currently, and possibly could still happen when saving some files, but this is
  reduced and doesn't appear to show up in any cases with these patches applied.
• The name field Content-Disposition is used by contentAreaUtils.js as well as the filename. I'm
  not clear of the background behind this, but this special case is kept in just when using this
  codepath.
• nsWebBrowserPersist::CalculateAndAppendFileExt used to be supplied an original url that was
  checked as an alternate, but I can't find a case where that url differs from the regular url
  that was supplied. It seems inconsequential though so I just removed this.

Depends on D135951

Depends on D135957

Depends on D135959

Backed out for causing failures on uriloader/exthandler/tests/

• backout: https://hg.mozilla.org/integration/autoland/rev/15cebc1bbdefe8a635edef28b8503b89446105b3
• push: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&revision=d19cc58e3cab262ccf4f7e908d59f8b08903a67e
• failure logs:
  • TEST-UNEXPECTED-FAIL | uriloader/exthandler/tests/mochitest/browser_save_filenames.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. -
  • TEST-UNEXPECTED-FAIL | uriloader/exthandler/tests/mochitest/browser_auto_close_window.js | Test timed out -

This test involves clicking on a link to a .bin file. In the Mac test environment, this is given the macbinary content type. This test assumes that it will be octet-stream (another valid content type for the bin extension) and sets the alwaysAskBeforeHandling flag for that, so the dialog never shows up. However, another subtest needs octet-stream to prompt as well, so set the always ask for both.

Depends on D138738

Backed out 14 changesets (Bug 1746052) for causing build bustages in nsExternalHelperAppService.cpp CLOSED TREE

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&collapsedPushes=842382&selectedTaskRun=M7Cz89JCRQW1oToRzx0B1w.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=bf46b0add531503bb1f37b51c3cb80552d6adba2

Log: https://treeherder.mozilla.org/logviewer?job_id=377016321&repo=autoland&lineNumber=31367
https://treeherder.mozilla.org/logviewer?job_id=377017991&repo=autoland&lineNumber=6396

Backout: https://hg.mozilla.org/integration/autoland/rev/53107941679965745bfe12311b44f411aaccb5a7

https://hg.mozilla.org/mozilla-central/rev/0dfb58ea1a60
https://hg.mozilla.org/mozilla-central/rev/e8245a15c3c9
https://hg.mozilla.org/mozilla-central/rev/d60765ec0794
https://hg.mozilla.org/mozilla-central/rev/6861a1edb0f7
https://hg.mozilla.org/mozilla-central/rev/36e041cca337
https://hg.mozilla.org/mozilla-central/rev/f95c284ca227
https://hg.mozilla.org/mozilla-central/rev/f47ddc358e1a
https://hg.mozilla.org/mozilla-central/rev/a8ab5e1f863c
https://hg.mozilla.org/mozilla-central/rev/ad582bc5019f
https://hg.mozilla.org/mozilla-central/rev/45b3ecacb364
https://hg.mozilla.org/mozilla-central/rev/c5206784e1a6
https://hg.mozilla.org/mozilla-central/rev/fa3172404fd7
https://hg.mozilla.org/mozilla-central/rev/98d24e564a25
https://hg.mozilla.org/mozilla-central/rev/b91422aa4ba1

since version 101.2 until 103.0b4, firefox no longer saves winrar/zip extensions when downloading those files