The scroll snap spec defines the concepts [1]. There are three type of scroll
operations. 1) intended end position, 2) intended direction and end position
and 3) intended direction.
Basically our existing ScrollUnits types correspond;
1) DEVICE_PIXELS, WHOLE => intended end position
2) PAGES => intended direction and end position
3) LINES => intended direction
There are two exceptions in the `intended direction and end position` case,
scrollBy() and fling gestures (on Linux). They were defined as scroll operations
with DEVICE_PIXELS unit, but the spec cleary says they are `intended direction
and end position` operations.
Note that we will also use this information for scroll-snap-stop property since
the properly will only have effects on both 2) and 3) cases.
[1] https://drafts.csswg.org/css-scroll-snap/#scroll-types
Depends on D145190
Differential Revision: https://phabricator.services.mozilla.com/D145191
The second best edge is used for `snap-overflow` feature [1]. The
`snap-overflow` is applied when the following conditions are met.
1) A scroll snap target element is larger than the snapport (e.g. scrollport)
in an axis
2) The distance between the best edge and the second best edge (on the opposite
side of the best edge) is later than the snapport size in the axis
There was a problem in our implementation. For example, in below diagram, D is
the original destination of the given scroll operation, 1 is the best edge, 2 is
the second best in our original implementation and 3 is of of the other snap
points. In this case if there's an element larger than the distance between 1
and 3 and if the snapport size is larger than the distance between 1 and 2 but
smaller than the distance between 1 and 3, we should apply `snap-overflow`.
2 1 D 3
|-|---|-----|
There are a couple of test cases in wpt for this condition, for example there's
one of them in oveflowing-snap-area.html [2]. That test case have been passed
incorrectly due to our incorrect `snap-scope` implementation which will be fixed
a subsequent change in this commit series.
[1] https://drafts.csswg.org/css-scroll-snap-1/#snap-overflow
[2] https://searchfox.org/mozilla-central/rev/13d69189a8abfc5064fe44944550b9b6eb4544f5/testing/web-platform/tests/css/css-scroll-snap/overflowing-snap-areas.html#131-137
Differential Revision: https://phabricator.services.mozilla.com/D144531
Note: The WPT test included in this test is intended to excercise cases that
are (newly) interoperable between WebKit, Blink, and Gecko (with this patch).
There are other related cases where browsers still disagree; I'll add
additional WPT tests for those cases in a later patch in this series.
Differential Revision: https://phabricator.services.mozilla.com/D145159
Change to derive from nsDisplayEffectsBase, since the backdrop-filter
can still have a visual bounds (and effect) even if the child
stacking context has no items. Also use the same approach to get
the bounding rect and implement GetBounds as nsDisplayFilters uses.
Differential Revision: https://phabricator.services.mozilla.com/D145295
This patch does not impact behavior.
Before this patch, these variables' names are abbreviations of their original
type-name, "nsCSSOffsetState". We renamed that type to SizeComputationInput in
bug 1277129, and this patch just updates the variable-names to reflect that
renaming, so that now they're abbreviations of the new type-name, rather than
the old one.
This patch also takes this opportunity to move these variables declarations
closer to their usage, and in one case we convert a variable to be a temporary
anonymous value in the middle of another assignment.
Differential Revision: https://phabricator.services.mozilla.com/D145137
This patch doesn't impact behavior.
The namespace prefix is unnecessary, given the fact that this code is all
inside `namespace mozilla {...}`.
Differential Revision: https://phabricator.services.mozilla.com/D145136
This patch does not impact behavior; it's just a handful of renamings and
documentation-updates.
Before this patch, our float-handling code has a bunch of variables and
functions with "replaced" in the name. But in fact these aren't necessarily
replaced; they're just block-level frames that elicit a "false" return-value
from "BlockCanIntersectFloats". This category *includes* replaced boxes, and
it also includes frames that establish a formatting context, e.g.:
scrollframes, flex/grid containers, flow-root, table.
This patch seeks to clarify things by renaming these to refer to the fact that
they "avoid" floats, e.g. s/replacedBlock/floatAvoidingBlock/.
I've included a comment to reference this term in the BlockCanIntersectFloats()
documentation (note that the "can intersect" concept is the opposite of
"avoids"). I've also renamed a few "aFrame" variables to
"aFloatAvoidingBlock", for a few functions that are explicitly dealing with
this scenario and only expect to be passed frames that are in this category.
Differential Revision: https://phabricator.services.mozilla.com/D145131
This patch does not impact behavior; it's just formatting changes.
This patch was automatically generated by the following command:
./mach clang-format -p layout
Differential Revision: https://phabricator.services.mozilla.com/D145163
Please note that ScaleFactors2D is missing operator*=() for now,
hence the "resolutionToScreen = resolutionToScreen * X" formula.
Differential Revision: https://phabricator.services.mozilla.com/D144883
This has a TODO about empty page names on previous sibling frames, to match
Chrome's behavior of page break coalescing we should be looking to the frame
before that sibling and check for page breaks there instead.
Differential Revision: https://phabricator.services.mozilla.com/D140423
Fix regression from returning zero intrinsic size for audio
elements, which caused the element to be positioned incorrectly
in absolutely positioned, orthogonal flow situations.
Differential Revision: https://phabricator.services.mozilla.com/D144182
There are some mediaqueries-5 features that we still don't support and
explain the remaining failures in at-container-{parsing,serialization}.
Differential Revision: https://phabricator.services.mozilla.com/D144446
Basically, the transferred min & max sizes shouldn't override the min &
max sizing properties, so applying it earlier than these properties
should be identical. This just makes the flex base size and main size be
more correct at the beginning (and so other adjustments of sizes
in flex algorithm can override the transferred min/max sizes), for
non-replaced elements.
Note:
In Chromium code, it clamps the flex items' base size by transferred min &
max sizes, but the computation of items' used min & used max sizes doesn't
include the transferred min & max sizes.
So in this patch, I'm trying to make this patch simple: we let minimum &
maximum sizes only taken into account for flex base size and only for
non-replaced elements for now. So the behavior should be similar to other
browsers.
And we may have to update this tentative solution once these spec words get
updated.
Differential Revision: https://phabricator.services.mozilla.com/D144499
This can happen on regular content (I see it when loading google.com on
a debug build for example). Given there's no action to take it seems
only noise atm. No strong opinion into whether it's better to ifdef the
code or just remove it.
Differential Revision: https://phabricator.services.mozilla.com/D144415
Instead, make the behavior consistent across all <length-percentage>
values (by truncating instead of rounding). This is the already-existing
behavior for calc() and percentages, but with this patch we also apply
it to plain length-flavored <length-percentage> values (this is needed
to avoid regressing things like bug 989802).
Regular <length>s keep rounding, to preserve existing behavior. We can
consider changing that in a follow-up if need be.
Differential Revision: https://phabricator.services.mozilla.com/D143857
There are two cases for the audio element:
1. audio element with "controls" - replaced element (but UA shouldn't
show the content. Only control UI there.)
2. audio element without "controls" - UA sets display:none.
Per spec, if a replaced element’s only natural dimension is a natural width or
a natural height, giving it a preferred aspect ratio also gives it an natural
height or width, whichever was missing, by transferring the existing size
through the preferred aspect ratio.
However, the audio element (with or without "controls") doesn't have the
natural ratio and natural size. I think it's a special case and it doesn't
make sense to apply aspect-ratio to it even though we specify a width or
height.
Blink and Webkit don't apply aspect-ratio to audio element, either. So
let's follow other browsers' behavior.
Differential Revision: https://phabricator.services.mozilla.com/D118245
This change applies the same fix in the code above for mix-blend
containers to backdrop roots. Without this, the backdrop-root is
the viewport, so it includes things like the fixed position background
rects used for checkerboarding.
Differential Revision: https://phabricator.services.mozilla.com/D142772
Norisz Fay
Hiroyuki Ikezoe
Emilio Cobos Álvarez
Narcis Beleuzu
Daniel Holbert
Glenn Watson
Emily McDonough
Tooru Fujisawa
Boris Chiou
Razvan Cojocaru
Morgan Reschenberg
David Shin
Martin Robinson
Noemi Erli
Cosmin Sabou
Peter Van der Beken
Olli Pettay