This patch:
- Creates an anon-box pseudo-style for PrintedSheetFrame, in part so that it
can co-opt the styles that we formerly gave to page-frames in ua.css, to draw
the sheet of paper and the shadow in Print Preview.
- Adjusts nsCSSFrameConstructor to create a PrintedSheetFrame as the parent of
nsPageFrame (inserting between it and its nsPageSequenceFrame container, in
the frame tree).
- Fleshes out out a simple BuildDisplayList() implementation for
PrintedSheetFrame (taking the responsibility for "paper"-drawing from
nsPageFrame).
- Fleshes out a simple Reflow implementation for PrintedSheetFrame, just
placing the child page (assuming there's only one for now) at the origin.
- Adjusts nsPageFrame and nsPageSequenceFrame to account for the fact that
there's another layer between them now.
Note that PrintedSheetFrame needs to implement AppendDirectlyOwnedAnonBoxes()
(just as nsSimplePageSequence and nsPageFrame do), since it owns anonymous
nsPageFrame instances. This implementation only needs to append the first
child, as explained in the code-comment and in
https://bugzilla.mozilla.org/show_bug.cgi?id=1374761#c9 (and of course, for
now, PrintedSheetFrame only has one child at a time anyway.)
Differential Revision: https://phabricator.services.mozilla.com/D83457
Per documentation, `aPositionedFrame` (the second argument) of
`PushAbsoluteContainingBlock` should be the frame whose style actually
makes the new absolute containing block a containing block, so it should
be the fieldset frame itself, not fieldset's inner frame.
Co-authored-by: Mats Palmgren <mats@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D82651
Also: adjust include paths to be consistent for usages of various SVG headers,
and remove unused SVG includes (mostly for "utils" classes),
and drop stray "ns" from already-renamed SVG classes in various code comments.
Differential Revision: https://phabricator.services.mozilla.com/D83140
We were dealing with it correctly when switching display from e.g. block
to inline, or such. But we were not dealing with it when the node was
undisplayed.
Handle it properly, and free one frame bit while at it. We can't really
do this for ManualNAC (the editor resizers) because they request a
reframe explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D76679
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
If `contentFrame` is out-of-flow, nsFrameConstructorState::AddChild() can
construct a placeholder frame for `contentFrame` and put the placeholder in
`frameList`.
Also, we need to use nsFrameConstructorState::GetGeometricParent() to
get the correct parent when calling InitAndRestoreFrame() for an
out-of-flow `contentFrame`. For example, if `contentFrame` has
position:fixed, its parent should be ViewportFrame, not
CanvasFrame (which is mDocElementContainingBlock).
This patch also adds reftests for position:absolute flex & grid root
element. Reftests for position:fixed root element are in the next part.
Differential Revision: https://phabricator.services.mozilla.com/D76205
If `contentFrame` is out-of-flow, nsFrameConstructorState::AddChild() can
construct a placeholder frame for `contentFrame` and put the placeholder in
`frameList`.
Also, we need to use nsFrameConstructorState::GetGeometricParent() to
get the correct parent when calling InitAndRestoreFrame() for an
out-of-flow `contentFrame`. For example, if `contentFrame` has
position:fixed, its parent should be ViewportFrame, not
CanvasFrame (which is mDocElementContainingBlock).
This patch also adds reftests for position:absolute flex & grid root
element. Reftests for position:fixed root element are in the next part.
Disable crashtest 1608851.html on Android because it causes OOM crash
after landing this patch.
Differential Revision: https://phabricator.services.mozilla.com/D76205
If `contentFrame` is out-of-flow, nsFrameConstructorState::AddChild() can
construct a placeholder frame for `contentFrame` and put the placeholder in
`frameList`.
Also, we need to use nsFrameConstructorState::GetGeometricParent() to
get the correct parent when calling InitAndRestoreFrame() for an
out-of-flow `contentFrame`. For example, if `contentFrame` has
position:fixed, its parent should be ViewportFrame, not
CanvasFrame (which is mDocElementContainingBlock).
This patch also adds reftests for position:absolute flex & grid root
element. Reftests for position:fixed root element are in the next part.
Differential Revision: https://phabricator.services.mozilla.com/D76205
It's not like we're going to change behavior here anytime soon anymore
(other than removing XUL usage), and the helpfulness of the warning has
probably decreased with time.
But maybe I'm missing a reason why it should be kept around?
Differential Revision: https://phabricator.services.mozilla.com/D73544
For whatever reasons, we pass body element into
`RecreateFramesForContent`, the root element won't be reframed down in
the `ContentRemoved` path, but in `ContentRangeInserted()` path while
checking `WipeContainingBlock`. And in bug 1593752, we already have the
logic to reframe root element only when html and body's writing-modes
are different, so we won't over-eagerly reframe the root element.
Differential Revision: https://phabricator.services.mozilla.com/D71606
According to spec, option elements with label attributes should show and use
those labels rather than their element text. So let's do that.
Requires some trickery because the option element is a block element (so it
lays out its width based on its text content) so we put its label (if it has
one) in its ::before and skip frame generation so it measures the text of its
label, not of its text node children.
Differential Revision: https://phabricator.services.mozilla.com/D63545
According to spec, option elements with label attributes should show and use
those labels rather than their element text. So let's do that.
Requires some trickery because the option element is a block element (so it
lays out its width based on its text content) so we put its label (if it has
one) in its ::before and skip frame generation so it measures the text of its
label, not of its text node children.
Differential Revision: https://phabricator.services.mozilla.com/D63545
Both PresShell() and PresContext() are cached in nsIFrame. This
simplifies the setup for the callers to
nsCSSFrameConstructor::CreateContinuingFrame().
Differential Revision: https://phabricator.services.mozilla.com/D66600
The nsPresContext* argument of
nsCSSFrameConstructor::CreateContinuingFrame() is used only to get
PresShell. However, mPresShell is already cached in
nsCSSFrameConstructor (via its base class nsFrameManager).
By switching to use the cached value, we can remove now-unused
nsPresContext* or PresShell* from some continuing-frame-creation
methods' argument list in the next part.
Differential Revision: https://phabricator.services.mozilla.com/D66599
`nsFrameConstructorState::ProcessFrameInsertions` has a 600+ byte stack frame due to its `AutoTArray`s. If this function becomes indirectly inlined into the recursive parts of `nsCSSFrameConstructor`, that will bloat the callers' stack frames and make us pay 600 bytes at every level of recursion. Crashtests aren't happy about that on stack-limited Win32 builds.
This inlining has not yet happened in official builds, but did occur in my try runs for bug 1619461 where the inliner became more aggressive.
Differential Revision: https://phabricator.services.mozilla.com/D65815
I thought this would fix <input type=number style="user-select: none">, but
turns out it doesn't.
<input type=number> doesn't have the editor root as a root of the anonymous
subtree, so the current hack wouldn't work, as the anon root wouldn't have the
editable flag. So tweak the code a bit to handle stuff in a simpler way than
setting the flags after the fact, and set the NAC-root flag earlier to avoid
the mOuterWrapper->AppendChildTo(root) call forgetting about root's flags.
I had to tweak one AccessibleCaret test, but that's because it uses <textarea>
with user-select: none, and our behavior there is not particularly sane. It just
happened to work because that test-case also had a bunch of contenteditable
elements, and we stop matching this rule:
https://searchfox.org/mozilla-central/rev/220a3bd6063fcbe5ca50e88dcabdc7dee0aca448/layout/style/contenteditable.css#22
Because the anonymous div now properly matches :-moz-read-write, which made the
rule apply and the test work. See comment 4 of this bug.
I'll fix this stuff up and add some tests for our behavior here in bug 1611699.
I refactored the dragdrop tests to cover more input types, but I ended up not
being able to use them because they're dependent on the content.
Instead I added an extra test and changed the refactor so that it applies to
<input type=search>, as there's layout work going on in bug 558594, and it'd be
unfortunate to regress this there too.
Differential Revision: https://phabricator.services.mozilla.com/D61094
