There are three exceptions made for `about:newtab`; this updates the
first exception. It does not appear that the `about:asrouter` CSP
includes a web scheme, so the second exception in the file is not
needed; nor does it appear that `about:asrouter` require
`unsafe-inline`, so the third exception in the file is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D200733
nsJSUtils::GetCallingLocation is used mostly for console message and logging,
except for the following:
* profiler label in TimeoutHandler
* CC log for TimeoutHandler
* events in nsIConsoleAPIStorage
* JSON used by mozilla::dom::SendReports
Differential Revision: https://phabricator.services.mozilla.com/D193370
nsJSUtils::GetCallingLocation is used mostly for console message and logging,
except for the following:
* profiler label in TimeoutHandler
* CC log for TimeoutHandler
* events in nsIConsoleAPIStorage
* JSON used by mozilla::dom::SendReports
Differential Revision: https://phabricator.services.mozilla.com/D193370
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
