I've finally found time to look at this enhancement and I now have a patch that works in my environment.

There is a new optional "toFileName" property in the PageSettings parameter object.

The saved file name (before the ".pdf" extension) is determined as follows, in decreasing priority order:

• the toFileName property value, if defined and not an empty string,
• the content title, if not an empty string
• the last segment of the page URL path (excluding any file type extension), if not an empty string
• otherwise "mozilla" (the default in the print-to-PDF core code when the printSettings.toFileName is an empty string)

The new code looks like:

      if (pageSettings.toFileName !== null && pageSettings.toFileName != "") {
        picker.defaultString = pageSettings.toFileName + ".pdf";
      }
      else if (activeTab.linkedBrowser.contentTitle != "") {
        picker.defaultString = activeTab.linkedBrowser.contentTitle + ".pdf";
      }
      else
      {
        let url = new URL(activeTab.linkedBrowser.currentURI.spec);
        let path = decodeURIComponent(url.pathname);

        if (path.substr(-1) == "/")
        {
          path = path.substr(0,path.length-1);
        }
        let i = path.lastIndexOf("/");
        if (i >= 0) {
          path = path.substr(i+1);
        }
        i = path.lastIndexOf(".")
        if (i >= 0) path = path.substr(0,i);

        if (path != "") {
          picker.defaultString = path + ".pdf";
        }
        else {
          picker.defaultString = "mozilla.pdf";
        }
      }

I will submit a patch for review shortly.

Jim, please can you make me the assignee for this bug.

Add optional 'toFileName' property to the 'pageSettings' object
passed into tabs.saveAsPDF().

Shane,

I have created the patch to add an optional 'toFileName' property to the 'pageSettings' object passed into tabs.saveAsPDF().

I have updated the schema (tabs.json), updated the saveAsPDF code (ext-tabs.js), and updated the automated test code (browser_ext_tabs_saveAsPDF.js) to test that the saved filename is correct when the 'toFileName' is a defined string and when it is undefined (null).

All 3 of these files passed the checks in eslint. I have done extensive informal testing with an updated version of my Print Edit WE extension. All of the automated tests are passed successfully.

Please can you review this patch.

Shane,

I have tried:

filename = Services.io.newURI(filename).QueryInterface(Ci.nsIURL).fileName;

but that throws an exception.

I have tried:

filename = Services.io.newURI("file:///" + filename).QueryInterface(Ci.nsIURL).fileName;

and that works, but does not give the required result.

For example, if filename contains "Wikipedia, the free encyclopedia", then the result is "Wikipedia,%20the%20free%20encyclopedia". This is fine for the last segment of a URL path, but not for a computer file name, where "Wikipedia, the free encyclopedia" is perfectly valid and would be expected by a user.

Adding a "filename" FORMAT will have the same problem if it uses Services.io.newURI. Also, I'm not sure that the 'context' parameter would give access to 'activeTab.linkedBrowser.contentTitle' which is necessary to replicate the default 'Save As' behaviour in Firefox and Chrome.

The regex in the current revision replaces a superset of the characters that are not accepted by the major operating system file systems (Windows, Linux and Mac OS X), although in this case only Windows and Linux are relevant.

For me the distinction between a computer file name and a segment of a URL path is important to the user experience.

Maybe I am missing something or maybe it can be achieved in a different way?

From a user perspective, I think what we want to do is replicate the logic used in Firefox's normal "Save Page As" menu command.

The relevant sources are:

getDefaultFileName() - https://searchfox.org/mozilla-central/source/toolkit/content/contentAreaUtils.js#1165
validateFileName() - https://searchfox.org/mozilla-central/source/toolkit/content/contentAreaUtils.js#1271
sanitize() - https://searchfox.org/mozilla-central/source/toolkit/components/downloads/DownloadPaths.jsm#71

getDefaultFileName() generates a default file name for the file picker. getDefaultFileName() calls validateFileName() to validate the file name. validateFileName() just calls sanitize(), with some additional processing for Android.

In the current revision:

lines 1313-1329 implement a simplified version of the logic in getDefaultFileName(), giving priority to the name in pageSettings.toFileName.
line 1330 implements a simplified version of the logic in sanitize(), without any additional processing for Android.

I think it would be an improvement to replace the regex in line 1330 with a call to validateFileName().

Please see the new revision with this change.

(In reply to dw-dev from comment #13)

validateFileName() - https://searchfox.org/mozilla-central/source/toolkit/content/contentAreaUtils.js#1271

Good find. The point of using a FORMAT is that we can simply have that handled via schema for any future need as well. But I would call it localFilename or something to indicate it's intended use. However, it's probably best to just validate all the potential inputs.

@dw-dev thanks!

https://hg.mozilla.org/mozilla-central/rev/262718256e32

toFileName added to tabs.PageSettings and compatibility data is merged.

Please let me know if there need to be any changes.

Looks fine. Thanks.

Works in released Firefox 75.

Is any more information required?