This greatly improves non-native theme on Windows in presence of fractional DPI
(see bug 1657191).
This matches what the Windows native theme does, to my knowledge, see
ScaleForFrameDPI in nsNativeThemeWin.h.
However I think the right fix is to not make these LayoutDeviceInt* things but
LayoutDevice*.
That's a bigger fix, and fits well as a follow-up to this bug, so let's land
this in the meantime.
Differential Revision: https://phabricator.services.mozilla.com/D97937
This is arguably a big outline compared with the usual one, so if it
somehow caused problems (which it really shouldn't because outline is
ink overflow rather than scrollable overflow) we could avoid painting
the second ring or such.
Differential Revision: https://phabricator.services.mozilla.com/D97157
What's implemented in this patch doesn't match the spec to 100%, but it comes
pretty close. This patch is cutting two corners: We're only using one shadow
instead of two, and we're using a smaller blur radius (2 instead of 2 and 4).
Both adjustments are done to improve performance; blurring is a computationally
expensive operation, so we should minimize its cost.
As the shadow color, I'm using a transparent black instead of a transparent
gray, because this makes it easier to do the blurring on an A8 surface rather
than on a full RGBA surface, given the current Moz2D API.
Differential Revision: https://phabricator.services.mozilla.com/D95090
The Mac theme will need this to check for RTL, and for whether the scrollbar has
the hover attribute, and for whether the scrollbar is on a dark background.
It looks like the philosophy of the virtual DrawScrollbar* methods was to supply
narrow pieces of information, instead of the frame itself. So this patch undoes
that separation of concerns.
In theory, we could grab the three pieces of state in
nsNativeBasicTheme::DrawWidgetBackground, but then we'd do a bunch of
computations (especially the "dark background" check) unnecessarily on platforms
that don't need them.
Differential Revision: https://phabricator.services.mozilla.com/D95077
This makes the disabled state look good because the track pieces are no longer
visible behind the partially-transparent disabled thumb.
Differential Revision: https://phabricator.services.mozilla.com/D94701
This feels a bit nicer but the difference isn't visible to the user.
But it demonstrates how we can fix progress bars.
Differential Revision: https://phabricator.services.mozilla.com/D94699
This removes some duplication and replaces it with a bool aHorizontal parameter.
It also splits out scroll corner drawing into its own method.
And it consistently passes down the DPI ratio into all methods.
Drive-by fixes:
- The border of horizontal scrollbars in the default theme now scales with the
DPI ratio.
- The border is device-pixel aligned by insetting the stroked rectangle by
half the stroke width.
This patch also changes the scroll corner drawing in the default theme to no
longer draw a border on the left. We can revert that if needed
Differential Revision: https://phabricator.services.mozilla.com/D94662
Otherwise on Windows, we have a ColorID::Scrollbar but not any of the other scrollbar part
colors, and the Windows-provided value for Scrollbar doesn't work well
with the default values for the other scrollbar parts that come from the
non-native theme.
Differential Revision: https://phabricator.services.mozilla.com/D93728
This allows it to be forward-declared (while a nested class cannot be),
such that headers files that use RectCallback by pointer or reference
do not need to include nsLayoutUtils.h.
This avoids including nsLayoutUtils.h in nsRange.h.
Differential Revision: https://phabricator.services.mozilla.com/D91685
We've had nsNativeBasicTheme enabled since 75, and all reported issues
were fixed real soon (and I haven't heard of any of them recently).
Given the non-native theme is likely changing in the future, I'd rather
not maintain three themes for Android :)
Differential Revision: https://phabricator.services.mozilla.com/D80105
See https://bugzilla.mozilla.org/show_bug.cgi?id=932410#c2 for the
context for which this pseudo-element was added.
In the previous patch, I had to special-case range appearance because of
this pseudo-class, but that patch makes this pseudo-class completely
redundant, as now all form controls, themed and unthemed, display
outlines, unless the native theme displays a focus indicator on its own.
Remove the special case, and make ranges use outlines like everything
else rather than this bespoke pseudo-element.
Differential Revision: https://phabricator.services.mozilla.com/D74734
See https://bugzilla.mozilla.org/show_bug.cgi?id=932410#c2 for the
context for which this pseudo-element was added.
In the previous patch, I had to special-case range appearance because of
this pseudo-class, but that patch makes this pseudo-class completely
redundant, as now all form controls, themed and unthemed, display
outlines, unless the native theme displays a focus indicator on its own.
Remove the special case, and make ranges use outlines like everything
else rather than this bespoke pseudo-element.
Differential Revision: https://phabricator.services.mozilla.com/D74734
Turns out we did have a hook for this already! But it is used to draw or
not inner button styles, so not quite equivalent.
I had to expand the amount of things it applies to because buttons and
such do paint focus indicators in all widgets. This patch could cause
some undesired outlines in some widgets. I hope not (I tried to audit to
the best of my knowledge), but in that case they'd be just more values
to add to the list.
Differential Revision: https://phabricator.services.mozilla.com/D74733
Turns out we did have a hook for this already! But it is used to draw or
not inner button styles, so not quite equivalent.
I had to expand the amount of things it applies to because buttons and
such do paint focus indicators in all widgets. This patch could cause
some undesired outlines in some widgets. I hope not (I tried to audit to
the best of my knowledge), but in that case they'd be just more values
to add to the list.
Differential Revision: https://phabricator.services.mozilla.com/D74733
This is used by platforms with overlay scrollbars, only in order to
reserve enough space for the chevron of the `<select>` element.
So our general min-widget-size, which is the same as for scrollbars
works.
Differential Revision: https://phabricator.services.mozilla.com/D71825
This is used by platforms with overlay scrollbars, only in order to
reserve enough space for the chevron of the `<select>` element.
So our general min-widget-size, which is the same as for scrollbars
works.
Differential Revision: https://phabricator.services.mozilla.com/D71825
By painting focus colors. I suspect this was mostly an oversight? But it is the
most obvious issue I always find with this theme.
I followed active > focus > hover, which seems to match what GTK does (and makes
sense, generally).
Differential Revision: https://phabricator.services.mozilla.com/D68088
--HG--
extra : moz-landing-system : lando
Only button / menulist-button were missing from the hard-coded if condition. I
don't think we ever want to override author padding, and this can cause compat
issues as the one in this bug.
I'm making HasAuthorSpecifiedRules fast in bug 1624080, btw.
Differential Revision: https://phabricator.services.mozilla.com/D68085
--HG--
extra : moz-landing-system : lando
By painting focus colors. I suspect this was mostly an oversight? But it is the
most obvious issue I always find with this theme.
I followed active > focus > hover, which seems to match what GTK does (and makes
sense, generally).
Differential Revision: https://phabricator.services.mozilla.com/D68088
--HG--
extra : moz-landing-system : lando
Only button / menulist-button were missing from the hard-coded if condition. I
don't think we ever want to override author padding, and this can cause compat
issues as the one in this bug.
I'm making HasAuthorSpecifiedRules fast in bug 1624080, btw.
Differential Revision: https://phabricator.services.mozilla.com/D68085
--HG--
extra : moz-landing-system : lando
I've left checkbox / radio / range-thumb alone because they don't have borders
on gtk either. We need this for the next patch to fix our test.
In particular, our combination of padding + no border means that
sanityEventUtils tries to hit an <input>, but it hits the anonymous scrollable
element instead, and asserts that it doesn't.
I don't think that test is particularly correct, but implementing
GetWidgetBorder works around it, and seems like the right thing to do anyways.
Differential Revision: https://phabricator.services.mozilla.com/D66240
--HG--
extra : moz-landing-system : lando
I've left checkbox / radio / range-thumb alone because they don't have borders
on gtk either. We need this for the next patch to fix our test.
In particular, our combination of padding + no border means that
sanityEventUtils tries to hit an <input>, but it hits the anonymous scrollable
element instead, and asserts that it doesn't.
I don't think that test is particularly correct, but implementing
GetWidgetBorder works around it, and seems like the right thing to do anyways.
Differential Revision: https://phabricator.services.mozilla.com/D66240
--HG--
extra : moz-landing-system : lando
Emilio Cobos Álvarez
Simon Giesecke
Stephen A Pohl
Markus Stange
Cameron McCormack
Razvan Maries
Botond Ballo
Noemi Erli
Csoregi Natalia
Narcis Beleuzu
Bogdan Tara
Dorel Luca