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
Spec: https://html.spec.whatwg.org/multipage/#coep:coep-credentialless
Credentialless is a new cross-origin embedder policy which allows us
to not enforcing CORP when loading cross-origin resources while
providing SharedArrayBuffer.
There are two main things involved here:
1. Fetching cross-origin no-CORS resources omits credentials
- This is done by applying `LOAD_ANONYMOUS` flag to the request
2. Other requests sent with credentials require the server's explicit
permission through the CORS protocol or the CORS header
- This is done by expanding `ProcessCrossOriginResourcePolicyHeader`
function to apply the necessary checks.
Differential Revision: https://phabricator.services.mozilla.com/D147802
Spec: https://html.spec.whatwg.org/multipage/#coep:coep-credentialless
Credentialless is a new cross-origin embedder policy which allows us
to not enforcing CORP when loading cross-origin resources while
providing SharedArrayBuffer.
There are two main things involved here:
1. Fetching cross-origin no-CORS resources omits credentials
- This is done by applying `LOAD_ANONYMOUS` flag to the request
2. Other requests sent with credentials require the server's explicit
permission through the CORS protocol or the CORS header
- This is done by expanding `ProcessCrossOriginResourcePolicyHeader`
function to apply the necessary checks.
Differential Revision: https://phabricator.services.mozilla.com/D147802
Spec: https://html.spec.whatwg.org/multipage/#coep:coep-credentialless
Credentialless is a new cross-origin embedder policy which allows us
to not enforcing CORP when loading cross-origin resources while
providing SharedArrayBuffer.
There are two main things involved here:
1. Fetching cross-origin no-CORS resources omits credentials
- This is done by applying `LOAD_ANONYMOUS` flag to the request
2. Other requests sent with credentials require the server's explicit
permission through the CORS protocol or the CORS header
- This is done by expanding `ProcessCrossOriginResourcePolicyHeader`
function to apply the necessary checks.
Differential Revision: https://phabricator.services.mozilla.com/D147802
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
In future parts, TaskQueue will require extra initialization to be performed
which cannot happen in a constructor, as it takes references to the TaskQueue
object itself, which will require the introduction of a helper method. This
patch switches all callers of the TaskQueue constructor to use the new method.
Differential Revision: https://phabricator.services.mozilla.com/D142604
Before this patch, nsISiteSecurityService APIs took "flags" parameters that
differentiated private contexts from not private contexts. However, these
parameters were redundant with respect to origin attributes, which led to some
confusion for consumers of these APIs. This patch removes these parameters in
favor of using origin attributes.
Differential Revision: https://phabricator.services.mozilla.com/D142901
- Add new function to netwerk utils to check for about:srcdoc URIs, mirroring the function for about:blank.
- When performing check whether or not a Window is third-party, check if the URI is about:srcdoc when you check if the URI is about:blank.
- When computing whether a channel is third-party to the top window, if the channel's URI is about:srcdoc, use its parent context's origin.
Differential Revision: https://phabricator.services.mozilla.com/D137286
org.mozilla.geckoview_testrunner currently permanently crashes locally when running web-platform-tests jobs on Android.
This patch temporarily disables the chrome registration check until the underlying issue has been completely fixed.
Differential Revision: https://phabricator.services.mozilla.com/D135115
Given that we use the partitioned Principal in the third-party context
and the loading principal won't have it, we should ignore the
partitionKey when doing the verfication.
Differential Revision: https://phabricator.services.mozilla.com/D127841
Revert some of the fix for 1722758 so that only the URL ref component is re-encoded for NSURL compatibility. Other URL fields need additional work to be addressed in a follow up.
Update the set of characters re-encoded to be as minimal as possible and include missing characters.
Add tests to ensure encoding works as expected, not just that it is accepted by NSURL.
Differential Revision: https://phabricator.services.mozilla.com/D130445
Given that we use the partitioned Principal in the third-party context
and the loading principal won't have it, we should ignore the
partitionKey when doing the verfication.
Differential Revision: https://phabricator.services.mozilla.com/D127841
Given that we use the partitioned Principal in the third-party context
and the loading principal won't have it, we should ignore the
partitionKey when doing the verfication.
Differential Revision: https://phabricator.services.mozilla.com/D127841
Given that we use the partitioned Principal in the third-party context
and the loading principal won't have it, we should ignore the
partitionKey when doing the verfication.
Differential Revision: https://phabricator.services.mozilla.com/D127841
Given that we use the partitioned Principal in the third-party context
and the loading principal won't have it, we should ignore the
partitionKey when doing the verfication.
Differential Revision: https://phabricator.services.mozilla.com/D127841
