Implement the style part for shape(). Besides, update some issues in the
test file, e.g. avoid using viewport height so we get the fixed result
on different devices.
I will refactor `PathCommand` to let it be a specialization of
`GenericShapeCommand` in the following path.
Differential Revision: https://phabricator.services.mozilla.com/D202882
Per spec
https://drafts.csswg.org/css-shapes-1/#basic-shape-computed-values, and
the spec issue, https://github.com/w3c/csswg-drafts/issues/9053,
all <basic-shape-rect> functions compute to the equivalent inset() function.
i.e.
`xywh(x y w h)` computes to
`inset(y calc(100% - x - w) calc(100% - y - h) x)`
The basic concept is to use `BasicShapeRect` as the specified value of
`<basic-shape-rect>`, i.e. inset()/xywh()/rect(), and its computed value is
the equivalent `InsetRect`, and so it becomes possible to interpolate among
these three functions.
Also, we can drop BuildXywhPath() and ComputeRect() because now there is
only inset() function when building gfx::Path.
Besides, tweak the test, offset-path-shape-xywh-003.html, because the original
test, `xywh(10% 10% 80% 80%)`, has to calculate `calc(100% - 10% - 80%)`.
Its result is `Percentage(0.099999964)` in Rust code, and then it makes us
compute an imprecision inset rect when building the gfx::path, which results in
a transform with the sub-pixel translation. So change it to
`xywh(10% 10% 90% 90%)` to avoid adding fuzzy tolerance.
Differential Revision: https://phabricator.services.mozilla.com/D183221
The fuzzy in the test happens on the round because we use the different way
to draw the round of clip-path (compared to border-radius property) in
the render backend, so there are some tiny differences.
Differential Revision: https://phabricator.services.mozilla.com/D182421
We would like to use these function for all rectangular shape, i.e.
inset()/xywh()/rect(). So rename them to avoid confusion.
No behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D182422
The definition of `<basic-shape>` includes other types of basic shapes,
e.g. path(), xywh(), rect(). So we put them together to match the spec.
However, some properties only use the subset of basic shapes, so we use
the bitflags to choose the supported basic shape at the parse time.
Also, remove StyleBasicShapeType because no one uses it.
Only refactoring in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D179624
[Int]CoordTyped no longer inherits Units because otherwise
instances of [Int]IntPointTyped may get one Base subobject because
it inherits Units, and others because of BasePoint's Coord members,
which end up increasing the [Int]CoordTyped's objects size (since
according to the ISO C++ standard, different Base subobject are
required to have different addresses).
Differential Revision: https://phabricator.services.mozilla.com/D160713
* 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
There are only 3 places where nsMemory.h is still needed (image/RasterImage.cpp,
gfx/thebes/gfxFT2FontList.cpp, and nsMemory.cpp). Remove the rest.
Differential Revision: https://phabricator.services.mozilla.com/D158213
`aY * aY` or `aRadiusY * aRadiusY` can lead to 32-bit integer overflow,
resulting a negative number. Then `sqrt()` will produce a `nan` on a negative
number.
We should compute the `y/radiusY` division, and then square the result.
Differential Revision: https://phabricator.services.mozilla.com/D149951
Without this patch, the test case, floats-aspect-ratio-001.html, hangs because:
1. The initial float available space is correct, and its size is 100px x 50px.
And the bfc element is "width: auto; height: auto; aspect-ratio: 1/1;".
So its width and height depend on the available space.
2. And then, we try to get a new available area based on the height of
the bfc element (note: its size is 100px x 100px). However, we get an
invalid zero-width float available area which is occupied by the element
with float:right (i.e. the pink one), in the first band, and the size of
float available space is 0px x 100px. This makes the size of bfc element
become 0px x 0px when checking `FloatAvoidingBlockFitsInAvailSpace()`.
So it always fits in this float available area. And because we get two
different available areas in the first band (i.e. same `aBCoord`), so we
don't go into the break condition, and contine to get a new
`childReflowInput`, and then go to the next iteration.
3. In the 2nd loop, we try to get a new float available space by the
height of the bfc element (note: its size is 0px x 0px now because
the width of current float available space is 0px), so the
new float available space is 100px x 0px, and the bfc element fits in
this available area, but again, we have two different available
areas, so we still don't go into the break condition. Instead, we use
the new available area to compute the childReflowInput for the next
iteration, and now the size of the bfc element becomes 100px x 100px.
And then we go back to the state of (2).
4. So the bfc element enters a resize oscillation due to the invalid
float available space together with the aspect-ratio and auto sizes
(i.e. "widht: auto; height: auto;") I think. And the invalid float
available space also let |AvailableSpaceShrunk()| be unexpected because
we hit an assertion: "ASSERTION: available space should not grow on the
start side and shrink on the end side".
A possible way is to make sure we get a suitable float available area for
`floatAvoidingBlock`, so this can avoid the bfc element from entering
a resize oscillation.
Note:
1. bfc means block-formatting-context, and its variable name is
`floatAvoidingBlock` in nsBlockFrame.cpp.
2. We don't need to check zere or positive inline size for the float
available space because `AvailableSpaceShrunk()` should make sure we
leave the loop properly.
See https://phabricator.services.mozilla.com/D145524#4766290 for the
the example when the inline size is exactly zero.
Besides, we also fix contain-inline-size-bfc-floats-001.html with this
patch.
Differential Revision: https://phabricator.services.mozilla.com/D145524
All the callers in nsBlockFrame call BlockReflowInput::ClearFloats(), I
don't feel we need to pass the DONT_CLEAR_PUSHED_FLOATS down to
nsFloatManager. Besides, I'll remove the flag in a later patch.
Differential Revision: https://phabricator.services.mozilla.com/D74537
We don't actually share _that_ much code across them. This makes callers clearer
and code less confusing, IMHO.
This also has the benefit of not autocompleting path from devtools for
shape-outside.
Differential Revision: https://phabricator.services.mozilla.com/D62373
The trickier part is that we represent -moz-image-rect as a Rect() type instead
of image with non-null clip-rect. So we need to add a bit of code to
distinguish "image request types" from other types of images.
But it's not too annoying, and we need to do the same for fancier images like
image-set and such whenever we implement it, so seems nice to get rid of
most explicit usages of nsStyleImage::GetType().
Differential Revision: https://phabricator.services.mozilla.com/D62164
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 changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.
Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:
* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.
Differential Revision: https://phabricator.services.mozilla.com/D56440
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
We always define it to the same thing, and we're inconsistent in whether
we use `CPP_THROW_NEW` or `throw()`, so we might as well just use the
standard C++ thing and get rid of some baggage.
Differential Revision: https://phabricator.services.mozilla.com/D40425
It was introduced in bug 1352096 to reduce complexity with Stylo (apparently).
Right now it doesn't look like it reduces any complexity, and it's a bit
annoying with some of the patches that I'm writing at the moment.
So unless there's any objection I think it should go away.
Differential Revision: https://phabricator.services.mozilla.com/D31708
This enables destructors for tagged unions in cbindgen, implemented in:
* https://github.com/eqrion/cbindgen/pull/333
Which allow us to properly generate a destructor for the cbindgen-generated
StyleBasicShape (which now contains an OwnedSlice).
For now, we still use the glue code to go from Box<BasicShape> to
UniquePtr<BasicShape>. But that will change in the future when we generate even
more stuff and remove all the glue.
I could add support for copy-constructor generation to cbindgen for tagged
enums, but I'm not sure if it'll end up being needed, and copy-constructing
unions in C++ is always very tricky.
Differential Revision: https://phabricator.services.mozilla.com/D29769
Per the discussion in:
https://groups.google.com/d/msg/mozilla.dev.platform/P79pwa9z5m8/iPYPAWPHCAAJ
They should be CamelCase, and that's what most of them already do. This converts
the rest, which are a few.
For the ones that already used `e` or `k` prefixes, I've mostly done:
for file in $(rg Type::e layout | cut -d : -f 1 | sort | uniq); do sed -i 's#Type::e#Type::#g' $file; done
For the ones that used uppercase, I've removed the prefix if it was already in
the type name, and turn them into CamelCase.
Depends on D28680
Differential Revision: https://phabricator.services.mozilla.com/D28681
This patch changes remaining things under `layout/`. However, there are some
places which still need to use `nsIPresShell`. That will be fixed in a
follow up bug.
Differential Revision: https://phabricator.services.mozilla.com/D27477
It doesn't make much sense to return const UniquePtr<Foo>& for something that
can't be null, it's just confusing.
Also make more stuff actually const.
Differential Revision: https://phabricator.services.mozilla.com/D10647
Define OffsetPath & SVGPathData on the servo-side, and StyleMotion &
StyleSVGPath on the gecko-side. We parse the SVG Path string into a
vector of PathCommand. To build the gfx::Path, we will convert it into
gfx::Path later in a different patch.
The basic flow is:
* Parse SVG Path String into SVGPathData (in Rust).
* Use cbindgen to make sure the layout of PathCommand and StylePathCommand,
and then set the Box[PathCommand] into nsTArray<StylePathCommand>.
* Try to convert nsTArray<StylePathCommand> into gfx::Path. (This part
will be implemented in a different patch.)
Finally, we use the gfx::Path to create a motion path transform.
The layout implementation is in the later patch.
Differential Revision: https://phabricator.services.mozilla.com/D2963
Ting-Yu Lin