This only hides the cursor if it's on the page you're editing, but given
that the point of the feature is to move the cursor out of the way, that
seems acceptable (and honestly it feels more of a feature than a bug).
This should work across platforms (though non-windows platforms need
ui.hideCursorWhileTyping=1 in about:config to enable).
Differential Revision: https://phabricator.services.mozilla.com/D171155
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
Implemented the inverted-colors media feature from Media Queries Level 5
for all platforms.
Spec: https://drafts.csswg.org/mediaqueries-5/#inverted
Platform specific implementations:
- Windows: Checks system color filter setting, and if it is inverted
(note: Windows does not live update due to having to read a reg key)
- Mac: Checks dedicated inverted accessibility system setting
- Android: Checks dedicated inverted system setting
- Linux: No GTK API exposes anything like it so always none
Locked behind new pref `layout.css.inverted-colors.enabled`,
always off by default for now.
Also added new WPT tests (none previously).
Other browsers:
- WebKit: shipped since Safari 9.1 (Jan 2017)
- Blink: no signal
Test page: https://goose.icu/inverted-colors
Differential Revision: https://phabricator.services.mozilla.com/D173201
Implemented the prefers-reduced-transparency media query for all
platforms.
Windows and Mac have specific settings which are used, others (Android
and Linux/GTK) have it enabled if prefers-reduced-motion is also enabled
as there is no dedicated setting to check.
Locked behind new pref `layout.css.prefers-reduced-transparency.enabled`,
off by default always for now.
Also added new WPT tests (none previously).
Demo video: https://goose.icu/firefox_prt.mp4
Test page: https://goose.icu/prefers-reduced-transparency
Differential Revision: https://phabricator.services.mozilla.com/D172424
Other browsers don't do this, and it might confuse users, see e.g., [1]
and bug 1813684.
Before Firefox 110, we didn't do it consistently, but I fixed that in
bug 1807687. See comments in the patch for context, [2] in particular:
> The code being removed here is intended to implement the Windows
> setting 'Underline access keys' in the Keyboard Accessibility
> control panel, which somewhat confusingly also controls whether
> focus rings appear by default when clicking on controls. The former
> part -- the showing and hiding of the underlines based on the
> setting -- was never yet implemented, this is bug 25894. The focus
> rings part was implemented.
Given:
* This setting is confusing.
* Modern windows apps and other browsers don't follow it.
* We already provide other means of achieving the same behavior
(browser.display.show_focus_rings=true).
It seems better to remove. I asked Neil in bug 1813684 in case he felt
more strongly about this, and didn't hear back.
[1]: https://www.reddit.com/r/firefox/comments/116n3kp/why_is_firefox_110_now_putting_a_blue_box_around/
[2]: https://phabricator.services.mozilla.com/D165578#5448547
Differential Revision: https://phabricator.services.mozilla.com/D170395
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
The "preferred" one is the behavior we have for chrome docs, where we
fall back always to the document's preferred color-scheme rather than
falling back to light.
We'll use this in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D154923
This matches what Linux and macOS do, and that allows the fix for bug 1782623
to work on Windows for unstyled selects.
This also simplifies the CSS (though it adds a new system color which is a bit
more annoying). I filed https://github.com/w3c/csswg-drafts/issues/7561 to
propose adding a more generic way to do this in the future (not just for
Firefox).
Differential Revision: https://phabricator.services.mozilla.com/D153549
This is reasonably straight-forward and should allow us change the
desired behavior on platforms if / when we need.
Also, this adds tests for the feature by using the relevant float pref
(though we can't easily assert the full-zoom behavior because it changes
the size of the reftest window itself).
Differential Revision: https://phabricator.services.mozilla.com/D148902
This is reasonably straight-forward and should allow us change the
desired behavior on platforms if / when we need.
Also, this adds tests for the feature by using the relevant float pref
(though we can't easily assert the full-zoom behavior because it changes
the size of the reftest window itself).
Differential Revision: https://phabricator.services.mozilla.com/D148902
GTK already did this, sorta, in a platform-specific way: by hacking in the
scale factor in the CSS screen code. I think this is cleaner, since we have a
centralized place to compute the full zoom in nsPresContext, and that code path
is fairly well tested.
This also would make it trivial to make this text zoom rather than full zoom in
the future, if we wanted (which is probably _technically_ more correct, even
though less pretty less pretty).
This also allows us to remove some hacks where we were undoing the text scale
factor on Linux (since stuff like scrollbars already ignore full zoom).
Depends on D148675
Differential Revision: https://phabricator.services.mozilla.com/D148676
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
To do this, we always draw the native titlebar behind the toolbox, and
then make the toolbox adapt to it by using the titlebar radius. This
makes us preserve the shadow properly.
On Wayland we'd double-draw the shadow (see bug 1509931 comment 4) so
this fixes it by trimming it as well using border-radius.
Differential Revision: https://phabricator.services.mozilla.com/D128681
This is based off work by smurfd. But this patch doesn't support buttons
both at the left and right, which simplifies a lot the implementation.
Also, clean-up the existing env variables while at it.
Co-authored-by: Nicklas Boman <smurfd@gmail.com>
Differential Revision: https://phabricator.services.mozilla.com/D132073
The previous patch would be a better fix, but it causes some xpcshell
crashes on Linux which I haven't figured out yet (because initializing
LookAndFeel initializes gfxPlatform).
This should be less risky and still fix the bug.
Differential Revision: https://phabricator.services.mozilla.com/D132011
To more properly support Linux having a different default at runtime.
Expose the resolved value in appinfo for convenience, and use it in the
front-end as needed.
Differential Revision: https://phabricator.services.mozilla.com/D129004
We use "is-in-chrome-docshell" rather than "is a chrome doc" so that about:
pages that are loaded in the content area (like about:addons etc) follow the
general content theme as well.
Cache the relevant color schemes since having that many branches on the default
system theme made me a bit uncomfortable, and this code can be called quite a
lot... Though it probably isn't such a huge deal. This makes us initialize the
theme right away, so make sure subclasses do the right thing. This in practice
was only an issue for GTK, which does cache the "system theme is dark" bit.
Differential Revision: https://phabricator.services.mozilla.com/D128674
We always use alpha visual for WebRender, and appearance: none is
unnecessary (root element has no intrinsic appearance).
Differential Revision: https://phabricator.services.mozilla.com/D128682
For that:
* Tweak the standin system colors to match the non-native theme.
* Use those system colors for button and field backgrounds.
* Rename the "should use system colors" bit to "is high contrast",
which is what it really is (specially now that we use system colors
also in non-high-contrast).
Border colors and other colors like the <input type=range> and such
might need some extra tweaking perhaps, but this is a decent start and
looks good in https://crisal.io/tmp/form-controls.html afaict (dark mode
toggle needs the color-scheme pref enabled of course).
Differential Revision: https://phabricator.services.mozilla.com/D127533
We need to use standins for CSS-accesible colors in high contrast mode
(when appropriate) so that the CSS color matches the one in forms.css.
But this is not needed for e.g. scrollbar colors, which are not
CSS-accessible. So shuffle around the checks so that we account for
that as we should.
Differential Revision: https://phabricator.services.mozilla.com/D125830
Emilio Cobos Álvarez
CanadaHonk
Csoregi Natalia
Cristian Tuns
Brad Werth
Butkovits Atila
Marian-Vasile Laza
Andi-Bogdan Postelnicu
Hiroyuki Ikezoe
Jonathan Kew
stransky
Stephen A Pohl
Bob Owen
Karl Tomlinson