This should make the optimization landed earlier in this bug apply for
some of the NotifyThemeChanged() calls in nsWindow.cpp which are causing
all the extra invalidations.
If we know that system colors/fonts didn't change, we can avoid doing a
bunch of reflow work and the patch from earlier in the bug can avoid
re-rasterizing images too.
Differential Revision: https://phabricator.services.mozilla.com/D94425
Similar to bug 1280653, it appears that GLX invalidates the back buffer
while we are drawing. The only indication we get of this are resize and
configure events from X. We suppress the configure event for popups for
various reasons, so this patch explicitly generates a forced recomposite
of the frame. It does it immediately so that most of the time it should
beat the presentation of the buffer and avoid displaying of the bad
frame to the user; popups generally are not complicated and should have
plenty of budget to perform the second composite.
Differential Revision: https://phabricator.services.mozilla.com/D93862
On Linux, Firefox is listening on notify::scale-factor to detect DPI
change. However, scale-factor is an int and on the lower-end side of
the DPI scale, some devices are using fractional scale factors encoded
into Xft/DPI setting. Changing from ×1 to ×1.5 scale is therefore
undetected.
The proposed change is two-folds:
- remove use of a cached sDPI value and rely on GTK being the cache
- listening on notify::gtk-xft-dpi to trigger a DPI change
What is missing:
- performance evaluation of not caching sDPI (on a 10s session
loading 2 pages, there is an "overhead" of 6ms on my setup, nothing
visible from my point of view)
- when changing Xft/DPI and scale, the change is done twice, this
seems harmless
Differential Revision: https://phabricator.services.mozilla.com/D92095
The tooltip width can be real number in the hidpi display setup
or when the font scaling is used. In this case the nsWindow GTK
implementation will cut out the non integer part which leads to
narrowing the tooltip and later overflowing the text which
is in the tooltip to next line. This workaround patch adds
a one pixel to the tooltip frame when the tooltip has real number
width or height.
Differential Revision: https://phabricator.services.mozilla.com/D92620
This allows mesa to continue using the existing vsync implementation
and nvidia to use the new EGL xvisual logic.
It is an intermediate solution until the issues are fixed. However,
assuming it will take a while to do so, it's probably worth it.
Differential Revision: https://phabricator.services.mozilla.com/D92466
Until bug 1617002 Firefox would unintendedly not get unredirected on X11
when used with WR and OpenGL as it didn't fullfill the requirements -
not being transparent.
Now that this is fixed, fullscreen unredirection can happen on certain
compositors. For the basic compositor we already explicitely ask to not
get unredirected - do that for all backends.
Also adapt tests accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D92180
Until bug 1617002 Firefox would unintendedly not get unredirected on X11
when used with WR and OpenGL as it didn't fullfill the requirements -
not being transparent.
Now that this is fixed, fullscreen unredirection can happen on certain
compositors. For the basic compositor we already explicitely ask to not
get unredirected - do that for all backends.
Also adapt tests accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D92180
Until bug 1617002 Firefox would unintendedly not get unredirected on X11
when used with WR and OpenGL as it didn't fullfill the requirements -
not being transparent.
Now that this is fixed, fullscreen unredirection can happen on certain
compositors. For the basic compositor we already explicitely ask to not
get unredirected - do that for all backends.
Differential Revision: https://phabricator.services.mozilla.com/D92180
Until bug 1617002 Firefox would unintendedly not get unredirected on X11
when used with WR and OpenGL as it didn't fullfill the requirements -
not being transparent.
Now that this is fixed, fullscreen unredirection can happen on certain
compositors. For the basic compositor we already explicitely ask to not
get unredirected - do that for all backends.
Differential Revision: https://phabricator.services.mozilla.com/D92180
Until bug 1617002 Firefox would unintendedly not get unredirected on X11
when used with WR and OpenGL as it didn't fullfill the requirements -
not being transparent.
Now that this is fixed, fullscreen unredirection can happen on certain
compositors. For the basic compositor we already explicitely ask to not
get unredirected - do that for all backends.
Differential Revision: https://phabricator.services.mozilla.com/D92180
Popups like autoscroll does not have anchor rectangle while it has set negative
margin to center the popup under cursor. Adding this offset to the final position
leads recursive repositioning of the popup to upper-left position under Wayland.
On the other hand we have to keep the offset for the popups with given anchor rect
like hamburger menus which use the offset to correctly position their pointing arrow.
Differential Revision: https://phabricator.services.mozilla.com/D92045
This allows it to be forward-declared (while a nested class cannot be),
such that headers files that use RectCallback by pointer or reference
do not need to include nsLayoutUtils.h.
This avoids including nsLayoutUtils.h in nsRange.h.
Differential Revision: https://phabricator.services.mozilla.com/D91685
- Use toplevel transparent window by default.
- Use Client decoration for Deepin desktop.
- Hide system titlebar by default on latest KDE versions.
- Hide system titlebar by default on Gnome/Pantheon.
Differential Revision: https://phabricator.services.mozilla.com/D89363
What is going on is that nsComboboxControlFrame first positions the 0x0
widget, then sizes it. But when moving a 0x0 wayland popup, we just bail
out in NativeMoveResizeWaylandPopup().
So unless we also change the offset in some other way, and hit this
code:
https://searchfox.org/mozilla-central/rev/dc30fc92f2d02abe716426df7eff0f0bbb907da2/view/nsView.cpp#335
when updating the view tree (which doesn't happen with the maximized
window, and actually it's a bit questionable that it happens without it,
there may be some pre-existing coordinate space confusion there) we'll
end up in a plain Resize() rather than MoveResize(), and never position
the widget at the right place.
This doesn't happen for regular web content because the new print dialog
lives in the parent process (which uses nsComboboxControlFrame) rather
than on the child (which uses nsMenuPopupFrame).
Differential Revision: https://phabricator.services.mozilla.com/D89320
When user adds and sets widget.workspace-management preference value, use it as override to restore windows on particular worspaces.
Differential Revision: https://phabricator.services.mozilla.com/D86205
The new implementation is based on traversing the parent window hierarchy and accumulating relative positions. The implementation unfortunately has to be disabled while another issue is investigated.
Differential Revision: https://phabricator.services.mozilla.com/D85278
* always update the opaque region if the toplevel window allocation
changes - this fixes opaque regions on X11 with WR and OGL renderers,
as GTK resets the opaque region in this case. The previous solution
was modeled similar to what's done on Windows - we have to follow GTK
though.
* use `gdk_window_set_opaque_region` also for Wayland - this fixes
occasional glitches where the opaque region was not properly updated.
Let GTK handle that instead, as it has better control of the internals.
* remove a failed attempt to work around bug 1615098 from
MozContainerWayland
* repurpose `widget.wayland.use-opaque-region` for subsurface opaque
regions and disable it by default. We want to enable it again eventually
and not all Wayland compositors suffer from bug 1615098
* some cleanups - some optimizations should not be needed anymore now
Unfortunately this does not cover the classic title bar yet - that will
need to be done in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D84024
It has been deprecated since GTK 3.12 as it can not reliable work on
modern X11 compositors.
On Wayland, the equivalent functionally is part of the core protocol
via frame callbacks.
While on it, mark a call to `gtk_widget_set_double_buffered` explicitly
limited to X11.
Differential Revision: https://phabricator.services.mozilla.com/D84624
