To do this we look at the extension on the content disposition filename, if present, or the extension
of the url, and, if it is .pdf, we assume that the file will be a pdf.
Differential Revision: https://phabricator.services.mozilla.com/D147409
In pdf.js, files are saved thanks to a blob but the original URL is lost.
Consequently, the download panel doesn't contain any information about the
origins of a saved pdf.
The saveURL, internalSave and nsITransfer.init functions has now a parameter for this originalURL.
Differential Revision: https://phabricator.services.mozilla.com/D147651
The relevant information was already being set on the final channel when
not performing a process switch [1], but it was not copied for
cross-process redirects, despite being sent to the child process. This
wasn't a problem previously, as we would handle downloads in the parent
process, but with the download panel improvements, it is an issue.
This issue led to the wrong filename being selected by default when
clicking on the save icon in a downloaded PDF from a blob URL, as the
information was lost before being passed to the pdf.js stream filter.
[1]: https://searchfox.org/mozilla-central/rev/87ecd21d3ca517f8d90e49b32bf042a754ed8f18/netwerk/ipc/DocumentChannelChild.cpp#308-315
Differential Revision: https://phabricator.services.mozilla.com/D145255
When downloading a file, we check for existing mime types and construct
a new one if it's unrecognized. Mime types have a flag,
alwaysAskBeforeHandling, that determines whether the unknown content
type dialog should be opened before handling the file. Before bug
1733492, the default value for that flag was simply true. Since the new
downloads flow is intended to avoid unnecessary steps, the default value
was changed to the inverted value of the new downloads panel
improvements pref. This patch adds a new pref that the mime info
constructor will read in configuring the flag's value. If the
improvements pref is not enabled, then the flag will be true, so the UCT
dialog will open. If the improvements pref is enabled, then it'll use
the value of the new pref. Also add a an interface for the pref to the
about:preferences UI, and automatically migrate a false value for
browser.download.improvements_to_download_panel to a true value for this
pref. I'm updating some tangentially related test files since they
happen to be touched slightly by this change. Strictly speaking they
would still work, but if the pref value was somehow changed from the
default they would fail.
Differential Revision: https://phabricator.services.mozilla.com/D143002
Currently there's a fair bit of unneeded overhead when localizing the PDF Viewer, since *every single* string requires a round-trip from the `viewer.js` file to the `PdfStreamConverter.jsm` file.
This despite the fact that the relevant `viewer.properties` file is read *only once*, and its result is then cached, see https://searchfox.org/mozilla-central/rev/8f42809e51cb07aa4f5739932a06d14581e9dd4a/toolkit/components/pdfjs/content/PdfStreamConverter.jsm#470-473
Hence we can improve things here by instead sending the *entire* localization data at once when it's first requested, and also cache it in the viewer, to reduce completely unneeded message passing overhead caused by localizing the PDF Viewer.
To put these changes into perspective, let's look at what happens when loading the PDF Specification; i.e. https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf
When loading that document we first of all need to localize the viewer UI, however the initialization/rendering of the PDF Document itself also causes some l10n-string lookups. All-in-all, simply loading the above PDF document in Firefox currently results in just over `3900` l10n-strings being fetched (with most of them being duplicates).
Furthermore, all these l10n-string lookups also have a measurable performance impact on the viewer UI localization. Using some, admittedly crude, benchmarking with `console.time/timeEnd` around the viewer UI localization code in https://searchfox.org/mozilla-central/rev/8f42809e51cb07aa4f5739932a06d14581e9dd4a/toolkit/components/pdfjs/content/web/viewer.js#484-485 gives the following results (using the best observed values, with `privacy.reduceTimerPrecision = false` set):
- With the current code, the viewer UI localization takes around `12-13` ms.
- With this patch, the viewer UI localization takes around `4-5` ms.
While these improvements are obviously not huge, they thus cannot hurt as far as I'm concerned.
(Assuming this is accepted, I'll obviously follow-up with the relevant `web/viewer.js` patch at GitHub. However, these changes must be synchronized in the both the viewer/integration code.)
Differential Revision: https://phabricator.services.mozilla.com/D139928
Note that this doesn't ever trigger currently as pdf files loaded as attachments always get downloaded go through the external helper service
Differential Revision: https://phabricator.services.mozilla.com/D130098
