This is to be landed after the soft-freeze of course. This patch aligns
with Linux, removing the ability to draw native-looking buttons and
progress-bars on Windows.
Note that checkboxes, menus, and a bunch of other things already use
non-native drawing (including virtually all our main browser UI), so
this only affects "secondary" UI: the old profile manager, a couple
dialogs, the bookmarks sidebar panel searchbox, page info window...
Also, we already effectively fallback to the non-native theme in dark
mode, and our non-native theme looks reasonably windows-like.
Advantages (apart from not having to maintain all this code) is that the
non-native theme is also faster, and this paves the way towards making
the layout side of theming simpler.
In order to make buttons still react to hover feedback, fix the
button{hover/active} system colors to match the windows task manager.
Also adjust the padding to match what the non-native theme returned.
Things that I've tested:
* Buttons (profile manager, create profile wizard, page info window).
* Trees and other listboxes (profile manager, page info window).
* <input type=text> (bookmarks sidebar)
* <menulist> (ask to save dialog, note it needs D250006 to show the
dropmarker and have the right spacing).
Things that were supported but are unused (to the best of my ability):
* <progress> (there are a few like the downloads popup but they're
custom).
* <input type=range>
Note that the places window already uses non-native painting.
IMHO the only thing that _could_ be considered a regression is the
button rendering (debatable tho). I think longer term we might want to
move to our design system's button tokens and such, but over all things
look a bit more consistent and I'm happy to look at improving the colors
here in a follow-up to match the Win32 blue or something else if we deem
it worth it.
Differential Revision: https://phabricator.services.mozilla.com/D250325
This is to be landed after the soft-freeze of course. This patch aligns
with Linux, removing the ability to draw native-looking buttons and
progress-bars on Windows.
Note that checkboxes, menus, and a bunch of other things already use
non-native drawing (including virtually all our main browser UI), so
this only affects "secondary" UI: the old profile manager, a couple
dialogs, the bookmarks sidebar panel searchbox, page info window...
Also, we already effectively fallback to the non-native theme in dark
mode, and our non-native theme looks reasonably windows-like.
Advantages (apart from not having to maintain all this code) is that the
non-native theme is also faster, and this paves the way towards making
the layout side of theming simpler.
In order to make buttons still react to hover feedback, fix the
button{hover/active} system colors to match the windows task manager.
Also adjust the padding to match what the non-native theme returned.
Things that I've tested:
* Buttons (profile manager, create profile wizard, page info window).
* Trees and other listboxes (profile manager, page info window).
* <input type=text> (bookmarks sidebar)
* <menulist> (ask to save dialog, note it needs D250006 to show the
dropmarker and have the right spacing).
Things that were supported but are unused (to the best of my ability):
* <progress> (there are a few like the downloads popup but they're
custom).
* <input type=range>
Note that the places window already uses non-native painting.
IMHO the only thing that _could_ be considered a regression is the
button rendering (debatable tho). I think longer term we might want to
move to our design system's button tokens and such, but over all things
look a bit more consistent and I'm happy to look at improving the colors
here in a follow-up to match the Win32 blue or something else if we deem
it worth it.
Differential Revision: https://phabricator.services.mozilla.com/D250325
Eventually I want to simplify a lot of how the theming code deals with
overriding border / padding, and this helps with that.
Since bug 1765076 this isn't used anywhere, so I think simplifying this
is the right trade-off. Thunderbird also doesn't use it.
Differential Revision: https://phabricator.services.mozilla.com/D250314
Since now we rely on the non-native combobox button, we need the same
dropmarker.
Remove a useless override for the native windows theme too.
Differential Revision: https://phabricator.services.mozilla.com/D247838
There's no reason this is a separate singleton. This makes sure they are in sync.
THEMECHANGED already triggers LookAndFeel updates via WinEventObserver.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D243342
There's no reason this is a separate singleton. This makes sure they are in sync.
THEMECHANGED already triggers LookAndFeel updates via WinEventObserver.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D243342
* Spinner and spinner-textfield are totally unused.
* up/down buttons are only used for <input type=number>. The only
number inputs we have in our UI use the non-native theme already (the
print preview dialog).
* Windows already always uses non-native spinner up/down unconditionally, and
linux does it on mismatched color scheme.
We can probably live without native theme support for these. It's
completely unused right now.
Differential Revision: https://phabricator.services.mozilla.com/D236904
We had the same list of attributes in multiple places, put it in
Theme.cpp.
Only a few states can change widget state. Just hardcode them in
RestyleManager.cpp (where there was already some of it) instead of
reusing a weird API.
Shouldn't have any behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D222160
We had the same list of attributes in multiple places, put it in
Theme.cpp.
Only a few states can change widget state. Just hardcode them in
RestyleManager.cpp (where there was already some of it) instead of
reusing a weird API.
Shouldn't have any behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D222160
Most of this code is already dead. The native appearance on macOS
doesn't work on dark mode, and on Windows and Linux we are already
overriding it.
Add a first-column tree property to be able to align the inner borders
on macOS properly.
Differential Revision: https://phabricator.services.mozilla.com/D206526
* Linux doesn't support them already.
* macOS doesn't draw anything either.
* Windows doesn't have dark-color-scheme support so the relevant
windows that have them need to set appearance none already.
Remove them and simplify the relevant code.
Differential Revision: https://phabricator.services.mozilla.com/D205872
* Linux doesn't support them already.
* macOS doesn't draw anything either.
* Windows doesn't have dark-color-scheme support so the relevant
windows that have them need to set appearance none already.
Remove them and simplify the relevant code.
Differential Revision: https://phabricator.services.mozilla.com/D205872
This fixes various things, like sort arrows not working, even in regular
non-mixed-color-scheme settings, and is a lot less code.
The toolbarbutton appearance on the problematic case described in
comment 0 could get some work (the extra borders aren't exactly pretty),
but it's still a much better improvement.
Differential Revision: https://phabricator.services.mozilla.com/D195345
In particular, spinner buttons, checkboxes, radio buttons, and the
menulist arrow.
These are all windows-style anyways, and look better than the native
counter-parts because they support webrender, zooming and scaling, etc.
The easiest way to see some of this in action is using ./mach run -P.
Differential Revision: https://phabricator.services.mozilla.com/D184648
Everytime I look at this code I find more stuff to remove... :)
-moz-default-appearance: groupbox is not used anywhere.
menulist-text is, but it does nothing (it only would prevent drawing a
background, but we don't specify another background anyways).
Differential Revision: https://phabricator.services.mozilla.com/D184647
Some basic clean-up. I want to do this before doing bigger changes in
bug 1843044.
There's tons more code that can get cleaned-up on the widget side, but
let's start with this.
Differential Revision: https://phabricator.services.mozilla.com/D183622
I was looking into simplifying our scrollbar styles:
* StyleAppearance::Resizer is not used in content, and some of the
values were only for <xul:window> which are not supported anymore.
* Statusbarpanel and Resizerpanel aren't used. Statusbar is only used
once on macOS so we only need to keep it there.
Differential Revision: https://phabricator.services.mozilla.com/D178374
I was looking into simplifying our scrollbar styles:
* StyleAppearance::Resizer is not used in content, and some of the
values were only for <xul:window> which are not supported anymore.
* Statusbarpanel and Resizerpanel aren't used. Statusbar is only used
once on macOS so we only need to keep it there.
Differential Revision: https://phabricator.services.mozilla.com/D178374
Sylvestre Ledru