The Java ExoPlayer that we use for HLS support on Android does an accurate
seek, that is, it seeks to the frame at the seek target. This may not be a
keyframe, which we can start decoding at. So change the HLS seek to seek 2
seconds behind the seek target, and drop all frames up to the next keyframe.
This means that after a seek the HLSDemuxer will output a keyframe, and
hopefully (but we can't guarantee of course) it will lie behind the actual seek
target.
We also need to purge the GeckoHlsVideoRenderer's queue of frames which it
is holding onto in order to determine their durations, otherwise after a seek,
we'll get output from this queue of frames. That is, after a seek we would still
get a few frames from the old playback position.
This seek case is particularly problematic as we aggressively shutdown decoders
when the media is paused, including right after the load reaches
loadedmetadata, and we need to seek in order to recover from going dormant.
Differential Revision: https://phabricator.services.mozilla.com/D33254
--HG--
extra : moz-landing-system : lando
Right now there's some duplicated code with the focus manager and the
DOMWindowFocus event.
Android didn't handle the new framefocusrequested event, so the test-cases in
bug 416771 still didn't work there.
I think using the focus manager codepath everywhere is preferable. I confirmed
manually that the stuff that sent DOMWindowFocus events still works as expected
with this patch (i.e., switching to the right tab when you click on a
notification, etc.).
This fixes it so that it works in Fennec, and it sends the focus events right in
GeckoView Example (i.e., we get here[1] properly).
The snippet that Snorp provided on IRC to implement the "bring activity to
front" stuff (`startActivity(getIntent())`) didn't actually work for me, but I
confirmed that the right message is sent when the focus is requested, and that
we get there.
[1]: https://searchfox.org/mozilla-central/rev/952521e6164ddffa3f34bc8cfa5a81afc5b859c4/mobile/android/geckoview_example/src/main/java/org/mozilla/geckoview_example/GeckoViewActivity.java#503
Depends on D32353
Differential Revision: https://phabricator.services.mozilla.com/D32354
--HG--
extra : moz-landing-system : lando
Bug 1303806 moved `GeckoJavaSampler` to be Fennec-only as part of a general push
to slim GeckoView down. But there is no reason to restrict to Fennec and it is useful
for other non-Fennec GeckoView vehicles.
This patch moves the `GeckoJavaSampler` inside `geckoview` and changes profiler
code to make Java sampling work in both GeckoView and Fennec.
Depends on D33522
Differential Revision: https://phabricator.services.mozilla.com/D33502
--HG--
rename : mobile/android/base/java/org/mozilla/gecko/GeckoJavaSampler.java => mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoJavaSampler.java
extra : moz-landing-system : lando
This is to allow us to detect the enabling and disabling of recording so that we can notify the embedding application of the change in status.
Differential Revision: https://phabricator.services.mozilla.com/D31072
--HG--
extra : moz-landing-system : lando
Whenever we switch processes in GeckoView we didn't inject frameScripts.
This change adds a new method `loadInitFrameScript` that is called whenever a
module's new browser is attached to a window so that the frame script is loaded
correctly into the new browser.
This fixes a bug in WebExtension pages where the WebExtension Process Script
would never be notified of a new WebExtension page window, breaking privileged
APIs.
Differential Revision: https://phabricator.services.mozilla.com/D32148
--HG--
extra : moz-landing-system : lando
WebExtension can always open their respective WebExtension pages even when the
WebExtension page is not content accessible.
However, this is not true for `tabs.update`, which couldn't link to
WebExtension pages at all.
Similarly, a user should be able to open a WebExtension page directly by typing
the URL.
To fix the above problems we pass the correct `triggeringPrincipal` when
loading such URIs. This change also makes URI typed by the user not use the
`systemPrincipal` anymore but a more restrictive codebase principal local to
the page that's being typed to avoid unintended side-effects. This also makes
the triggering URI always the page for these privileged pages, so we need to
adjust some tests to account for that by loading unprivileged `http` pages
instead.
Differential Revision: https://phabricator.services.mozilla.com/D32149
--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
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
Support using the Google Play-provided FIDO2 API for Web Authentication.
FIDO U2F API support is being handled subsequently in Bug 1550625.
This patch uses the privileged APIs and thus will only work on Fennec Nightly, Beta, and Release builds.
Differential Revision: https://phabricator.services.mozilla.com/D1148
--HG--
extra : moz-landing-system : lando
Update this junit test with this bug's test case. Actually, autofill_userpass
doesn't work with the latest GV, so I should like to update this to fix focus
timing.
Also, this does't run on our test infra because this requires API 26.
Differential Revision: https://phabricator.services.mozilla.com/D30178
--HG--
extra : moz-landing-system : lando
This is more related to telephony than anything else, and are more suited to
real telephony app.
Differential Revision: https://phabricator.services.mozilla.com/D30071
--HG--
extra : moz-landing-system : lando
