And don't resolve them prematurely; the computed value should remain
logical, and only be mapped to physical sides at use time.
Differential Revision: https://phabricator.services.mozilla.com/D229998
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
Also add meta viewport tag to the setup of `/FileAPI/url/url-in-tags.window.js`
WPT - This test passes now, but without this change, the test's viewport gets
automatically zoomed out when run on Android; and that zoom factor can lead to
off-by-one test failures from pixel-rounding discrepancies.
Differential Revision: https://phabricator.services.mozilla.com/D229191
Normally we shouldn't be starting reflow from a block that is not a BFC,
and so BlockNeedsFloatManager would return true for the reflow root.
What happens in the testcase here, though, is that we call PresShell::FrameNeedsReflow
for the <article> block (because we've just added a child to it), which is fine:
it's a BFC at that moment.
Then we restyle, and during restyling we remove the NS_BLOCK_BFC flag because the
newly-added element means that the <article> no longer matches ::only-child, and
so we lose the `contain` property that was previously set. So <article> is no longer
a BFC, but we've already recorded it in the PresShell's mDirtyRoots.
We then call PresShell::FrameNeedsReflow for the foreignObject, which adds that
to mDirtyRoots as well.
And then we flush layout, reflowing first the foreignObject (because it is the
shallower of the two dirty-roots) and then the <article> block. We might expect
that the reflow of the SVGForeignObject would fix things, because it would reflow
all its descendants (including <article>) safely, but there's an early-return in
SVGForeignObjectFrame::Reflow in the case where it is zero-sized (which it is here).
So the <article> block remains dirty, and PresShell::ProcessReflowCommands tries
to reflow it directly even though it is no longer a BFC, and that's when we crash
due to not having a float manager.
Removing that early-return from SVGForeignObjectFrame::Reflow would avoid the crash,
but in any case I think we should make nsBlockFrame::Reflow handle this situation
as there may be other code-paths that potentially set up a similar scenario of
attempting to reflow from a root that has lost its BFC-ness.
Differential Revision: https://phabricator.services.mozilla.com/D228778
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 does not change the result, only the performance characteristics:
the search will be fast if the target frame is near either edge of the line,
not only if it's at the end.
Also includes a bit of trivial cleanup that I noticed in the surrounding
nsLineBox code. (No changes to behavior.)
Differential Revision: https://phabricator.services.mozilla.com/D226916
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
Currently, only the grid container needs the containing block size to resolve
the transferred min and max sizes for `repeat()` function in
`nsGridContainerFrame::ComputeIntrinsicISize()`.
This patch is a preparation for Bug 1865438. `mContainingBlockSize` will be used
there, so it does not change any behavior yet.
Differential Revision: https://phabricator.services.mozilla.com/D221333
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
