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
Both '-webkit-fill-available' and 'stretch' are equivalent to '-moz-available'
at this point in the patch series, and both are off-by-default, because
actually supporting them would require that we add special logic to handle them
as block-axis sizes (which I'll do in a separate bug).
Differential Revision: https://phabricator.services.mozilla.com/D217687
This patch is intended to be mechanical, just adding the new keyword as an
alias for the existing behavior, basically.
In a later bug, 'stretch' will gain additional capabilities before we enable
the pref. After that, I intend to ultimately make '-moz-available' an alias of
'stretch', assuming that doing so is web-compatible.
Differential Revision: https://phabricator.services.mozilla.com/D217686
This patch doesn't change behavior.
The '-moz-available' keyword is our closest equivalent to the CSS 'stretch'
keyword, *specifically* for the inline axis (since we currently nerf
'-moz-available' to behave like the initial value in the block axis). Hence, it
makes sense to say that the '-moz-available' keyword "Behaves Like Stretch On
Inline Axis".
By abstracting the existing behavior behind this helper-function, we can
start implementing the actual 'stretch' value in terms of this existing
behavior, in later patches.
Differential Revision: https://phabricator.services.mozilla.com/D217685
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
`ComputeISizeValue()` used to take `StyleSizeOverrides`, but
This patch reflects the fact that intrinsic inline size value such as
'min-content', 'max-content', etc. can be resolved via a definite block size and
a preferred aspect-ratio.
For the callers in `nsIFrame::ComputeSize()` and
`nsContainerFrame::ComputeSizeWithIntrinsicDimensions()`, we can pass the
`styleBSize` and `aspectRatio` that have considered the size overrides.
Also, simplify `ComputeISizeValueFromAspectRatio()` so that it can be reused in
other places. We'll adapt more callers in the next part. Note that the `aFlags`
parameter is unused, so it is removed.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D215294
Every time we recompute border collapsed table borders, we discard previously
computed values. This is done to avoid statefulness bugs, like Bug 1871609.
When a table-edge cell is modified, the border computation needs to extend
to cover all cells adjacent to that edge, to determine which cell contributes
to the maximum border-width.
Also, rename the use of X/Y usage to Col/Row to reduce potential confusion.
Differential Revision: https://phabricator.services.mozilla.com/D213793
This also makes `PhysicalAxis::{Horizontal,Vertical}` more useful when we
previous needed `PhysicalAxes::{Horizontal,Vertical}`.
Differential Revision: https://phabricator.services.mozilla.com/D211941
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
This also makes `PhysicalAxis::{Horizontal,Vertical}` more useful when we
previous needed `PhysicalAxes::{Horizontal,Vertical}`.
Differential Revision: https://phabricator.services.mozilla.com/D211941
This also makes `PhysicalAxis::{Horizontal,Vertical}` more useful when we
previous needed `PhysicalAxes::{Horizontal,Vertical}`.
Differential Revision: https://phabricator.services.mozilla.com/D211941
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
LogicalAxis is one of the Logical* enums. Converting it from enum to
enum class increases type safety. To run with the pre-existing code,
type casting was added when needed. Comments have been edited where
needed.
Differential Revision: https://phabricator.services.mozilla.com/D206108
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
Follow-up of bug 1795630 for some crashtests that were not in `mathml`
directories. The list was extracted in a subjective way from [1] by
looking at some tests that seem to contain essentially MathML with
some simple HTML or CSS. The changes to `crashtest.list` files have
been generated by [2].
[1] https://searchfox.org/mozilla-central/search?q=%3Cmath%7Cmathml&path=crashtest&case=true®exp=true
[2] `for file in $(^Ct ~/list-of-tests.txt); do D=$(dirname $file); F=$(filename $file); sed -i "/$F/d" $D/crashtests.list; done`
Differential Revision: https://phabricator.services.mozilla.com/D203614
Bug 1861562 Part 6 [1] made a bold assumption that TableBCDataProperty should
only be set on first-in-flow, but apparently a table continuation can call
`GetOrCreateTableBCData()` to set the property in the testcase [2].
This patch restores the old behavior that allows TableBCDataProperty to be set
on table continuations.
[1] https://hg.mozilla.org/mozilla-central/rev/c9c310c769d2
[2] Note: we don't support fragmenting tables in multicol. Table continuations
are created in this testcase because the abspos `<dialog>` in the table
is fragmented.
Differential Revision: https://phabricator.services.mozilla.com/D203707
Bug 1861562 Part 6 [1] made a bold assumption that TableBCDataProperty should
only be set on first-in-flow, but apparently a table continuation can call
`GetOrCreateTableBCData()` to set the property in the testcase [2].
This patch restores the old behavior that allows TableBCDataProperty to be set
on table continuations.
[1] https://hg.mozilla.org/mozilla-central/rev/c9c310c769d2
[2] Note: we don't support fragmenting tables in multicol. Table continuations
are created in this testcase because the abspos `<dialog>` in the table
is fragmented.
Differential Revision: https://phabricator.services.mozilla.com/D203707
