* Let layout.css.use-counters.enabled be independent from the unimplemented
property counters.
* Always count in the style system (that is, always create
Document::mStyleUseCounters), so that the warning from bug 1582374 works
irrespective of these prefs.
* Add a pref check to the SVGElement code path so that the prefs properly
reflect whether the histograms end up being recorded or not.
* Make the pref checks consistent (check both when reporting telemetry, not
earlier).
Differential Revision: https://phabricator.services.mozilla.com/D46633
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
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
1. Add `generics::motion::OffsetPath`, and use specified `Angle` and
computed `Angle` to define specified `OffsetPath` and computed `OffsetPath`.
2. Add `ray` function into `OffsetPath`.
We also tweak the degree from 150deg to 135deg in wpt (e.g.
offset-path-ray-001.html and others) to avoid floating point precision issues.
For example:
```
// offset-path: ray(150deg ...);
// offset-distance: 20px;
matrix:
{
{0.500000 0.866025 0.000000 0.000000},
{-0.866025 0.500000 0.000000 0.000000},
{0.000000 0.000000 1.000000 0.000000},
{10.000000 17.320509 0.000000 1.000000}
}
// rotate(60deg) translate(20px)
matrix:
{
{0.500000 0.866025 0.000000 0.000000},
{-0.866025 0.500000 0.000000 0.000000},
{0.000000 0.000000 1.000000 0.000000},
{10.000000 17.320507 0.000000 1.000000}
}
```
Their translate parts, 17.320509 vs 17.320507, are almost the same (only
tiny difference), which may cause the reftest failed.
Differential Revision: https://phabricator.services.mozilla.com/D42721
WebIDL codegen: Replace cmake with a single Python script
When [playing around with Cargo’s new timing visualization](https://internals.rust-lang.org/t/exploring-crate-graph-build-times-with-cargo-build-ztimings/10975/21), I was surprised to see the `script` crate’s build script take 76 seconds. I did not expect WebIDL bindings generation to be *that* computationally intensive.
It turns out almost all of this time is overhead. The build script uses CMake to generate bindings for each WebIDL file in parallel, but that causes a lot of work to be repeated 366 times:
* Starting up a Python VM
* Importing (parts of) the Python standard library
* Importing ~16k lines of our Python code
* Recompiling the latter to bytecode, since we used `python -B` to disable writing `.pyc` files
* Deserializing with `cPickle` and recreating in memory the results of parsing all WebIDL files
----
This commit remove the use of CMake and cPickle for the `script` crate. Instead, all WebIDL bindings generation is done sequentially in a single Python process. This takes 2 to 3 seconds.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/24303)
<!-- Reviewable:end -->
When playing around with Cargo’s new timing visualization:
https://internals.rust-lang.org/t/exploring-crate-graph-build-times-with-cargo-build-ztimings/10975/21
… I was surprised to see the `script` crate’s build script take 76 seconds.
I did not expect WebIDL bindings generation to be *that* computationally
intensive.
It turns out almost all of this time is overhead. The build script uses CMake
to generate bindings for each WebIDL file in parallel, but that causes a lot
of work to be repeated 366 times:
* Starting up a Python VM
* Importing (parts of) the Python standard library
* Importing ~16k lines of our Python code
* Recompiling the latter to bytecode, since we used `python -B` to disable
writing `.pyc` file
* Deserializing with `cPickle` and recreating in memory the results
of parsing all WebIDL files
----
This commit remove the use of CMake and cPickle for the `script` crate.
Instead, all WebIDL bindings generation is done sequentially
in a single Python process. This takes 2 to 3 seconds.
Stylo's Gecko wrapper duplicated some logic from the C++ side so
that the Rust compiler would be able to optimize better. Now that
we have xLTO, this kind of manual inlining should not be neccessary
anymore.
Differential Revision: https://phabricator.services.mozilla.com/D43765
For developing properties, we will handle them in an other bug.
Besides, I use an iframe for the test because we create a use counter in
the constructor of Document, which use the prefs to decide what kind of
properties we want to record. So, in the test, we have to reload iframe
to make sure we re-create the document, so does the use counter, to make
sure the prefs work properly.
The two prefs affect the css use counters:
1. layout.css.use-counters.enabled: Allocate use counters, and record
non-custom properties.
2. layout.css.use-counters-unimplemented.enabled: Record all unimplmented
properties into the use counters.
If we disable layout.css.use-counters.enblaed, we don't create use counters
object, so layout.css.use-counters-unimplemented.enabled doesn't work,
either.
Differential Revision: https://phabricator.services.mozilla.com/D43860
This is consistent with the `order` property anyhow, and allows to simplify some
code.
Negatives are still not parsed, but rust uses a similar representation for all
CSS <integer> values and so should C++.
Differential Revision: https://phabricator.services.mozilla.com/D42912
These two bugs (bug 1572738 and bug 1572451) are stylo regressions.
When font-family changes, we try to recompute the font-size with a length /
percentage combinations in case the generic family changes, so the user
preferences are kept.
When calc() is involved, we clamp to non-negative too early, via
NonNegativeLength::scale_by.
I think we should generally dump this "try to track font-size across calc()"
thingie, as as various comments note it is not quite perfect, and it's not clear
how it should work in presence of min()/max().
This patch fixes the issue and simplifies code a bit, I may consider removing
this altogether in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D41776
