This seems to match the expectation of ~all our stylesheets, which have
nice things for HCM / forced-colors which only happen when actually
using OS HCM.
Differential Revision: https://phabricator.services.mozilla.com/D125269
This bug was introduced with the Proton tab design. Since we no longer draw a background behind inactive tabs, tabs are not legible against some accent colors. This problem is especially bad in brighttext themes. This patch also fixes 1714507, since the tabs are now legible against the light gray inactive window color.
Differential Revision: https://phabricator.services.mozilla.com/D125213
accent-color is inherited, there's no need to set it on every element.
And since it's ignored in HCM we can just put it in the regular place.
Differential Revision: https://phabricator.services.mozilla.com/D125273
With the non-native theme we don't need filter for this to affect
"native" inputs, we can just implement the logic in nsNativeBasicTheme
instead.
A bit unfortunate that we need that special-case, but it seems better
than using filter, which can break websites due to it creating an
stacking context.
I _think_ there are tests that I need to adjust for this change, but if
not I'll write some.
Keep the current behavior behind a pref just in case.
Differential Revision: https://phabricator.services.mozilla.com/D125232
And this renames the method to `ExtendOrShrinkRangeToDelete` for alining to
new behavior changed by the following patch.
Depends on D125028
Differential Revision: https://phabricator.services.mozilla.com/D125029
Per spec, the informational description about data collection under the main
Firefox Suggest checkbox should be hidden except for the "online" scenario,
since only the online scenario sends data to Mozilla.
We're also changing the two checkbox labels and adding another description under
the sponsored checkbox.
Depends on D125024
Differential Revision: https://phabricator.services.mozilla.com/D125031
Enable the Firefox Suggest "offline" scenario by default for users in the US
region with en-* locales.
Previously we relied on Nimbus to enable the offline scenario, and the goal here
is to make it permanent for all users in the US `home` region using en-* locales
so that we don't need Nimbus for it anymore.
With Nimbus, there were two essential mechanisms that restricted the scenario to
the desired population: the `browser.urlbar.quicksuggest.enabled` pref, which is
a global toggle for Firefox Suggest suggestions regardless of region and locale,
and a Nimbus recipe that enabled the pref for US en-* users only.
Without Nimbus, we have only the `browser.urlbar.quicksuggest.enabled` pref. We
can't rely on a server-side solution to target a specific population, so we need
to do it in the client. This patch keeps the default `false` value of
`browser.urlbar.quicksuggest.enabled` in firefox.js, and then it sets a new
default-branch value for the pref for the US en-* population on app startup.
There's actually a set of prefs related to the offline scenario that need to be
set, not only `browser.urlbar.quicksuggest.enabled`.
Depends on D124943
Differential Revision: https://phabricator.services.mozilla.com/D125024
On one website, the touch input fluffing made an audio scrubber so large that it
covered other playback controls, making them inaccessible. This patch addresses
this problem by changing the top fluffing radius so it more closely matches the
bottom radius.
In our investigation, we found the top radius was added asymmetrically to the
bottom radius without an explanation. We speculate the bottom bias was added
because when you touch the screen, you tend to aim with the top part of your
finger, near your fingernail, and sometimes the bottom part of your finger will
also touch the screen, fat fingering it: if true, we would fluff the event less
below the touch point (which is what the code was). I vaguely remember this fat
fingering problem in the early 2010's but I haven't thought about it in recent
years and I didn't notice this problem in my testing for this patch – perhaps
device touch handling has just gotten better. Therefore, we feel safe to remove
the bias.
Differential Revision: https://phabricator.services.mozilla.com/D124267
We need to compute the anonymous name on the fly while building the
CascadeData, otherwise we may see the same layer rule in two places due
to stylehseet sharing and make them incorrectly share a name.
Differential Revision: https://phabricator.services.mozilla.com/D125175
This seems to match the expectation of ~all our stylesheets, which have
nice things for HCM / forced-colors which only happen when actually
using OS HCM.
Differential Revision: https://phabricator.services.mozilla.com/D125269
With the non-native theme we don't need filter for this to affect
"native" inputs, we can just implement the logic in nsNativeBasicTheme
instead.
A bit unfortunate that we need that special-case, but it seems better
than using filter, which can break websites due to it creating an
stacking context.
I _think_ there are tests that I need to adjust for this change, but if
not I'll write some.
Keep the current behavior behind a pref just in case.
Differential Revision: https://phabricator.services.mozilla.com/D125232
These includes provide some types and functionality that these files need. In
the default build environment, there's no issue because they pick up these
includes via piggybacking on neighboring files that they're unified with; but
in a non-unified build, the files need to directly have these includes, to
avoid build errors.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1730265#c0 for the specific
build errors being addressed here.
Differential Revision: https://phabricator.services.mozilla.com/D125285
Similar to the previous patch, this patch makes `insertLineBreak` command
handler of `HTMLEditor` may insert a linefeed character instead of `<br>`
element for compatibility with Blink/WebKit.
Note that for making same name rules as `insertParagraphSeparator` command
handlers, this patch renames
`HTMLEditor::InsertBRElementAtSelectionWithTransaction()` to
`InsertLineBreakAsSubAction()` and moves
`EditorBase::InsertLineBreakAsSubAction()` to `TextEditor` since it's
used only by `TextEditor` instance.
Depends on D124731
Differential Revision: https://phabricator.services.mozilla.com/D124732
