Removed the Reflow Input in nsIFrame. Added includes for ReflowInput as
necessary in cpp files. Also Forward Declared nsLineLayout in 3 header
files.
Differential Revision: https://phabricator.services.mozilla.com/D298203
Replaces the `vertical-align` longhand with the shorthand version and the corresponding `alignment-baseline` and `baseline-shift` longhands (the `baseline-source` property was already implemented). Some notes about this change:
- The CSS Inline Layout Module Level 3 specification introduced new
values to `alignment-baseline` and `baseline-shift` that were not
available in the original `vertical-align` longhand. This change
only implements the original keywords; the new values will be used
in a future patch.
- The SVG layout still ignores the `vertical-align` (and now the
corresponding longhands) in favor of the `dominant-baseline`. This
will also be addressed in a future patch.
Differential Revision: https://phabricator.services.mozilla.com/D277725
As tested by `css/css-ui/user-select-none-in-editable.html`, we should
treat editable nodes as selectable even if `user-select: none` is
specified.
Then, some tests start failing due to an existing bug of caret move
when an inline element starts/ends with invisible white-spaces.
Therefore, to make them keep passing, this fixes the bug of
`nsTextFrame::PeekOffsetCharacter()`.
Differential Revision: https://phabricator.services.mozilla.com/D272608
No need to reposition views during layout and so on, now that we don't
use views for either popups nor subdocuments.
No need for nsView to have parent / sibling / children either.
Differential Revision: https://phabricator.services.mozilla.com/D271205
No behavior change, but this saves some per-child work and conceptually
is the right thing to do. HidesContent() is non-trivial.
Add an assertion to make sure we don't enter BuildDisplayListForChild
at all if content is hidden.
I audited all the callers, and the ones I didn't touch can't have
content-visibility (things like the viewport / pages / etc).
Differential Revision: https://phabricator.services.mozilla.com/D265956
`MutationEvent_Bindings::MODIFICATION`,
`MutationEvent_Bindings::ADDITION` and `MutationEvent_Bindings::REMOVAL`
will be removed. Therefore, we need alternative `enum class` for that.
This patch makes `nsIFrame` and subclasses use the new one.
Differential Revision: https://phabricator.services.mozilla.com/D263053
Rename `mPercentageBasis` to `mPercentageBasisForChildren` to clarify that the
percentage basis is intended for resolving the percentage sizes for child
frames.
Differential Revision: https://phabricator.services.mozilla.com/D221332
A percentage basis is needed to resolve percentage block size when computing
children's intrinsic inline size contributions. This is necessary for a child or
descendants with a preferred aspect-ratio so that the block size can transfer
through the aspect-ratio to become an intrinsic inline size.
The change in `nsFlexContainerFrame::ComputeIntrinsicISize()` is necessary to
keep us passing
`testing/web-platform/tests/css/css-flexbox/image-nested-within-definite-column-flexbox.html`.
The change in `nsPlaceholderFrame::AddFloatToIntrinsicISizeData()` is necessary
to keep us passing
`testing/web-platform/tests/css/css-sizing/intrinsic-percent-replaced-dynamic-010.html`.
`GetISizeInfo()` in BasicTableLayoutStrategy.cpp is modified to pass table cell
frame's bsize as percentage basis. Otherwise,
`layout/reftests/bugs/522632-1.html` fails. This is our current behavior, but it
is bug 1461852.
Differential Revision: https://phabricator.services.mozilla.com/D219523
This patch changes the signature to `GetMinISize()`, `GetPrefISize()`,
`IntrinsicISize` by adding a helper struct as a preparation. Then we can just
add more data such as a percentage basis to the struct without altering the
signature in the future.
When passing `IntrinsicSizeInput` struct down to another helper method, we
generally just pass the original one if the method is computing the intrinsic
size of our own or our anonymous children. If the method is computing our
children's intrinsic contribution, we'll need to create a brand new
`IntrinsicSizeInput` for our children.
Differential Revision: https://phabricator.services.mozilla.com/D219521
A percentage basis is needed to resolve percentage block size when computing
children's intrinsic inline size contributions. This is necessary for a child or
descendants with a preferred aspect-ratio so that the block size can transfer
through the aspect-ratio to become an intrinsic inline size.
The change in `nsFlexContainerFrame::ComputeIntrinsicISize()` is necessary to
keep us passing
`testing/web-platform/tests/css/css-flexbox/image-nested-within-definite-column-flexbox.html`.
The change in `nsPlaceholderFrame::AddFloatToIntrinsicISizeData()` is necessary
to keep us passing
`testing/web-platform/tests/css/css-sizing/intrinsic-percent-replaced-dynamic-010.html`.
`GetISizeInfo()` in BasicTableLayoutStrategy.cpp is modified to pass table cell
frame's bsize as percentage basis. Otherwise,
`layout/reftests/bugs/522632-1.html` fails. This is our current behavior, but it
is bug 1461852.
Differential Revision: https://phabricator.services.mozilla.com/D219523
This patch changes the signature to `GetMinISize()`, `GetPrefISize()`,
`IntrinsicISize` by adding a helper struct as a preparation. Then we can just
add more data such as a percentage basis to the struct without altering the
signature in the future.
When passing `IntrinsicSizeInput` struct down to another helper method, we
generally just pass the original one if the method is computing the intrinsic
size of our own or our anonymous children. If the method is computing our
children's intrinsic contribution, we'll need to create a brand new
`IntrinsicSizeInput` for our children.
Differential Revision: https://phabricator.services.mozilla.com/D219521
The underlying helper `IntrinsicForAxis()` already accepts an optional
percentage basis. This patch adds the same percentage basis argument to
`IntrinsicForContainer()`, allowing future callers to use it without needing to
convert to `IntrinsicForAxis()`.
This patch is a preparation for bug 1909761.
Differential Revision: https://phabricator.services.mozilla.com/D217792
Most frame types have identical or very similar implementation for GetMinISize()
and GetPrefISize(), and many of them already have `IntrinsicISize()` to unify
the implementation. This patch introduces nsIFrame::IntrinsicISize() so that
derived classes only need to override one method.
`nsBlockFrame`, `ColumnSetWrapperFrame`, and `nsColumnSetFrame` are the only
three classes where their `GetMinISize()` and `GetPrefISize()` have significant
differences. Therefore, we rename `GetMinISize()` and `GetPrefISize()` to
`MinISize()` and `PrefISize`, respectively, and use them as helpers to implement
their `IntrinsicISize()`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D217790
A potentially better approach could be to call FrameNeedsReflow from
nsBCTableCellFrame::SetBorderWidth... But it seems that might
over-invalidate quite a lot when recalculating borders, since it seems
we reset the relevant ones and then accumulate directly on the frame.
If that seems like a better approach, happy to give that a try. This
should be less risky for performance changes in general tho.
Differential Revision: https://phabricator.services.mozilla.com/D216409
Also, simplify some callers of `GetScrollTargetFrame()` to drop
`nsIScrollableFrame*` and unnecessary `do_QueryFrame`. We'll continue removing
more `nsIScrollableFrame*` in later parts.
Differential Revision: https://phabricator.services.mozilla.com/D211490
Also, simplify some callers of `GetScrollTargetFrame()` to drop
`nsIScrollableFrame*` and unnecessary `do_QueryFrame`. We'll continue removing
more `nsIScrollableFrame*` in later parts.
Differential Revision: https://phabricator.services.mozilla.com/D211490
The two macros are used in `GetPrefISize()` and `GetMinISize()` implementations.
After removing them, we could further simplify some implementations because we
don't need a `result` variable in many cases.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D206316
Values were static_casted where required. Some functions in WritingModes.h were
rewritten such that bitwise operations aren't being used. Added static_casts to
avoid (debug) build errors from debugging printfs in layout/tables/nsCellMap.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D205510
When printing tables, if a table row group is split across the page boundary,
its table-cell descendants with `vertical-align:baseline|middle|bottom|` do not
align as expected and there might be data loss. Currently, we reflow the table
row frames first, and then call DidResize() [1] to move table cells to their
vertical-align positions via BlockDirAlignChild() [2] . This is fine if the
table is in gallery mode or can fit in one page, but it doesn't work if it is
across the page boundary.
To fix this properly, we need to rewrite the table fragmentation code so that
the a table cell is reflowed in its aligned position with a correct constrained
available bsize. In the meantime, this patch works around the data loss by
forcing table-cells to use `vertical-align:top`. This is a hack, but it also
matches Google Chrome's current behavior. I feel this is a good interim solution
to improve our printing quality.
[1] https://searchfox.org/mozilla-central/rev/2537e5eaafaab9a7ef6be5cfc8e9b1e2c747fdfd/layout/tables/nsTableRowGroupFrame.cpp#1119-1125
[2] https://searchfox.org/mozilla-central/rev/2537e5eaafaab9a7ef6be5cfc8e9b1e2c747fdfd/layout/tables/nsTableRowFrame.cpp#370-372
Differential Revision: https://phabricator.services.mozilla.com/D205538
Eugeniusz Lewandowski