Also, simplify some callers of `GetScrollTargetFrame()` to drop
`nsIScrollableFrame*` and unnecessary `do_QueryFrame`. We'll continue removing
more `nsIScrollableFrame*` in later parts.
Differential Revision: https://phabricator.services.mozilla.com/D211490
Also, simplify some callers of `GetScrollTargetFrame()` to drop
`nsIScrollableFrame*` and unnecessary `do_QueryFrame`. We'll continue removing
more `nsIScrollableFrame*` in later parts.
Differential Revision: https://phabricator.services.mozilla.com/D211490
In order to do it, expose the button padding to CSS via env(), and make
the buttons just use the regular drawing.
This slightly changes the padding to the end of the titlebar to match
one half of the inter-button spacing, rather that however much padding
the headerbar has.
We could improve on this slightly by also exposing the headerbar padding
and applying that to the last button, but that's not terribly easy to do
due to us supporting re-ordering of the titlebar buttons, and reversing
their placement, so it'd involve some rather hacky CSS. Not impossible,
but not trivial, and this looks good enough IMO.
Differential Revision: https://phabricator.services.mozilla.com/D202616
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
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
I didn't find a single GTK theme that drew something useful for this:
* The container appearance isn't needed. It is a hack needed to get the
right styles for the native checkbox, but that's it, we don't need to
expose it to CSS.
* The label appearance was meant to draw the focus outline but since it
didn't work reliably we've been doing it manually since seven years
ago (see bug 582951 and bug 1312169).
Other platforms also don't use these so this simplifies the code a bit.
Depends on D185279
Differential Revision: https://phabricator.services.mozilla.com/D185286
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
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
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
This makes our menus closer to GTK4, and depends less on the native menu
rendering etc. Thunderbird already does this to some extent.
Leave the old code behind a pref for now (just in case). Also fix some
code in nsNativeTheme::GetContentState (fixes rendering of radio menu
items).
Differential Revision: https://phabricator.services.mozilla.com/D175664
This makes our menus closer to GTK4, and depends less on the native menu
rendering etc. Thunderbird already does this to some extent.
Leave the old code behind a pref for now (just in case). Also fix some
code in nsNativeTheme::GetContentState (fixes rendering of radio menu
items).
Differential Revision: https://phabricator.services.mozilla.com/D175664
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
This element had a really weird dependency on the order of the command
events from the menuitems and the button which broke in bug 1790920.
Instead of keeping this element as a XULButtonElement, have a separate
button and popup. That's simpler and less prone to breakage, and allows
to get rid of special cases in Gecko.
Differential Revision: https://phabricator.services.mozilla.com/D158438
This element had a really weird dependency on the order of the command
events from the menuitems and the button which broke in bug 1790920.
Instead of keeping this element as a XULButtonElement, have a separate
button and popup. That's simpler and less prone to breakage, and allows
to get rid of special cases in Gecko.
Differential Revision: https://phabricator.services.mozilla.com/D158438
This patch shouldn't change behavior. The Cocoa changes in particular
just save useless frame tree walks, since ThemeColors already computes
the color scheme in ColorSchemeForWidget.
Differential Revision: https://phabricator.services.mozilla.com/D153424
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
Since callers want just an effective color to compute whether it's dark,
we simplify the API a bit too.
This makes sure we find the dark background in plain text documents.
Differential Revision: https://phabricator.services.mozilla.com/D151018
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
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
This patch is a bit bigger than I'd like, but it's mostly moving code
around to centralize the color/color-scheme decisions we make when
forcing colors.
In practice, the only behavior change should be that when "use system
colors" is false and we force colors, we force a color-scheme that
matches the user-chosen background (via the LookAndFeel::IsDarkColor
check).
That should make sure that text from system colors is light and matches
the user expectations.
Before this patch, we used to force the color-scheme to light, but that
was just so that we ended up looking at mLightColors. Instead, we
achieve that via a separate bit (mForcedLightColorSet, naming up for
debate, not a fan), so that we can use the right system colors
otherwise.
Another alternative I considered is making all non-link system colors
return mDefaultBackground / mDefault depending on whether they are
background / foreground colors. That seemed a lot more work and
potentially a regression in various ways. I think this should be
strictly an improvement instead.
Differential Revision: https://phabricator.services.mozilla.com/D142423
This patch is a bit bigger than I'd like, but it's mostly moving code
around to centralize the color/color-scheme decisions we make when
forcing colors.
In practice, the only behavior change should be that when "use system
colors" is false and we force colors, we force a color-scheme that
matches the user-chosen background (via the LookAndFeel::IsDarkColor
check).
That should make sure that text from system colors is light and matches
the user expectations.
Before this patch, we used to force the color-scheme to light, but that
was just so that we ended up looking at mLightColors. Instead, we
achieve that via a separate bit (mForcedLightColorSet, naming up for
debate, not a fan), so that we can use the right system colors
otherwise.
Another alternative I considered is making all non-link system colors
return mDefaultBackground / mDefault depending on whether they are
background / foreground colors. That seemed a lot more work and
potentially a regression in various ways. I think this should be
strictly an improvement instead.
Differential Revision: https://phabricator.services.mozilla.com/D142423
We decided to keep it when initially making scrollbars non-native, but I think
it's time for it to go, since it's pretty much untested.
Nobody has complained about the non-native scrollbars in chrome documents, and
the GTK scrollbar implementation is not suitable for content because it doesn't
support scrollbar-width among other things.
Differential Revision: https://phabricator.services.mozilla.com/D135670
This should be more flexible / less footgunny, always ensuring there's enough
contrast. If the front-end wants to override the non-native appearance they can
still do it using appearance: none of course.
This reverts my other CSS fixes for Windows dark mode for buttons / textfields,
as those are supported by nnt.
Patch incoming for Linux in bug 1733968, as Linux has a similar issue when it
can't draw mismatched widgets with the system theme (and we can fix it now).
I intentionally didn't override GetWidget{Padding,Border}, as to avoid changing
sizing unnecessarily (the non-native-theme is flexible enough to support
basically whatever size you throw at it, so it doesn't matter).
Differential Revision: https://phabricator.services.mozilla.com/D127645
There's only one meaningful usage of it, which is to disable native
appearance of the <input type=range> (the windows native theme is no
longer exposed to content).
<input type=range> is inconsistent with every other native widget, which
only disables native appearance if the author specifies backgrounds or
borders. So make it match literally all other widgets and simplify a bit
the code.
We had no tests for this special behavior, let me know if you think it's
worth adding one (but I don't feel very strongly about it).
Differential Revision: https://phabricator.services.mozilla.com/D127082
There's only one meaningful usage of it, which is to disable native
appearance of the <input type=range> (the windows native theme is no
longer exposed to content).
<input type=range> is inconsistent with every other native widget, which
only disables native appearance if the author specifies backgrounds or
borders. So make it match literally all other widgets and simplify a bit
the code.
We had no tests for this special behavior, let me know if you think it's
worth adding one (but I don't feel very strongly about it).
Differential Revision: https://phabricator.services.mozilla.com/D127082
Two changes:
* Make it work across document boundaries, so that it works on e.g., the
bookmarks sidebar.
* Don't bail out if there's no scrollable frame, as XUL <tree>s use raw
<scrollbar> elements without any scrollframe (gnarly). In that case, just
use the target frame, but make sure to skip over themed elements (like the
scrollbars themselves) so that we can find the right background.
The logic to check the canvas frame background etcetera was simpler in
FindNonTransparentBackgroundFrame. The only caller other than the
scrollbar darkening code is nsTextFrame, which should find a non-canvas frame
before anyways, but it doesn't hurt there.
Differential Revision: https://phabricator.services.mozilla.com/D114697
Ting-Yu Lin