Also remove specified-value-only keywords, since those are handled
only in Rust code and C++ doesn't need to know about them.
Differential Revision: https://phabricator.services.mozilla.com/D9634
--HG--
extra : moz-landing-system : lando
First, we generate StyleComputedTimingFunction by cbindgen from Rust, and use
it in nsTimingFunction, so we could copy it directly without handling
the different memory layout. However, we have to rewrite the
nsTimingFunction and mozilla::ComputedTimingFunction for this.
Second, the rust-bindgen seems cannot generate the correct generic members
from complex C++ templates, especially for the nested template struct,
(https://github.com/rust-lang-nursery/rust-bindgen/issues/1429)
So we have to hide StyleTimingFunction to avoid the compilation errors.
Depends on D9312
Differential Revision: https://phabricator.services.mozilla.com/D9313
--HG--
extra : moz-landing-system : lando
This change removes directives NS_STYLE_ANIMATION_PLAY_STATE_* and replaces the values with those from a scoped enum called StyleAnimationPlayState.
Differential Revision: https://phabricator.services.mozilla.com/D9382
--HG--
extra : moz-landing-system : lando
Just a minor fix to use cbindgen to avoid the conversion between
basic_shape::FillRule and mozilla::StyleFillRule.
Differential Revision: https://phabricator.services.mozilla.com/D4171
--HG--
extra : moz-landing-system : lando
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
This moves most of the code to be Rust, except potentially some evaluator
functions, and allows to unblock the use case from any-hover / any-pointer and
remove nsMediaFeatures.
Differential Revision: https://phabricator.services.mozilla.com/D2976
We use the same setup WR uses, which is checking-in the files.
But I think it's much better than keeping the two things in sync manually :)
When you add a new value, you need to add it to the rust source, then run the
command, but since it doesn't need to build the style crate (it uses the Rust
AST, doesn't build) there's no problem.
Differential Revision: https://phabricator.services.mozilla.com/D2354
MozReview-Commit-ID: DnXkNAzP54H
We use the same setup WR uses, which is checking-in the files.
But I think it's much better than keeping the two things in sync manually :)
When you add a new value, you need to add it to the rust source, then run the
command, but since it doesn't need to build the style crate (it uses the Rust
AST, doesn't build) there's no problem.
Differential Revision: https://phabricator.services.mozilla.com/D2354
MozReview-Commit-ID: DnXkNAzP54H
I put Balance as the first item in StyleColumnFill because it is the default
value.
MozReview-Commit-ID: A4DVMLL6XBa
--HG--
extra : rebase_source : 8c8d07b724bcd49dd4f4057fcbf0ccd46ed591ff
NS_STYLE_COLUMN_COUNT_UNLIMITED is unused, so I remove it.
MozReview-Commit-ID: HLHLn9ZbkUY
--HG--
extra : rebase_source : 9bf00e1db00051c4454719e205633717fabde050
Most of it is automated by:
%s/eStyleContentType_/StyleContentType::/g
%s/nsStyleContentType/StyleContentType/g
But I removed some parentheses by hand.
Differential Revision: https://phabricator.services.mozilla.com/D1900
MozReview-Commit-ID: 3IcirjIYX5p
nsStyleConsts.h doesn't use anything from gfxRect.h or nsFont.h, so this patch
removes those #includes from it. However, it does need some other headers that
it was pulling in indirectly via those #includes, which I'm now making it
*directly* #include. Specifically, it needs:
- inttypes.h for "uint8_t"
- gfxFontConstants.h for NS_FONT_WEIGHT_BOLD and related constants.
On its own, the above changes cause build errors in nsStyleCoord.h, because
that other header has an #include for nsStyleConsts.h, which it was
inadvertently depending on (very indirectly) to provide some definitions (via
the aforementioned removed #includes). So we need to give nsStyleCoord.h some
new #includes to directly provide what it needs & keep it
compiling. Specifically:
- mozilla/gfx/Types.h for the mozilla::Side type
- nsISupportsImpl.h for the NS_INLINE_DECL_THREADSAFE_REFCOUNTING macro
MozReview-Commit-ID: BDlaIIOQiPE
--HG--
extra : rebase_source : a16f85f030330ff009461c4d48028327cc4ba0cf
It only has one use, has the same effect that "auto", and should have no effect
in <a> elements anyway (plus it's not overridden or used in that file at all
anyway), so we can remove its only use instead.
I can also change that use to "auto" if you want, but bug 760876 doesn't mention
-moz-user-input at all, so I think this is quite useless...
See the intent to unship for research on out of the tree usage:
https://groups.google.com/d/msg/mozilla.dev.platform/E6tfP__wkwg/YVW6nPX9CQAJ
MozReview-Commit-ID: 8EzQlzu9drE
Some Gecko style system files are modified to prevent assertions and
crashing, and to keep test failures on stylo disabled builds to minimum.
MozReview-Commit-ID: GuxAeCTz0xx
--HG--
extra : rebase_source : 2342085d13a50535836be46d75a731641d0fc49e
