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
The legacy DOM mutation events shouldn't be used even in content and must not be
used in chrome.
This patch makes it crash if legacy mutation event listener is:
* added to a node in a chrome document
* added to a node in a native anonymous subtree
* added to the system event group
* implemented by C++
This causes some crash tests and chrome tests. Therefore, this patch modifies
them to use `MutationObserver` instead or removes them if it's impossible to
rewrite with `MutationObserver`.
Note that if I prevent to dispatch mutation events in some/all of the cases,
that causes performance regression in Speedometer3. Therefore, this patch
does not touch `EventDispatcher`.
Differential Revision: https://phabricator.services.mozilla.com/D181828
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 tweak css/motion/offset-path-coord-box-001.html a little bit to
avoid decimals in the reference file.
For offset-path-coord-box-002.html and offset-path-coord-box-003.html,
I make the border width larger so it'd be clear to see the difference.
Also the original reference files are not correct because they always use
border-box, so I also fix them to use the correct box.
Also, rename offset-path-geometry-box.html as offset-path-coord-box-004.html,
because there is no "geometry-box" in the spec. We are using "coord-box"
now.
Differential Revision: https://phabricator.services.mozilla.com/D181317
Basically, the fuzzy happens because the direction angle in circle(),
ellipse(), and inset() can not be equal to the degree perfectly (due to
the arc drawing implementation and the anti-alias around the element),
so we need some tolerance.
And drop offset-path-shape(-ref).html because it has been removed from
the upstream repo.
Differential Revision: https://phabricator.services.mozilla.com/D179630
The data structure of StyleOffsetPath is complicated, so adding some
useful functions to simplify the code.
No behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D181316
I'd like to reuse it to compute the center position for circle() and
ellipse(), so use a better function name.
No behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D181315
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
Allow smooth scrolls for elements in the browser chrome if
toolkit.scrollbox.smoothScroll is set. This should be used instead of
the value of general.smoothScroll.
Differential Revision: https://phabricator.services.mozilla.com/D181662
Since nesting is only enabled on Nightly at the moment,
a couple tests using nesting were failing on beta simulation.
Taking this as an opportunity to sort tests in ini file
Differential Revision: https://phabricator.services.mozilla.com/D181886
The idea behind this change is for flex items with swapped block-flow direction
to end up in swapped baseline-sharing groups on the flex container's FlexLine.
The outcome of this is that all of the baseline-aligned flex items that are
using a baseline on their left edge will be aligned together (e.g. in the
"first" group), and all of the flex items with a baseline on their right edge
will be aligned together (e.g. in the "last" group), even if they may have
varying block-flow directions (vertical-lr vs. rl) and varying `align-self`
values.
This is rooted in the idea of baseline alignment preferences being "compatible"
as defined here:
https://drafts.csswg.org/css-align-3/#compatible-baseline-alignment-preferences
This makes us start passing a bunch of WPT tests; this patch removes the
corresponding .ini files for those tests that are now passing.
Differential Revision: https://phabricator.services.mozilla.com/D181824
This patch doesn't affect behavior; it's just a refactoring to prepare for the
next patch in this series.
(As of this patch, the BaselineSharingGroup is always the same as the
'align-self' baseline selection, but the next patch will change that.)
Differential Revision: https://phabricator.services.mozilla.com/D181823
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
The idea of this struct is to allow live data of a highlight selection to be passed into layout.
Layout needs highlight properties such as priority or type to resolve combinations of highlights correctly.
Differential Revision: https://phabricator.services.mozilla.com/D181142
No change in behavior here; this is to prepare for offscreen-canvas workers
to be able to access the pref (following patch).
Depends on D181636
Differential Revision: https://phabricator.services.mozilla.com/D181637
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
This is the spec describing flex container baselines.
https://drafts.csswg.org/css-flexbox-1/#flex-baselines
* Separate the cache for last baseline in FlexItem. This is needed beacuse we set
an item's first baseline via `SetAscent()` after reflowing it. Any query to last
baseline via `ResolvedAscent(false)` will wrongly return the first baseline.
* We used to compute flex container baseline from the first item in
ReflowChildren(). Now we consolidate all the logic computing flex container
baseline in PopulateReflowOutput().
Differential Revision: https://phabricator.services.mozilla.com/D181604
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