This makes it easier to get parity between legacy and regular flex
without having to either have tons of arbitrary attribute selectors in
the xul sheet, nor adding attribute lookup hacks to the html flexbox
layout.
Also, reimplement the remaining supported flex attribute-values (0 and 1)
purely in terms of CSS rules in xul.css (regardless of whether
emulate-moz-box-with-flex is enabled).
In practice these are pretty uncommon and the style attribute does the
trick in every case I've tried.
Add a debug-only assertion to ensure we preserve behavior for now.
Add a new test with another behavior difference between flexbox
emulation and old xul layout because the old reftest now passes. Use
replaced elements, which in modern flex are treated differently.
Differential Revision: https://phabricator.services.mozilla.com/D154394
This makes it easier to get parity between legacy and regular flex
without having to either have tons of arbitrary attribute selectors in
the xul sheet, nor adding attribute lookup hacks to the html flexbox
layout.
Also, reimplement the remaining supported flex attribute-values (0 and 1)
purely in terms of CSS rules in xul.css (regardless of whether
emulate-moz-box-with-flex is enabled).
In practice these are pretty uncommon and the style attribute does the
trick in every case I've tried.
Add a debug-only assertion to ensure we preserve behavior for now.
Add a new test with another behavior difference between flexbox
emulation and old xul layout because the old reftest now passes. Use
replaced elements, which in modern flex are treated differently.
Differential Revision: https://phabricator.services.mozilla.com/D154394
When generating code for arrays of interfaces from the rust-xpidl
compiler, the type was declared incorrectly as ThinVec<RefPtr<T>>
instead of ThinVec<Option<RefPtr<T>>> meaning that null values in the
array would be handled incorrectly.
This patch fixes this code generation mistake and updates crates using
the interface to handle null values correctly.
Differential Revision: https://phabricator.services.mozilla.com/D153485
These tests set up an ECH server which will only negotiate http/1.1 in the TLS ALPN extension.
If the client doesn't send an ALPN offering at least http/1.1 the connection will fail with
SSL_ERROR_NEXT_PROTOCOL_NO_PROTOCOL.
Differential Revision: https://phabricator.services.mozilla.com/D153368
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 moves EqualsIgnoreCase to ns[T]StringObsolete, and removes
the aCount argument, instead migrating callers to use `StringBeginsWith`
with a case-insensitive comparator.
In addition, nsTStringRepr::Compare was removed and replaced with either
calls to methods like `StringBeginsWith` or the global `Compare` method.
These changes required some modifications at call-sites but should make
the behaviour less surprising and more consistent.
Differential Revision: https://phabricator.services.mozilla.com/D148299
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 patch adds two new telemetry histograms which collect specific types
of TLS handshake seperately from existing handshakes.
- The conservative histogram tracks handshakes used for essential connections (e.g. update checks)
- The first-try histogram tracks all initial connection attempts. This allows us to identify issues that might otherwise be masked by our retry logic.
A single handshake may belong to more than one histogram. All handshakes belong to the root histogram.
As the histogram buckets are aligned, it is possible to derive new histograms from these stored results.
For example, as ECH GREASE is only used on first-try handshakes, the histogram from non-GREASE first-try
handshakes can be calculated by subtracting the entries in the GREASE histogram from the first-try histogram.
This patch also extends the existing handshake necko tests to verify that the telemetry is recorded correctly.
Telemetry checks don't run if networking is running on the socket process as the histograms are no longer
accessible.
Differential Revision: https://phabricator.services.mozilla.com/D150754
If nsNSSSocketInfo::mFd is nullptr, it means the connection has been closed.
This isn't an error, and ClientAuthCertificateSelected shouldn't assert if this
happens.
Differential Revision: https://phabricator.services.mozilla.com/D151962
In bug 1682412, loadCerts was removed from nsICertTree. At the time, the
certificate manager still had one use of it that should have been updated to
loadCertsFromCache. This patch makes that update.
Differential Revision: https://phabricator.services.mozilla.com/D150503
Before this patch, the certificate verifier would only attempt to build a
trusted path to a root with the first recognized EV OID in the end-entity
certificate. Thus, if an end-entity certificate had more than one EV OID, it
could fail to verify as EV if an intermediate or root had the "wrong" EV OID.
This patch addresses this shortcoming by trying to build a path with each
recognized EV OID in the end-entity certificate until it finds one that works.
Differential Revision: https://phabricator.services.mozilla.com/D149319
Certificate error overrides made in non-private contexts should be availble in
private contexts as well (but not vice-versa).
Differential Revision: https://phabricator.services.mozilla.com/D149296
Add a preference for whether to remove ECH GREASE extensions when retrying a connection. This repurposes the flag which was previously present but not actually functional.
Differential Revision: https://phabricator.services.mozilla.com/D147191
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 changes the behavior of CRLite when configured in `ConfirmRevocations`
mode (the default mode on nightly and early beta). Under the new definition,
ConfirmRevocations mode fails closed when OCSP fails open. In particular, a
certificate will be marked as "Revoked" in the following scenarios:
- CRLite returns "Revoked" and the certificate does not list an OCSP URL,
- CRLite returns "Revoked" and the OCSP responder is unreachable,
- CRLite returns "Revoked" and the OCSP responder returns an error.
Differential Revision: https://phabricator.services.mozilla.com/D148686
Add a preference for whether to remove ECH GREASE extensions when retrying a connection. This repurposes the flag which was previously present but not actually functional.
Differential Revision: https://phabricator.services.mozilla.com/D147191
Before this patch, the content signature verifier
(nsIContentSignatureVerifier/ContentSignatureVerifier) would identify the root
it trusted based on the value of a preference. This patch changes the
implementation to require a specified hard-coded root to trust as with add-on
signature verification.
Depends on D146644
Differential Revision: https://phabricator.services.mozilla.com/D146645
Before this patch, the app signature verification code lived in security/apps/.
The majority of the rest of PSM is in security/manager/ssl/ and there's little
reason to have that extra directory for the app signature verification
implementation alone.
Differential Revision: https://phabricator.services.mozilla.com/D146644