Set the Content-Type to an empty string for an blob when the type was not
given. Ensure that the channel Content-Type is not overriden in the case
that it was previously set and the blob type is not valid.
Depends on D147568
Differential Revision: https://phabricator.services.mozilla.com/D147481
The remaining methods in ns[T]StringObsolete are all find+replace methods for
nsTSubstring. These were migrated in a similar way to the find methods, and
partially updated to avoid using methods from nsStringObsolete.cpp.
This change removes the ns[T]StringObsolete.cpp files completely, as they are
no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D148301
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
This patch adds a new Content Blocking Eveent flag and modifies the
current email tracking event flag. This would allow us to log the
loading of email tracker in two levels. The level 1 email tracker
contains the base list of the email trackers, The level 2 email tracker
contains both base and content email trackers.
Differential Revision: https://phabricator.services.mozilla.com/D152679
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
This prevents copies and avoids the hack we have to avoid this, which
right now is using nsDependent{C,}String.
Non-virtual actors can still use `nsString` if they need to on the
receiving end.
Differential Revision: https://phabricator.services.mozilla.com/D152519
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
The remaining methods in ns[T]StringObsolete are all find+replace methods for
nsTSubstring. These were migrated in a similar way to the find methods, and
partially updated to avoid using methods from nsStringObsolete.cpp.
This change removes the ns[T]StringObsolete.cpp files completely, as they are
no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D148301
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
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
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
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
Andi-Bogdan Postelnicu
Dan Robertson
Mark Banner
Nika Layzell
Christian Holler
Tim Huang
Neil Deakin
Tooru Fujisawa
Emilio Cobos Álvarez
Shane Hughes
smolnar
criss
Andreea Pavel
Barret Rennie
Kris Maglione
Andrew McCreight
Tom Schuster
Dimi
Manuel Bucher
Cosmin Sabou
Norisz Fay
Calixte