This implements script registration and some basic validity checks so
that we start keeping track of custom properties in the CascadeData and
in script.
Differential Revision: https://phabricator.services.mozilla.com/D182110
This patch sends the information of border-radius to the compositor as
well, so we can use it if offset-path uses coord-box only.
Note:
We repaint the frame if border-radius property gets changed, and rebuild
the display item. In this case, we resend the transaction of compositor
animation as well. Therefore, we don't have to block the compositor animations
if they depends on border-radius (i.e. use coord-box only).
We may need a better way to check what should we pass to the compositor,
for motion path, in Bug 1838977.
Differential Revision: https://phabricator.services.mozilla.com/D179631
I'd like to reuse the data in RayReferenceData for all basic shapes,
so unpack RayReferenceData and drop this struct.
Also, use `nsPoint` for the current position and use `nsRect` for coord-box
because we use these types (i.e. app units) in ShapeUtils.
Besides, remove the usage of Maybe from nsStyleTransformMatrix.h and
just accept the pointer of ResolvedMotionPathData to avoid including
the entire header.
No behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D181008
Due to the prioritization rules for custom highlights, it is not feasible to rely on cascading.
Instead, highlights need to be stacked by their priority (and order of insertion).
Text and background color of the highest-prioritized highlight which defines that property should be used.
Since highlights are implemented as special `Selection`s, the algorithm that determines the prevailing selection for a text frame needed to be adapted to instead return a list of selections.
Differential Revision: https://phabricator.services.mozilla.com/D181143
Instead, lazily schedule evaluation of them before styling, much like we
were doing for SVG.
A subtle tweak is that we only remain scheduled while in the document.
This allows us to use the "in document" bit plus the "mapped attributes
dirty" bit to know our scheduled status. It also prevents doing silly
work for disconnected elements, and having to do hashmap lookups on
adoption and node destruction.
Differential Revision: https://phabricator.services.mozilla.com/D181549
Instead, lazily schedule evaluation of them before styling, much like we
were doing for SVG.
A subtle tweak is that we only remain scheduled while in the document.
This allows us to use the "in document" bit plus the "mapped attributes
dirty" bit to know our scheduled status. It also prevents doing silly
work for disconnected elements, and having to do hashmap lookups on
adoption and node destruction.
Differential Revision: https://phabricator.services.mozilla.com/D181549
While we're at it:
* Hide :-moz-is-html from content. This is barely documented (a google
search for that yields two pages mostly of our UA sheet) and unlikely
to cause any compat impact (plus it's a one-liner to expose it if we
needed to).
* Make that only depend on the document state. It doesn't have any
practical implications since we only use it on html.css which already
has a default namespace.
* Add some documentation on why are these pseudo-classes (rather than
e.g., media queries).
Differential Revision: https://phabricator.services.mozilla.com/D181406
This method returns a flat list of all the rules in a given stylesheet.
This will be helpful for DevTools so we don't have to recursively walk through
all the children rules (which is slow on the JS DevTools server).
Differential Revision: https://phabricator.services.mozilla.com/D181505
This doesn't change behavior on its own. It could be split up a bit more
if needed though over all it shouldn't be hard to follow.
Unify nsHTMLStyleSheet and nsHTMLCSSStyleSheet into AttributeStyles
because the fact that we have two right now is pretty silly. They are
also not stylesheets (they used to be pre-stylo).
Differential Revision: https://phabricator.services.mozilla.com/D181414
We are using NonNegative now for offset-path, so just like clip-path, we
have to make sure we don't get the negative radius for circle and ellipse,
and don't get the negative border-radius for inset. Therefore, we have to
convert the computed value into animated value when doing interpolation,
and then clamp the value to make sure it is always >= 0 when converting
it back to computed value, just like what we do for clip-path in Bug 1512883.
Also drop the normalization of SVGPathData in AnimationInfo when
preparing offset-path for compositor animations. It's useless because we
"always" do normalization in SVGPathData::animate().
Differential Revision: https://phabricator.services.mozilla.com/D180284
We rewrite the data structure of OffsetPath to support all basic shapes.
However, We don't build the gfx::Path for basic shapes other than path()
for now because the current caching mechanism (on the main thread) doesn't
work for basic shapes. It's layout dependent.
Note:
1. Update offset-path-interpolation-006.html to make sure the start value
and the end value have `at <position>`. `offset-path` doesn't set center
as default for `at <position>`, so if any of the values omits the
`at <position>`, we expect they are not interpolated in Gecko.
This is different from Blink, they still use center as the default value
for interpolation.
2. We still have some failures in offset-path-interpolation-006.html
beacuse we don't clamp the negative radius/radii and the negative
border-radius. We will handle it in the following patches.
3. We will add `<coord-box>` in the later patch.
4. Adding Deserialize and Serialize is necessary for compositor
animations.
Differential Revision: https://phabricator.services.mozilla.com/D179627
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
The spec asks to post a task, see html.spec.whatwg.org/#update-a-style-block
What we were doing is quite crazy. Unifying the scheduling between
<style> and <link rel=stylesheet> on the patch above causes failures on
some mochitests.
Some of them aren't really related to these and are a pre-existing bug,
see bug 1838346.
Differential Revision: https://phabricator.services.mozilla.com/D180895
Boris Chiou
Emilio Cobos Álvarez
Norisz Fay
Kershaw Chang
Tom Schuster
Jan-Niklas Jaeschke
Cristian Tuns
Tiaan Louw
Peter Van der Beken
Emily McDonough
Nicolas Chevobbe
Jonathan Kew
Narcis Beleuzu
Vincent Hilla
Sandor Molnar
Jake Senne
Cristina Horotan