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
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
This causes the subject principal that was responsible for setting a CSS
property, or the full cssText of an attribute, to be threaded through the call
chain to the point where CSS parsing happens, so that it can be used as the
triggering principal when loading URLs for that property.
Note that this allows for different properties defined in the same style
attribute to have different triggering principals, depending on the caller
which originally set them, as long as the cssText of that attribute is not
modified. Once it is, all properties revert to the principal of the caller
that modified the CSS text.
MozReview-Commit-ID: ISUyxbqAZMX
This is a prerequisite change for passing pseudo element to
Servo_StyleSet_GetBaseComputedValuesForElement which will be done in the next
commit.
MozReview-Commit-ID: HEGF2wjBGEP
This fixes multiple things:
* EffectCompositor was using the light tree instead of the flat tree.
* When we insert an element inside the document, we may not style it right away
(we mark it for lazy frame construction with the NODE_NEEDS_FRAME). Since we
trigger animations and transitions from the traversal, we can't skip flushing
if we call getComputedStyle on any of those.
MozReview-Commit-ID: DpAhmLH3uJ2
According to the spec, negative values are valid for inset(), so we should not
clamp it while computing and serializing negative calc values for inset().
MozReview-Commit-ID: DA21CaPO9w7
nsComputedDOMStyle::BoxValuesToString() is a helper function for computing and
serializing box values. In the current implementation, BoxValuesToString
implicitly clamp negative calc values, which is pretty non-trivial.
In this patch, we expose an extra aClampNegativeCalc parameter for BoxValuesToString,
so the callers can explicitly set the clamping mode as needed.
MozReview-Commit-ID: 1UjLSqtqVzn
According to the spec, negative values are valid for polygon(), so we should not
clamp it while computing and serializing negative calc values for polygon().
MozReview-Commit-ID: 5uhLjoYmJEh
nsComputedDOMStyle::SetCssTextToCoord() is a helper function for computing and
serializing a nsStyleCoord. In the current implementation, SetCssTextToCoord
implicitly clamp negative calc values, which is pretty non-trivial.
In this patch, we expose an extra aClampNegativeCalc parameter for SetCssTextToCoord,
so the callers can explicitly set the clamping mode as needed.
MozReview-Commit-ID: IOIhssjUldC
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
After StyleBasicShape is set to StyleShapeSource, it's life cycle never go
beyond StyleShapeSource, so I make StyleBasicShape hold by a UniquePtr in
StyleShapeSource.
Also, replace all raw pointers to StyleBasicShape by UniquePtr in all APIs.
MozReview-Commit-ID: 1MfIFjP8TsQ
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
This property accepts a color. It's inherited and defaults to transparent.
Its value is respected on macOS when rendering text into transparent pixels.
This property should be used for text that is placed on top of "vibrant"
-moz-appearances, in order to achieve high quality text rendering for such text.
In most cases, the property should be set to a named system color; an upcoming
patch in this patch series will add one such color for each vibrant
-moz-appearance value.
However, in some cases it can also be useful to use a custom color: If text
is rendered into an intermediate surface, for example because a mask is applied
to it, and the background color behind that intermediate surface is known, then
this property can be set to that background color in order to achieve subpixel
AA for the text inside the mask effect. In that case, the font smoothing
background color is respected because text is rendered into transparent pixels
*inside the intermediate surface*. At the moment, the only example of that use
case is the text of the active tab in the state where the text is overflowing.
MozReview-Commit-ID: D98qQnxoFaq
Prefixed linear gradients use direction keyword to indicate starting point of the
gradient but modern syntax uses this keyword to indicate ending point of the gradient.
Top-to-bottom direction is the default value for gradients. Therefore `top` is default
value of prefixed linear gradients and `to bottom` is default one for unprefixed one.
For brevity, we omit the direction keyword from our serialization when it matches the
default direction, but we were incorrectly trying to remove `bottom` keyword from
prefixed computed values.
MozReview-Commit-ID: 8UCsFE44LRX
