The semantics of what Firefox implemented for the AppID extension for WebAuthn
were wrong. Notably: It was always emitted if the extension were used, and
always set to `true`. The specification has more nuance so that RPs can use
that result to determine what to validate against.
As a reminder since it's been a while, this change has impacts to the WebAuthn
Token Manager layer, so there's duplicative changes in the soft token and in
the HID token, _and the automated tests only test the soft token_. Manual
testing using webauthn.bin.coffee and other test sites are needed to verify
behavior in U2FHIDTokenManager.
Differential Revision: https://phabricator.services.mozilla.com/D79568
Before P1, GetCurrentThreadSerialEventTarget would have always returned the same data as NS_GetCurrentThread, making the comment incorrect Now it will properly return the running TaskQueue if any.
This change of name more clearly exposes what they are doing, as we aren't always dealing with threads directly; but a nsISerialEventTarget
Differential Revision: https://phabricator.services.mozilla.com/D80354
In this bug we're moving away from monolithic JNI headers to class-specific
headers so that we don't have to rebuild the world every time we make a change
to a JNI interface.
Differential Revision: https://phabricator.services.mozilla.com/D75378
The rejection process consumes the ErrorResult, so an rvalue reference is the honest thing here.
Differential Revision: https://phabricator.services.mozilla.com/D62632
--HG--
extra : moz-landing-system : lando
The test changes are for the following reasons:
1) Removing the "empty ArrayBuffer" test: I don't see anything obvious in the
spec that would cause that to reject before prompting the user, and in fact it
does not do that in browsers. All browsers time out on that line.
2) Removing the "name is object" test: This test is wrong. Passing {} where a
string is expected in IDL will come out as the string "[object Object]" on the
other side, and that seems like a perfectly valid name.
3) Removing the "name is null" test: This test is wrong. Passing null where a
string is expected in IDL will come out as the string "null" on the other side,
and that seems like a perfectly valid name.
4) Removing the "name is empty" test: I don't see anything obvious in the
spec that would cause that to reject before prompting the user.
5) Removing the various "icon is whatever" tests: I don't see anything obvious in the
spec that would cause that to reject before prompting the user.
6) Removing the various "displayName is whatever" tests: the same reasoning as
for the coresponding "name is whatever" tests applies.
Differential Revision: https://phabricator.services.mozilla.com/D60685
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
