Frozen flex items have already been clamped to their min/max sizes, so their
size-change isn't a "how much we want to flex" measurement, and it's not useful
for determining whether the rest of the line is shrinking.
This patch is just adding a `if (!item->IsFrozen())` check around some code,
and reindenting that code, and adjusting a few comments.
This change is necessary to avoid failing the "GrowthState" assertions,
because (for example) a flex item that's clamped to a small max-width
could fool us into thinking we're in a "shrinking" state (since its final
size is smaller than its base size), even though really we're
in a "growth" state and the item was simply clamped. We avoid this
problem by skipping (potentially-clamped) frozen items when determining
the line's GrowthState.
Depends on D8922
Differential Revision: https://phabricator.services.mozilla.com/D9018
--HG--
extra : moz-landing-system : lando
We'd like to be able to record the "desired" (pre-clamped) delta size from
tentatively flexing for these items. That size would be computed during a loop
of the flex layout algorithm -- but we can't do that if we freeze them before
we start flexing. So let's bypass this early freeze so they get a chance to
compute this tentative size, even though they can never have it.
Differential Revision: https://phabricator.services.mozilla.com/D8922
--HG--
extra : moz-landing-system : lando
PresShell::PageMove() climbs up to parent document when there is no scrollable
parent in current document. However, if aExtend is true, it should expand
Selection in the document itself. Therefore, it needs different rules to
look for container of expanding Selection from scrollable element to scroll.
Additionally, old rules (i.e., before the fix of bug 1369072 which caused
this regression) were also buggy. It used parent scrollable element or
root scrollable element simply. Therefore, if found scrollable element is
ancestor of selection limiter, it didn't work as expected.
This patch creates nsFrameSelection::GetFrameToPageSelect() to retrieve
per-page selection container element with the following rules:
- look for a scrollable element in selection limiter.
- if there is no scrollable element, use selection limiter.
- if there is no selection limiter, use the root frame.
So, nsFrameSelection::CommonPageMove() should take nsIFrame rather than
nsIScrollableFrame since container of per-page selection may be used in
non-scrollable contenteditable element. If it's called with non-scrollable
frame, it needs to compute the expanding range with the frame size.
Differential Revision: https://phabricator.services.mozilla.com/D8954
--HG--
extra : moz-landing-system : lando
In order to get the correct computed value of these keywords, we have to
make sure we store the correct computed values in sizing properties in
both inline axis and block axis.
-moz-max-content and -moz-min-content should behave as the property's
initial value in block axis. -moz-fit-content and -moz-available are not
supported in block axis, so we also treat them as initial values.
Differential Revision: https://phabricator.services.mozilla.com/D8290
--HG--
extra : moz-landing-system : lando
nsRefreshDriver::ObserverArray is a nsTObserverArray which is
infallible, so no need to check the return value from AppendElement
(which a later patch in this series will remove).
It's not really invalidated anywhere, and the float manager code only checks for
float region changes. Extend it so that it knows about shapes as well, and avoid
reframing due to a bogus nsChangeHint_ScrollbarChange which really meant to be
UpdateOverflow, which really is useless in this situation..
Differential Revision: https://phabricator.services.mozilla.com/D7583
The CSSWG has recently resolved that layout containment
suppress baseline alignment, while size containment does not:
https://github.com/w3c/csswg-drafts/issues/2995
Spec text (https://drafts.csswg.org/css-contain/#containment-layout):
"7. For the purpose of the vertical-align property,
or any other property whose effects need to relate
the position of the containing element's baseline
to something other than its descendants,
the containing element is treated as having no baseline."
And a note in (https://drafts.csswg.org/css-contain/#containment-size):
"Note: size containment does not suppress baseline alignment.
See layout containment for that."
This patch does this change just switching IsContainSize()
by IsLayoutSize() in several places related to baseline alignment
in the source code.
With the patch several WPT tests start to pass. Apart from that,
some of the tests under vendor-imports are updated to follow
the new behavior.
--HG--
extra : amend_source : 05dc9a320afeb1d58981e2bd8bc47b435999f2f9
Before this patch, TextOverflow had an explicitly-*defaulted* default
constructor. But in fact, this constructor was *implicitly* deleted because one
of the member variables (of type LogicalRect) couldn't be default-constructed
due to having its own default constructor explicitly deleted.
clang trunk highlights this inconsistency with a build warning
(-Wdefaulted-function-deleted) which this patch addresses.
Differential Revision: https://phabricator.services.mozilla.com/D8028
--HG--
extra : moz-landing-system : lando
If we're waiting on an interrupt, then our child items haven't been totally
reflowed and our measures would be bogus.
This will probably regress performance in the cases bug 1209697 fixed, so we
should probably add an interrupt check somewhere in nsFlexContainerFrame to
avoid keeping reflowing flex containers indefinitely.
We could probably just bail out from our reflow if any kid reflow was
interrupted.
Filed bug 1495532 to consider that.
Differential Revision: https://phabricator.services.mozilla.com/D7288
--HG--
extra : moz-landing-system : lando
Once again, calculating the amount of font size inflation isn't as expensive as
it used to be, but there's still no need to do it unnecessarily. The current
code does this unconditionally as part of computing a frame's margins
Additionally, calculating the font size inflation for frames that we don't
actually want to inflate also messes with the planned writing mode assertions
from bug 1428670. In some special cases (e.g. the scroll bars), a frame might
use a different writing mode (horizontal/vertical) than its parent without
creating a new font inflation flow root at the boundary. As long as we never
want to apply font size inflation for that frame this is okay, but if the margin
computation then runs the font inflation calculation regardless, we have a
problem.
Differential Revision: https://phabricator.services.mozilla.com/D7329
--HG--
extra : moz-landing-system : lando
When one of the two factors governing the effective container width for font
inflation changes, we need to mark all affected frames as dirty.
While the visible area commonly changes because of viewport changes and we can
catch those through the check for ISize resizes of the top-level frame
("!mFrame->GetParent() && isIResize"), it still seems nicer to move calculation
of the effective container width into the FontInflationData itself, especially
since the effective container width calculation in nsLayoutUtils is the only
consumer of the NCAISize currently stored by the FontInflationData.
That way
- we can be sure that really all changes of the visible width will correctly
mark all affected frames as dirty
- can avoid repeatedly recalculating the effective container width
- can also detect the cases where the effective container width actually remains
the same after a change in one of its input factors and skip forcing a full
dirty reflow for all descendants just because of font inflation.
While the code in nsLayoutUtils was technically always using the writing
mode (horizontal/vertical) of each individual frame for determining which
dimension of the visible size should be used for clamping, just using the
writing mode of the respective flow root should be enough, since each change in
the writing mode should create a new flow root.
This assumption should already hold today because
1. as per the Writing Modes CSS spec, a change in writing mode compared to its
parent means that the affected block cannot be purely "inline", but at most
"inline-block".
2. Generally, any non-inline frame will be marked as a font inflation container.
3. Any block frame whose writing direction doesn't match its parent will be a
block formatting context, which implies NS_BLOCK_FLOAT_MGR.
4. Any block frame that has both NS_BLOCK_FLOAT_MGR set and is a font inflation
container will also become a font inflation flow root.
but because this chain of reasoning is not the most direct, we also add a
corresponding assertion to better catch any potential bugs here.
Differential Revision: https://phabricator.services.mozilla.com/D5578
--HG--
extra : moz-landing-system : lando
Before bug 1308876, child frames marked themselves as dirty during reflow if
their parent was dirty, too. After bug 1308876, the point where dirtiness is
being propagated to a frame's descendants has been shifted: Now, dirty parents
are responsible for marking all their children as dirty, too, when the parent
starts reflowing.
This means that if a frame wants to mark a whole subtree as dirty *during its
own* reflow, it's no longer sufficient to just mark the root of the subtree as
dirty and then rely on all further children marking themselves as dirty as well
when reflow reaches them.
The font inflation code is one such case. When the font inflation data on a font
inflation flow root has become dirty, or we're resizing the top-level frame
(which because of the effective container width clamping from bug 707855 can
affect the font inflation font size as well), we now need to explicitly mark all
affected children as dirty.
Differential Revision: https://phabricator.services.mozilla.com/D5577
--HG--
extra : moz-landing-system : lando
In bug 1488300 xidorn make us kick off loading of masks/filters/clipPaths in
resource documents when the style context is set so that the 'load' event
will be blocked until they load. I missed that in 5177bb8cb2ce (bug 1494355)
where we stopped creating the SVGFilterObserverList in
SVGObserverUtils::GetEffectProperties since I missed that creating that object
looks up the target element (without observing it), which triggers loading of
external resources as necessary.
Differential Revision: https://phabricator.services.mozilla.com/D7188
--HG--
extra : rebase_source : 698fe4b437660761e457ecf54d8d604a098229db
extra : amend_source : 3ae9f25761372ee6a33bd4043c7bf6183361ca58
This patch make nsCSSFrameConstructor::CreateGeneratedContentItem() early
returns if the originating element contains an UA Widget shadow root.
Differential Revision: https://phabricator.services.mozilla.com/D6828
--HG--
extra : moz-landing-system : lando
nsCSSFrameConstructor::FindDisplayData() guarantees a block with "display:
list-item" will be constructed by ConstructBlock() (either through
ConstructScrollableBlock() or ConstructNonScrollableBlock()).
This is also a preparation to fix bug 1491915 since we want to control
bullet frame creation under column hierarchy.
Depends on D6840
Differential Revision: https://phabricator.services.mozilla.com/D6841
--HG--
extra : moz-landing-system : lando
Those arguments were added in bug 591737 to create a triangle for the
summary frame, but <summary> has been re-implemented by using "list-item"
since then. Now the only caller is nsBlockFrame itself, so there's no need
to expose those arguments.
Differential Revision: https://phabricator.services.mozilla.com/D6839
--HG--
extra : moz-landing-system : lando
It's queried during layer building, for the RCD-RSF only. If we set it for
a subframe RSF, that overwrites the value for the RCD-RSF, and we end up
querying the incorrect value.
Differential Revision: https://phabricator.services.mozilla.com/D6536
--HG--
extra : moz-landing-system : lando
This patch isn't expected to change behavior; it's just some simplification.
Depends on D6976
Differential Revision: https://phabricator.services.mozilla.com/D6978
--HG--
extra : moz-landing-system : lando
This patch isn't expected to change behavior; it's just some simplification.
Differential Revision: https://phabricator.services.mozilla.com/D6976
--HG--
extra : moz-landing-system : lando
A flex item's available inline size would be relevant (i.e. would have an
impact on layout) if we were fragmenting the flex item in its inline direction
(e.g. if it were an inline-level box, in an inline-layout context).
But we're not doing that, so its available isize doesn't make a difference. To
the extent that it's been useful at all in this flex-item-caching code up to
this point, we'll now be caching something more-specific (the item's *computed*
inline size) which should serve roughly the same purpose.
Depends on D6991
Differential Revision: https://phabricator.services.mozilla.com/D6992
--HG--
extra : moz-landing-system : lando
Daniel Holbert
Brad Werth
Masayuki Nakano
Boris Chiou
Gurzau Raul
Miko Mynttinen
Mats Palmgren
Diego Pino Garcia
Noemi Erli
Emilio Cobos Álvarez
Manuel Rego Casasnovas
Edgar Chen
Narcis Beleuzu
Ryan Hunt
Nicholas Nethercote
Jan Henning
Jonathan Watt
Timothy Guan-tin Chien
Coroiu Cristina
Xidorn Quan
Ting-Yu Lin
shindli
Botond Ballo