Otherwise we may keep the scroll anchor around and we may try to anchor to it
later even though we should've really suppressed it completely.
Maybe we should just call InvalidateAnchor() unconditionally from that code
path, even if there are no suppressions pending...
Differential Revision: https://phabricator.services.mozilla.com/D48456
--HG--
extra : moz-landing-system : lando
Unclear whether the visual viewport code path is the right thing to do at all.
Differential Revision: https://phabricator.services.mozilla.com/D47791
--HG--
extra : moz-landing-system : lando
That is, for the multicol container of depth two and more, we lay them
out by using "column-fill:auto" and "column-count:1".
I've check bug 725376 comment 9 for the previous approaches. Thanks to
bug 1555818, this solution is feasible because the fragmentation with
"column-fill:auto" is now possible.
Differential Revision: https://phabricator.services.mozilla.com/D47011
--HG--
extra : moz-landing-system : lando
I think these should hold, everything that runs under them should just schedule
other stuff to some later date:
* Synth mouse events -> scheduled as refresh driver observers.
* Scroll events -> Scheduled as well.
* Caret state change events -> Also scheduled after last patch.
* IME and accessibility stuff -> I don't think they can reenter layout.
We can always revert this if it causes troubles, plus it shouldn't crash on
release so should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D31090
--HG--
extra : moz-landing-system : lando
I think most of them should not be needed after bug 1561450. From our discussion
at TPAC in https://github.com/w3c/csswg-drafts/issues/4239, there should be no
reason not to do this unless we find fallout.
We need to enable the pref in tests that test these particular heuristics of
course.
Differential Revision: https://phabricator.services.mozilla.com/D47315
--HG--
extra : moz-landing-system : lando
That is, for the multicol container of depth two and more, we lay them
out by using "column-fill:auto" and "column-count:1".
I've check bug 725376 comment 9 for the previous approaches. Thanks to
bug 1555818, this solution is feasible because the fragmentation with
"column-fill:auto" is now possible.
Differential Revision: https://phabricator.services.mozilla.com/D47011
--HG--
extra : moz-landing-system : lando
This patch makes fragmentation in "column-fill:auto" mode possible.
Note that we only bail out of creating more column contents when
"column-fill:auto" mode is set from the styles, i.e. when mForceAuto is
false. That is because when mForceAuto is true, we usually in the case
where we have gave up balancing, and we really want to create overflow
columns.
Note: without `!aConfig.mForceAuto` check, 673770.html can generated
assertions, and the frame tree contains dangling Overflow-lines and
ExcessOverflowContainersList.
Differential Revision: https://phabricator.services.mozilla.com/D47005
--HG--
extra : moz-landing-system : lando
mUsedColCount is used in balancing mode to check whether we have created
the maximum number of columns when the content cannot fit. Similarly,
mUsedColCount can also be useful in "column-fill:auto" mode to improve
the fragmentation story in the next patch.
This patch doesn't change the behavior (yet).
Differential Revision: https://phabricator.services.mozilla.com/D47004
--HG--
extra : moz-landing-system : lando
In next patch, this variable won't be set to INT32_MAX in
"column-fill:auto" mode, and it will be used in Part 4. Hence the
rename.
Differential Revision: https://phabricator.services.mozilla.com/D47003
--HG--
extra : moz-landing-system : lando
The associated if-block has a "break" statement at the end of the scope
to break the while-loop, making the else-block redundant.
Differential Revision: https://phabricator.services.mozilla.com/D47002
--HG--
extra : moz-landing-system : lando
Fragmentation spec already has a paragraph describing this behavior.
DONTBUILD because this is a comment only change.
Differential Revision: https://phabricator.services.mozilla.com/D46691
--HG--
extra : moz-landing-system : lando
In particular: in our frontend code, if we happen to end up with a flex/grid
item with 'display:-moz-box', we want it to take the same sizing codepath as
other flex/grid items, which are all block-level (even though -moz-box is not
exactly block-level itself). Notably, we want to use ComputeSizeFlags::eDefault
for sizing (like we do for real block-level things), because that's necessary
in order for grid items to stretch correctly in their inline axis.
Also: this patch renames "isBlock" to "isBlockLevel" to reflect reality. Its
naming is based on the constant NS_CSS_FRAME_TYPE_BLOCK, which in fact is not
specific to 'display:block' but in fact is for frames that are "block-level in
normal flow" (which I think in practice means block-level and not
out-of-flow). That is documented here:
https://searchfox.org/mozilla-central/rev/7531325c8660cfa61bf71725f83501028178cbb9/layout/generic/ReflowInput.h#51
Differential Revision: https://phabricator.services.mozilla.com/D46539
--HG--
extra : moz-landing-system : lando
This is in the interests of allowing the frontend team to experiment with
switching from XUL grid to CSS grid, without inadvertently changing the
display values for the grid items via css-grid-item blockification.
This patch's new pref is not expected to remain in the codebase for long.
We're just adding it so that the behavior remains the same by default, because
we do currently have some XUL code that inadvertently depends on -moz-box
display values being blockified to 'block'. The plan is for folks to remove
that dependency e.g. by adding explicit 'display:block' styling to frontend
code as-needed. After we've done that, we can tentatively flip the pref to true
by default, and then remove the pref entirely.
Differential Revision: https://phabricator.services.mozilla.com/D45258
--HG--
extra : moz-landing-system : lando
Currently, there's no way to tell whether the SIDEWAYS bit is set from
`writing-mode:sideways-*` or `writing-mode:vertical-*; text-orientation:sideways;`.
To be able to tell them apart, split SIDEWAYS bits into VERTICAL_SIDEWAYS
and TEXT_SIDEWAYS. This is needed by my proposed solution in bug 1102175.
Also, provide convenience methods related to sideways writing-mode, and replace
obscure checks in the codebase.
Note that we don't have the use cases to distinguish vertical-rl from
sideways-rl in layout, but for the completeness, IsSidewaysLR() is still
defined.
Differential Revision: https://phabricator.services.mozilla.com/D46321
--HG--
extra : moz-landing-system : lando
Brendan Dahl
Emma Malysz
Emilio Cobos Álvarez
Ricky Stewart
Daniel Varga
Savo
Sylvestre Ledru
Morgan Reschenberg
Ting-Yu Lin
Cameron McCormack
Matt Woodrow
Brad Werth
Mats Palmgren
Tim Nguyen
Daniel Holbert
Dorel Luca
L. David Baron
Coroiu Cristina
Geoff Brown
Kris Maglione
Lee Salzman
Jonathan Kew
Bogdan Tara
Alexander Surkov