Matthew Finkel authored 3 years ago and Pier Angelo Vendrame committed 1 year ago

Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1711084

Bug 1829981, reduce maximum filename length to 254, as Windows File Explorer won't allow deleting filenames longer than this, r=Gijs a=RyanVM

Differential Revision: https://phabricator.services.mozilla.com/D176911

Original Revision: https://phabricator.services.mozilla.com/D171405

Differential Revision: https://phabricator.services.mozilla.com/D173948

Bug 1815062, move filename and extension validity checks into SanitizeFileName so that they get called after sanitization is complete, r=Gijs,necko-reviewers a=RyanVM

For now, this leaves existing callers of DownloadPaths.sanitize as is using a flag.

Differential Revision: https://phabricator.services.mozilla.com/D174190

Differential Revision: https://phabricator.services.mozilla.com/D165466

Differential Revision: https://phabricator.services.mozilla.com/D170086

Bug 1792138: Show the extension's name in permission prompts for opening external links. r=ckerschb,robwu,pbz,flod a=RyanVM

In order to handle the content script case correctly we must expose the
contentScriptAddonPolicy to JavaScript. With that we can always see what
extension is trying to perform an action and use its name rather than internal
ID in the dialog.

Differential Revision: https://phabricator.services.mozilla.com/D168807

Bug 1799632: Refactor `testOpenProto` to accept a callback to trigger protocol loads. r=Gijs, a=RyanVM

Currently this function uses six different booleans to decide which code to run
to trigger the load (many of which are used in just one test) and elsewhere I
need to add more cases. This changes the function to instead take a callback
function so individual tests can just pass their one-off functions. For the
few that are shared global functions are used to share those.

Differential Revision: https://phabricator.services.mozilla.com/D161588

Differential Revision: https://phabricator.services.mozilla.com/D167953

Bug 17910339, avoid crash by computing the extension's byte length correctly and truncate the filename's extension when it is too long, r=gsvelto,jfkthame, a=RyanVM

Differential Revision: https://phabricator.services.mozilla.com/D159478

Bug 1777207, don't replace extensions of executables when saving on Windows any more; the filename has already been validated and it can cause the filename a user chose to be incorrect, r=mhowell, a=dmeehan

Differential Revision: https://phabricator.services.mozilla.com/D156729

Differential Revision: https://phabricator.services.mozilla.com/D157516

Differential Revision: https://phabricator.services.mozilla.com/D156007

Bug 1772988, add some additional extensions for some media types as Windows doesn't provide some of them, causing valid extensions to be replaced when saving files, r=mhowell, a=RyanVM

Differential Revision: https://phabricator.services.mozilla.com/D155972

This is a medium sized patch to legacy download construction. It takes
advantage of the new property added in Bug 1762033 to prevent the
downloads panel from being automatically shown when a download is added
after an interaction with the unknown content type dialog or the file
picker dialog. I chose to not do the same for failed transfers since I
thought it might serve some use, but that might be wrong. I don't know
if there's a way to test the dialog that appears when you download an
executable without going through the same path I adjusted with the
patch. It seems like it's covered but I could be wrong. Also add a test
to cover these changes from the bottom up. Thanks and apologies for my
sloppy C++, though I'm sure I'll learn a lot more from the review 

Differential Revision: https://phabricator.services.mozilla.com/D145312

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

Bug 1778429, use utf-16 character literals when calling ReplaceChar in SanitizeFileName, r=Gijs, a=RyanVM

Differential Revision: https://phabricator.services.mozilla.com/D152669

Bug 1779128, rework filename sanitization to ensure that the extension is properly validated, r=Gijs, a=RyanVM

The existing code doesn't use the sanitized extension part of the filename, when it replaces the filename when it is too long but instead used a version passed to SanitizeFileName. This newer version always gets the extension from the filename after it has been validated.

Some tests have slightly different results, because the file is now cropped slightly differently when the character count and byte count of long filenames don't match, resulting in some filenames being cropped a few extra characters more than needed.

Differential Revision: https://phabricator.services.mozilla.com/D151826

Bug 1773907, don't clear the extension on the possible filename if we don't have one to replace it with, r=mhowell, a=dmeehan

The issue here is that ShouldModifyExtension returns Replace because the content type isn't known.

Differential Revision: https://phabricator.services.mozilla.com/D151427

Differential Revision: https://phabricator.services.mozilla.com/D150386

Bug 1770683, only replace or append the correct extension for media types, and some selected content types, or if the extension is not present, r=Gijs

This is closer to the behaviour before bug 1746052. Also adds some tests for compressed types.

Differential Revision: https://phabricator.services.mozilla.com/D147537

Depends on D146727

Differential Revision: https://phabricator.services.mozilla.com/D146728

Bug 1768898, special case zip, json, and xml to allow these files to be saved with any extension, r=Gijs

Differential Revision: https://phabricator.services.mozilla.com/D146727

Bug 1738574 - add an option to put downloads in tmp to start with, r=mak,mkaply,fluent-reviewers,flod

Differential Revision: https://phabricator.services.mozilla.com/D146719

The component that handles MIME type information will consult whatever
the OS uses as a registry of file types / applications; in the past
this caused problems for sandboxing on macOS and then Windows, so IPC was
used to remote those queries to the parent process.

We've also been having similar problems on Linux, and none of the
infrastructure here seems to be OS-specific; therefore I've removed the
`#ifdef` so that we always use IPC.

Differential Revision: https://phabricator.services.mozilla.com/D145823

Bug 1514936, part 1 - Remove the outer argument to nsIFactory::createInstance. r=xpcom-reviewers,preferences-reviewers,nika,Gijs

This patch won't actually build, because a few bits of code are used
for both nsIFactory::createInstance and static components, and static
components are not fixed until the next patch.

The first place is nsLoadGroupConstructor, which uses an nsIFactory
macro to create a static component constructor. (This could be worked
around by expanding the macro to the state before this patch.)

The other issue is that nsAppShellConstructor is used in an nsIFactory
on OSX, but as a static component on all other platforms. This could
be worked around by wrapping nsAppShellConstructor in an adaptor that
passes in the extra null argument to nsAppShellConstructor.

Differential Revision: https://phabricator.services.mozilla.com/D146456

Bug 1757771, always launch the save dialog when pressing the PDF Viewer download button, and remove test code that expected the unknown type dialog to appear, r=marco

Differential Revision: https://phabricator.services.mozilla.com/D145814

Bug 1768189 - Part 47: Apply modernize-concat-nested-namespaces to layout/style/MediaQueryList.h ... r=andi

Depends on D145782

Differential Revision: https://phabricator.services.mozilla.com/D145783

Differential Revision: https://phabricator.services.mozilla.com/D137997

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.

Differential Revision: https://phabricator.services.mozilla.com/D145547

Bug 1746052, add tests for filename validation when dragging images, copy/paste of images, saving a document or image, and when content disposition: attachment is used, and add a unit test that verifies nsIMIMEService.validateFileNameForSaving, r=mhowell

Differential Revision: https://phabricator.services.mozilla.com/D135959

Bug 1746052, use validateFileNameForSaving to get and validate the default filename when a document or image is chosen to be saved, r=Gijs

Differential Revision: https://phabricator.services.mozilla.com/D135958

Bug 1746052, don't allow Windows reserved filenames when sanitizing filenames. Move MangleTextToValidFileName to nsLocalFileWin and rename it to CheckForReservedFileName, r=Gijs

Differential Revision: https://phabricator.services.mozilla.com/D138737

Differential Revision: https://phabricator.services.mozilla.com/D135957

Bug 1746052, don't modify the extension for text and binary types, as this is the behaviour that save as had, r=Gijs

Differential Revision: https://phabricator.services.mozilla.com/D135955

Bug 1746052, improve file sanitization by filtering and collpasing more whitespace characters and truncating files to 255 bytes, r=jfkthame

Differential Revision: https://phabricator.services.mozilla.com/D138736

Bug 1746052, add methods to the mime service that compute and validate a filename for a given content type, r=Gijs

The code in SanitizeFilename will be expanded upon in the following patch.

Differential Revision: https://phabricator.services.mozilla.com/D135951

Backed out changeset 076c2a81804a (bug 1739348) for xpcshell failures on test_DownloadBlockedTelemetry.js. CLOSED TREE

This is a medium sized patch to legacy download construction. It takes
advantage of the new property added in Bug 1762033 to prevent the
downloads panel from being automatically shown when a download is added
after an interaction with the unknown content type dialog or the file
picker dialog. I chose to not do the same for failed transfers since I
thought it might serve some use, but that might be wrong. I don't know
if there's a way to test the dialog that appears when you download an
executable without going through the same path I adjusted with the
patch. It seems like it's covered but I could be wrong. Also add a test
to cover these changes from the bottom up. Thanks and apologies for my
sloppy C++, though I'm sure I'll learn a lot more from the review 

Differential Revision: https://phabricator.services.mozilla.com/D145312