Eventually we should support all of them, but for now they are only used
by native code (unless you enable the color-scheme pref) and these will
be enough.
Differential Revision: https://phabricator.services.mozilla.com/D126737
The Nvidia driver does not yet support `EGL_GENERATE_RESET_ON_VIDEO_MEMORY_PURGE_NV`,
triggering bug 1731172 (see bug 1731172 comment 13).
In Wayland sessions, however, setups currently need to have the alternative
(and more involved) solution around `NVreg_PreserveVideoMemoryAllocations`
configured to not run into similar issues for the whole desktop.
This is not the case for most Xorg setups, thus don't ship EGL there for now.
We can enable it again once either `EGL_GENERATE_RESET_ON_VIDEO_MEMORY_PURGE_NV`
is supported or `NVreg_PreserveVideoMemoryAllocations` is the default (and
detectable).
While on it, also allow HW-WR on Nvidia on native Wayland again. The
issue why this blocklist entry was added was solved soon afterwards and
was reported to work now. Also, native Wayland is still not the default,
so this does not affect default configuration.
Differential Revision: https://phabricator.services.mozilla.com/D126344
We only draw a scrollbar thumb, so it's easy enough (fair amount of
boilerplate, though).
For now I've done the trivial thing (keep painting a round thumb without
other fancy things), as that's what we were doing, but in the future we
should consider drawing a stroke around the thumb like cocoa does to add
more contrast.
This patch does change behavior in some cases. For example dark websites
now get a lighter, easier to distinguish scrollbar, thanks to the
scrollbar darkening code in nsNativeBasicTheme.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D125826
We only draw a scrollbar thumb, so it's easy enough (fair amount of
boilerplate, though).
For now I've done the trivial thing (keep painting a round thumb without
other fancy things), as that's what we were doing, but in the future we
should consider drawing a stroke around the thumb like cocoa does to add
more contrast.
This patch does change behavior in some cases. For example dark websites
now get a lighter, easier to distinguish scrollbar, thanks to the
scrollbar darkening code in nsNativeBasicTheme.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D125826
widget/windows/nsAppShell.cpp(685,10): error: variable 'uiMessage' set but not used [-Werror,-Wunused-but-set-variable]
bool uiMessage = false;
^
widget/windows/TaskbarPreview.cpp(370,11): error: variable 'hr' set but not used [-Werror,-Wunused-but-set-variable]
HRESULT hr;
^
Differential Revision: https://phabricator.services.mozilla.com/D126461
We only draw a scrollbar thumb, so it's easy enough (fair amount of
boilerplate, though).
For now I've done the trivial thing (keep painting a round thumb without
other fancy things), as that's what we were doing, but in the future we
should consider drawing a stroke around the thumb like cocoa does to add
more contrast.
This patch does change behavior in some cases. For example dark websites
now get a lighter, easier to distinguish scrollbar, thanks to the
scrollbar darkening code in nsNativeBasicTheme.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D125826
Actually, date, datetime-local and time won't set correct `mHTMLInputType`
in `InputContext` since focused `aContent` isn't input element on UAWidget.
Another attribute (`inputmode`) is still correct value since `IMEState` isn't
editable, even if this isn't fixed.
Differential Revision: https://phabricator.services.mozilla.com/D126576
Wayland/Gtk sets drag state right after drag_motion event only.
While we're reading data for child process we're getting 'drag_motion' events from nested loop.
We don't know the final D&D state yet as we need reply from the child process.
When we set the D&D state latter, it's ignored by Gtk and D&D is considered as
canceled by client.
Right now we explicitly state 'drag denied' after D&D start until we have a reply from child process.
We're changing it to 'drag accepted' on Wayland until we have a reply from child process
and we also send the reply in WindowDragMotionHandler() to fulfill Wayland protocol needs.
It does not change final D&D state - we get the data only when child process requests it.
Differential Revision: https://phabricator.services.mozilla.com/D126226
Right now we query all MIME data types during D&D operation and rely on Gtk to filter out
missing ones. It leads to possible D&D failures as we can't process D&D events
from Gtk during it.
This patch does:
- Query MIME types available for D&D transfer by nsDragService::GetDragFlavors().
- Quit early at nsDragService::GetTargetDragData() when requested MIME can't be transferred by D&D.
- Use gdk_drag_context_get_suggested_action() instead of gdk_drag_context_get_actions().
- Check mTargetWindow before we use it.
Differential Revision: https://phabricator.services.mozilla.com/D126200
Wayland/Gtk sets drag state right after drag_motion event only.
While we're reading data for child process we're getting 'drag_motion' events from nested loop.
We don't know the final D&D state yet as we need reply from the child process.
When we set the D&D state latter, it's ignored by Gtk and D&D is considered as
canceled by client.
Right now we explicitly state 'drag denied' after D&D start until we have a reply from child process.
We're changing it to 'drag accepted' on Wayland until we have a reply from child process
and we also send the reply in WindowDragMotionHandler() to fulfill Wayland protocol needs.
It does not change final D&D state - we get the data only when child process requests it.
Differential Revision: https://phabricator.services.mozilla.com/D126226
With EGL enabled by default (bug 1695933) and the biggest blocker,
bug 1635186, apparently not being reproducible anymore on recent
distributions, lets finally enable HW-WR on Xwayland by default.
Differential Revision: https://phabricator.services.mozilla.com/D125530
The Intel DDX driver is known to cause troubles with HW-WR and
has been deprecated by most distributions, in favor of the glamor
based "modesetting" driver.
Lets blocklist it. This will mostly affect older/legacy setups.
Note: the xrandr boilerplate code in glxtest will be useful for
better multi-screen detection in a follow up patch. The current
legacy X11 screen detection does not work in composited environments,
always reporting one single big screen with the combined size.
Xrandr allows for correct detection in such setups.
Differential Revision: https://phabricator.services.mozilla.com/D126221
When we get data from D&D operation by nsWindow::OnDragDataReceivedEvent, speed up data transfer to child process by
WindowDragMotionHandler() call.
Differential Revision: https://phabricator.services.mozilla.com/D126211
Right now we query all MIME data types during D&D operation and rely on Gtk to filter out
missing ones. It leads to possible D&D failures as we can't process D&D events
from Gtk during it.
This patch does:
- Query MIME types available for D&D transfer by nsDragService::GetDragFlavors().
- Quit early at nsDragService::GetTargetDragData() when requested MIME can't be transferred by D&D.
- Use gdk_drag_context_get_suggested_action() instead of gdk_drag_context_get_actions().
- Check mTargetWindow before we use it.
Differential Revision: https://phabricator.services.mozilla.com/D126200
We sometimes miss reply to D&D motion event due to delayed DnsDragService::RunScheduledTask() call.
We can't call D&D handler directly from drag-motion event as it causes nested recursions and re-entrance
in glib loop so use higher priority for the delayed handler call at least.
Disable re-entrance of nsDragService::RunScheduledTask() which may happen when
we get D&D data from drag_drop event.
Provide more loggig to D&D code.
Differential Revision: https://phabricator.services.mozilla.com/D126182
Other apps might block the clipboard. There's no clean fix for this,
because Windows doesn't provide a reasonable clipboard API. But this
should solve the problem in practice. That's based on the assumption
that other apps cooperate and access the clipboard only for a short
duration.
Differential Revision: https://phabricator.services.mozilla.com/D125661
This is another requirement for the video display layer to be detached and use
less power: the layer must be topmost and have only a black layer behind it.
Differential Revision: https://phabricator.services.mozilla.com/D124150
This allows the native layer code to determine when specialized video layers
might be beneficial for reducing power consumption.
Differential Revision: https://phabricator.services.mozilla.com/D124149
`swrast` is reported as fallback software driver. This happens with
unknown sw-drivers (e.g. zink on lavapipe), but also when `glxtest`
incorrectly detects software rendering. This can be confusing and
is basically always wrong - by now it even got removed from Mesa
and for years only has been used on niche setups.
Make this more clear by using "mesa/software-unknown" instead.
No functional change beyond reporting intended here.
Differential Revision: https://phabricator.services.mozilla.com/D126052
We need to use standins for CSS-accesible colors in high contrast mode
(when appropriate) so that the CSS color matches the one in forms.css.
But this is not needed for e.g. scrollbar colors, which are not
CSS-accessible. So shuffle around the checks so that we account for
that as we should.
Differential Revision: https://phabricator.services.mozilla.com/D125830
We now always use the non-native theme, and the Android native theme
never did much anyways, so let's remove it, no point in keeping
around dead code.
Differential Revision: https://phabricator.services.mozilla.com/D125825
Tim Giles
Emilio Cobos Álvarez
stransky
Sandor Molnar
Robert Mader
Csoregi Natalia
criss
Mike Hommey
Tom Schuster
Makoto Kato
Stephen A Pohl
Cosmin Sabou
Mirko Brodesser
Butkovits Atila
Junjie Ying
lamoure6
Brad Werth
David Parks
Botond Ballo