These tests used <iframe mozbrowser> for convenience, mostly forcing
themselves to only run in non-e10s mode in the process, but none of them
really have any need to.
Differential Revision: https://phabricator.services.mozilla.com/D70745
These tests used <iframe mozbrowser> for convenience, mostly forcing
themselves to only run in non-e10s mode in the process, but none of them
really have any need to.
Differential Revision: https://phabricator.services.mozilla.com/D70745
These tests used <iframe mozbrowser> for convenience, mostly forcing
themselves to only run in non-e10s mode in the process, but none of them
really have any need to.
Differential Revision: https://phabricator.services.mozilla.com/D70745
This patch initializes the ulIvBits member of CK_GCM_PARAMS, which is new in PKCS11 v3.
For libprio, we instead define NSS_PKCS11_2_0_COMPAT, which yields the old struct definition.
Differential Revision: https://phabricator.services.mozilla.com/D67740
--HG--
extra : moz-landing-system : lando
Revert setting CK_GCM_PARAMS ulIvBits, as this field won't exist until NSS 3.52.
Depends on D68665
Differential Revision: https://phabricator.services.mozilla.com/D68602
--HG--
extra : moz-landing-system : lando
This patch initializes the ulIvBits member of CK_GCM_PARAMS, which is new in PKCS11 v3.
For libprio, we instead define NSS_PKCS11_2_0_COMPAT, which yields the old struct definition.
Differential Revision: https://phabricator.services.mozilla.com/D67740
--HG--
extra : moz-landing-system : lando
Using JSON.stringify in dom/tests/mochitest/chrome/test_clonewrapper.xhtml might not be the best solution, because
the testObject contains ImageData objects.
Differential Revision: https://phabricator.services.mozilla.com/D58645
--HG--
extra : moz-landing-system : lando
We don't need the full generality of templated typed arrays here, just
the ability to assign from `Uint8Array`. Some versions of clang in
C++17 mode have problems with overload resolution when faced with
templated method parameters that resolve to base classes of the passed
arguments. Using the more-specific type here avoids those bugs.
Differential Revision: https://phabricator.services.mozilla.com/D53069
--HG--
extra : moz-landing-system : lando
id-ecPublicKey is defined as the OID {iso(1) member-body(2) us(840)
ansi-x962(10045) keyType(2) ecPublicKey(1)}, and is the NSS default, so
remove the override code from CryptoKey.cpp that forced it to the legacy
id-ecDH code.
Differential Revision: https://phabricator.services.mozilla.com/D52570
--HG--
extra : moz-landing-system : lando
Bug 1034856 added support for DH algorithms to WebCrypto, however the final
specification did not choose to include them, making Firefox the only browser
with support.
Bug 1539578 added telemetry to show usage, and it is extremely low (not
appearing on the graphs), which could be expected as Firefox is the only
supporting browser.
Since DH is an ongoing maintenance burden -- and overall cryptanalysis of DH
is progressing -- let's remove it.
Notice to unship went to dev-platform on 29 March 2019 with no objections. [0]
[0] https://groups.google.com/d/msg/mozilla.dev.platform/Ut3-eQmUdWg/O9w1et1aBgAJ
Differential Revision: https://phabricator.services.mozilla.com/D50865
--HG--
extra : moz-landing-system : lando
The current API name is bad: we want it to be read "some background
thread", but it could just as easily be read "a singular background
thread", which would lead people to assume that for:
```
NS_DispatchToBackgroundThread(...);
NS_DispatchToBackgroundThread(...);
```
the dispatched tasks will necessarily run in the order they are
dispatched, which is not the case.
Let's try to head off that interpretation by renaming this function.
Differential Revision: https://phabricator.services.mozilla.com/D51703
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
With the additional tests running, task times increase; I have added one
more test chunk for android mochitest-plain.
These tests were identified from a random sampling of mochitest manifests;
I intend to enable more mochitests in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D48912
--HG--
extra : moz-landing-system : lando
Since background threads get shut down near `xpcom-shutdown-threads`,
there's no need to have `WebCryptoThreadPool` anymore; we can rely on
the background thread dispatching to fail to dispatch our task as
appropriate.
Differential Revision: https://phabricator.services.mozilla.com/D47006
--HG--
extra : moz-landing-system : lando
This is split from the previous changeset since if we include dom/ the file size is too
large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27457
--HG--
extra : moz-landing-system : lando
Our WebCrypto implementation supports using DH as an algorithm in generateKey,
which is not one of the recognized algorithms in the published specification [0].
We should seek to remove it from Firefox, but before we do, it'd be good to
gather some telemetry on whether it's used at all, even in its' non-standard
form.
[0] https://www.w3.org/TR/WebCryptoAPI/#algorithm-overview
Differential Revision: https://phabricator.services.mozilla.com/D25291
--HG--
extra : moz-landing-system : lando
Our WebCrypto implementation supports using DH as an algorithm in generateKey,
which is not one of the recognized algorithms in the published specification [0].
We should seek to remove it from Firefox, but before we do, it'd be good to
gather some telemetry on whether it's used at all, even in its' non-standard
form.
[0] https://www.w3.org/TR/WebCryptoAPI/#algorithm-overview
Differential Revision: https://phabricator.services.mozilla.com/D25291
--HG--
extra : moz-landing-system : lando
Our WebCrypto implementation supports using DH as an algorithm in generateKey,
which is not one of the recognized algorithms in the published specification [0].
We should seek to remove it from Firefox, but before we do, it'd be good to
gather some telemetry on whether it's used at all, even in its' non-standard
form.
[0] https://www.w3.org/TR/WebCryptoAPI/#algorithm-overview
Differential Revision: https://phabricator.services.mozilla.com/D25291
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13046
--HG--
extra : moz-landing-system : lando
There are surprisingly many of them.
(Plus a couple of unnecessary checks after `new` calls that were nearby.)
--HG--
extra : rebase_source : 47b6d5d7c5c99b1b50b396daf7a3b67abfd74fc1
In bug 1364624 we switched over to SRWLock on Windows for our internal
implementation of mozilla::Mutex. This doesn't allow for re-entrancy. The
WebCryptoThreadPool shutdown code has potential for re-entrancy due to the
spinning of the main thread event loop while shutting down the worker threads.
By limiting the scope of the lock protecting mPool during shutdown we can avoid
the re-entrancy. Addtionally we track the shutdown status to avoid dispatching
events once shutdown has started.
--HG--
extra : rebase_source : 6e97a1fbdf4033ef93b3ecbafcf4b7898d9b19af