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
Adds another restyle generation which represents the dirty state of raw
style changes, so that getComputedStyle() wont be confused by optimizations
made by style engines.
MozReview-Commit-ID: 7RYeNCzFygO
Before this refactoring, getComputedStyle could have side effects, and left the
style data in the element, so we could never arrive there without data.
There are a few crashtests that caught this, but this was already broken if you
called animate() on an element deep in a display: none subtree.
MozReview-Commit-ID: 1AvOvhAyOP3
