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
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
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
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
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
- Drop the "ns" prefix, and move the class into mozilla namespace.
- Remove unnecessary constructors and `operator=` because compiler can generate
them automatically.
- Change `get` to `Get` to conform to the coding style.
- Misc cosmetic fix such as adding braces.
Differential Revision: https://phabricator.services.mozilla.com/D217056
- Drop the "ns" prefix, and move the class into mozilla namespace.
- Remove unnecessary constructors and `operator=` because compiler can generate
them automatically.
- Change `get` to `Get` to conform to the coding style.
- Misc cosmetic fix such as adding braces.
Differential Revision: https://phabricator.services.mozilla.com/D217056
Rename `mHasForcedLineBreak` to `mHasForcedLineBreakAfter` since block lines
don't need to set this bit. This patch removes setting the bit in
`SetFloatClearTypeBefore()`, and adds an assertion in
`HasForcedLineBreakAfter()` to ensure that.
Improve `HasFloatClearType(Before|After)` implementation by using
`FloatClearType(Before|After)`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D205154
With only the Part 1, `layout/generic/crashtests/1683126.html` will timeout.
It can be reproduced locally via
```
./mach crashtest layout/generic/crashtests/1683126.html
```
It is because if we destroy a frame list from the first child to the last child,
each time we destroy the first child [1], the second child become the new first
child, and we have to update the first-in-flow and first-continuation cache for
later continuations, which is a linear time operation.
[1] See nsSplittableFrame::RemoveFromFlow() with the argument being the first
child in a frame list.
Differential Revision: https://phabricator.services.mozilla.com/D197967
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
* Rename `mBreakType` to `mFloatClearType` in nsLineBox and nsReflowStatus and
the methods around it.
* Rename `mBreakType` to `mClear` in nsStyleDisplay.
* Many other method parameters or local variables rename such as from
`aBreakType` to `aClearType`.
Differential Revision: https://phabricator.services.mozilla.com/D158276
* Print StyleClear value verbatim.
* Print mHasForcedLineBreak bit.
* Remove mAllFlags since I doubt anyone can decipher FlagBits from it.
Differential Revision: https://phabricator.services.mozilla.com/D158226
Before this patch, StyleClear::Line indicates that the nsLineBox has break-after
but no float clearance (note we don't allow line break-before with clear:none);
StyleClear::None indicates the line has no break-before nor break-after.
In this patch, I added `mHasForcedLineBreak` bit in nsLineBox to indicate the
line has a break so that StyleClear can serve its original meaning -- the float
clearance. In Part 6, I'll rename more existing methods and variables related to
float clearance.
Now, instead of using StyleClear::None to clear the line break status, the
caller should use ClearForcedLineBreak(); Similar to set
SetInlineLineBreakBeforeAndReset() and SetInlineLineBreakAfter on
nsReflowStatus, SetBreakTypeBefore/SetBreakTypeAfter on nsLineBox always sets
break status with an optional float clearance parameter.
This patch shouldn't change the behavior.
Differential Revision: https://phabricator.services.mozilla.com/D158224
Override GetFrameName() for BRFrame so that frame tree dump shows `BR(br)`
rather than `Frame(br)`.
Also, expand nsLineBox::StateToString() in List() to get rid of `cbuf`.
Differential Revision: https://phabricator.services.mozilla.com/D158111
Nowadays, nsFloatCache stores no extra information but `nsIFrame*`, which makes
nsFloatCacheList and nsFloatCacheFreeList are just singly and doubly linked
list of frames, respectively.
Most of this patch is a plain rewrite to use nsTArray APIs. There are two
rewrite that need more explanation.
1. `BlockReflowState::mFloatCacheFreeList` is served as a temporarily list to
avoid extra allocations of nsFloatCache. It takes the ownership of floats
from a line via FreeFloats(), and later reuses the cache in AddFloat().
We don't need this anymore, so we remove it.
2. In `PlaceBelowCurrentLineFloats()`, the old code removes a float which
needs to be pushed to next continuation from `mBelowCurrentLineFloats`.
After looking through all of the floats, the remaining of
`mBelowCurrentLineFloats` are moved to the line because they belong to the
line. In this patch, rather than removing the pushed floats one by one from
`mBelowCurrentLineFloats`, I use a new list to collect the floats that need
to be added to the line, and just clear `mBelowCurrentLineFloats` at the
end of the method.
Differential Revision: https://phabricator.services.mozilla.com/D157976
The `static_assert` is not very useful and maybe too strict because `StyleClear`
is 8-bits, and we've asserted that `FlagBits` should be not greater than 32-bits
in nsLineBox.h.
Differential Revision: https://phabricator.services.mozilla.com/D157772
This means nsBlockFrame::GetLineIterator is also infallible, so callers that know
they're dealing with an nsBlockFrame (not an arbitrary nsIFrame) don't need to
check for null.
Differential Revision: https://phabricator.services.mozilla.com/D126470
serge-sans-paille