In bug 1992573 we are seeing a lot of failures when attempting to launch
the GPU process on Android. If we had previously had a stable GPU
process we now crash the parent process rather than disabling the GPU
process.
This patch ensures that we log any java exception messages to
gfxCriticalNote when we fail to launch the GPU process. This will
hopefully mean that the crash reports will contain useful information
regarding why the process failed to launch.
Differential Revision: https://phabricator.services.mozilla.com/D267763
MOZ_RUNINIT => initialized at runtime
MOZ_CONSTINIT => initialized at compile time
MOZ_GLOBINIT => initialized either at runtime or compile time, depending on template parameter, macro parameter etc
This annotation is only understood by our clang-tidy plugin. It has no
effect on regular compilation.
Differential Revision: https://phabricator.services.mozilla.com/D223341
This is actually the removal of two different deprecated geckoview adapters:
GV Persistence, and GV Streaming Telemetry.
GVP has been out of use for four years. GVST has had all of its data migrated
to direct Glean use back in February and has been deprecated for two versions.
Differential Revision: https://phabricator.services.mozilla.com/D207475
This implementation supports
- HTML drag & drop API.
- Drop and drop for text/plain or text/html from/to external application.
Differential Revision: https://phabricator.services.mozilla.com/D197330
The detection is inadequate and the workaround does not work on all
versions of Android. Later patches in this series will replace this
with something better.
Differential Revision: https://phabricator.services.mozilla.com/D176719
The detection is inadequate and the workaround does not work on all
versions of Android. Later patches in this series will replace this
with something better.
Differential Revision: https://phabricator.services.mozilla.com/D176719
On some Android devices (predominantly Huawei devices running Android
9 or below) we are seeing large numbers of crashes due to the
compositor being unable to create an EGL surface to render in to. From
local testing, this appears to be due to the Surface we are being
provided from the SurfaceView being in an "abandoned"
state. Presumably this is due to an operating system bug - the Surface
is valid at the time of the surfaceChanged() callback, but becomes
abandoned moments later despite surfaceDestroyed() not being called.
We are able to detect when the Surface is in such a state from C++
code by calling ANativeWindow_getWidth(), as that will return a
negative value to indicate an error.
This patch uses this method to check whether the Surface is in such a
state prior to resuming the compositor. If so, rather than immediately
resuming the compositor it instead toggles the SurfaceView's
visibility. This tricks the SurfaceView in to providing a new (and
hopefully valid) Surface, which will in turn resume the compositor via
the surfaceChanged callback.
Differential Revision: https://phabricator.services.mozilla.com/D151479
`android.location.Location.getTime()` will return the acquired location time
that depends on location service. But `maximumAge` will be calculated by
current time (`PR_Now()`). So if the acquired time is old time,
`nsGeolocationRequest::SendLocation` won't send the location due to too old
(`isTooOld=true` in `nsGeolocationRequest::SendLocation`).
Like other platforms, we should pass PR_Now as the location time instead.
Also, GVE sometimes hits debug assertion since heading and/or speed aren't
expected value, so this patch fixes this situation.
Differential Revision: https://phabricator.services.mozilla.com/D148452
If the android system kills the GPU process to free memory while the
app is in the background, then we want to avoid immediately restarting
the GPU process.
To achieve this, we make GPUProcessManager keep track of whether it is
in the foreground or background. If HandleProcessLost() gets called
while in the background then we destroy the existing compositor
sessions as before, but return early instead of immediately
relaunching the process. If the process has not been launched when the
app later gets foregrounded then we do so then.
The final part of HandleProcessLost(), which reinitializes the content
bridges and emits the "compositor-reinitialized" signal, has been
moved to a new function ReinitializeRendering(). If the GPU process
has been disabled, this gets called as-before at the end of
HandleProcessLost(). When the GPU process is enabled, however, we now
call it from OnProcessLaunchComplete(), so that it gets called
regardless of whether the process is launched immediately or after a
delay.
While we're here, rename the functions RebuildRemoteSessions() and
RebuildInProcessSessions() to DestroyRemoteCompositorSessions() and
DestroyInProcessCompositorSessions(), to better reflect what they
actually do: the "rebuilding" part occurs later on. Also update the
mega-comment documenting the restart sequence, as it was somewhat
outdated.
In case a caller of EnsureGPUReady() gets called before the foreground
signal arrives (eg in nsBaseWidget::CreateCompositorSession() due to a
refresh tick paint), make EnsureGPUReady() launch the GPU process
itself if the GPU process is enabled but not yet launched. As a
consequence, to avoid launching the GPU process unnecessarily, change
a couple callers of EnsureGPUReady() to simply check whether the
process is enabled instead.
Additionally, guard against a null pointer deref if the compositor has
been destroyed when the widget receives a memory pressure event. This
is now more likely to occur as there may be a gap between the
compositor being destroyed and recreated.
Differential Revision: https://phabricator.services.mozilla.com/D139042
Make the ScreenOrientation part of the screen struct, as it should. Stop
using HAL to propagate just screen orientation updates, use the more
general screen manager.
Instead of HAL observers, add a simple observer service notification,
and clean a bunch of the code.
This will simplify bug 1754802 a bit, and is generally simpler.
Shouldn't change behavior. I've tested the events and some common
orientation locking use cases like Youtube, and they behave the same.
Differential Revision: https://phabricator.services.mozilla.com/D138477
On Android we use SurfaceTextures and Surfaces to render video and
webgl. These are allocated by content processes using the
SurfaceAllocator, which connects to a SurfaceAllocatorService running
in the parent process. The content process renders in to the
Surface (by attaching it to a media codec, or creating a GL context
with it for webgl), and the compositor renders the output
SurfaceTexture in the parent process.
With the GPU process this poses a difficulty, as we need to allocate
SurfaceTextures in either the parent process or GPU process, depending
on whether the GPU process is enabled. Additionally, we don't want to
run extra android Services in child processes such as the GPU process,
as process management is tricky and we want to contain it to a single
place.
This patch makes it so that SurfaceAllocatorService is not really an
android Service any more, just an singleton object which implements
the ISurfaceAllocator interface. It is renamed to
RemoteSurfaceAllocator to reflect that. A new method
getProcessManager() is added to the IProcessManager interface, which
child processes can use to fetch the surface allocator. It returns
either the parent process instance, or fetches the instance from the
GPU process using IChildProcess.getSurfaceAllocator().
Differential Revision: https://phabricator.services.mozilla.com/D133107
AFAICT, all roads lead though [`nsAppStartup::Quit`](https://searchfox.org/mozilla-central/rev/0fec57c05d3996cc00c55a66f20dd5793a9bfb5d/toolkit/components/startup/nsAppStartup.cpp#448),
which is responsible for firing the `"quit-application"` observer notification
and then posting the `nsAppExitEvent` that causes the `nsAppShell` to break out
of its event loop and proceed with shutdown.
If we trigger a native crash in the observer, we should be able to capture a
symbolicated stack of whatever called `Quit`. We might as well force-crash
anyway, since AC is going to throw an exception regardless...
Before we crash, we annotate the current `GeckoThread` state to enable us to
find out whether we were fully initialized at the time of the shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D122256
AFAICT, all roads lead though [`nsAppStartup::Quit`](https://searchfox.org/mozilla-central/rev/0fec57c05d3996cc00c55a66f20dd5793a9bfb5d/toolkit/components/startup/nsAppStartup.cpp#448),
which is responsible for firing the `"quit-application"` observer notification
and then posting the `nsAppExitEvent` that causes the `nsAppShell` to break out
of its event loop and proceed with shutdown.
If we trigger a native crash in the observer, we should be able to capture a
symbolicated stack of whatever called `Quit`. We might as well force-crash
anyway, since AC is going to throw an exception regardless...
Before we crash, we annotate the current `GeckoThread` state to enable us to
find out whether we were fully initialized at the time of the shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D122256
XPCOM complains when events are dispatched during shutdown. Since we're
shutting down, there's no really any point in dispatching these messages
anyway, so we can safely ignore them.
Differential Revision: https://phabricator.services.mozilla.com/D113203
nsBaseAppShell already listens to xpcom-shutdown and calls |Exit| when it
receives it so we don't need to also listen for it in nsAppShell (which causes
two calls to xpcom-shutdown instead of one).
Differential Revision: https://phabricator.services.mozilla.com/D106209
nsBaseAppShell already listens to xpcom-shutdown and calls |Exit| when it
receives it so we don't need to also listen for it in nsAppShell (which causes
two calls to xpcom-shutdown instead of one).
Differential Revision: https://phabricator.services.mozilla.com/D106209
serge-sans-paille