Currently, GetSplittableType() is called only in
nsCSSFrameConstructor::CreateContinuingFrame(). The splittable concrete frames
should inherit from nsSplittableFrame, and must explicitly create continuing
frame in CreateContinuingFrame(). Thus, no need to maintain GetSplittableType().
Differential Revision: https://phabricator.services.mozilla.com/D10798
The CSSWG has recently resolved that layout containment
suppress baseline alignment, while size containment does not:
https://github.com/w3c/csswg-drafts/issues/2995
Spec text (https://drafts.csswg.org/css-contain/#containment-layout):
"7. For the purpose of the vertical-align property,
or any other property whose effects need to relate
the position of the containing element's baseline
to something other than its descendants,
the containing element is treated as having no baseline."
And a note in (https://drafts.csswg.org/css-contain/#containment-size):
"Note: size containment does not suppress baseline alignment.
See layout containment for that."
This patch does this change just switching IsContainSize()
by IsLayoutSize() in several places related to baseline alignment
in the source code.
With the patch several WPT tests start to pass. Apart from that,
some of the tests under vendor-imports are updated to follow
the new behavior.
nsCSSFrameConstructor::FindDisplayData() guarantees a block with "display:
list-item" will be constructed by ConstructBlock() (either through
ConstructScrollableBlock() or ConstructNonScrollableBlock()).
This is also a preparation to fix bug 1491915 since we want to control
bullet frame creation under column hierarchy.
Depends on D6840
Differential Revision: https://phabricator.services.mozilla.com/D6841
Those arguments were added in bug 591737 to create a triangle for the
summary frame, but <summary> has been re-implemented by using "list-item"
since then. Now the only caller is nsBlockFrame itself, so there's no need
to expose those arguments.
Differential Revision: https://phabricator.services.mozilla.com/D6839
Summary:
Once the nsDisplayList difficulties are sorted out, this
becomes rather trivial.
Depends on D5293
Reviewers: mattwoodrow
Reviewed By: mattwoodrow
Bug #: 1489588
Differential Revision: https://phabricator.services.mozilla.com/D5294
We'll re-do the line anyway, and we'll forget about all the already-positioned
floats in the line DoReflowInlineFrames anyway.
Differential Revision: https://phabricator.services.mozilla.com/D4457
Bug 1478178 regressed this case because bullet frame is the last frame
added to line layout, rather than the first, so when we try to apply
justification, we end up giving it the accumulated offset of the whole
line.
Bullet frame has to be added after other frames in the line have been
placed, because its presence may depend on whether the line is empty.
However, bullet frame is logically the first frame in a line and
appending it to the end is somewhat counter-intuitive.
Thus, this patch tries to fix the issue via prepending bullet frame in
line layout, so that the order of frames there can be more reliable.
Differential Revision: https://phabricator.services.mozilla.com/D3760
Scrollable elements already trap all of their contents, nothing should spill
out, so there is no need for special handling of the `contain` CSS property.
Differential Revision: https://phabricator.services.mozilla.com/D3854
Using references helps to see when stuff can and cannot be null.
I removed useless aTag / aNamespaceId arguments which are useless now that XBL
can't override them (bug 1450617), so FindXULData is the only one that keeps
them alive.
Also, I took the liberty of renaming a few fooComputedStyle variables to just
fooStyle, and clarify naming in some pseudo-element-related functions to say
originating element (the spec term) and avoid confusing it with the generated
_moz_generated_content_before / _moz_generated_content_after element.
Note that this is a partial state, more stuff will come in the future.
Differential Revision: https://phabricator.services.mozilla.com/D2326
MozReview-Commit-ID: 39B30doREUH
Similar to lines (see previous patch), floats from next-in-flow or overflow
frames have probably not been marked dirty (as ReflowInput hasn't dealt with
them when it was constructed), so we need to mark them dirty for proper reflow.
If we don't do that, and they don't fit in the current column, the next column
will only mark its current children dirty, so when pulling back its first
floats from the previous column they will not be reflowed as needed.
MozReview-Commit-ID: KKrwtzeQMrI
Lines pulled from next-in-flow or overflow frames have probably not been marked
dirty (as ReflowInput hasn't dealt with them when it was constructed), so we
need to mark them dirty for proper reflow.
If we don't do that, and they don't fit in the current column, the next column
will only mark its current children dirty, so when pulling back its first lines
from the previous column they will not be reflowed as needed, which causes this
bug.
MozReview-Commit-ID: 8GFO1ZWuZ1b
Similar to lines (see previous patch), floats from next-in-flow or overflow
frames have probably not been marked dirty (as ReflowInput hasn't dealt with
them when it was constructed), so we need to mark them dirty for proper reflow.
If we don't do that, and they don't fit in the current column, the next column
will only mark its current children dirty, so when pulling back its first
floats from the previous column they will not be reflowed as needed.
MozReview-Commit-ID: KKrwtzeQMrI
Lines pulled from next-in-flow or overflow frames have probably not been marked
dirty (as ReflowInput hasn't dealt with them when it was constructed), so we
need to mark them dirty for proper reflow.
If we don't do that, and they don't fit in the current column, the next column
will only mark its current children dirty, so when pulling back its first lines
from the previous column they will not be reflowed as needed, which causes this
bug.
MozReview-Commit-ID: 8GFO1ZWuZ1b
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
