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
AccessibleNode::GetParentObject is a non-overriding final virtual function. GetParentObject is a common virtual function in many DOM classes, but AccessibleNode does not derive from any base classes that define virtual GetParentObject or have any derived classes of its own.
WebCryptoTask::CalculateResult and CallCallback are non-overriding final virtual functions that mirror virtual function names in the CryptoTask class, even though WebCryptoTask does not actually derive from CryptoTask.
nsWindowBase::GetWindowHandle is a non-overriding final virtual function. The only other function called GetWindowHandle is MouseScrollHandler::EventInfo::GetWindowHandle, which is not related to the nsWindowBase class.
MozReview-Commit-ID: 4ldSAyP3ZpP
--HG--
extra : rebase_source : cd6fea309c042183db59653ed39e1e63b70c6a63
As of bug 1417680, the NSS shutdown tracking infrastructure is unnecessary (and
does nothing anyway). This series of changesets removes the remaining pieces in
a way that is hopefully easy to confirm is correct.
MozReview-Commit-ID: 8Y5wpsyNlGc
--HG--
extra : rebase_source : ef6b481510d949e404a4ef5615097d66e566c947
Summary:
After calling mResult.SetLength(mData.Length() + 16) we should check that the
integer addition didn't overflow. It seems at the moment impossible to create
ArrayBuffers of size >= 0x0xfffffff0, however adding a check here doesn't hurt.
mResult.Length() is passed to the PK11 API functions as a maxOut parameter and
/should/ be checked by the softoken crypto algorithm implementations. AES-ECB
and AES-GCM seem to do that correctly.
Reviewers: keeler
Reviewed By: keeler
Subscribers: mcote, ttaubert, jcj, keeler
Bug #: 1413841
Differential Revision: https://phabricator.services.mozilla.com/D188
This was automatically generated by the script modeline.py.
MozReview-Commit-ID: BgulzkGteAL
--HG--
extra : rebase_source : a4b9d16a4c06c4e85d7d85f485221b1e4ebdfede
The Web Authentication types, by spec, return ArrayBuffer objects, while we
were returning a concrete Uint8Array. This is a fairly straightforward change
to add functionality to CryptoBuffer and the WebIDL types, however it's a
substantial change to the tests.
Frankly, the tests just could use another pass of clean-up now, since this is
a lot of relative ugliness added in. I refactored tab_webauthn_success.html
pretty heavily -- since it was also fairly ugly to start -- but I decided to go
with a lighter touch on the other tests.
MozReview-Commit-ID: 9vb1wdLo3SI
--HG--
rename : dom/webauthn/tests/browser/frame_webauthn_success.html => dom/webauthn/tests/browser/tab_webauthn_success.html
extra : rebase_source : bd2bc326c6bb5e00929b14c7aae66eba335c0605
Changes to Promise tests designed to test .then(null) have been reverted, and the browser/extensions directory was excluded because the projects it contains have a separate process for accepting changes.
MozReview-Commit-ID: 1buqgX1EP4P
--HG--
extra : rebase_source : 3a9ea310d3e4a8642aabbc10636c04bfe2e77070
