The rounding error workaround is broken - on recent Gtk it produces needless stream of move-to-rect callback.
It's because we move popup of GDK_WINDOW_TYPE_HINT_POPUP_MENU type and this is positioned by Gtk by move-to-rect even if gtk_window_move() is called.
But it looks like we don't need this workaround any more due to recent fixes (1786525, 1786588, 1786525, 1765714).
Differential Revision: https://phabricator.services.mozilla.com/D158217
There are only 3 places where nsMemory.h is still needed (image/RasterImage.cpp,
gfx/thebes/gfxFT2FontList.cpp, and nsMemory.cpp). Remove the rest.
Differential Revision: https://phabricator.services.mozilla.com/D158213
`TSFTextStore` needs to expose the document URL for supporting new feature
of Windows 11 22H2 update. Therefore, the `InputContext` should have the
document URL.
Differential Revision: https://phabricator.services.mozilla.com/D157893
We can't use move-to-rect if there are more parents of wl_subsurface popups types.
It's because wl_subsurface is ignored by xgd_popup (created by move-to-rect) so our popup scenario:
toplevel -> xgd_popup(1) -> wl_subsurface(2) -> xgd_popup(3)
looks for Wayland compositor as:
toplevel -> xgd_popup(1) -> xgd_popup(3)
If xgd_popup(1) and xgd_popup(3) are not adjacent then move-to-rect applied to xgd_popup(3) fails and we get missing popup.
Depends on D158120
Differential Revision: https://phabricator.services.mozilla.com/D158121
Wne context menu is positioned by plain move, we need relative popup coordinates. So calculate them according to context menu parent popup.
Differential Revision: https://phabricator.services.mozilla.com/D158120
There are some suspect crashes around Wayland SHM interface so let's make sure we have valid shm handle before we pass it to Wayland.
It covers the 'It can't happen' scenario which tends to happen despite of all premises.
Differential Revision: https://phabricator.services.mozilla.com/D157975
When figuring out menuhover background, make sure not to come up with
the exact same color as the menu background. This ensures we also try
gradients / background-images before giving up.
This is only an issue with the dark theme in this case, because
otherwise we use native drawing.
Differential Revision: https://phabricator.services.mozilla.com/D157963
move-to-rect offset does not work realibly in mutter and can lead to invisible window.
It's used mainly for tooltips so let's skip it for now.
Differential Revision: https://phabricator.services.mozilla.com/D157926
When GtkWidget is hidden, underlying wl_surface is deleted. We need to also update EGLSurface of GtkWidget (GtkCompositorWidget)
as EGLSurface is directly linked to wl_surface:
- When GtkWidget is hidden, call GtkCompositorWidget::DisableRendering(). That releases GtkCompositorWidget resources
related to GtkWidget (XWindow/XVisual etc.) and marks the widget as hidden.
- If GtkWidget is backed by EGL call compositor resume which forces compositor to create new EGLSurface.
- Make sure GLContextEGL can create EGLSurface even when GtkWidget is hidden and wl_surface is missing.
It prevents fallback to SW rendering or pause RenderCompositorEGL which leads to Bug 1777664 (whole browser UI freeze).
- Return early from RenderCompositorEGL::BeginFrame()/RenderCompositorEGL::EndFrame() when GtkCompositorWidget is hidden.
Depends on D157357
Differential Revision: https://phabricator.services.mozilla.com/D157358
Map/Unmap signals creates and deletes mContainer wayland surface and EGL window.
As we need to call the handlers in correct order (mContainer::map -> nsWindow::map and nsWindow::unmap -> mContainer::unmap)
connect the signals to mContainer widget and call mContainer::unmap from nsWindow::unmap.
Then nsWindow::unmap can update compositor before wl_surface/EGL window is released by mContainer.
Differential Revision: https://phabricator.services.mozilla.com/D157357
nsTransferable was modified to prevent disk leakings when copying data
in private browsing mode with Bug 1123480.
However, the context is nullptr when it is initialized, so it still
leaks if PBM is enabled by default.
Our solution is to check the browser.privatebrowsing.autostart in this
condition.
Differential Revision: https://phabricator.services.mozilla.com/D157800
The android magnifier widget does not work when using our
SurfaceControl rendering path, as we no longer render in to the
Surface provided by the SurfaceView, but instead into a child Surface
we have created and attached the SurfaceControl.
To fix this, we create a SurfaceView subclass, MagnifiableSurfaceView,
which allows us to set an override Surface to be used by the
magnifier. This class works by overriding getHolder() to return a
custom SurfaceHolder, which returns our override Surface rather than
the default one when called by the Magnifier class.
Depends on D157308
Differential Revision: https://phabricator.services.mozilla.com/D157309
In order to fix the magnifier widget being broken, the previous patch
in this bug added a mechanism to disable and enable the SurfaceControl
rendering path. This caused some glitches to occur, so we removed the
calls to that code in bug 1783542, but the code remained.
As we now have an alternative solution to fix the magnifier widget, we
no longer require this code. This patch therefore reverts the original
patch, to lead the way for the new solution in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D157308
Deletion of mutation observers from a list resulted in O(n^2) behavior and could lead to massive freezes.
This is resolved by using a LinkedList instead, reducing complexity to O(n).
A safely iterable doubly linked list was implemented based on `mozilla::DoublyLinkedList`,
allowing to insert and remove elements while iterating the list.
Due to the nature of `mozilla::DoublyLinkedList`, every Mutation Observer now inherits `mozilla::DoublyLinkedListElement<T>`.
This implies that a Mutation Observer can only be part of one DoublyLinkedList.
This conflicts with some Mutation Observers, which are being added to multiple `nsINode`s.
To continue supporting this, new MutationObserver base classes `nsMultiMutationObserver` and `nsStubMultiMutationObserver` are introduced,
which create `MutationObserverWrapper` objects each time they are added to a `nsINode`.
The wrapper objects forward every call to the actual observer.
Differential Revision: https://phabricator.services.mozilla.com/D157031
When GtkWidget is hidden, underlying wl_surface is deleted. We need to also update EGLSurface of GtkWidget (GtkCompositorWidget)
as EGLSurface is directly linked to wl_surface:
- When GtkWidget is hidden, call GtkCompositorWidget::DisableRendering(). That releases GtkCompositorWidget resources
related to GtkWidget (XWindow/XVisual etc.) and marks the widget as hidden.
- If GtkWidget is backed by EGL call compositor resume which forces compositor to create new EGLSurface.
- Make sure GLContextEGL can create EGLSurface even when GtkWidget is hidden and wl_surface is missing.
It prevents fallback to SW rendering or pause RenderCompositorEGL which leads to Bug 1777664 (whole browser UI freeze).
- Return early from RenderCompositorEGL::BeginFrame()/RenderCompositorEGL::EndFrame() when GtkCompositorWidget is hidden.
Depends on D157357
Differential Revision: https://phabricator.services.mozilla.com/D157358
Map/Unmap signals creates and deletes mContainer wayland surface and EGL window.
As we need to call the handlers in correct order (mContainer::map -> nsWindow::map and nsWindow::unmap -> mContainer::unmap)
connect the signals to mContainer widget and call mContainer::unmap from nsWindow::unmap.
Then nsWindow::unmap can update compositor before wl_surface/EGL window is released by mContainer.
Differential Revision: https://phabricator.services.mozilla.com/D157357
When entering fullscreen and saving the original position of a window,
also save the position to which it was moved.
When leaving fullscreen, keep the window on the same screen. Restore its
_screen-relative_ position, rather than its absolute position.
Differential Revision: https://phabricator.services.mozilla.com/D153410
`HideWindowChrome(false)` may change the reported window size on Mac:
the OS menu bar appears at the top of the screen, and this will cause the
window to shrink if it was fullscreen.
This isn't a problem yet, since we don't check the window dimensions
when exiting fullscreen... but the following commit will do exactly
that. Delay calling `HideWindowChrome` until the last possible minute --
but make sure that it _does_ get called.
Since HideWindowChrome(true) does not presently change the window size
(see bug 498835), no functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D154469
Use desktop pixels everywhere:
- Store the old window position as a `DesktopRect`.
- Since `GetRectDisplayPix` is infallible, use the convenience getter
that hands us a `DesktopIntRect`.
- Add a helper function that wraps `Resize()` and takes any `Rect`
which uses `DesktopPixel`s.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D153409
A window is fullscreenable iff it's a desktop window (that is, a
positional child of the desktop rather than of another window) -- and
desktop windows are the windows which use desktop-pixel units in
Resize().
Code coverage confirms that the branch when `BoundsUseDesktopPixels()`
returns `false` is never taken in tests.
Under the (hopefully justified) assumption that it's never taken at all,
no functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D153408
When widget is hidden gtk_window_move() does not move the widget but sets new widget coordinates
when widget is mapped again.
If popup used move-to-rect before (GdkWindow has POSITION_METHOD_MOVE_TO_RECT set),
popup will use move-to-rect again when it's mapped and we'll get bogus move-to-rect callback.
In this patch we implement nsWindow::WaylandPopupMovePlain() to perform simple popup movement.
It calls gdk_window_move() to set position_method to POSITION_METHOD_MOVE_RESIZE when popup is hidden
so we'll use simple move when popup is shown and don't slip to move-to-rect.
Depends on D156821
Differential Revision: https://phabricator.services.mozilla.com/D157432
If popup is moved we can't use recent popup position (mBounds) to check popup placement but
use requested position given at nsWindow::NativeMoveResize().
Differential Revision: https://phabricator.services.mozilla.com/D156821
If there's a gap between popups we can't use move-to-rect as anchor needs to be placed inside of parent popup.
In such case place anchor to upper corner of parent popup and submit popup position as offset.
Differential Revision: https://phabricator.services.mozilla.com/D156820
This restores behavior from before my patch, and makes it so that it's
easier to see which color pair ends up getting used.
Differential Revision: https://phabricator.services.mozilla.com/D157271
Prior to this commit the `ToastNotification`'s observer registration doesn't work due to `ToastNotification` not implementing `nsIWeakReference` while attempting to register itself as an observer as a weak reference.
Differential Revision: https://phabricator.services.mozilla.com/D155764
Non-MSIX notifications are not removed when Firefox is uninstalled. To handled this we've added a new `uninstall` background task and extended `nsIWindowsAlertService` to deregister notifications on uninstall.
Differential Revision: https://phabricator.services.mozilla.com/D156625
Non-MSIX notifications are not removed when Firefox is uninstalled. To handled this we've added a new `uninstall` background task and extended `nsIWindowsAlertService` to deregister notifications on uninstall.
Differential Revision: https://phabricator.services.mozilla.com/D156625
The immediate effect is to make any image larger and more prominent.
This might not be the right option for regular DOM notifications,
which support only `icon` (and not `image`) in Firefox at this time,
but we can adjust (perhaps limiting the generic template to privileged
alerts) as we need in the future.
Differential Revision: https://phabricator.services.mozilla.com/D156873
On Windows, when an alert is privileged and `name` is non-empty, round
trip its `name` (as `privilegedName`) through the Windows notification
mechanism, and provide it to the "relaunch" callback.
Differential Revision: https://phabricator.services.mozilla.com/D156636
I moved the following variables to their method of use:
- sSwitchKeyboardLayout, sCanQuit to nsWindow::ProcessMessageInternal;
- sLastMousePoint, sLastMouseDownTime, sLastClickCount, sLastMouseButton to nsWindow::DispatchMouseEvent;
- sFirstTopLevelWindowCreated to nsWindow::Create;
- sHasBogusPopupsDropShadowOnMultiMonitor to nsWindow::HasBogusPopupsDropShadowOnMultiMonitor;
- gIsSleepMode (now sWasSleepMode) to nsWindow::PostSleepWakeNotification.
I also removed one dead variable called sNeedsToInitMouseWheelSettings, as well as sHaveInitializedPrefs which was not required anymore.
Two variables mentioned in the bug had already been moved out of the nsWindow namespace as part of other changesets:
- sDropShadowEnabled, now replaced by local variables shouldUseDropShadow and sShadowEnabled of nsWindow::Show in https://hg.mozilla.org/integration/autoland/rev/18a7f69d5ce4 ;
- sCustomHCursor, now replaced by local variables sCurrentHCursor and sCurrentHCursorIsCustom of nsWindow::SetCursor in https://hg.mozilla.org/integration/autoland/rev/dd95f1e386f1 .
Differential Revision: https://phabricator.services.mozilla.com/D156539
We'll be defaulting Felt Privacy features to enabled, and allowing them to be disabled by Nimbus (primarily for a holdback study).
Differential Revision: https://phabricator.services.mozilla.com/D153275
Right now we look for first parent only at nsWindow::WaylandGetParentPosition() and that's wrong.
WaylandGetParentPosition() is expected to return popup position in root coordinates regardless of popup parent nembers.
In this patch we calc popup position according to whole popup chain.
Differential Revision: https://phabricator.services.mozilla.com/D156673
When we open a popup window (tooltip for instance) on top of GDK_WINDOW_TYPE_HINT_UTILITY popup, Mutter compositor sends bogus
leave/enter events to the GDK_WINDOW_TYPE_HINT_UTILITY popup (https://gitlab.gnome.org/GNOME/gtk/-/issues/5089).
That leads to immediate tooltip close. As a workaround ignore these
bogus events.
We need to check two affected window types:
- toplevel window with at least two child popups where the first one is
GDK_WINDOW_TYPE_HINT_UTILITY.
- popup GDK_WINDOW_TYPE_HINT_UTILITY with a child popup.
We ignore two bogus leave/enter sequences which are fired by mutter together:
1. Leave (popup) -> Enter (toplevel)
2. Leave (toplevel) -> Enter (popup)
Differential Revision: https://phabricator.services.mozilla.com/D156301
We don't need to hide/show GDK_WINDOW_TYPE_HINT_UTILITY popup type to change it's position.
Hide it only if we need to set correct popup type as such change is done in map event.
Differential Revision: https://phabricator.services.mozilla.com/D156305
When the notification server callback is executed by the Windows
notification system, it invokes Firefox with additional command line
parameters, most importantly the Windows-specific notification
"Windows tag".
If no appropriate Firefox is running, the command line will be
processed, the provided Windows tag will be inspected (and seen to not
be registered with this running Firefox instance) and a "launch URL"
stored as part of the Windows notification itself opened (if one is
provided).
If an appropriate Firefox is running, the remoting protocol will
forward this command line to the running instance. If the instance
recognizes the provided `--notification-windowsTag`, the command line
will be ignored. When the notification server exits, Windows will
fallback to the Windows 8.1 style notification callbacks registered
for this Windows tag and the existing (non notification server)
behaviour will occur.
In fact, the server therefore waits for a Windows tag-specific system
event to be signalled by the invoked Firefox (or a sibling process).
If we were to return `S_OK` from the notification server immediately,
and a running Firefox process would handle the notification via
Windows 8.1-style notification callbacks, then Windows would fall back
to those callbacks. The invoked callbacks unregister themselves upon
completion, often before the launched Firefox has an opportunity to
process the command line. By waiting for this system event, we allow
the invoked Firefox to process the command line while its own
notification callbacks are registered and therefore recognize that its
callbacks will handle the notification.
Differential Revision: https://phabricator.services.mozilla.com/D154468
In background task mode:
1. Re-launch Firefox into the default browsing profile, not the
(possibly ephemeral) background task profile.
2. Don't show the in-product notification settings, which won't apply
to the relevant Firefox profile.
Differential Revision: https://phabricator.services.mozilla.com/D155908
Use the existing mName field of alert which includes the host port and tag (or uuid) for Windows notification tag.
When a notification originates from the browser chrome, generate an identify on the fly as before.
The tag is hashed in order to fit the 16 character limit for tags. Note the limit was bumped to 64 in Windows 10 Creators Update.
Differential Revision: https://phabricator.services.mozilla.com/D155140
When the notification server callback is executed by the Windows
notification system, it invokes Firefox with additional command line
parameters, most importantly the Windows-specific notification
"Windows tag".
If no appropriate Firefox is running, the command line will be
processed, the provided Windows tag will be inspected (and seen to not
be registered with this running Firefox instance) and a "launch URL"
stored as part of the Windows notification itself opened (if one is
provided).
If an appropriate Firefox is running, the remoting protocol will
forward this command line to the running instance. If the instance
recognizes the provided `--notification-windowsTag`, the command line
will be ignored. When the notification server exits, Windows will
fallback to the Windows 8.1 style notification callbacks registered
for this Windows tag and the existing (non notification server)
behaviour will occur.
In fact, the server therefore waits for a Windows tag-specific system
event to be signalled by the invoked Firefox (or a sibling process).
If we were to return `S_OK` from the notification server immediately,
and a running Firefox process would handle the notification via
Windows 8.1-style notification callbacks, then Windows would fall back
to those callbacks. The invoked callbacks unregister themselves upon
completion, often before the launched Firefox has an opportunity to
process the command line. By waiting for this system event, we allow
the invoked Firefox to process the command line while its own
notification callbacks are registered and therefore recognize that its
callbacks will handle the notification.
Differential Revision: https://phabricator.services.mozilla.com/D154468
In background task mode:
1. Re-launch Firefox into the default browsing profile, not the
(possibly ephemeral) background task profile.
2. Don't show the in-product notification settings, which won't apply
to the relevant Firefox profile.
Differential Revision: https://phabricator.services.mozilla.com/D155908
Use the existing mName field of alert which includes the host port and tag (or uuid) for Windows notification tag.
When a notification originates from the browser chrome, generate an identify on the fly as before.
The tag is hashed in order to fit the 16 character limit for tags. Note the limit was bumped to 64 in Windows 10 Creators Update.
Differential Revision: https://phabricator.services.mozilla.com/D155140
`launchURL` captures the URL that triggered the alert, if it comes
from a DOM notification. If Firefox is launched when not already
running to handle an alert, it will navigate to this URL.
This URL can be set, and chrome privileged alerts can use this to
launch Firefox to a specific URL when it is launched. Toast
notifications popped by background tasks will use this to re-engage
Firefox users to a campaign-specific URL.
This functionality will be tested in the Windows-specific tests
accompanying Bug 1781929.
Differential Revision: https://phabricator.services.mozilla.com/D155907
This allows Windows native notification action buttons to access the
built-in "dismiss" and "snooze" support without requiring a Firefox
invocation.
Differential Revision: https://phabricator.services.mozilla.com/D155906
Otherwise, it changes the move-to-rect inputs, which can change the
output as well, making us move the anchor all the way to the right.
You could, I guess, consider this a mutter bug of sorts, because it
feels weird that you pass it an anchor that has been a `move-to-rect`
output and you get another rect as an output.
But also, it's kinda silly that we're doing that to begin with, so avoid
it by telling the popup frame whether it's been positioned / moved by
move-to-rect (and keeping the anchor in that case).
The reason this works on my setup without "Large text" is just dumb luck
(the front-end computes a max-height for the panel that is small enough
to fit on the screen).
Differential Revision: https://phabricator.services.mozilla.com/D155406
Otherwise, it changes the move-to-rect inputs, which can change the
output as well, making us move the anchor all the way to the right.
You could, I guess, consider this a mutter bug of sorts, because it
feels weird that you pass it an anchor that has been a `move-to-rect`
output and you get another rect as an output.
But also, it's kinda silly that we're doing that to begin with, so avoid
it by telling the popup frame whether it's been positioned / moved by
move-to-rect (and keeping the anchor in that case).
The reason this works on my setup without "Large text" is just dumb luck
(the front-end computes a max-height for the panel that is small enough
to fit on the screen).
Differential Revision: https://phabricator.services.mozilla.com/D155406
After the previous changes there was only one consumer left of the Shmem
version of GetSurfaceData, which could easily be changed to use BigBuffer,
removing the need for that overload.
After that consumer is removed, the interface was also simplified as the
generic logic in the implementation was no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D151854
The ShmemImage type was previously implemented using a Shmem, however due to
the usage patterns, `BigBuffer` is probably a better fit, and allows unifying
more code in nsContentUtils.
Differential Revision: https://phabricator.services.mozilla.com/D151853
The IPCDataTransfer type is used to transfer Clipboard/Drag & Drop payloads
over IPC to allow them to be written to or read from the relevant system
interfaces. Previously, the system which was used was somewhat complex, and
tried to use Shmem in some cases to store buffers out of line. Now that
BigBuffer is available, it can be simplified substantially.
In addition, this change removed the memory buffer overload of GetSurfaceData,
as the only consumer was using it to immediately send the payload over IPC as a
nsCString. It was changed to instead use `BigBuffer` as that is more efficient
in a large buffer situation, and reduces the number of required copies.
Differential Revision: https://phabricator.services.mozilla.com/D151852
We'll be defaulting Felt Privacy features to enabled, and allowing them to be disabled by Nimbus (primarily for a holdback study).
Differential Revision: https://phabricator.services.mozilla.com/D153275
Unfortunately this test doesn't run as expected on our CI since macs on our CI
are running normal DPI mode.
I tested this test works properly on my macbook, it fails without the fix in the
previous commit and it passes with the fix.
Differential Revision: https://phabricator.services.mozilla.com/D153688
Also moved from `typedef` to `using _ =` syntax to match new templated import of `ComPtr` in ToastNotificationHandler.h.
Depends on D155525
Differential Revision: https://phabricator.services.mozilla.com/D155526
We will be defaulting Felt Privacy features to enabled, and allowing them to be disabled by Nimbus (primarily for a holdback study).
Differential Revision: https://phabricator.services.mozilla.com/D153275
After the previous changes there was only one consumer left of the Shmem
version of GetSurfaceData, which could easily be changed to use BigBuffer,
removing the need for that overload.
After that consumer is removed, the interface was also simplified as the
generic logic in the implementation was no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D151854
The ShmemImage type was previously implemented using a Shmem, however due to
the usage patterns, `BigBuffer` is probably a better fit, and allows unifying
more code in nsContentUtils.
Differential Revision: https://phabricator.services.mozilla.com/D151853
The IPCDataTransfer type is used to transfer Clipboard/Drag & Drop payloads
over IPC to allow them to be written to or read from the relevant system
interfaces. Previously, the system which was used was somewhat complex, and
tried to use Shmem in some cases to store buffers out of line. Now that
BigBuffer is available, it can be simplified substantially.
In addition, this change removed the memory buffer overload of GetSurfaceData,
as the only consumer was using it to immediately send the payload over IPC as a
nsCString. It was changed to instead use `BigBuffer` as that is more efficient
in a large buffer situation, and reduces the number of required copies.
Differential Revision: https://phabricator.services.mozilla.com/D151852
In CI, we fail the glxtest which disables all gfx features, including
the backdrop filter feature. We can just enable it on Linux. A follow up
series of patches will reform the blocklist to prevent these footguns in
the future in the next nightly cycle.
Differential Revision: https://phabricator.services.mozilla.com/D155041
The "preferred" one is the behavior we have for chrome docs, where we
fall back always to the document's preferred color-scheme rather than
falling back to light.
We'll use this in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D154923
Backdrop filter crashes newer Intel drivers on Windows. This patch adds
support to the blocklist infrastructure for backdrop filter, and hooks
this up with the CSS property table.
Differential Revision: https://phabricator.services.mozilla.com/D154950
On Android we have until now determined the compositor widget's size
by querying the values from the ANativeWindow. However, since bug
1780093 landed we can now switch between which Surface we are
rendering in to, and as a result we appear to be using the wrong size
some of the time.
This patch is a speculative attempt to fix this, by using the size
passed to ResumeAndResize() (which itself comes from the Surface's
surfaceChanged() callback) rather than querying the window.
Differential Revision: https://phabricator.services.mozilla.com/D154909
Remove outdated check for move-to-rect. It's redundant and it's implemented in more complex way by nsWindow::WaylandPopupCheckAndGetAnchor() now.
Differential Revision: https://phabricator.services.mozilla.com/D154882
Backdrop filter crashes newer Intel drivers on Windows. This patch adds
support to the blocklist infrastructure for backdrop filter, and hooks
this up with the CSS property table.
Differential Revision: https://phabricator.services.mozilla.com/D154950
When entering fullscreen and saving the original position of a window,
also save the original position of its screen.
When leaving fullscreen, keep the window on the same screen. Restore its
_screen-relative_ position, rather than its absolute position.
Differential Revision: https://phabricator.services.mozilla.com/D153410
`HideWindowChrome(false)` may change the reported window size on Mac:
the OS menu bar appears at the top of the screen, and this will cause the
window to shrink if it was fullscreen.
This isn't a problem yet, since we don't check the window dimensions
when exiting fullscreen... but the following commit will do exactly
that. Delay calling `HideWindowChrome` until the last possible minute --
but make sure that it _does_ get called.
Since HideWindowChrome(true) does not presently change the window size
(see bug 498835), no functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D154469
Use desktop pixels everywhere:
- Store the old window position as a `DesktopRect`.
- Since `GetRectDisplayPix` is infallible, use the convenience getter
that hands us a `DesktopIntRect`.
- Add a helper function that wraps `Resize()` and takes any `Rect`
which uses `DesktopPixel`s.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D153409
A window is fullscreenable iff it's a desktop window (that is, a
positional child of the desktop rather than of another window) -- and
desktop windows are the windows which use desktop-pixel units in
Resize().
Code coverage confirms that the branch when `BoundsUseDesktopPixels()`
returns `false` is never taken in tests.
Under the (hopefully justified) assumption that it's never taken at all,
no functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D153408
This code path gets executed by existing tests, and I don't believe
there is a way to execute this behavior using our CI, since it's a macOS
version check.
Differential Revision: https://phabricator.services.mozilla.com/D154172
This allows us to correctly draw items with mismatched color-scheme
on GTK.
This is a reasonably simple fix. A more elaborate fix could be not using
appearance to draw menuitems on Linux at all, just like we don't use it
to draw menupopups anymore. But in practice it's a bit harder because we
use it also to draw menubar items (which probably should be its own
appearance type instead). I can look into that, but this seems
reasonable for now.
Differential Revision: https://phabricator.services.mozilla.com/D154680
With this patch moz_container_wayland_surface_lock() always locks MozContainer and needs to be paired with moz_container_wayland_surface_unlock() even if it fails and returns nullptr.
Split moz_container_wayland_add_initial_draw_callback() to two new functions:
- moz_container_wayland_add_initial_draw_callback_locked() is called on locked container and only adds draw callback. It asserts when MozContainer is already to draw as we don't expect it.
- moz_container_wayland_add_or_fire_initial_draw_callback() is called on unlocked container as it has it's own lock. It behaves as original moz_container_wayland_add_initial_draw_callback(), i.e. stores draw callback when MosContainer is not visible and fires draw callback when we're ready to draw.
- implement RAII class MozContainerSurfaceLock and use it to lock moz_contatier and get wl_surface of it.
Differential Revision: https://phabricator.services.mozilla.com/D152276
This lets users e.g. print-to-scale where it matters.
Custom margins are still clamped to unwriteable margins, even when all zeroes,
to avoid impacting user-specified & persisted margins.
Differential Revision: https://phabricator.services.mozilla.com/D152900
With this patch moz_container_wayland_surface_lock() always locks MozContainer and needs to be paired with moz_container_wayland_surface_unlock() even if it fails and returns nullptr.
Split moz_container_wayland_add_initial_draw_callback() to two new functions:
- moz_container_wayland_add_initial_draw_callback_locked() is called on locked container and only adds draw callback. It asserts when MozContainer is already to draw as we don't expect it.
- moz_container_wayland_add_or_fire_initial_draw_callback() is called on unlocked container as it has it's own lock. It behaves as original moz_container_wayland_add_initial_draw_callback(), i.e. stores draw callback when MosContainer is not visible and fires draw callback when we're ready to draw.
- implement RAII class MozContainerSurfaceLock and use it to lock moz_contatier and get wl_surface of it.
Differential Revision: https://phabricator.services.mozilla.com/D152276
Due to different D&D handling on X11 and Wayland we should pass only GDK_ACTION_MOVE to gdk_drag_status().
Different D&D operation passed to gdk_drag_status() is returned back by gdk_drag_context_get_selected_action() so
gdk_drag_context_get_selected_action returns value set by gdk_drag_status() and not D&D modifiers set by CTRL/SHIFT
Also pass correct time to gdk_drag_status().
Depends on D154417
Differential Revision: https://phabricator.services.mozilla.com/D154418
As we handle D&D in time now we can remove the D&D workaround.
It was used to enable D&D until D&D move handler sends reply to system but also enables D&D where should be disabled (like History menu).
Depends on D154416
Differential Revision: https://phabricator.services.mozilla.com/D154417
This is an update to Bug 1730203. We need to answer to D&D inside of D&D move handler due to specific Gtk architecture.
In fix for Bug 1730203 we send the reply but we failed to update D&D status so the reply may be outdated.
In this patch we:
- Set correct D&D state and send reply to D&D motion event
- Move above code to nsDragService (nsDragService::Schedule()) so UpdateDragAction()/ReplyToDragMotion() can be private again.
- Update UpdateDragAction()/ReplyToDragMotion() to use correct GdkDragContext.
- At UpdateDragAction() call gdk_drag_context_get_selected_action() for valid GdkDragContext only.
Depends on D154415
Differential Revision: https://phabricator.services.mozilla.com/D154416
D&D uses nested evenet loops to get data from system. Let's track how deep are they nested for diagnostic purpose.
Depends on D154413
Differential Revision: https://phabricator.services.mozilla.com/D154414
When turning on fission, OOP child frame doesn't receive touch events such as
`touchstart`.
When dispatching touch event from GeckoView side, some informations such as
`mLayersId` are missing since copy constructor of `MultiTouchInput` doesn't
copy all information.
Since the structure of Input data has a lot of members, we should use
`std::move` instead of copy constructor of `InputData`. It can avoid
unnecessary copy.
Differential Revision: https://phabricator.services.mozilla.com/D154242
This makes it easier to get parity between legacy and regular flex
without having to either have tons of arbitrary attribute selectors in
the xul sheet, nor adding attribute lookup hacks to the html flexbox
layout.
Also, reimplement the remaining supported flex attribute-values (0 and 1)
purely in terms of CSS rules in xul.css (regardless of whether
emulate-moz-box-with-flex is enabled).
In practice these are pretty uncommon and the style attribute does the
trick in every case I've tried.
Add a debug-only assertion to ensure we preserve behavior for now.
Add a new test with another behavior difference between flexbox
emulation and old xul layout because the old reftest now passes. Use
replaced elements, which in modern flex are treated differently.
Differential Revision: https://phabricator.services.mozilla.com/D154394
dom/ and dom/webidl/ : Default these files back to DOM: Core & HTML
PluginChild.jsm: Apparently this is only still used for GMP things.
browser/base/content/ : The remaining tests are mostly EME related, so I switched it over to that.
widget/tests/ : No plugin files remain, so I removed the rule.
Differential Revision: https://phabricator.services.mozilla.com/D154537
clang trunk doesn't like it being defined as a enum GdkEventMask,
because it doesn't fit in the value, but OTOH, it's only used in
kEvents, which is a gint.
Differential Revision: https://phabricator.services.mozilla.com/D154357
This makes it easier to get parity between legacy and regular flex
without having to either have tons of arbitrary attribute selectors in
the xul sheet, nor adding attribute lookup hacks to the html flexbox
layout.
Also, reimplement the remaining supported flex attribute-values (0 and 1)
purely in terms of CSS rules in xul.css (regardless of whether
emulate-moz-box-with-flex is enabled).
In practice these are pretty uncommon and the style attribute does the
trick in every case I've tried.
Add a debug-only assertion to ensure we preserve behavior for now.
Add a new test with another behavior difference between flexbox
emulation and old xul layout because the old reftest now passes. Use
replaced elements, which in modern flex are treated differently.
Differential Revision: https://phabricator.services.mozilla.com/D154394
We implement SendNativeTouchpadPan/SynthesizeNativeTouchpadPan (like Windows does for this test).
I tried to use the existing functions SendNativeMouseScrollEvent/SynthesizeNativeMouseScrollEvent which are implemented on Linux and which are what we use for mac on this test, but it's already used for other stuff and it would be very clunky to overload it to make it work for this too.
I didn't see any way to "tag" the gdk events with more info, so making the observer notifier work was clunky. Similarly for getting the phase start/update/end work.
Differential Revision: https://phabricator.services.mozilla.com/D154386
This still doesn't fire on print settings changes, so it uses the
default page size. Which is probably better than nothing, but...
To make viewport-size media-query listeners work more generally for
printed documents, we would need to re-clone the top document
unconditionally for all print settings changes, which needs front-end
work at least, and is dubious if the page changes dynamically.
Differential Revision: https://phabricator.services.mozilla.com/D150499
We have allowed it in nightly for quite a while now and of all drivers
capable of GL(ES) >= 3.0 all either have already their own rules, have
recently be tested (freedreno >= 22.2/panfrost) or are are still
experimental/niche.
So lets finally draw a line from where on rendering regressions will
be driver issues and not our business.
The choosen Mesa version is the upcoming one, containing some fixes
for freedreno. As many distros for ARM devices update their drivers
rather conservatively, the effect of this will only slowly take
effect and even in case of major issues on some drivers (maybe v3d?)
likely allow us to add block rules before hitting many users.
Differential Revision: https://phabricator.services.mozilla.com/D154134
Move popup window move-to-rect config (anchor canculation, check if we need it and can use it) to a new method WaylandPopupCheckAndGetAnchor().
Depends on D153860
Differential Revision: https://phabricator.services.mozilla.com/D154012
Move-to-rect fails to position and show a popup when the popup anchor is outside of its parent window area.
For instance we can't use a rectangle of 10x10 pixels located at -20, -20 as an anchor as it leads to invisible popup window.
But that scenario can happen so we need to use plain move in such case which works and places the popup to -20, -20 coordinates.
Differential Revision: https://phabricator.services.mozilla.com/D153860
- In order to get tooltip position we need to use gtk_window_get_position() as it cover case when GdkWindow is not placed yet.
- Use both gdk_window_move()/gdk_window_move() to reset widget position as a workaround for https://gitlab.gnome.org/GNOME/gtk/-/issues/4071.
- Apply the workaround to tooltips only as it affects only temporary windows.
Differential Revision: https://phabricator.services.mozilla.com/D153859
As popups and Firefox main window can share refresh drivers we need to remove blocked compositing requests of hidden windows to make sure
we're not blocking other windows.
Implement moz_container_wayland_clear_waiting_to_show_flag() to clear MozContainer::waiting_to_show flag.
Depends on D154005
Differential Revision: https://phabricator.services.mozilla.com/D154006
Make RevokeTransactionIdAllocator() call part of nsBaseWidget::DestroyCompositor() so we don't need to do extra call.
Depends on D154004
Differential Revision: https://phabricator.services.mozilla.com/D154005
When entering fullscreen and saving the original position of a window,
also save the original position of its screen.
When leaving fullscreen, keep the window on the same screen. Restore its
_screen-relative_ position, rather than its absolute position.
Differential Revision: https://phabricator.services.mozilla.com/D153410
Use desktop pixels everywhere:
- Store the old window position as a `DesktopRect`.
- Since `GetRectDisplayPix` is infallible, use the convenience getter
that hands us a `DesktopIntRect`.
- Add a helper function that wraps `Resize()` and takes any `Rect`
which uses `DesktopPixel`s.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D153409
A window is fullscreenable iff it's a desktop window (that is, a
positional child of the desktop rather than of another window) -- and
desktop windows are the windows which use desktop-pixel units in
Resize().
Code coverage confirms that the branch when `BoundsUseDesktopPixels()`
returns `false` is never taken in tests.
Under the (hopefully justified) assumption that it's never taken at all,
no functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D153408
stransky
Mark Banner
Sandor Molnar
Andrew McCreight
Masayuki Nakano
Emilio Cobos Álvarez
Neill Miller
Pier Angelo Vendrame
Jamie Nicol
Butkovits Atila
Norisz Fay
Jan-Niklas Jaeschke
Ray Kraesig
Nick Alexander
Iulian Moraru
Hiroyuki Ikezoe
Nicholas Rishel
sotaro
Mike Kaply
Dão Gottwald
Yannis Juglaret
Ben Hearsum
Kershaw Chang
Frederic Wang
Marian-Vasile Laza
Calixte
Karl Tomlinson
Brad Werth
Nika Layzell
Cristian Tuns
Csoregi Natalia
Edgar Chen
Botond Ballo
Andrew Osmond
Ryan VanderMeulen
Greg Tatum
Razvan Cojocaru
Andi-Bogdan Postelnicu
David Shin
Makoto Kato
Mike Hommey
Timothy Nikkel
Neil Deakin
Robert Mader
Christian Holler
Kagami Sascha Rosylight