This also involves making MatchGlob operate on UTF8String instead of DOMString,
as the rust `regex` crate operates on utf-8 strings. This should have no
functional impact on callers.
Differential Revision: https://phabricator.services.mozilla.com/D158877
This also involves making MatchGlob operate on UTF8String instead of DOMString,
as the rust `regex` crate operates on utf-8 strings. This should have no
functional impact on callers.
Differential Revision: https://phabricator.services.mozilla.com/D158877
This also involves making MatchGlob operate on UTF8String instead of DOMString,
as the rust `regex` crate operates on utf-8 strings. This should have no
functional impact on callers.
Differential Revision: https://phabricator.services.mozilla.com/D158877
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
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 fixes a known problem where the default branch contains a
value for general.config.filename but the user branch
does not, resultnig in a Telemetry event for prefcalls.js to
be created.
However I don't think resolves all issues.
Differential Revision: https://phabricator.services.mozilla.com/D141677
In 1746231 the JS Exception stuff was moved from the
callback call site into the callback itself.
However, when it was moved, an exception could be
added even if we were going to permit the script
execution. This is wrong.
Move the exception stuff back to the callback site
and use the result of the callback to determine if
we add anything to the stack or not
Differential Revision: https://phabricator.services.mozilla.com/D135250
frame-ancestor support requires a CSP. While extensions can declare a
CSP for extension pages, the frame-ancestors directive was not enforced
because the implementation expected only HTTP channels.
This patch also adds support for channels from ExtensionProtocolHandler.
Differential Revision: https://phabricator.services.mozilla.com/D134143
If the string pref is not set, then pref lookup fails. If the lookup
fails, we interpret it as an error (rather than a missing pref) and
bail early.
This means that we never set sJSHacksChecked and no telemetry will be
sent because we permit everything. (It also means we do a ton of pref
lookups all the time because every one of them fails.)
Differential Revision: https://phabricator.services.mozilla.com/D132727
Previously we would only include about: and moz-extension details
on Windows, because I erroneously thought that was the only place
we could sanitize them properly. But these types of URLs aren't
hard to sanitize, and really it's file:// URIs that are hard, and
those will stay windows only.
So now we collect about: and moz-extension: URIs on all platforms
and we additionally include whether the extension is privileged
or not.
We put them under new keys also.
Differential Revision: https://phabricator.services.mozilla.com/D126132
