Fission without WebRender is an unsupported configuration and enrolls
users based on their compositor. However because of our own rollout of
WebRender, a user might start in early beta with WebRender and lose it
in late beta, while they remain enrolled in the Fission experiment.
Also, a user could lose WebRender because of crashes or device reset,
and we may fall back to Basic.
This patch forces Software WebRender as available (but does not override
Hardware WebRender) if Fission is enabled. It also prevents fallback to
Basic layers when disabling acceleration due to crashes and runtime
errors, so the user will be stuck with Software WebRender at a minimum.
It also enables Software WebRender for Windows popups with transparency.
Differential Revision: https://phabricator.services.mozilla.com/D107661
The Linux styles match Adwaita trunk[1], so it's a bit smaller than the
native ones but I think that's fine (it matches other themes more
closely, like Arc).
On OSX the system color needs to be tweaked (will do in a follow-up)
since it is windows-style yellow right now, which is rather ugly. But
this is a progression regardless.
[1]: https://gitlab.gnome.org/GNOME/gtk/-/issues/3352
Differential Revision: https://phabricator.services.mozilla.com/D107548
Like it is in other platforms. We have no uses of this on the UI currently
except the one in the other patch on this bug, if I'm reading it correctly, and
this makes the popups look decent.
I have another alternative / complementary patch on the bug if you want, but
this shouldn't be objectionable regardless I think.
Differential Revision: https://phabricator.services.mozilla.com/D107574
We can't get meaningful drm info at about:config as the info gathered too early and GfxPlatformGtk() is not initialized yet.
Differential Revision: https://phabricator.services.mozilla.com/D107502
If we error out in, say, DrawSkeletonUI, the window we created will be orphaned
and left to sit there indefinitely. This patch fixes that by separating the
error from the consume result.
Differential Revision: https://phabricator.services.mozilla.com/D107301
There are two ranges here:
- The requested range aRange, and
- the IME composition range: [`mIMECompositionStart`, `mIMECompositionStart + [mIMECompositionString length]`].
Whenever this function was called with a requested range that included the IME
composition range and was larger than the IME composition range, we would
request an invalid substring, and doing so would trigger an Objective C exception.
Differential Revision: https://phabricator.services.mozilla.com/D107256
In D106726 this was changed to `GDK_IS_WAYLAND_DISPLAY` as a drive-by
cleanup, in order to eventually support compiling FF without X11 support.
Turns out that was misguided as it breaks compatability with
setups that have GTK compiled without Wayland support.
Stick to `GDK_IS_X11_DISPLAY` until we have a better solution.
Differential Revision: https://phabricator.services.mozilla.com/D107345
This isn't really an uneven border (because we snap border widths
correctly); this is the textfield border snapping differently than the
outline, actually, in a way such that the outline shows underneath. We
use negative offsets to try to cover the border but that breaks in this
case.
I thought of two ways to fix it, but this one looks slightly more
future-proof (and simpler), see the comment in ComputeBorderColor. Let
me know if you want me to go the other way (snapping offsets instead) or
both, actually.
The transparent border uncovered that the radius was slightly off, and
also that I forgot to snap the auto-style outline width properly, so I
fixed those drive-by too (without the first one stuff looks off
otherwise, at least, the second one I could move).
Differential Revision: https://phabricator.services.mozilla.com/D107287
This isn't really an uneven border (because we snap border widths
correctly); this is the textfield border snapping differently than the
outline, actually, in a way such that the outline shows underneath. We
use negative offsets to try to cover the border but that breaks in this
case.
I thought of two ways to fix it, but this one looks slightly more
future-proof (and simpler), see the comment in ComputeBorderColor. Let
me know if you want me to go the other way (snapping offsets instead) or
both, actually.
The transparent border uncovered that the radius was slightly off, and
also that I forgot to snap the auto-style outline width properly, so I
fixed those drive-by too (without the first one stuff looks off
otherwise, at least, the second one I could move).
Differential Revision: https://phabricator.services.mozilla.com/D107287
Although 11 years ago feature-checking for native menus made sense, right now we do not
expect any other OSes to implement native menus, and macOS' behaviour is currently not
quite right because we stopped exposing the relevant XPCOM component.
The change in browser-menubar.inc fixes macOS behaviour. The nsWidgetsCID.h change
is just clean-up.
Differential Revision: https://phabricator.services.mozilla.com/D106962
This code is no longer needed.
This patch also removes a comment that was referring a CoreAnimation pref that
no longer exists, and replaces it with a better comment.
Differential Revision: https://phabricator.services.mozilla.com/D107254
I'm not sure whether we should deal with ancestor scales and such. There
seemed to be a discussion about that in D77436 but dealing with
partially-3d-transformed content sounds like a massive pain. For now
this fixes the start point, which is a progression.
Differential Revision: https://phabricator.services.mozilla.com/D106896
This removes some polymorphism and makes it easier to understand what's actually going on.
The explicit if checks added in this patch will go away once nsMenuX and nsMenuItemX are unified.
Differential Revision: https://phabricator.services.mozilla.com/D106376
Andrew Osmond
Emilio Cobos Álvarez
mazin
Simon Giesecke
owlishDeveloper
stransky
Doug Thayer
Bogdan Tara
alaaemad
Markus Stange
Robert Mader
Cosmin Sabou
Alexandru Michis
Brindusan Cristian
Gijs Kruitbosch
Tom Schuster