Add test paintStatusReset() to ContentDelegateTest, which asserts that
onPaintStatusReset() is called after GeckoSession.setActive(false).
Add test capturePixelsSessionDeactivatedActivated() to ScreenshotTest, which
asserts that capturePixels() is successful if called when the session is
deactivated then reactivated, after waiting for the onPaintStatusReset() and
onFirstContentfulPaint() callbacks.
Differential Revision: https://phabricator.services.mozilla.com/D87463
Android-components listens to the GeckoView callback onFirstContentfulPaint to
track whether a contentful paint has occured, in order to decide when to
thumbnail a tab. Currently this gets fired once per tab.
However, when the GeckoSession is paused, we clear cached resources in the
compositor. This means that when the session is resumed, the compositor does not
have the necessary information to render the page (such as painted content
buffers, or the webrender display list). Because android-components attempts to
capture a new thumbnail immediately upon resuming, it ends up capturing a blank
thumbnail.
To fix this, add a new callback onPaintStatusReset() which is invoked when the
cached resources are cleared. Android-components can listen for this to be
informed when the contentful paint is no longer visible. It can then wait until
the subsequent contentful paint occurs before capturing the thumbnail.
Differential Revision: https://phabricator.services.mozilla.com/D87341
Do this by spinning the event loop until we've done the clone for
preview as appropriate.
This should be much less risky than finishing the previous patches
which would still be nice, but realistically landing them for 81 is not
going to happen.
This just returns without doing nothing in a couple cases, like when
there's already another modal dialog or such. That seems acceptable to
me, it's not clear what better way to do would be.
Differential Revision: https://phabricator.services.mozilla.com/D87484
This will make clang put reproducers for compiler crashes into the artifacts upload directory. We've been doing this on other platforms for a while but it seems Android was left out.
Differential Revision: https://phabricator.services.mozilla.com/D87482
Before this patch, we were always waiting for libxul to load because we were
starting the JVM from libxul. But we needed to start this a lot earlier. Also
thinking that JVM profiler can actually run without the gecko side, we can
start this a lot earlier than we currently start. We need to check the
environmnet variables to be able to start the profiler. It looks like the best
place to do it is inside the GeckoThread.run method.
We have also a similar code for Java debugger, with maybeWaitForJavaDebugger
name. This fucntion does similar things in terms of enviromnent variable
handling.
Differential Revision: https://phabricator.services.mozilla.com/D87069
After moving to actors it will be common to define both a onInit phase and a
onEnable phase for actors. We don't handle having both phases contain a
main-process script so we should check that.
Differential Revision: https://phabricator.services.mozilla.com/D87119
This commit splits the `GeckoViewContent` actor in two parts:
- `GeckoViewContent` proper, which runs unconditionally and handles code that
needs to run regardless of whether we have a delegate installed or not.
- `ContentDelegate` which runs only when a delegate is first installed.
This emulates the previous paradigm of installing some listeners only when the
delegate is installed.
I discussed it briefly with :nika and she thinks that splitting modules in two
should not affect performance in a measurable manner.
Note that actors cannot be registered per-window, so we will get messages from
all windows as long as one content delegate is registered.
Differential Revision: https://phabricator.services.mozilla.com/D86776
This patch adds a "named" EventDispatcher that can be accessed on both java and
javascript by calling
```
EventDispatcher.byName(...)
```
A named EventDispatcher will receive messages only from it's counterpart with
the same name and can be used to implement bidirectional communication like
WebExtension ports.
Differential Revision: https://phabricator.services.mozilla.com/D84260
This commit splits the `GeckoViewContent` actor in two parts:
- `GeckoViewContent` proper, which runs unconditionally and handles code that
needs to run regardless of whether we have a delegate installed or not.
- `ContentDelegate` which runs only when a delegate is first installed.
This emulates the previous paradigm of installing some listeners only when the
delegate is installed.
I discussed it briefly with :nika and she thinks that splitting modules in two
should not affect performance in a measurable manner.
Note that actors cannot be registered per-window, so we will get messages from
all windows as long as one content delegate is registered.
Differential Revision: https://phabricator.services.mozilla.com/D86776
This patch adds a "named" EventDispatcher that can be accessed on both java and
javascript by calling
```
EventDispatcher.byName(...)
```
A named EventDispatcher will receive messages only from it's counterpart with
the same name and can be used to implement bidirectional communication like
WebExtension ports.
Differential Revision: https://phabricator.services.mozilla.com/D84260
The threading model described in the javadoc (ExoPlayer.java#92 in tree)
requires that the player is accessed from a single thread. However current
GeckoHlsPlayer implementation violates this rule and uses the player from
Gecko main thread and other media task queues. Introduce methods to execute
code asynchronously and synchronously for GeckoHlsPlayer to follows the rule.
Also add comments documenting thread usages for some instance variables and
assertions in the begining of methods that need to be on the player thread
to help debugging.
Differential Revision: https://phabricator.services.mozilla.com/D85668