The key here is to test the type of the variable declaration for being a
smartptr type, instead of testing the type of the variable _use_.
Differential Revision: https://phabricator.services.mozilla.com/D65581
--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
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
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
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
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
There are two related problems this patch is trying to address. The first, and
simpler, one is bug 1553436: there are websites that use existing variables and
functions named "u2f" and adding a non-replaceable readonly property with that
name on Window breaks them. The fix for this is straightforward: mark the
property [Replaceable].
The second problem, covered by bug 1551282, involves sites that use the Google
U2F polyfill. The relevant parts of that polyfill look like this:
'use strict';
var u2f = u2f || {};
u2f.register = some_function_that_only_works_right_in_Chrome;
u2f.sign = some_function_that_only_works_right_in_Chrome;
The failure mode for that code before this fix is that the assignment to "u2f"
throws because it's a readonly property and we're in strict mode, so any code
the page concatenates in the same file after the polyfill does not get run.
That's what bug 1551282 is about. The [Replaceable] annotation fixes that
issue, because now the polyfill gets the value of window.u2f and then redefines
the property (via the [Replaceable] setter) to be a value property with that
value. So far, so good.
But then we need to prevent the sets of u2f.register
and u2f.sign from taking effect, because if they are allowed to happen, the
actual sign/register functionality on the page will not work in Firefox. We
can't just make the properties readonly, because then the sets will throw due
to being in strict mode, and we still have bug 1551282. The proposed fix is to
make these accessor properties with a no-op setter, which is exactly what
[LenientSetter] gives us.
The rest of the patch is just setting up infrastructure for generating the
normal bits we would generate if "sign" and "register" were methods and using
that to create the JSFunctions at the point when the getter is called. The
JSFunctions then get cached on the u2f instance object.
Differential Revision: https://phabricator.services.mozilla.com/D32357
--HG--
extra : moz-landing-system : lando
There are two related problems this patch is trying to address. The first, and
simpler, one is bug 1553436: there are websites that use existing variables and
functions named "u2f" and adding a non-replaceable readonly property with that
name on Window breaks them. The fix for this is straightforward: mark the
property [Replaceable].
The second problem, covered by bug 1551282, involves sites that use the Google
U2F polyfill. The relevant parts of that polyfill look like this:
'use strict';
var u2f = u2f || {};
u2f.register = some_function_that_only_works_right_in_Chrome;
u2f.sign = some_function_that_only_works_right_in_Chrome;
The failure mode for that code before this fix is that the assignment to "u2f"
throws because it's a readonly property and we're in strict mode, so any code
the page concatenates in the same file after the polyfill does not get run.
That's what bug 1551282 is about. The [Replaceable] annotation fixes that
issue, because now the polyfill gets the value of window.u2f and then redefines
the property (via the [Replaceable] setter) to be a value property with that
value. So far, so good.
But then we need to prevent the sets of u2f.register
and u2f.sign from taking effect, because if they are allowed to happen, the
actual sign/register functionality on the page will not work in Firefox. We
can't just make the properties readonly, because then the sets will throw due
to being in strict mode, and we still have bug 1551282. The proposed fix is to
make these accessor properties with a no-op setter, which is exactly what
[LenientSetter] gives us.
The rest of the patch is just setting up infrastructure for generating the
normal bits we would generate if "sign" and "register" were methods and using
that to create the JSFunctions at the point when the getter is called. The
JSFunctions then get cached on the u2f instance object.
Differential Revision: https://phabricator.services.mozilla.com/D32357
--HG--
extra : moz-landing-system : lando
The new Android functionality can conflict with the tests' expected behavior,
so it should be generally disabled, like the Rust module.
Differential Revision: https://phabricator.services.mozilla.com/D31266
--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
Before this patch, the WebAuthnManager/U2F destructors would call MaybeReject on
existing transaction promises. Doing this leaks JS objects. If
WebAuthnManager/U2F are being destructed, though, the window is going away, so
it shouldn't be necessary to reject any outstanding promises. This patch just
clears the transactions.
Differential Revision: https://phabricator.services.mozilla.com/D27346
--HG--
extra : moz-landing-system : lando
This stack is pretty clear that calling StopListeningForVisibilityEvents
(via ClearTransaction) is a no-go from the cycle collector. We need to instead
just do the minimum version of bug 1540378, just reset mTransaction and move on.
Differential Revision: https://phabricator.services.mozilla.com/D25804
--HG--
extra : moz-landing-system : lando
In Bug 1448408 ("Don't listen to visibility events"), it became possible to
close a tab without a visibility event to cause transactions to cancel. This
is a longstanding bug that was covered up by the visibility events. This patch
updates the cycle collection code to ensure that transactions get cleared out
safely, and we don't proceed to RejectTransaction (and subsequent code) on
already-cycle-collected objects.
Differential Revision: https://phabricator.services.mozilla.com/D25641
--HG--
extra : moz-landing-system : lando
The published recommendation of L1 for WebAuthn changed the visibility/focus
listening behaviors to a SHOULD [1], and Chromium, for reasons like our SoftU2F
bug [0], opted to not interrupt on tabswitch/visibility change.
Let's do the same thing.
This changes the visibility mechanism to set a flag on an ongoing transaction,
and then, upon multiple calls to the FIDO/U2F functions, only aborts if
visibility had changed. Otherwise, subsequent callers return early.
This is harder to explain than it is really to use as a user. I think. At least,
my testing feels natural when I'm working within two windows, both potentially
prompting WebAuthn.
Note: This also affects FIDO U2F API.
[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1448408#c0
[1] https://www.w3.org/TR/webauthn-1/#abortoperation
Differential Revision: https://phabricator.services.mozilla.com/D25160
--HG--
extra : moz-landing-system : lando
Per the thread "Intent-to-Ship: Backward-Compatibility FIDO U2F support for
Google Accounts" on dev-platform [0], this bug is to:
1. Enable the security.webauth.u2f by default, to ride the trains
2. Remove the aOp == U2FOperation::Sign check from EvaluateAppID in
WebAuthnUtil.cpp, permitting the Google override to work for Register as
well as Sign.
This would enable Firefox users to use FIDO U2F API on most all sites, subject
to the algorithm limitations discussed in the section "Thorny issues in
enabling our FIDO U2F API implementation" of that post.
[0] https://groups.google.com/d/msg/mozilla.dev.platform/q5cj38hGTEA/lC834665BQAJ
Differential Revision: https://phabricator.services.mozilla.com/D25241
--HG--
extra : moz-landing-system : lando
The old code for member method calls did the following:
1) Find the member method calls.
2) Look at their "this" expression.
3) If the "this" is an operator call, check for any of the arguments of the
operator call being invalid.
4) Otherwise (if not an operator call) check for the "this" value being
invalid.
This wasn't right, because the "is invalid" check checks the type and only
considers refcounted things. So if the code looked something like
"foo[i]->call_method()", we would look at the types of "foo" and "i" and
determine that none of those are refcounted types so there is nothing invalid
here (since "foo" is some sort of array type and "i" is an integer). The new
setup just checks whether the "this" value is invalid, which does the type
check on the "this" value itself; in the "foo[i]->call_method()" case on
"foo[i]". We then adjust the exclusions in InvalidArg to consider operator->
on known-live things valid, to allow the thing that we were really trying to
accomplish with the "check for an operator call" bits:
"stackRefPtr->some_method()".
The test coverage being added for the made-up TArray type is meant to catch
things like the geolocation issue that was being hidden by the buggy behavior.
I'm not using nsTArray itself because some header included by nsTArray.h
tries to define operator new/delete bits inline and that triggers warnings that
then cause a clang-plugin test failure, because they're unexpected.
Differential Revision: https://phabricator.services.mozilla.com/D24117
--HG--
extra : moz-landing-system : lando
The old code for member method calls did the following:
1) Find the member method calls.
2) Look at their "this" expression.
3) If the "this" is an operator call, check for any of the arguments of the
operator call being invalid.
4) Otherwise (if not an operator call) check for the "this" value being
invalid.
This wasn't right, because the "is invalid" check checks the type and only
considers refcounted things. So if the code looked something like
"foo[i]->call_method()", we would look at the types of "foo" and "i" and
determine that none of those are refcounted types so there is nothing invalid
here (since "foo" is some sort of array type and "i" is an integer). The new
setup just checks whether the "this" value is invalid, which does the type
check on the "this" value itself; in the "foo[i]->call_method()" case on
"foo[i]". We then adjust the exclusions in InvalidArg to consider operator->
on known-live things valid, to allow the thing that we were really trying to
accomplish with the "check for an operator call" bits:
"stackRefPtr->some_method()".
The test coverage being added for the made-up TArray type is meant to catch
things like the geolocation issue that was being hidden by the buggy behavior.
I'm not using nsTArray itself because some header included by nsTArray.h
tries to define operator new/delete bits inline and that triggers warnings that
then cause a clang-plugin test failure, because they're unexpected.
Differential Revision: https://phabricator.services.mozilla.com/D24117
--HG--
extra : moz-landing-system : lando
There are few things that are either Fennec-specific or don't work
currently under GeckoView w/ e10s under TestRunnerActivity. Disable
these so we can get some testing going in automation.
This also replaces 'isFennec' with the more correct 'is_fennec'.
Differential Revision: https://phabricator.services.mozilla.com/D19016
--HG--
extra : moz-landing-system : lando
J.C. Jones
Mark Banner
Boris Zbarsky
MahakBansal
Tooru Fujisawa
Kris Maglione
shindli
Noemi Erli
Daniel Varga
Gabriele Svelto
Dorel Luca
Victor Porof
Brian Grinstead
Dana Keeler
Brindusan Cristian
Alex Gaynor
Sylvestre Ledru
Akshay Kumar
Ryan Hunt
James Willcox