It's only meaningfully read in two places:
* WebRender fallback code.
* Some widget DEBUG-only code, which on Linux is ifdef'd and on Windows does
some rather sketchy things like sleeping for 30ms
So I think it should be ok to remove, since WR fallback has its own flashing
pref as well, IIUC.
Differential Revision: https://phabricator.services.mozilla.com/D132313
See the comments as for why. If as a user you want to get this behavior
you could put something like:
:root { color-scheme: light dark }
in a user stylesheet, but that could cause the same contrast issues the
allow-gtk-dark-theme pref has now.
Differential Revision: https://phabricator.services.mozilla.com/D132361
This patch ensures that, following a GPU process crash, we
re-initialize the compositor and resume painting on Android.
nsWindow::GetWindowRenderer() is made to always reinitialize the
window renderer if there is none, like on other platforms. We
therefore no longer need to track whether webrender is being disabled,
as this is no longer a special case.
Previously we started the compositor as initially paused in
nsBaseWidget::CreateCompositorSession only if the widget did not yet
have a surface. Now we must unconditionally (re)start it as initially
paused, as even though the widget in the parent process may have a
surface, we will not have been able to send it to the GPU process
yet. We will send the surface to the compositor once control flow
returns to nsWindow::CreateLayerManager, where we will also now resume
the compositor if required.
Finally, we must ensure that we manually trigger a paint, both in the
parent and content processes. On other platforms this occurs
automatically following a GPU process loss through various refresh
driver events. On Android, however, nothing causes the refresh driver
to paint by itself, and we cannot receive input without first
initializing our APZ controllers, which does not happen until the
compositor receives a display list. We therefore must manually
schedule a paint. We do so from nsWindow::NotifyCompositorSessionLost
for the parent process, and BrowserChild::ReinitRendering for content
processes.
Differential Revision: https://phabricator.services.mozilla.com/D131232
Declare a GPU process and corresponding Service in the
AndroidManifest. This is of a new class GeckoServiceGpuProcess which
inherits from GeckoServiceChildProcess, and provides a binder
interface ICompositorSurfaceManager which allows the parent process to
set the compositor Surface for a given widget ID, and the compositor
in the GPU process to look up the Surface for a widget ID. The
ICompositorSurfaceManager interface is exposed to the parent process
through a new method getCompositorSurfaceManager() in the
IChildProcess interface.
Add a new connection type for GPU processes to GeckoProcessManager,
along with a function to look up the GPU process connection and fetch
the ICompositorSurfaceManager binder. When the GPU process is launched
we store the returned binder in the GPUProcessHost, and when each
widget's compositor is created we store a reference to the binder in
the UiCompositorControllerChild.
Each nsWindow is given a unique ID, and whenever the Surface changes
due to an Android resume event, it sends the new surface for that ID
to the GPU process (if enabled) by calling
ICompositorSurfaceManager.onSurfaceChanged().
Stop inheriting AndroidCompositorWidget from InProcessCompositorWidget
and instead inherit from CompositorWidget directly. This class holds a
reference to the Surface that will be rendered in to. The
CompositorBridgeParent notifies the CompositorWidget whenever it has
been resumed, allowing it to fetch the new Surface. For the
cross-process CompositorWidgetParent implementation it fetches that
Surface from the CompositorSurfaceManagerService, whereas the
InProcessAndroidCompositorWidget can read it directly from the real
widget.
AndroidCompositorWidget::GetClientSize() can now calculate its size
from the Surface, rather than racily reading the value from the
nsWindow. This means RenderCompositorEGL and RenderCompositorOGLSWGL
can now use GetClientSize() again rather than querying their own size
from the Surface.
With this patch, setting layers.gpu-process.enabled to true will cause
us to launch a GPU process and render from it. We do not yet
gracefully recover from a GPU process crash, nor can we render
anything using SurfaceTextures (eg video or webgl). Those will come in
future patches.
Differential Revision: https://phabricator.services.mozilla.com/D131231
When we use OP_OVER for the final blit in WindowSurfaceX11Image::Commit,
this causes Cairo to hit a compositing fallback that uses XGetImage on
the window to get the pixel data, blends to it, then XPutImage's the
result back. We want to avoid this both because XGetImage may cause
errors and it is slow to read back from the window server.
If we use CopySurface/OP_SOURCE instead we avoid the readback via
XGetImage and so bypass both problems.
Differential Revision: https://phabricator.services.mozilla.com/D132319
When Firefox was activated by Alt+Tabbing, there was a case that event hook of WindowOcclusionCalculator could not detect an event of window activated. Then it is necessary to trigger window occlusion calculation from nsWindows.
Differential Revision: https://phabricator.services.mozilla.com/D132206
This is based off work by smurfd. But this patch doesn't support buttons
both at the left and right, which simplifies a lot the implementation.
Also, clean-up the existing env variables while at it.
Co-authored-by: Nicklas Boman <smurfd@gmail.com>
Differential Revision: https://phabricator.services.mozilla.com/D132073
Due to bug 1742986 and bug 1717863 we are blocking webrender on
Android devices PowerVR Rogue G6110 GPUs. These devices will use
software webrender instead.
Differential Revision: https://phabricator.services.mozilla.com/D132170
This prevents contrast issues with colors that are very similar to the
selection background.
See before / after screenshots. Selection on higher-contrasting
foregrounds still looks good.
This is the alpha channel that e.g., Bugzilla uses on dark mode
(so I didn't just mint it).
Differential Revision: https://phabricator.services.mozilla.com/D132022
`470.82` is the first version that supports `EGL_NV_robustness_video_memory_purge`
which is required so we don't run into bug 1731172. The first stable release of
the `495` series also supports that extension, previous beta versions don't need
to be considered.
Differential Revision: https://phabricator.services.mozilla.com/D132101
It is helpful if window visibility state could be checked by debug overlay.
For now, it works only on Windows with compositor.
Differential Revision: https://phabricator.services.mozilla.com/D131807
The previous patch would be a better fix, but it causes some xpcshell
crashes on Linux which I haven't figured out yet (because initializing
LookAndFeel initializes gfxPlatform).
This should be less risky and still fix the bug.
Differential Revision: https://phabricator.services.mozilla.com/D132011
This patch simply avoids calling SetAppID and SetCurrentProcessExplicitAppUserModelID when we're running from a packaged app. For `SetCurrentProcessExplicitAppUserModelID`, I ended up skipping the calls to the functions that call it because I thought it was less surprising behaviour given the names (eg: I might be surprised if `SetTaskbarGroupId` silently didn't set the taskbar group id). It's easy enough to switch up if skipping the calls at a lower level makes more sense.
I couldn't find any automated tests around the Jump List functionality (and we don't have any tests running within MSIX packages yet anyways...), but it worked just fine in my manual test. I also tested the scenario where the AppxManifest.xml ID changes during an upgrade (which will probably happen when https://bugzilla.mozilla.org/show_bug.cgi?id=1736113 gets done). This causes Jump Lists to stop working at first restart, but they appear to rebuilt after the usual few minute wait.
Differential Revision: https://phabricator.services.mozilla.com/D131693
The previous patches mean that VA-API shouldn't cause sandbox violations
in the RDD process, so there's no need to lock it out.
This patch does **not** change the prefs to enable it
(`media.rdd-ffmpeg.enabled` and `media.ffmpeg.vaapi.enabled`), but now
those prefs will be honored if they are flipped, to allow testing.
Differential Revision: https://phabricator.services.mozilla.com/D131681
- Make mCompositorState atomic to avoid thread race conditions.
- Remove !mIsDestroyed check from IsWaitingForCompositorResume() and keep only mCompositorState == COMPOSITOR_PAUSED_FLICKERING there.
We already set mCompositorState = COMPOSITOR_PAUSED_MISSING_WINDOW on Destroy().
Differential Revision: https://phabricator.services.mozilla.com/D131593
On Android the APZ controller thread is the android UI thread, rather
than the Gecko main thread as on other platforms. There some places
where the main thread requires to call IAPZCTreeManager functions that
must run on the controller thread. Currently we use the function
DispatchToControllerThread() prior to calling various IAPZCTreeManager
APIs to achieve this.
This works just fine for now, as there is no GPU process on
Android. However, once we do add a GPU process we will encounter
issues:
Firstly, there will now be a cross-process APZInputBridge rather than
using an in-process APZCTreeManager. The PAPZInputBridge protocol is
managed by PGPU, and therefore must run on the main thread in the
parent process. The input we require to send over the bridge, however,
originates from the UI thread.
To solve this we can convert PAPZInputBridge to a top-level protocol,
and bind it to the UI thread on Android. We can then send input
directly from the UI thread without issues.
Secondly, the PAPZCTreeManager protocol must also run from the main
thread in the parent process, as it is managed by
PCompositorBridge. Unlike PAPZInputBridge we cannot convert
PAPZCTreeManager in to a top level protocol, as it relies on the
ordering guarantees with PCompositorBridge.
We must therefore ensure that we only dispatch IAPZCTreeManager calls
to the controller thread when using an in-process
APZCTreeManager. Out-of-process calls, on the other hand, must be
dispatched to the main thread where we can send IPDL commands from. To
do this, we move the dispatch logic away from the callsites of
IAPZCTreeManager APIs, and in to the APZCTreeManager and
APZCTreeManagerChild implementations themselves.
Differential Revision: https://phabricator.services.mozilla.com/D131120
We can create DMABufSurface objects via deserialization without ever
setting a GL context. We must ensure we close the file handle even if we
don't have one.
Differential Revision: https://phabricator.services.mozilla.com/D131561
This re-arranges some deckchairs, allowing to have the launcher
process query the Windows packaged app environment.
Depends on D129882
Differential Revision: https://phabricator.services.mozilla.com/D130187
Emilio Cobos Álvarez
stransky
Jamie Nicol
Lee Salzman
Jonathan Watt
sotaro
Robert Mader
Nick Alexander
ssummar
Ben Hearsum
elfarto
Jed Davis
lamoure6
Andrew Osmond
Harry Twyford
Makoto Kato
Stephen A Pohl