add a site patch to fix PDK video player versions that are broken on Fennec
Differential Revision: https://phabricator.services.mozilla.com/D31122
--HG--
extra : moz-landing-system : lando
A Proguard update in Bug 1550596 optimized away the WebAuthn methods, but
there's a convenient ReflectionTarget defined to say 'hey, don't do that.'
Differential Revision: https://phabricator.services.mozilla.com/D31693
--HG--
extra : moz-landing-system : lando
`mach run` as it is doesn't really parallel `mach run` on Desktop;
this makes it a little closer more fully featured. The underlying
functionality is all there in layers of mozharness; let's make it
easier to get to.
Differential Revision: https://phabricator.services.mozilla.com/D18292
--HG--
extra : moz-landing-system : lando
This just separates out the Android definitions into
mobile/android/mach_commands.py. There was vestigial support for
running on Android with debuggers, but it was for wiring up JimDB,
which is no longer supported and in fact hasn't worked on actual
devices for a very long time. (The new flow for running on Android
under a debugger goes through the Android Studio hybrid debugger.)
Differential Revision: https://phabricator.services.mozilla.com/D18291
--HG--
extra : moz-landing-system : lando
This fixes a crash in `browser.tabs.update` when used with WebExtension pages.
Differential Revision: https://phabricator.services.mozilla.com/D31453
--HG--
extra : moz-landing-system : lando
This fixes a crash in `browser.tabs.update` when used with WebExtension pages.
Differential Revision: https://phabricator.services.mozilla.com/D31453
--HG--
extra : moz-landing-system : lando
The mozilla::java::WebAuthnTokenManager asserts its return-to-C++ callbacks as
being run on the main Android UI thread, but since these methods are called
directly from the Fido2PendingIntent listeners, there's no guarantee of that.
We don't actually care what thread was tasked with returning us data, just that
it gets done, so let's not assert the thread here.
Differential Revision: https://phabricator.services.mozilla.com/D31497
--HG--
extra : moz-landing-system : lando
Some minor refactor to make it possible to remove android.speech dependencies using Proguard
Differential Revision: https://phabricator.services.mozilla.com/D27612
--HG--
extra : moz-landing-system : lando
Some minor refactor to make it possible to remove android.speech dependencies using Proguard
Differential Revision: https://phabricator.services.mozilla.com/D27612
--HG--
extra : moz-landing-system : lando
Now checking for private mode in order to ignore any permissions that had been set in previous sessions.
Differential Revision: https://phabricator.services.mozilla.com/D26702
--HG--
extra : moz-landing-system : lando
Requesting reviewers based on `hg blame` output and general knowledge of who is working on the project. I hope that's okay.
Differential Revision: https://phabricator.services.mozilla.com/D30580
--HG--
extra : moz-landing-system : lando
Checking extension.shutdownReason for any purpose other than detecting
app shutdown is unreliable, since actions such as disabing, uninstalling,
etc. may happen ito an extension after it has shut down. Remove the
temptation for api authors to write incorrect code by removing
extension.shutdownReason and replacing it with an isAppShutdown boolean
passed to shutdown handlers.
Differential Revision: https://phabricator.services.mozilla.com/D30605
--HG--
extra : rebase_source : 07ff7710757150d011fec6bc3ed134c6509e9a12
The problem from bug 1278581 was that hiding the URL bar in response to a
key-down event (for the Enter key) would then lead to the corresponding key-up
event then ending up in GeckoView, thereby confusing the "last user activity"
tracking.
It appears that this only happens with key events received through the
regular OnKeyListener, but not with events coming from the OnKeyPreImeListener.
On devices where pressing Enter in the URL bar would transmit the key event
through the latter mechanism, this means that because the key-up event we wanted
to suppress in BrowserApp never arrived, we would instead suppress whatever
other key event would arrive next, e.g. possibly a press of the back button.
This would lead to the observed behaviour where after entering an URL, the first
subsequent press of the back button might then be ignored.
Differential Revision: https://phabricator.services.mozilla.com/D30573
--HG--
extra : moz-landing-system : lando