This is a straightforward conversion except that
`NS_SUBTREE_DIRTY(this)` can be written terser as `IsSubtreeDirty()`.
Differential Revision: https://phabricator.services.mozilla.com/D82811
This avoids arbitrary precision loss when computing REM units and so on,
which is particularly important if we ever change the base of our app
units (but useful regardless).
Differential Revision: https://phabricator.services.mozilla.com/D79928
This avoids arbitrary precision loss when computing REM units and so on,
which is particularly important if we ever change the base of our app
units (but useful regardless).
Differential Revision: https://phabricator.services.mozilla.com/D79928
The modifications are all straightforward conversion except the one in
nsMathMLContainerFrame, where it is simplified by calling the equivalent
BuildDisplayListForInline() helper.
Differential Revision: https://phabricator.services.mozilla.com/D78166
There's no use case for stateful comparators, so they can be just plain
function pointers.
This is used in some hot places like CSS selector matching.
Differential Revision: https://phabricator.services.mozilla.com/D77084
If |nsDisplayItem::CreateWebRenderCommands()| returns false, the items that have been pushed to |DisplayListBuilder::pending_chunk| need to be cleared, because the item will be pushed as an image instead. This happens, for example, when nsDisplayText encounters unsupported features.
Differential Revision: https://phabricator.services.mozilla.com/D77095
In favor of the NativeAnonymous versions which they forward to.
Done automatically with:
rg -l 'IsInAnonymousSubtree' | xargs sed -i 's/IsInAnonymousSubtree/IsInNativeAnonymousSubtree/g'
And removing the function definitions afterwards.
Differential Revision: https://phabricator.services.mozilla.com/D76681
Converts `ui.menu.incremental_search.timeout` to a static pref and replaces macros related to the incremental search timeout with the actual pref, so that they are kept in sync without the need to manually update any macros. The two `.xml` files mentioned in the note were nowhere to be found, so this patch makes the assumption that those do not exist anymore and do not need to be kept in sync.
Differential Revision: https://phabricator.services.mozilla.com/D75182
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
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
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
Now that we have outlines for them, unthemed select / buttons show two
different focus indicators, which is undesired.
Furthermore, the ones in comboboxes are basically unremovable /
unstylable, so authors end up having to use massive hacks to do it, see
bug 1580935.
This fixes it elegantly (IMO) by just rendering them when themed (which
is what these were for anyway, to match the windows theme).
Differential Revision: https://phabricator.services.mozilla.com/D75283
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 the "core" change of the patch series, which causes most
existing layout codepaths to correctly factor in the visual to
layout transform (or its inverse), as long as the callers correctly
propagate it in the correct ViewportType.
Differential Revision: https://phabricator.services.mozilla.com/D68920
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
Ting-Yu Lin
Hiroyuki Ikezoe
Kagami Sascha Rosylight
Sylvestre Ledru
Simon Giesecke
Emilio Cobos Álvarez
Cosmin Sabou
Kris Maglione
Csoregi Natalia
Razvan Maries
Miko Mynttinen
Narcis Beleuzu
Mats Palmgren
Noemi Erli
Kristen Wright
Xidorn Quan
Botond Ballo