SetFrame() is equivalent to `operator=`, so external callers can use `operator=`
instead. For the two callers wanting to set `nsFrameList` to `AbsoluteFrameList`
in `nsCSSFrameConstructor`, removing SetFrame() disallows it. However, we can
easily change the declaration from `nsFrameList` to a `AbsoluteFrameList` to
resolve the problem.
Differential Revision: https://phabricator.services.mozilla.com/D160840
This patch doesn't change behavior.
AbsoluteFrameList is a derived class of nsFrameList, so we change it a move-only
class in order to nsFrameList move-only in Part 3.
Some detail of this patch:
- Define move constructor and move assignment operator for AbsoluteFrameList.
This effectively disables the auto generated copy constructor and copy
assignement operator.
- Initialize nsFrameConstructorSaveState's member variables in class definition,
and remove its constructor.
- Remove `mSavedFixedList` since we can rewire the logic in
`~nsFrameConstructorSaveState` and `PushAbsoluteContainingBlock()` to make it
redundant.
- Make self-assignment correct in nsFrameList's move assignment operator.
Differential Revision: https://phabricator.services.mozilla.com/D160014
This patch doesn't change behavior.
AbsoluteFrameList is a derived class of nsFrameList, so we change it a move-only
class in order to nsFrameList move-only in Part 3.
Some detail of this patch:
- Define move constructor and move assignment operator for AbsoluteFrameList.
This effectively disables the auto generated copy constructor and copy
assignement operator.
- Initialize nsFrameConstructorSaveState's member variables in class definition,
and remove its constructor.
- Remove `mSavedFixedList` since we can rewire the logic in
`~nsFrameConstructorSaveState` and `PushAbsoluteContainingBlock()` to make it
redundant.
- Make self-assignment correct in nsFrameList's move assignment operator.
Differential Revision: https://phabricator.services.mozilla.com/D160014
After this patch, we still need nsFrameList::Enumerator to iterate
nsFrameList::Slice. We might enhance nsFrameList::Iterator to support Slice, but
I'll leave this for another day.
Differential Revision: https://phabricator.services.mozilla.com/D158809
I feel it's hard to understand the purpose of ExtractHead(), especially where
aFrame is going after the call. Therefore, I rename it to TakeFramesBefore(),
and have it complement the existing RemoveFramesAfter(), which will be rename
later. No behavioral change intended.
Also, slightly reword the method's documentation to reflect the its new
name. (Remove the "sibling" wording from the comment since it's an
implementation details that frames are actually a doubly linked list.)
Differential Revision: https://phabricator.services.mozilla.com/D158806
This is a preparation to remove nsFrameList::FrameLinkEnumerator in the next
part.
FrameLinkEnumerator::Find() can be replaced with std::find/std::find_if.
Differential Revision: https://phabricator.services.mozilla.com/D158700
This applies both to the individual mStartPageValue and mEndPageValue fields
of the nsIFrame::PageValues struct, and for the nsIFrame::PageValuesProperty
being null to indicate both mStartPageValue and mEndPageValue are auto.
Fetching this is handled by nsIFrame::GetStartPageValue and
nsIFrame::GetEndPageValue, which also ensure the use of first-in-flow frames.
Differential Revision: https://phabricator.services.mozilla.com/D157873
After bug 1665476, it's pretty much a regular XUL box with a couple
special-cases that we can use IsRootElementStyle for. Do that, and allow
using nsFlexContainerFrame when using flexbox emulation.
Differential Revision: https://phabricator.services.mozilla.com/D158288
After bug 1665476, it's pretty much a regular XUL box with a couple
special-cases that we can use IsRootElementStyle for. Do that, and allow
using nsFlexContainerFrame when using flexbox emulation.
Differential Revision: https://phabricator.services.mozilla.com/D158288
After bug 1665476, it's pretty much a regular XUL box with a couple
special-cases that we can use IsRootElementStyle for. Do that, and allow
using nsFlexContainerFrame when using flexbox emulation.
Differential Revision: https://phabricator.services.mozilla.com/D158288
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
Gijs for front-end bits, layout for the new CSS properties and the
removal of nsDeckFrame / nsStackLayout, Jamie and Morgan for the a11y
changes.
As discussed in the bug, the main tricky part here is handling a11y
correctly. For <deck>, that's trivial (just use `visibility: hidden` to
hide the panels visually, while removing the unselected panels from the
a11y tree).
For <tabpanels> however we need to do something special. We do want to
hide stuff visually, but we want to preserve the contents in the a11y
tree.
For that, the easiest fix is introducing a new privileged CSS property
(-moz-subtree-hidden-only-visually), which takes care of not painting
the frame, but marks stuff offscreen in the accessibility tree. This is
not intended to be a property used widely.
Other than that, the changes are relatively straight-forward, though
some of the accessible/mac changes I could get a sanity-check on.
Differential Revision: https://phabricator.services.mozilla.com/D157875
Gijs for front-end bits, layout for the new CSS properties and the
removal of nsDeckFrame / nsStackLayout, Jamie and Morgan for the a11y
changes.
As discussed in the bug, the main tricky part here is handling a11y
correctly. For <deck>, that's trivial (just use `visibility: hidden` to
hide the panels visually, while removing the unselected panels from the
a11y tree).
For <tabpanels> however we need to do something special. We do want to
hide stuff visually, but we want to preserve the contents in the a11y
tree.
For that, the easiest fix is introducing a new privileged CSS property
(-moz-subtree-hidden-only-visually), which takes care of not painting
the frame, but marks stuff offscreen in the accessibility tree. This is
not intended to be a property used widely.
Other than that, the changes are relatively straight-forward, though
some of the accessible/mac changes I could get a sanity-check on.
Differential Revision: https://phabricator.services.mozilla.com/D157875
This also properly handles placeholder frames, and ensures that when checking
next/prev sibling we ignore placeholder frames.
To properly test this for multiple levels of page value propagation, we also
need to use FirstInFlow to get page values when checking for breaks in block
frames.
Differential Revision: https://phabricator.services.mozilla.com/D157175
Create XULButtonElement instead to do the event handling. Pretty much a
straight port, this allows these elements to respect CSS display
properly (and use modern flexbox rather than old XUL layout).
Differential Revision: https://phabricator.services.mozilla.com/D157509
The page-name property only applies to boxes which can create class A
breakpoints. One of the qualifiers for this is a block-level item, which is
the child of a block frame. Additionally, page-name propagation only occurs
through frames for which the page-name property applies, because where it does
not apply the auto page-name is propagated instead.
This means we only need to worry about block frames, and only use specified
page-name for BlockOutside frames.
Differential Revision: https://phabricator.services.mozilla.com/D155285
This also adds a small post-processing step for frame-construction to ensure
that replaced frames (or more generally frames with content but no children)
have the auto page-name set on them.
When page-name value tracking is switched to be lazy, this post-processing step
will likely be redundant and can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D152701
The page-name property only applies to boxes which can create class A
breakpoints. One of the qualifiers for this is a block-level item, which is
the child of a block frame. Additionally, page-name propagation only occurs
through frames for which the page-name property applies, because where it does
not apply the auto page-name is propagated instead.
This means we only need to worry about block frames, and only use specified
page-name for BlockOutside frames.
Differential Revision: https://phabricator.services.mozilla.com/D155285
This also adds a small post-processing step for frame-construction to ensure
that replaced frames (or more generally frames with content but no children)
have the auto page-name set on them.
When page-name value tracking is switched to be lazy, this post-processing step
will likely be redundant and can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D152701
I haven't spotted any UI regression from this, and this should generally
make the XUL -> modern flex transition easier, and simplify some
of the relevant code.
This does fix a few layout issues with emulated flexbox.
For the most part, this shouldn't change behavior without that. This
changes behavior if you have mixed inline/non-inline content in the same
XUL box (before they'd get a single item, now you'd get the flexbox /
grid behavior of one item per inline run), and multiple inline-elements
(which would become their own flex items). But I pushed a patch with
some asserts and they didn't fire on our browser mochitests, so I think
we're good.
The UA rule refactoring (removing the inherit from xul anon blocks)
shouldn't matter in practice, since we only have one item (so
box-ordinal is irrelevant) and they have overflow: visible (so
text-overflow and overflow-clip-box shouldn't have an effect).
Differential Revision: https://phabricator.services.mozilla.com/D156375
