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
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
The root cause of this bug is that we're now accidentally using the
native theme for the spinners because GetNumberControlFrameForSpinButton
broke with my changes.
These pseudos are not exposed to content, and there's just one user of
this pseudo-class (the print.css one).
So just disable native appearance explicitly and remove that check.
Differential Revision: https://phabricator.services.mozilla.com/D108653
Right now the resizer inside a random <div style="overflow: hidden"> is
the themed one, and that seems unintended.
I'm not sure how to best test this since resizers are sized to a
scrollbar width, so I can't just position an <img src=resizer.svg>.
I noticed this while looking at bug 1689253.
Differential Revision: https://phabricator.services.mozilla.com/D103304
If we hit the canvas frame, and the root has a background but the body
doesn't, previously we were using the body style. Then
FindNonTransparentBackgroundFrame would return the document element
frame (with the right background), but FindBackgroundFor that failed.
Differential Revision: https://phabricator.services.mozilla.com/D103975
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
Changes to nsIScrollableFrame.h cause the world to rebuild which I find annoying.
This removes the inclusion into Element.h which is responsible for the
world-rebuilding and is relatively easy to eliminate. A bunch of usages of
nsIScrollableFrame get moved from .h files into .cpp files and I include the
header into .cpp files as needed.
Differential Revision: https://phabricator.services.mozilla.com/D90735
The current code assumes that nsNativeTheme is in use which breaks with
the non-native theme.
Instead of hackily remove the FOCUS bit, make the theme check for the
FOCUSRING bit, which is the right thing to check for anyway.
Differential Revision: https://phabricator.services.mozilla.com/D75782
Instead move the check to the focus manager, more similar to how
focus-visible works.
Now nsGlobalWindowInner::ShouldShowFocusRing means "Should we show focus
ring for anything in this window", that is: Have we keyboard-navigated
in this window, or do we have a pref that says that we should always
show focus rings.
Fix some callers appropriately (some of them that were not properly
accounting for the element being focused in the first place...).
Differential Revision: https://phabricator.services.mozilla.com/D75504
This patch computes the author-specified properties during the CSS cascade, and
removes the complex rule-tree-based implementation that tries to do the cascade
again.
This changes behavior in two ways, one of them which is not observable to
content, I believe:
* revert now re-enables the native styling. This was brought up in
https://github.com/w3c/csswg-drafts/issues/4777 and I think it is a bug-fix.
This is observable to content, and I'm adding a test for it.
* We don't look at inherited styles from our ancestors when `inherit` is
specified in a non-author stylesheet. This was introduced for bug 452969 but
we don't seem to inherit background anymore for file controls or such. It
seems back then file controls used to have a text-field.
I audited forms.css and ua.css and we don't explicitly inherit
padding / border / background-color into any nested form control.
We keep the distinction between border/background and padding, because the later
has some callers. I think we should try to align with Chromium in the long run
and remove the padding bit.
We need to give an appearance to the range-thumb and such so that we can assert
that we don't call HasAuthorSpecifiedRules on non-themed stuff. I used a new
internal value for that.
Differential Revision: https://phabricator.services.mozilla.com/D67722
--HG--
extra : moz-landing-system : lando
This patch computes the author-specified properties during the CSS cascade, and
removes the complex rule-tree-based implementation that tries to do the cascade
again.
This changes behavior in two ways, one of them which is not observable to
content, I believe:
* revert now re-enables the native styling. This was brought up in
https://github.com/w3c/csswg-drafts/issues/4777 and I think it is a bug-fix.
This is observable to content, and I'm adding a test for it.
* We don't look at inherited styles from our ancestors when `inherit` is
specified in a non-author stylesheet. This was introduced for bug 452969 but
we don't seem to inherit background anymore for file controls or such. It
seems back then file controls used to have a text-field.
I audited forms.css and ua.css and we don't explicitly inherit
padding / border / background-color into any nested form control.
We keep the distinction between border/background and padding, because the later
has some callers. I think we should try to align with Chromium in the long run
and remove the padding bit.
We need to give an appearance to the range-thumb and such so that we can assert
that we don't call HasAuthorSpecifiedRules on non-themed stuff. I used a new
internal value for that.
Differential Revision: https://phabricator.services.mozilla.com/D67722
--HG--
extra : moz-landing-system : lando
I don't think we want to keep the ugly widget hacks forever. Let me know if
you'd rather keep the property behind a pref but I don't think there's a point
in doing that.
Differential Revision: https://phabricator.services.mozilla.com/D62649
--HG--
extra : moz-landing-system : lando
I don't think we want to keep the ugly widget hacks forever. Let me know if
you'd rather keep the property behind a pref but I don't think there's a point
in doing that.
Differential Revision: https://phabricator.services.mozilla.com/D62649
--HG--
extra : moz-landing-system : lando
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--HG--
extra : moz-landing-system : lando
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55444
--HG--
extra : moz-landing-system : lando
I discovered this while improving `ScrollFrameHelper::IsPhysicalLTR()`
in Part 1. Our code base needs a notion of physical direction. Let's add
it to WritingMode.
Differential Revision: https://phabricator.services.mozilla.com/D49818
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
This patch makes widget use `mozilla::PresShell` directly rather than via
`nsIPresShell` and changes some pure virtual methods of `nsIPresShell` which
called by widget to `mozilla::PresShell`'s non-virtual methods.
Differential Revision: https://phabricator.services.mozilla.com/D29112
--HG--
extra : moz-landing-system : lando
`nsPresContext` should use `mozilla::PresShell` directly instead of
`nsIPresShell`. This patch makes it.
Unfortunately, `nsPresContext` and `nsIFrame` have `PresShell()`. Therefore,
we cannot use `PresShell*` in its methods so that this patch uses `mozilla::`
namespace prefix.
It might be better to rename them as `PresShellPtr()` in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D25721
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
The functions were introduced in bug 1460456 as part of the initial impl
of scrollbar color properties, and then got moved to nsNativeTheme in
bug 1464722 to be shared with cocoa impl.
Its usage is later removed in bug 1494607 and bug 1498216 as we turn to
rely on native blending instead, and these functions become unused.
Differential Revision: https://phabricator.services.mozilla.com/D9596
--HG--
extra : source : 02ce40d9ca40eba4485cf6e0db33b726ad531a89
Emilio Cobos Álvarez
Cristian Tuns
Csoregi Natalia
Stephen A Pohl
Markus Stange
Botond Ballo
Kartikaya Gupta
Cameron McCormack
Simon Giesecke
Sylvestre Ledru
Razvan Maries
Xidorn Quan
Bogdan Tara
Mihai Alexandru Michis
Gabriele Svelto
Ting-Yu Lin
Nicholas Nethercote
Masayuki Nakano
Ryan Hunt
Jonathan Watt