This revision modifies the Windows definitions of Field, Fieldtext, and
MozDisabledField for high contrast mode. Scoping this more directly
to high contrast mode avoids undesirable knock-on effects in other schemes. In
particular, we want to keep Field mapping to field-like colors, rather than
button colors. This fixes the color of autofill richlistbox. This revision also
fixes the HCM color of disabled checkboxes and radio buttons, which weren't
discernible.
Differential Revision: https://phabricator.services.mozilla.com/D215176
This revision updates the HCM colors of many controls. In particular:
- HCM hover and active states for checkboxes, radio buttons are now discernible
- HCM focus ring colors fixed
- Field, Disabledfield on Windows adjusted to COLOR_BTNFACE
- FieldText on Windows adjusted to COLOR_BTNTEXT to match
- checkbox, radio button colors fixed to more closely match design
Differential Revision: https://phabricator.services.mozilla.com/D213674
This was needed because we didn't use to override the color of the
textfield, so it needed to work with whatever color was there already.
Now that we enforce the color however, there's no point on it being
semi-transparent.
Add a darker version of the color so that it also works on dark mode
(<input style="color-scheme: dark"> or so).
Now that it's opaque, there's no need for Theme.cpp to blend with the
field background.
Differential Revision: https://phabricator.services.mozilla.com/D209021
Also, rewrite GetInlineDir() and GetBlockDir() to remove bit operations for
computing the InlineDir and BlockDir enum variants.
Differential Revision: https://phabricator.services.mozilla.com/D208176
This only really takes care of making it compile, although there are
still missing pieces for other directories to rely on it. This is enough
to unblock a bunch of other work.
While here, remove `virtual` on methods with `override`.
Differential Revision: https://phabricator.services.mozilla.com/D203198
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
Now that we have a DocumentState type we can be a bit less explicit
(before this used EventStates, so the extra Document in the names was
useful).
Differential Revision: https://phabricator.services.mozilla.com/D190602
The scrollcorner isn't a child of a scrollbar so we don't find it.
Instead, check for the scrollable node. This info is only used on macOS,
this fixes the rendering of rtl scrollcorners with non-overlay
scrollbars, e.g.:
<div style="border: 1px solid; width: 100%; height: 100%; overflow: scroll; direction: rtl"></div>
Or so.
Differential Revision: https://phabricator.services.mozilla.com/D181259
This removes the capability of having differently-sized vertical and
horizontal scrollbars (which is only potentially used in windows, and in
practice almost-never used). For that case, we choose the larger of
vertical/horizontal scrollbar sizes.
This is in order to be able to realistically expose the scrollbar size
to CSS, see blocked bug.
We make RecomputeScrollbarParams the central place where each scrollbar
style decides its sizes, and make GetDPIRatioForScrollbarPart handle the
cocoa special-case of scaling to 1 or 2, but nothing else.
Differential Revision: https://phabricator.services.mozilla.com/D168080
Move most the event handling stuff to the DOM. I've left nsMenuBarFrame
for now, but I will be removing that in the future.
The basic set up is:
* nsMenuParent becomes XULMenuParentElement (menubar or popup, manages
the current active menu item)
* nsMenuFrame -> XULButtonElements that return true for IsMenu().
Can't use XULMenuElement because of <button type=menu>, which
behaves like a, well, menu.
This makes the a11y events for menus (DOMMenuItem{Active,Inactive}) make
sense (before that we were firing duplicate Inactive events etc, and the
event order was rather suspicious).
Differential Revision: https://phabricator.services.mozilla.com/D164210
Move most the event handling stuff to the DOM. I've left nsMenuBarFrame
for now, but I will be removing that in the future.
The basic set up is:
* nsMenuParent becomes XULMenuParentElement (menubar or popup, manages
the current active menu item)
* nsMenuFrame -> XULButtonElements that return true for IsMenu().
Can't use XULMenuElement because of <button type=menu>, which
behaves like a, well, menu.
This makes the a11y events for menus (DOMMenuItem{Active,Inactive}) make
sense (before that we were firing duplicate Inactive events etc, and the
event order was rather suspicious).
Differential Revision: https://phabricator.services.mozilla.com/D164210
[Int]CoordTyped no longer inherits Units because otherwise
instances of [Int]IntPointTyped may get one Base subobject because
it inherits Units, and others because of BasePoint's Coord members,
which end up increasing the [Int]CoordTyped's objects size (since
according to the ISO C++ standard, different Base subobject are
required to have different addresses).
Differential Revision: https://phabricator.services.mozilla.com/D160713
We haven't seen this with Adwaita because it uses dark tooltips in both
light and dark mode, so stuff kinda worked out in the end.
Differential Revision: https://phabricator.services.mozilla.com/D159966
The previous patch made me realize that we have this widget-imposed size
for color controls which doesn't match any other browser. This patch
removes it.
I don't feel strongly whether we should land this other than "it matches
other browsers, and removes a special case from Gecko". Behavior might
be simpler to understand for authors this way.
Differential Revision: https://phabricator.services.mozilla.com/D158620
The XUL behavior in nsBox.cpp is fairly different to what the non-XUL
layout code paths do. In particular, canOverride=false means that the
min-{width,height} properties cannot go under the min widget size of the
widget, but that doesn't mean that intrinsic sizes don't affect the
final size of the widget.
This is very visible if you turn on flex emulation on Windows or macOS,
where the toolbar has an appearance that returns
width=0,height=N,canOverride=false.
With flex emulation we'd collapse the item to be zero-width, which is
not good at all.
The good thing is that this is no longer exposed to the web
(non-native-theme always returns canOverride=true), and our front-end
code doesn't seem to rely on this, so we can just remove support for
canOverride=false.
Differential Revision: https://phabricator.services.mozilla.com/D158608
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
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
This also makes stuff like `CSSPixel::ToAppUnits(<integer>)` not do
floating point math, which should be slightly faster.
Differential Revision: https://phabricator.services.mozilla.com/D150465
Nathan LaPre
Irene Ni
Emilio Cobos Álvarez
Aron Cseh
Otto Länd
Ting-Yu Lin
Sebastian Hengst
tannal
Gregory Pappas
Mike Hommey
Morgan Rae Reschenberg
Jonathan Kew
Iulian Moraru
Noemi Erli
Csoregi Natalia
Zach Hoffman
Zach Hoffman
Razvan Cojocaru
criss
smolnar