And remove unused includes of nsGkAtoms.h in the process. The few
dependencies have been moved to ServoStyleConstsInlines.h
The used command to remove the now unused dependency was:
git grep -l nsGkAtoms.h | while read line; do grep -v nsGkAtoms.h $line | grep -q -E '\<nsGkAtoms\>' || sed -i -e '/nsGkAtoms.h/d' $line ; done
Differential Revision: https://phabricator.services.mozilla.com/D292697
And remove unused includes of nsGkAtoms.h in the process. The few
dependencies have been moved to ServoStyleConstsInlines.h
The used command to remove the now unused dependency was:
git grep -l nsGkAtoms.h | while read line; do grep -v nsGkAtoms.h $line | grep -q -E '\<nsGkAtoms\>' || sed -i -e '/nsGkAtoms.h/d' $line ; done
Differential Revision: https://phabricator.services.mozilla.com/D292697
This patch fixes multiple points which may cross independent selection
boundaries which is element boundary of the native anonymous `<div>` for
editable content in text controls. The reason why I don't split this patch is,
fixing one of them leads another assertion failure. So, I couldn't pass all
tests with separated patches.
1. `nsFrameTraversal` should take `Element` instead of `nsIFrame` for the
limiter because e.g., inline editing host like `<span contenteditable>` may
have multiple frames if it's wrapped. Therefore, we should make it take
an element as the ancestor limiter, and check it when getting parent frame
or after getting previous or next frame.
2. `nsIFrame::PeekBackwardAndForward` may cross the boundary because it does not
take the anonymous `<div>` element as ancestor limiter of the selection. It's
currently used only for extending selection. Therefore, I rename it to make
it clearer.
3. `SelectionMovementUtils::GetPrevNextBidiLevel` to take the ancestor limiter
for calling `nsIFrame::GetFrameFromDirection()`.
4. `nsINode` should have a method to return the `nsFrameSelection` instance
which manages the selection in the node. This makes the check simpler, and
this is not expensive. Then, for making it clearer, I rename
`TextControlElement::GetConstFrameSelection()` to
`GetIndependentFrameSelection()`.
5. `nsINode::GetSelectionRootContent()` should have an option to return
independent selection root when the node is its host for
`nsFrameSelection::ConstrainFrameAndPointToAnchorSubtree()`
6. `nsFrameSelection::ConstrainFrameAndPointToAnchorSubtree()` should not
retrieve independent selection root when the given frame is a text control
frame.
7. `RangeUtils` should get parent with checking the independent selection
boundaries.
8. `Selection::Extend` should assert if the destination is managed by its
frame selection to detect a bug.
Differential Revision: https://phabricator.services.mozilla.com/D241587
Nobody shares an instance of `nsFrameIterator`. Therefore, we can make it
non-refcountable. Additionally, `nsVisualIterator` is not required because
it overrides only 4 methods which are really simple. So, once we merge it
into `nsFrameIterator`, we can allocate it in the stack.
Differential Revision: https://phabricator.services.mozilla.com/D197144
The class is used only for creating `nsFrameIterator`, but it's unnecessary
so that we can get rid of it and its interface.
Differential Revision: https://phabricator.services.mozilla.com/D197143
It's inherited only by `nsFrameIterator`, and `nsFrameIterator` can be declared
in a header file. So, the interface is not required and removing it can avoid
virtual calls.
Differential Revision: https://phabricator.services.mozilla.com/D197142
Nobody shares an instance of `nsFrameIterator`. Therefore, we can make it
non-refcountable. Additionally, `nsVisualIterator` is not required because
it overrides only 4 methods which are really simple. So, once we merge it
into `nsFrameIterator`, we can allocate it in the stack.
Differential Revision: https://phabricator.services.mozilla.com/D197144
The class is used only for creating `nsFrameIterator`, but it's unnecessary
so that we can get rid of it and its interface.
Differential Revision: https://phabricator.services.mozilla.com/D197143
It's inherited only by `nsFrameIterator`, and `nsFrameIterator` can be declared
in a header file. So, the interface is not required and removing it can avoid
virtual calls.
Differential Revision: https://phabricator.services.mozilla.com/D197142
This implements the focus behavior described in [1]:
1. Moves focus from an invoking element to its invoked popover,
regardless of where in the DOM that popover lives.
2. Moves focus back to the next focusable element after the
invoking element once focus leaves the invoked popover.
3. Skips over an open invoked popover otherwise.
[1] https://html.spec.whatwg.org/#focus-navigation-scope-owner
Differential Revision: https://phabricator.services.mozilla.com/D190560
This implements the focus behavior described in [1]:
1. Moves focus from an invoking element to its invoked popover,
regardless of where in the DOM that popover lives.
2. Moves focus back to the next focusable element after the
invoking element once focus leaves the invoked popover.
3. Skips over an open invoked popover otherwise.
[1] https://html.spec.whatwg.org/#focus-navigation-scope-owner
Differential Revision: https://phabricator.services.mozilla.com/D190560
This implements the focus behavior described in [1]:
1. Moves focus from an invoking element to its invoked popover,
regardless of where in the DOM that popover lives.
2. Moves focus back to the next focusable element after the
invoking element once focus leaves the invoked popover.
3. Skips over an open invoked popover otherwise.
[1] https://html.spec.whatwg.org/#focus-navigation-scope-owner
Differential Revision: https://phabricator.services.mozilla.com/D190560
This implements the focus behavior described in [1]:
1. Moves focus from an invoking element to its invoked popover,
regardless of where in the DOM that popover lives.
2. Moves focus back to the next focusable element after the
invoking element once focus leaves the invoked popover.
3. Skips over an open invoked popover otherwise.
[1] https://html.spec.whatwg.org/#focus-navigation-scope-owner
Differential Revision: https://phabricator.services.mozilla.com/D190560
This implements the focus behavior described in [1]:
1. Moves focus from an invoking element to its invoked popover,
regardless of where in the DOM that popover lives.
2. Moves focus back to the next focusable element after the
invoking element once focus leaves the invoked popover.
3. Skips over an open invoked popover otherwise.
[1] https://html.spec.whatwg.org/#focus-navigation-scope-owner
Differential Revision: https://phabricator.services.mozilla.com/D190560
After moving FrameChildListID into mozilla namespace, `kPrincipalList` etc. are
also exposed in the mozilla namespace. In the next part, I'll convert
FrameChildListID enum into an enum class, so the naming pollution shouldn't be
an issue.
This patch has a nice side effect that it is now easier to remove all the
aliases of FrameChildListID (`kPrincipalList` etc.) defined in multiple places
since it is confusion to have the same thing written in different ways, e.g.
`nsIFrame::kPrincipalList`, `mozilla::layout::kPrincipalList`,
`FrameChildListID::kPrincipalList`, `kPrincipalList`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D161863
After moving FrameChildListID into mozilla namespace, `kPrincipalList` etc. are
also exposed in the mozilla namespace. In the next part, I'll convert
FrameChildListID enum into an enum class, so the naming pollution shouldn't be
an issue.
This patch has a nice side effect that it is now easier to remove all the
aliases of FrameChildListID (`kPrincipalList` etc.) defined in multiple places
since it is confusion to have the same thing written in different ways, e.g.
`nsIFrame::kPrincipalList`, `mozilla::layout::kPrincipalList`,
`FrameChildListID::kPrincipalList`, `kPrincipalList`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D161863
It's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Differential Revision: https://phabricator.services.mozilla.com/D90846
It's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Differential Revision: https://phabricator.services.mozilla.com/D90846
After the fixes in this patch, the REQUIRES_UNIFIED_BUILD declaration is no
longer needed, so I'm removing it here. This directory now builds successfully
with that removed and with ac_add_options --disable-unified-build in the
mozconfig.
Differential Revision: https://phabricator.services.mozilla.com/D125601
It's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Differential Revision: https://phabricator.services.mozilla.com/D90846
My previous patch somehow causes WR to crash and fall back to d2d on Windows,
see bug 1671591.
While I figure that out let's fix TB by restoring the previous behavior
for XUL.
Rename the Root frame type because it's super-confusing that IsRootFrame
is not equivalent to !GetParent().
Differential Revision: https://phabricator.services.mozilla.com/D94105
serge-sans-paille