The mozconfig in the task definition is overriden in hazard-browser.sh,
so it has effectively no effect, and hazard-browser.sh has been using
js/src/devtools/rootAnalysis/mozconfig.haz since bug 1321014.
Differential Revision: https://phabricator.services.mozilla.com/D41879
--HG--
extra : moz-landing-system : lando
__PRETTY_FUNCTION__ and __FUNCTION__ are not guaranteed to be a string
literal, and only string literals should be used as format strings. GCC
9 complains about this with -Werror=format-security.
Differential Revision: https://phabricator.services.mozilla.com/D42459
--HG--
extra : moz-landing-system : lando
See https://github.com/mathml-refresh/mathml/issues/24
and https://groups.google.com/forum/#!topic/mozilla.dev.platform/-yV6wb3klSA
This commit introduces a new preference option
mathml.nonzero_unitless_lengths.disabled to disable MathML nonzero unitless
values like "5" for 500%. MathML nonzero unitless are now disabled by default
but it could be easily enabled again later if we decide otherwise.
* test_bug553917.html is updated to check that these values now cause an error
message to be logged into the console rather than a deprecated warning
when nonzero unitless lengths are disabled.
Additionally, the test checking invalid double dots "2..0" is updated not
to use unitless syntax.
* The old test 355548-3.xml checks support for mathsize names and also uses
several features that are going to be deprecated. So it is just run with
the proper preference adjustment.
* mfrac-linethickness-2.xhtml and number-size-1.xhtml check support for
unitless lengths so they are now run with that support enabled.
* WPT tests frac-linethickness-001.html and lengths-1.html are executed with
the some MathML features disabled in order to make them pass.
We get more assertion passing for the "Legacy numbers" test of
lengths-2.html ; however there are still some issues to address
(see bug 1574751).
Differential Revision: https://phabricator.services.mozilla.com/D42427
--HG--
extra : moz-landing-system : lando
See https://github.com/mathml-refresh/mathml/issues/7
and https://groups.google.com/forum/#!topic/mozilla.dev.platform/kyB34PjYXek
This commit introduces a new preference option
mathml.mathsize_names.disabled to disable mathsize keyword values. For
now, these are only disabled in Nightly builds.
* test_bug553917.html is updated to check that these values now cause an
error message to be logged into the console when mathsize names are used
and the feature disabled.
* The old test 355548-3.xml checks support for mathsize names and also uses
several features that are going to be deprecated. So it is just run with
the proper preference adjustment.
* mathml/relations/css-styling/mathsize-attribute-legacy-values.html passes
after this change so the test is run with the mathsize names disabled too
and the failure expectation is removed.
* mathml/relations/css-styling/mathsize-attribute-css-keywords.html is added
to check that CSS keywords won't be supported when we switch to using the
CSS parser in the future. This test passes now when the "small" keyword
is not accepted so it is run with the mathsize names disabled too.
Differential Revision: https://phabricator.services.mozilla.com/D42426
--HG--
extra : moz-landing-system : lando
These two bugs (bug 1572738 and bug 1572451) are stylo regressions.
When font-family changes, we try to recompute the font-size with a length /
percentage combinations in case the generic family changes, so the user
preferences are kept.
When calc() is involved, we clamp to non-negative too early, via
NonNegativeLength::scale_by.
I think we should generally dump this "try to track font-size across calc()"
thingie, as as various comments note it is not quite perfect, and it's not clear
how it should work in presence of min()/max().
This patch fixes the issue and simplifies code a bit, I may consider removing
this altogether in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D41776
--HG--
extra : moz-landing-system : lando
The `MockSecurityInfo` instances in the patched devtools tests are not actually
being used as `nsITransportSecurityInfo` instances; while `QueryInterface`
methods were generated for the them, these were never called. Additionally, the
methods they are being passed to are not XPCOM-defined and therefore do not
strictly require `nsITransportSecurityInfo`.
In addition `NetworkHelper#parseSecurityInfo` now requires its `securityInfo`
to be `QueryInterface`d to a `nsITransportSecurityInfo` before calling the
function (except in the case of `MockSecurityInfo`, which is structurally
similar).
Differential Revision: https://phabricator.services.mozilla.com/D40521
--HG--
extra : moz-landing-system : lando
There are no longer any consumers of the JS-implemented
`FakeTransportSecurityInfo` class, so it can be removed. That removes the last
JS-implemented `nsITransportSecurityInfo` instance and it therefore can be
marked `builtinclass`.
Differential Revision: https://phabricator.services.mozilla.com/D40355
--HG--
extra : moz-landing-system : lando
As part of making `nsITranportSecurityInfo` builtinclass, we can no longer
use JS-implemented `nsITransportSecurityInfo` instances in test cases.
This patch migrates `test_sss_resetState.js` to use `add_connection_test()` to
get a valid `nsITransportSecurityInfo` instance for the unit tests.
Differential Revision: https://phabricator.services.mozilla.com/D40352
--HG--
extra : moz-landing-system : lando
As part of making `nsITranportSecurityInfo` builtinclass, we can no longer use
JS-implemented `nsITransportSecurityInfo` instances in test cases. This patch
migrates `test_sss_originAttributes.js` to use `add_connection_test()` to get a
valid `nsITransportSecurityInfo` instance for the unit tests.
Differential Revision: https://phabricator.services.mozilla.com/D40351
--HG--
extra : moz-landing-system : lando
As part of making `nsITranportSecurityInfo` builtinclass, we can no longer
use JS-implemented `nsITransportSecurityInfo` instances in test cases.
This patch migrates `test_sss_enumerate.js` to use `add_connection_test()` to
get a valid `nsITransportSecurityInfo` instance for the unit tests.
Differential Revision: https://phabricator.services.mozilla.com/D40350
--HG--
extra : moz-landing-system : lando
As part of making `nsITranportSecurityInfo` builtinclass, we can no longer use
JS-implemented `nsITransportSecurityInfo` instances in test cases. This patch
migrates `test_pinning_header_parsing.js` to use `add_connection_test()` to get
a valid `nsITransportSecurityInfo` instance for the unit tests.
Differential Revision: https://phabricator.services.mozilla.com/D40349
--HG--
extra : moz-landing-system : lando
As part of making `nsITranportSecurityInfo` builtinclass, we can no longer use
JS-implemented `nsITransportSecurityInfo` instances in test cases. This patch
migrates `test_ocsp_must_staple.js` to use `add_connection_test()` to get a
valid `nsITransportSecurityInfo` instance for the unit tests.
Differential Revision: https://phabricator.services.mozilla.com/D40348
--HG--
extra : moz-landing-system : lando
As part of making `nsITranportSecurityInfo` builtinclass, we can no longer use
JS-implemented `nsITransportSecurityInfo` instances in test cases. This patch
migrates `test_forget_about_site_security_headers.js to use
`add_connection_test()` to get a valid `nsITransportSecurityInfo` instance for
the unit tests.
Differential Revision: https://phabricator.services.mozilla.com/D40347
--HG--
extra : moz-landing-system : lando
There is now a contract ID for `nsITransportSecurityInfo`, allowing
`mozilla::psm::TransportSecurityInfo` instances to be created from JS. Tests
using a JS-implemented `nsITransportSecurityInfo` that were not modifying,
e.g., the `serverCert` attribute have been updated to create a
`mozilla::psm::TransportSecurityInfo` via the contract.
Differential Revision: https://phabricator.services.mozilla.com/D40346
--HG--
extra : moz-landing-system : lando
There are two interrelated problems with `InitializeGlobalState`. The
first is that the function itself is enormous; it clocks in at around
90K in my x86-64 Linux Nightly. (For comparison, the core interpreter
of the JS engine is smaller than this function.) This comes about
mostly because of:
```
gOriginHashesList = MakeUnique<OriginHashesList>(OriginHashesList{
});
```
which has to:
1. Construct a Tuple.
2. Append that Tuple to a temporary `std::initializer_list`.
3. Repeat for ~2500 origins.
4. Hand the `std::initializer_list` off to an `nsTArray`.
5. Move that temporary `nsTArray` into the newly `MakeUnique`'d `nsTArray`.
6. Destroy all the temporary objects created in the process.
You can imagine that this process is not exactly efficient.
The second problem is that creating this giant mass of code means that
TelemetryOrigin.cpp takes ~30s to compile on my home machine (x86-64
Android, because that's what I took the measurements on). This amount
of time is...excessive.
We're going to attack both problems with a single patch. The core idea
is that we're going to make three statically constructed arrays from
TelemetryOriginData.inc:
1. An array of (`originLength`, `hashLength`) pairs.
2. A large string constant containing the origins, in TelemetryOriginData.inc
declared order.
3. Likewise for the hashes.
The length of the first array is therefore the number of origins that
we're dealing with. It's important to note that items 2 and 3 are
storing data that we'd have to store anyway; they're just storing them
in a slightly different format. The first array is ~5K, but we're
willing to pay that to cut down on codesize.
To access the i'th origin, we need to sum the [0, i) `originLengths`
members; this sum then gives us the offset into the giant string
constant for the origins for the i'th origin. We can do the same
computation for the hashes, but using `hashLength` and the giant string
constant for the hashes. Fortunately, as we iterate through
the (`originLength`, `hashLength`) array, we can maintain a running
total of these members for nominal cost.
We can then build `gOriginHashesList` in the same loop that initializes
`gOriginToIndexMap` and `gHashToIndexMap`, for significantly less work.
As a bonus, we can make inserting items into those two maps cheaper,
because we have easy access to the lengths for the keys, rather than
computing them at runtime.
All of these changes combine to shrink `InitializeGlobalState` to less
than 2K of code on a local build. Compilation time is similarly reduced.
Differential Revision: https://phabricator.services.mozilla.com/D42344
--HG--
extra : moz-landing-system : lando
Replaced the message body div with an unstyled button element, which creates the correct tabbing behavior.
Differential Revision: https://phabricator.services.mozilla.com/D41829
--HG--
extra : moz-landing-system : lando
Changes:
- mass edit manifests to either re-enable disabled css tests on windows10-aarch64, or adjust expectations.
Differential Revision: https://phabricator.services.mozilla.com/D41065
--HG--
extra : moz-landing-system : lando
x509.subjectPublicKeyInfo was returning undefined in Firefox while in Certainly-Something it was returning the expected value. There was a problem in PublicKeyInfo.js of pkijs library, this condition `if(this.algorithm.algorithmParams instanceof asn1js.ObjectIdentifier)` was returning false, but it shouldn't. This problem was fixed in the new version of the library.
Differential Revision: https://phabricator.services.mozilla.com/D42035
--HG--
extra : moz-landing-system : lando
This patch fixes a number of miscellaneous issues with permission setting.
When we move a directory, recreate it, and move the contents back, those contents may be in use (possibly by antivirus). To address this, we now fall back to copying the data back and removing the originals.
The maximum number of backups to make when moving conflicting files is now 3 instead of 9. 9 seemed a bit excessive.
There is now an additional level of SetPermissionsOf, FilesAndDirsWithBadPerms. This new value causes permissions not to be fixed if we are unable to read them. This should prevent unnecessary permission fixes while still allowing us to aggressively set them when necessary.
Differential Revision: https://phabricator.services.mozilla.com/D42066
--HG--
extra : moz-landing-system : lando
Some tests check that the remote type is "web", but with Fission it
will instead start with "webIsolated=".
I fixed some of the errors in
browser_new_web_tab_in_file_process_pref.js and
browser_httpResponseProcessSelection.js, but there are other failures,
so they remain disabled.
Differential Revision: https://phabricator.services.mozilla.com/D42354
--HG--
extra : moz-landing-system : lando
If Status is defined (X11 headers define it as int), it ends up busting the
Status enum used in the Widevine headers. Avoid this by undeffing it before
including headers.
Differential Revision: https://phabricator.services.mozilla.com/D42335
--HG--
extra : moz-landing-system : lando
GetStatusPolicy should not treat unrecognized values as if they were no hdcp
policy. A trivial example is that if we do not recognize a newer hdcp string,
say "2.3", then we should not query if the CDM supports this policy as if it
were no hdcp.
This patch means that we surface and error to JS if we do no recognize an hdcp
string.
Differential Revision: https://phabricator.services.mozilla.com/D42061
--HG--
extra : moz-landing-system : lando
MANUAL PUSH: Lando appears to be confused about which branch it needs to push to (landing blocked on "Repository is not supported by Lando.").
Differential Revision: https://phabricator.services.mozilla.com/D42466
--HG--
extra : rebase_source : b70568422d12aedd3d371139d2505f863ff29ee2
extra : amend_source : 54d289dae1fe85bdf70893ed165ac990ac8dc35d
