Previously this code was using ipc::DuplicateHandle, which was unnecessary, as
the code is being run in the parent process which has access to perform direct
handle transfers. After this patch we'd like to remove ipc::DuplicateHandle and
rely only on attached handles for serialization, so the code is converted to
instead directly use DuplicateHandle.
Differential Revision: https://phabricator.services.mozilla.com/D126571
Fix a mistake during porting the ComputeNativeWindowOcclusionStatus() from chromium to gecko. chromium uses (left, top right, bottom), but gecko needs to use (x, y, width, height).
Differential Revision: https://phabricator.services.mozilla.com/D130331
Most of our JNI code either holds strong references to Java objects, i.e. the
Gecko Garbage Collector is responsible for clearning the object, or weak
references to Java code, i.e. the Java GC is responsible for clearing the
object.
Some objects, however, are special and need manual care. These objects
implement the `onWeakNonIntrusiveDetach` method, which is manually triggered by
calling `Detach`.
My understanding is that these objects need to be cleared from either the Java
side (when the GC destroys the GeckoSession) or from the C++ side, when the
window associated to a GeckoSession is closed.
This is done to avoid holding off to a window for longer than necessary, since
it's very expensive to do so.
The intermittent subject of this bug was caused by us not clearing the
Compositor object when the window closes on the Gecko side, letting the Java
side call `syncPauseCompositor` on a dead JNI object.
This is the before code of the Compositor's `onWeakNonIntrusiveDetach`:
```
void OnWeakNonIntrusiveDetach(already_AddRefed<Runnable> aDisposer) {
RefPtr<Runnable> disposer = aDisposer;
if (RefPtr<nsThread> uiThread = GetAndroidUiThread()) {
// ...
uiThread->Dispatch(NS_NewRunnableFunction(
"LayerViewSupport::OnWeakNonIntrusiveDetach",
[compositor, disposer = std::move(disposer),
results = &mCapturePixelsResults, window = mWindow]() mutable {
if (auto accWindow = window.Access()) {
// ...
compositor->OnCompositorDetached();
}
disposer->Run();
}));
}
```
As you can see from the above, the `OnCompositorDetached` method, which informs
the Java layer that the compositor should not be called anymore, was only
invoked when `window.Access()` returns successfully, i.e. when we have a
window that is alive.
Normally, a Compositor object always has a window associated to it, as there's
a strong link between the GeckoSession and the Compositor object on the Java
side.
There are, however, some edge cases (mostly during shutdown) where the Java
code holds a reference to the Compositor but not the GeckoSession. In those
cases, we would fail the following check
```
if (auto accWindow = window.Access()) {
```
And fail to call `OnCompositorDetached`.
We don't really need the window to call `OnCompositorDetached`, as explained
above, so we can just move the call outside the `if` statement to fix this
problem.
Differential Revision: https://phabricator.services.mozilla.com/D130101
These are only used for frameset painting and the non-e10s <select>
dropdown focus codepath. We have other more appropriate standard
colors for this.
Differential Revision: https://phabricator.services.mozilla.com/D129992
GetWindowDesktopId is a slow function and is called on the UI thread during WM_CLOSE message handing (as part of SessionStore). This was causing Windows to assume we are stalled and it abandons some messages, namely future WM_CLOSE messages sent for other windows during a "Close All Windows" operation.
In this patch, GetWorkspaceId uses a cached value for GetWindowDesktopId (if available) but also queues an update for that cache value if one isn't already in progress. Since SessionStore already regularly calls GetWorkspaceId in response to window moves, this keeps the value fresh in plases where it might change. (The SessionStore architecture is designed that way because Windows does not notify the application if the user moves the window to another virtual desktop.)
Differential Revision: https://phabricator.services.mozilla.com/D128955
Currently, checking whether an `EventTarget` is `nsINode` (or its concrete
classes) or not requires a QI, but it's expensive and used a lot while we
handle each event. Therefore, it'd be nicer for creating a virtual method,
`EventTarget::IsNode()` and use it for the check.
If trying to convert `EventTarget` to a concrete class, it may require two
virtual method calls. I'm not sure whether it's cheaper than a QI, but at
least, it won't depend on the UUID check order of `QueryInterface()` when
multiple interfaces are implemented.
Differential Revision: https://phabricator.services.mozilla.com/D129781
Many users report that GeckoView returns non-coarse value for primary pointer
capabilities. Actually, we assume that primary pointer device is 1st device by
`InputDevice.getDeviceIds`, but some mobile devices seems not to return touch
screen as 1st item according to user reports.
Also, Android's `InputDevice` API doesn't define what is primary pointer
device, so we cannot assume primary pointer device well.
Other implements are,
- Chrome returns coarse if something input device has coarse capability.
- Firefox for Windows seems to return coarse if it is tablet mode.
So we should return coarse as primary pointer capability when having touch
screen, like Chrome.
But there is still another issue.
When I check some devices (including Android VM on Chrome OS), even if no touch
screen, the `InputDevice`'s source may has `SOURCE_TOUCHSCREEN`. Chrome checks
that fine pointer at first, then it checks coarse pointer. But current GV is
coarse pointer at first. Since the `InputDevice`'s source may have both
`SOURCE_MOUSE` and `SOURCE_TOUCHSCREEN` on touchpad/mouse, GV returns different
result. So we shouldn't check `SOURCE_TOUCHSCREEN` at first.
Differential Revision: https://phabricator.services.mozilla.com/D129901
Child windows are not supported correctly now as we don't tie them to parent windows. It's because we removed child widget hierarchy
and use popups to draw them. In this patch we revert some changes to manage child popups appropriately:
- Introduce 'mIsChildWindow' flag to mark child popups.
- Use GdkWindow hierarchy to connect chid popup to its parent.
- Destroy all child popups when parent it also destroyed.
- Implement nsWindow::SetParent() and nsWindow::ReparentNativeWidget() for child popups.
- Fix GrabPointer() to ignore destroyed windows.
Differential Revision: https://phabricator.services.mozilla.com/D129964
And remove the autofill.background pref for 95 (or 96, depending on
when this lands) assuming nothing terrible causes us to turn it off on
94.
Differential Revision: https://phabricator.services.mozilla.com/D129988
This fix simply ignores tablet mode when running on Windows 11. The
reasoning behind this is that per Microsoft documentation tablet mode
is specific to Windows 10 and not supported anymore on Windows 11. This
seems consistent in the behavior of the APIs we use to detect the
presence of a keyboard: Windows 10-specific APIs return unexpected
results while APIs that predate them return values that seem consistent
and reliable.
Differential Revision: https://phabricator.services.mozilla.com/D128229
We want to be able to have a different behavior for interactions with an entry
in the Windows system tray - specifically, we want to be able to open a window
on left click, and show a menu on right click. This patch allows us to control
this with a "contextmenu" attribute on the menu passed in to `AddItem`, and
receive a "systemstatusbarclick" event in the case of a left click.
Regarding tests, I don't know that we have a good way of testing this?
Suggestions are of course welcome here.
Differential Revision: https://phabricator.services.mozilla.com/D129413
I think this patch is functionally neutral.
I'm not completely sure about the best way to do these casts - the __bridge may not be
necessary since we don't use ARC yet. But it's probably fine to add it anyway.
Also, returning autoreleased CFTypeRef objects seems a bit weird, but it's what we've
already been doing and it's probably fine.
And some of these nils should maybe be nullptrs, but the compiler doesn't seem to care.
Differential Revision: https://phabricator.services.mozilla.com/D129559
This makes me think that pre-10.13 macOS is the only platform without dark
system colors...
We might want to do something like D127645 for pre-10.14 macs?
Differential Revision: https://phabricator.services.mozilla.com/D129575
For Bug 1733955, we need a support of dynamic enabling/disabling window occlusion by pref. It is for enabling/disabling window occlusion for some mochitests by pref.
Differential Revision: https://phabricator.services.mozilla.com/D129369
Make both the light and dark colors less opaque too, since even in light
mode it looks very off IMO for stuff like:
data:text/html,<body bgcolor=grey><input>
Differential Revision: https://phabricator.services.mozilla.com/D129302
- When GtkCompositorWidget is created, make suspended rendering state as initial one as we can't render to widget window.
Enable rendering when underlying window is visible (nsWindow::ConfigureGdkWindow) or GtkCompositorWidget is assigned (nsWindow::SetCompositorWidgetDelegate).
- Use moz_container_wayland_add_initial_draw_callback() at nsWindow::ConfigureGdkWindow() to set Wayland EGL window as it was before.
- Make moz_container_wayland_add_initial_draw_callback() to run callbacks instantly when mozcontainer is already visible.
- Implement and use moz_container_wayland_clear_initial_draw_callback() to clear mozcontainer callbacks when it becomes hidden.
- Rename COMPOSITOR_PAUSED_MISSING_EGL_WINDOW to COMPOSITOR_PAUSED_MISSING_WINDOW as it's used for GLX too.
- Initially pause rendering for GLX too.
Differential Revision: https://phabricator.services.mozilla.com/D127542