* Make non-menulist popups just absolute positioned top-layer items.
* Simplify menulist popups to just be static-positioned items under
nsMenuFrame.
We need to keep kPopupList only for nsMenuFrame. In the future it can be
removed, see TODO in xul.css
Differential Revision: https://phabricator.services.mozilla.com/D161404
* Make non-menulist popups just absolute positioned top-layer items.
* Simplify menulist popups to just be static-positioned items under
nsMenuFrame.
We need to keep kPopupList only for nsMenuFrame. In the future it can be
removed, see TODO in xul.css
Differential Revision: https://phabricator.services.mozilla.com/D161404
* Make non-menulist popups just absolute positioned top-layer items.
* Simplify menulist popups to just be static-positioned items under
nsMenuFrame.
We need to keep kPopupList only for nsMenuFrame. In the future it can be
removed, see TODO in xul.css
Differential Revision: https://phabricator.services.mozilla.com/D161404
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
