We should parse the inset value as `<view-timeline-inset>`, just same as
the CSS property, if the input is a UTF8String.
Differential Revision: https://phabricator.services.mozilla.com/D301986
Skipping the picker part for now, as we don't support wide color gamut yet. Color mapping doesn't work either because of how the picker element is implemented - it's using white-and-black-to-transparent linear-gradient on top of the solid color.
Differential Revision: https://phabricator.services.mozilla.com/D277905
Skipping the picker part for now, as we don't support wide color gamut yet. Color mapping doesn't work either because of how the picker element is implemented - it's using white-and-black-to-transparent linear-gradient on top of the solid color.
Differential Revision: https://phabricator.services.mozilla.com/D277905
This patch renames AnimatedPropertyID to CSSPropertyId and updates all uses
accordingly. No behavior changes intended.
AnimatedPropertyID has long served as the general property identifier,
covering both non custom and custom properties. The name is currently
misleading.
Potential follow-ups:
- Rename AnimatedPropertyIDSet
Differential Revision: https://phabricator.services.mozilla.com/D271750
nsCSSPropertyID only enumerates non custom properties, but the name suggests
otherwise. (eCSSPropertyExtra_variable only signals a custom property and does
not carry the custom name.) This mismatch has been confusing and also blocks
renaming AnimatedPropertyID to CSSPropertyId.
This patch renames nsCSSPropertyID to NonCustomCSSPropertyId to make the non
custom scope explicit. It also normalizes identifier naming (aPropID ->
aPropId, mID -> mId, etc.) for consistency.
No behavior changes intended.
Potential follow-ups:
- Move the enum to the mozilla namespace.
- Convert the enum to an enum class.
- Rename nsCSSPropertyIDSet.
Differential Revision: https://phabricator.services.mozilla.com/D271443
The alpha and colorspace part of the https://html.spec.whatwg.org/#serialize-a-color-well-control-color is largely skipped in this patch, as we don't support them yet in `<input type=color>`, and thus the value is always in the "HTML compatible" form.
Changing the existing WPT color.tentative.html to color.html to specifically cover implementations without `alpha` and `colorspace` support, because otherwise reading the test result of `color.window.js` is overly confusing. (Ideally the two tests should share the same test data, but for now I'm skipping that as I'm not confident yet to fill the display-p3 fields. That can be done when we actually implement `colorspace` support.)
Introducing Servo_ComputeColorWellControlColor so that the colorspace conversion can happen before losing number precision, following the spec.
Differential Revision: https://phabricator.services.mozilla.com/D258654
The alpha and colorspace part of the https://html.spec.whatwg.org/#serialize-a-color-well-control-color is largely skipped in this patch, as we don't support them yet in `<input type=color>`, and thus the value is always in the "HTML compatible" form.
Changing the existing WPT color.tentative.html to color.html to specifically cover implementations without `alpha` and `colorspace` support, because otherwise reading the test result of `color.window.js` is overly confusing. (Ideally the two tests should share the same test data, but for now I'm skipping that as I'm not confident yet to fill the display-p3 fields. That can be done when we actually implement `colorspace` support.)
Introducing Servo_ComputeColorWellControlColor so that the colorspace conversion can happen before losing number precision, following the spec.
Differential Revision: https://phabricator.services.mozilla.com/D258654
This will allow calling InspectorUtils.ColorTo("red", "lab") and
receive {color: "lab(54.3 80.8 69.9)", components: [54.3, 80.8, 69.9, 1.0], adjusted: false}.
The adjusted value is always "false", because gamut checking and mapping
is not supported at the moment. See:
https://bugzilla.mozilla.org/show_bug.cgi?id=1823363
Depends on D192673
Differential Revision: https://phabricator.services.mozilla.com/D169942
HasBoxFFI and HasArcFFI aren't great, see bug 1831242 as for examples of
why.
HasArcFFI requires a bit more care, but HasBoxFFI doesn't give us much
benefit. Instead use the same type in the FFI boundary.
Differential Revision: https://phabricator.services.mozilla.com/D177252
Now that cbindgen and rust support const generics, it seems more simple.
This centralizes all the relevant font constants etc in rust and avoids
conversions when going from rust to C++ and vice versa.
Differential Revision: https://phabricator.services.mozilla.com/D148847
Now that cbindgen and rust support const generics, it seems more simple.
This centralizes all the relevant font constants etc in rust and avoids
conversions when going from rust to C++ and vice versa.
Differential Revision: https://phabricator.services.mozilla.com/D148847
This is the only meaningful consumer of
ServoCSSParser::GetParsingEnvironment right now, but seems worth fixing
before other folks add more.
Differential Revision: https://phabricator.services.mozilla.com/D148145
When running in a Worker, the canvas2d SetFontInternal method can't call GetFontStyleForServo
because it doesn't have a canvasElement or presShell to pass. But we can use the method
ServoCSSParser::ParseFontShorthandForMatching to parse the canvas 'font' property, if we
extend it so as to also return the size from the font shorthand.
(This is incomplete by itself; Emilio's following patch fixes it up, so the intention is to land them together.)
Depends on D144186
Differential Revision: https://phabricator.services.mozilla.com/D144187
This changes font-family storage to reuse the rust types, removing a
bunch of code while at it. This allows us to, for example, use a single
static font family for -moz-bullet and clone it, rather than creating a
lot of expensive copies.
Differential Revision: https://phabricator.services.mozilla.com/D118011
This lifts a bunch of string conversions higher up the stack, but allows
us to make the servo code use utf-8 unconditionally, and seemed faster
in my benchmarking (see comment 0).
It should also make a bunch of attribute setters faster too (like
setting .cssText), now that we use UTF8String for them (we couldn't
because we couldn't specify different string types for the getter and
setters).
Differential Revision: https://phabricator.services.mozilla.com/D99590
Now that we have UTF8String in the WebIDL, we can remove quite a few of the
conversions. Do that, and lift the remaining string conversions up as needed.
Also deindent Servo_ComputeColor while touching it.
Most of the remaining copies are because either bug 1606994, or because they're
WebIDL attributes that we still need to serialize back as UTF-16 (bug 1606995).
Differential Revision: https://phabricator.services.mozilla.com/D58687
This reduces a lot the boilerplate that's needed in order to add simple binding
functions.
This starts using &Foo and Option<&Foo> instead, and as a result we need to
remove the servo_function_signatures test, which is a bit unfortunate.
I think it's worth though, this causes problems on some platforms (see bug
1534844), and messing up the functions signature is not something that I've ever
seen (other than bug 1308234, which already had all the FooBorrowed mess which
I'm removing).
Also, cbindgen understands references and Option<&Foo>, so it will be the way to
go in the future.
After this patch we can also remove HasSimpleFFI, but I've kept it for now since
I still use it in a few places, and this patch is quite big on its own.
Differential Revision: https://phabricator.services.mozilla.com/D24092
I wrote this patch by first removing UNIFIED_ from layout/style/moz.build, and
then rebuilding, and then addressing build errors one by one.
Nearly all of the build errors were for using the "Document" type without a
proper namespace, and I've addressed this by sprinkling "using namespace"
declarations in the affected .cpp files (and removing a few now-unnecessary
dom:: prefixes on types in those files).
The only other errors were for WorkletGlobalScope.h which needed an #include to
provide the type "DOMHighResTimeStamp", and nsHTMLStyleSheet.h which needed a
forward-declaration for the type "mozilla::dom::Document".
Differential Revision: https://phabricator.services.mozilla.com/D22767
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
Emilio Cobos Álvarez