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
Add a dom/base/rust crate called just "dom" where we can share these.
Most of the changes are automatic:
s/mozilla::EventStates/mozilla::dom::ElementState/
s/EventStates/ElementState/
s/NS_EVENT_STATE_/ElementState::/
s/NS_DOCUMENT_STATE_/DocumentState::/
And so on. This requires a new cbindgen version to avoid ugly casts for
large shifts.
Differential Revision: https://phabricator.services.mozilla.com/D148537
Adjust the dropdown-arrow to take into account the orientation of the
dropdown itself, so as to point in the direction the dropdown should
emerge from.
Differential Revision: https://phabricator.services.mozilla.com/D139091
Our scrollbar drawing code had various RTL checks for the writing mode.
These checks were busted since bug 1554571 (where the writing-mode of
the scrollbar frames and so on is reset). However, they also wouldn't be
correct (we allow to customize scrollbar position via pref).
Instead, look at the scrollable frame to really know if the scrollbar is
on the right or not. Compute that once in Theme.cpp and pass it around
light we were doing for the "is horizontal" bit.
Differential Revision: https://phabricator.services.mozilla.com/D145865
This might be a bit more controversial, but matches Chromium at least,
and it makes sense to me... Would've also fixed this particular bug,
though I think the previous patch is also desirable if devtools ever
wants to add `:disabled` locked states or so.
Depends on D140529
Differential Revision: https://phabricator.services.mozilla.com/D140530
This might be a bit more controversial, but matches Chromium at least,
and it makes sense to me... Would've also fixed this particular bug,
though I think the previous patch is also desirable if devtools ever
wants to add `:disabled` locked states or so.
Depends on D140529
Differential Revision: https://phabricator.services.mozilla.com/D140530
This is faster and more straight-forward code than the old
ShouldUseDarkScrollbar shenanigans, and allows to have dark-themed
scrollbars.
Differential Revision: https://phabricator.services.mozilla.com/D138077
tannal