We rely on positioning ancestors before descendants to get the right
position. This was very implicitly enforced before the regressing bug,
by reframing on position changes (due to the order
StickyScrollContainer::AddFrame was called, ancestors before children).
In order to support dynamic sticky changes without reframing, we need to
handle the case of an existing ancestor switching position to sticky
dynamically.
Luckily we already have the right data-structure for that, so the change
is rather trivial.
Write a testharness test for this because APZ does get the position
right, so it's more future-proof against regressions to just test the
raw layout values.
Differential Revision: https://phabricator.services.mozilla.com/D216858
Convert `nsIScrollableFrame` to `ScrollContainerFrame` for all the APIs in
nsLayoutUtils, and then adapt other callers until everything compiles.
In `nsLayoutUtils::CalculateBasicFrameMetrics()`'s documentation,
s/ComputeFrameMetrics/ComputeScrollMetadata/ because the method was renamed in
https://hg.mozilla.org/mozilla-central/rev/cb2023f50288
Differential Revision: https://phabricator.services.mozilla.com/D211493
Convert `nsIScrollableFrame` to `ScrollContainerFrame` for all the APIs in
nsLayoutUtils, and then adapt other callers until everything compiles.
In `nsLayoutUtils::CalculateBasicFrameMetrics()`'s documentation,
s/ComputeFrameMetrics/ComputeScrollMetadata/ because the method was renamed in
https://hg.mozilla.org/mozilla-central/rev/cb2023f50288
Differential Revision: https://phabricator.services.mozilla.com/D211493
In block or flex layout, an 'auto' margin can be used to align the element by
consuming rest of the space of a particular side in its container [1]. However,
if we used the resolved 'auto' margin as part of the element's margin-box, it
won't stick within its scroll container if the margin is larger than the scroll
container's size in that dimension. Bug 1488080 comment 15 has more explanation.
The spec requires all 'auto' margin on the box are treated as zero when
computing Static-Position Rectangle [2] (See the requirement at the end of this
section).
[1] https://drafts.csswg.org/css-flexbox-1/#auto-margins
[2] https://drafts.csswg.org/css-position/#staticpos-rect
Differential Revision: https://phabricator.services.mozilla.com/D209097
Captions should be relatively-positioned (other browsers support this as
well). This ensures we correctly save their normal positions and thus
that the sticky scroll container knows how to reposition them correctly.
Avoid registering inner table frames with the sticky scroll container to
make the assertion sound in cases of sticky-positioned tables.
Differential Revision: https://phabricator.services.mozilla.com/D147092
Captions should be relatively-positioned (other browsers support this as
well). This ensures we correctly save their normal positions and thus
that the sticky scroll container knows how to reposition them correctly.
Avoid registering inner table frames with the sticky scroll container to
make the assertion sound in cases of sticky-positioned tables.
Differential Revision: https://phabricator.services.mozilla.com/D147092
Also, add an nsIFrameInlines.h include to all .cpp files who call these APIs
and who don't yet have an include for this header.
Differential Revision: https://phabricator.services.mozilla.com/D61615
This change effectively disallows sticky elements to enlarge overflow
area. That is, the position of a sticky element will be bounded by the
union of scrolled frame's border-box and the overflow area created by
other non-sticky elements within the same block formatting context.
This makes Firefox's position:sticky elements behaves like Google Chrome
in this respect.
Differential Revision: https://phabricator.services.mozilla.com/D54345
This change effectively disallows sticky elements to enlarge overflow
area. That is, the position of a sticky element will be bounded by the
union of scrolled frame's border-box and the overflow area created by
other non-sticky elements within the same block formatting context.
This makes Firefox's position:sticky elements behaves like Google Chrome
in this respect.
Differential Revision: https://phabricator.services.mozilla.com/D54345
Also for the intersection observer root margin, since it was easier to fix it
up and clean it up than not doing it.
This is the first big step to get rid of nscoord. It duplicates a bit of logic
in nsLayoutUtils since for now max/min-width/height are still represented with
nsStyleCoord, but I think I prefer to land this incrementally.
I didn't add helpers for the physical accessors of the style rect sides that
nsStyleSides has (top/bottom/left/right) since I think we generally should
encourage the logical versions, but let me know if you want me to do that.
Differential Revision: https://phabricator.services.mozilla.com/D17739
This matches Blink's behavior.
Just skipping table row groups from being containing blocks makes
layout/reftests/table-overflow/table-cell-block-overflow.html render differently
(and way more different than any other browser, actually...), so I avoided doing
that.
Though I'm not really proud of this one, better ideas welcome. Maybe I should
just fix table layout so that we agree with WebKit / Blink... But that seemed
harder, too.
MozReview-Commit-ID: AkUB4MFzwZK
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
By changing signature of those two functions, we make compiler complain about
all their existing uses, so we can find all of them and convert them.
Some of the callsites of Get() with those properties are also converted, but not
all of them. It is fine because if there is any incorrect conversion, compilers
is able to find out now. So they are completely typesafe.
- The condition described in the FIXME comment is already handled by
GetNearestBlockContainer in nsFrame.cpp (helper for
nsIFrame::GetContainingBlock).
Emilio Cobos Álvarez