No change in behavior, just makes it clearer when we're working with used values
where the inline-* logical values have been resolved.
Differential Revision: https://phabricator.services.mozilla.com/D230029
No change in behavior, just makes it clearer when we're working with used values
where the inline-* logical values have been resolved.
Differential Revision: https://phabricator.services.mozilla.com/D230029
Added Gecko reftests because I don't know what the best place to put
them in WPT is, and caret rendering is kind of undefined, but...
Differential Revision: https://phabricator.services.mozilla.com/D229926
Added Gecko reftests because I don't know what the best place to put
them in WPT is, and caret rendering is kind of undefined, but...
Differential Revision: https://phabricator.services.mozilla.com/D229926
Added Gecko reftests because I don't know what the best place to put
them in WPT is, and caret rendering is kind of undefined, but...
Differential Revision: https://phabricator.services.mozilla.com/D229926
This avoids returning wrong intrinsic values with different calls into
intrinsic size computation, which is wrong by definition.
We shouldn't be wallpapering over it by clearing intrinsic sizes
mid-layout as the original patch was doing.
Differential Revision: https://phabricator.services.mozilla.com/D229621
This avoids returning wrong intrinsic values with different calls into
intrinsic size computation, which is wrong by definition.
We shouldn't be wallpapering over it by clearing intrinsic sizes
mid-layout as the original patch was doing.
Differential Revision: https://phabricator.services.mozilla.com/D229621
This means that when users scroll to the inline-end of a scroller, they will
see that the inline-end padding of that scroller is added in.
This is achieved by unioning an additional rect into the scrollable element's
overflow area (Which is an accumulation of the recursive overflow-area
contributions from its subtree).
This additional rect is calculated as follows:
- In-flow children and float's margin boxes are unioned (including zero-size boxes)
- The unioned rect is then inflated by the scrollable element's padding
Note: The bounds of zero-area in-flow-child rects are included in this rect,
in both block- and inline- directions. This is a change in behavior; Divs of
huge inline size and zero block size used to not affect the scrollable overflow,
where divs with huge block size and zero inline size did, as a side effect of now
removed `nsBlockFrame::ConsiderBlockEndEdgeOfChildren`.
Note on WPT change sizing-orthog-(vlr|vrl)-in-htb-(008|020)-ref.xht - the padding existed
to force empty space below `p#sentence-after`. However, this only applies to previous
Firefox. Any combination of browser + default font (+ its default size) causing a scroll
would cause the test to fail as false positive (According to wpt.fyi, this is what happens
with sizing-orthog-(vlr|vrl)-008.xht tests). This change brings Firefox's scroll behaviour
inline with other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D151310
This means that when users scroll to the inline-end of a scroller, they will
see that the inline-end padding of that scroller is added in.
This is achieved by unioning an additional rect into the scrollable element's
overflow area (Which is an accumulation of the recursive overflow-area
contributions from its subtree).
This additional rect is calculated as follows:
- In-flow children and float's margin boxes are unioned (including zero-size boxes)
- The unioned rect is then inflated by the scrollable element's padding
Note: The bounds of zero-area in-flow-child rects are included in this rect,
in both block- and inline- directions. This is a change in behavior; Divs of
huge inline size and zero block size used to not affect the scrollable overflow,
where divs with huge block size and zero inline size did, as a side effect of now
removed `nsBlockFrame::ConsiderBlockEndEdgeOfChildren`.
Note on WPT change sizing-orthog-(vlr|vrl)-in-htb-(008|020)-ref.xht - the padding existed
to force empty space below `p#sentence-after`. However, this only applies to previous
Firefox. Any combination of browser + default font (+ its default size) causing a scroll
would cause the test to fail as false positive (According to wpt.fyi, this is what happens
with sizing-orthog-(vlr|vrl)-008.xht tests). This change brings Firefox's scroll behaviour
inline with other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D151310
This matches Blink with border / padding in nested blocks, and seems
worth doing even if we paint the nested lines. Follow-up patch will
prevent painting the nested lines.
Differential Revision: https://phabricator.services.mozilla.com/D157572
This matches Blink with border / padding in nested blocks, and seems
worth doing even if we paint the nested lines. Follow-up patch will
prevent painting the nested lines.
Differential Revision: https://phabricator.services.mozilla.com/D157572
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
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
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
On optimized builds for all desktop platforms, `nsBlockFrame` is 192 bytes, and
`mFloats` is 16 bytes. With this patch, we can reduce the size of `nsBlockFrame`
to 176 bytes, saving 8.33% memory on every `nsBlockFrame` and its derived
subclasses allocated.
On a real webpage like https://en.wikipedia.org/wiki/Firefox, `about:memory`
shows that we allocate 0.36 MB of `nsBlockFrame` consistently. After this patch,
we allocate 0.33 MB, saving approximately 30 KB (0.36 MB * 8.33%) of the memory.
Differential Revision: https://phabricator.services.mozilla.com/D214046
`EnsurePushedFloats()` either returns the existing pushed floats list or creates
a new empty one. Therefore, it can never return nullptr.
Differential Revision: https://phabricator.services.mozilla.com/D214045
On optimized builds for all desktop platforms, `nsBlockFrame` is 192 bytes, and
`mFloats` is 16 bytes. With this patch, we can reduce the size of `nsBlockFrame`
to 176 bytes, saving 8.33% memory on every `nsBlockFrame` and its derived
subclasses allocated.
On a real webpage like https://en.wikipedia.org/wiki/Firefox, `about:memory`
shows that we allocate 0.36 MB of `nsBlockFrame` consistently. After this patch,
we allocate 0.33 MB, saving approximately 30 KB (0.36 MB * 8.33%) of the memory.
Differential Revision: https://phabricator.services.mozilla.com/D214046
`EnsurePushedFloats()` either returns the existing pushed floats list or creates
a new empty one. Therefore, it can never return nullptr.
Differential Revision: https://phabricator.services.mozilla.com/D214045
- Remove "FRAME" for nsBlockFrame state bits for the consistency with other bits.
- Use helpers instead of checking state bits if possible.
- Tweak one line documentation to use C++ comment style.
- Move `GetMarker()` to protected section because it is used only internally.
Differential Revision: https://phabricator.services.mozilla.com/D213698
This is Fantasai's original patch, massively simplified:
* We now can switch whether we're a BFC dynamically (bug 1765615), which
simplifies the patch quite a lot.
* I removed some changes that were specific to pagination but were untested.
I left them as D202814, just in case we need some of those in the future.
All in all this makes the patch much more manageable.
Co-authored-by: Emilio Cobos Álvarez <emilio@crisal.io>
Differential Revision: https://phabricator.services.mozilla.com/D181858
This happens in a similar location to where we find a breakpoint caused by a
change in page name. However, if the breakpoint was caused by something else,
we still need to compute this value so that the next page being constructed
will have the correct page name.
This also "fixes" the WPT /css/printing/page-name-007-print.html, which passed
before this patch just because our previous logic would continue using the last
page value in those cases, which coincidentally matched what was expected.
Part 2 will include a test that specifically detects this discrepency.
Differential Revision: https://phabricator.services.mozilla.com/D196895
This happens in a similar location to where we find a breakpoint caused by a
change in page name. However, if the breakpoint was caused by something else,
we still need to compute this value so that the next page being constructed
will have the correct page name.
This also "fixes" the WPT /css/printing/page-name-007-print.html, which passed
before this patch just because our previous logic would continue using the last
page value in those cases, which coincidentally matched what was expected.
Part 2 will include a test that specifically detects this discrepency.
Differential Revision: https://phabricator.services.mozilla.com/D196895
