Servo doesn't use this flag or -webkit- prefixed media queries, so no point in
doing this conditionally.
Differential Revision: https://phabricator.services.mozilla.com/D49508
--HG--
extra : moz-landing-system : lando
There's no effort to disable it any time soon, so I don't think it's useful to
keep the pref around.
Differential Revision: https://phabricator.services.mozilla.com/D49507
--HG--
extra : moz-landing-system : lando
This is effectively superseded by the hover / any-hover media queries, which
actually are standard, and is also causing trouble in the wild.
Not even the browser fronted uses it, so we should be able to just remove it
everywhere at once.
Differential Revision: https://phabricator.services.mozilla.com/D49506
--HG--
extra : moz-landing-system : lando
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.
Adds a feature "moz_xbl" that when disabled causes the XBL code in servo to
be stubbed out.
Depends on D45613
Differential Revision: https://phabricator.services.mozilla.com/D45614
--HG--
extra : moz-landing-system : lando
This fixes another edge-case that I thought of while debugging this, I think
this makes our behavior correct now. The comment and test-case should be
self-descriptive.
Differential Revision: https://phabricator.services.mozilla.com/D48135
--HG--
extra : moz-landing-system : lando
This is a pre-existing bug, and this would be enough to fix the website, but
this is still not 100% correct. More on that in a second.
Differential Revision: https://phabricator.services.mozilla.com/D48134
--HG--
extra : moz-landing-system : lando
Mostly renaming for clarity, as the gradient parsing code is a bit hairy.
This also changes -webkit- gradients, which is, I think, the right thing to do
(otherwise I need to give up on the type system and sprinkle parse_non_negatives
around, which would be unfortunate).
I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1008112 on
Chromium still accepting negative radii for those, so will wait to submit the
patch for review until they reply there with their intentions.
Differential Revision: https://phabricator.services.mozilla.com/D47141
--HG--
extra : moz-landing-system : lando
We always check StyleWillChangeBits_TRANSFORM bit together with a
transform-like property set, so using WillChangeBits::TRANSFORM bit to
represent all transform-like properties is ok.
However, it seems the new test case works well even if we don't have this
patch. I still add it for individual transform properties to make sure
the test coverage is enough anyway.
Differential Revision: https://phabricator.services.mozilla.com/D47509
--HG--
extra : moz-landing-system : lando
Transition to syn 1.0 is ongoing, but these take a long time to build.
Hopefully we already patch coreaudio-sys manually so all the crates dependent on
bindgen are effectively in-tree.
I published v0.51.1-oldsyn to avoid pulling all these dependencies for now.
Differential Revision: https://phabricator.services.mozilla.com/D46966
--HG--
rename : third_party/rust/quote-0.6.11/tests/conditional/integer128.rs => third_party/rust/quote/tests/conditional/integer128.rs
rename : third_party/rust/unicode-xid-0.1.0/scripts/unicode.py => third_party/rust/unicode-xid/scripts/unicode.py
extra : moz-landing-system : lando
Also, update the serialization by the shorter perference because this is
a new feature and using older syntax doesn't make sense.
Besides, use `cssOffset` for web animation IDL attribute name.
Differential Revision: https://phabricator.services.mozilla.com/D45607
--HG--
extra : moz-landing-system : lando
If the sets get too big we cannot allocate anything else, we'll just empty them
and invalidate the whole document.
Differential Revision: https://phabricator.services.mozilla.com/D46828
--HG--
extra : moz-landing-system : lando
* 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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
C'est fini. Now to do the same with the unimplemented ones remains, but it
should be straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D44698
--HG--
extra : moz-landing-system : lando
C'est fini. Now to do the same with the unimplemented ones remains, but it
should be straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D44698
--HG--
extra : moz-landing-system : lando
C'est fini. Now to do the same with the unimplemented ones remains, but it
should be straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D44698
--HG--
extra : moz-landing-system : lando
Emilio Cobos Álvarez
Coroiu Cristina
Cameron McCormack
Anthony Ramine
Simon Sapin
Brendan Dahl
Brian Birtles
Savo
Morgan Reschenberg
Boris Chiou
Mats Palmgren
Benjamin Bouvier
Bogdan Tara
Daniel Holbert
Ting-Yu Lin
Cosmin Sabou
Andreea Pavel