(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
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
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
--HG--
extra : rebase_source : bdbbd47de57e0bc610e37913752ab8413f62588a
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
--HG--
extra : rebase_source : 254404e318e94b4c93ec8d4081ff0f0fda8aa7d1
Skips flushing current document if the target of getComputedDOMStyle cannot be
affected by any pending restyles.
MozReview-Commit-ID: C87HDIDvOth
--HG--
extra : rebase_source : 064880493f9aac2599689cdd0749200bb579c60b
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
--HG--
extra : rebase_source : 6185aec4c3c1b0647015d00d31e0120c9448867e
In the spec [1], computed value for column-gap is defined as
'as specified, with <length>s made absolute'.
[1] https://drafts.csswg.org/css-multicol-1/#column-gap
MozReview-Commit-ID: IO22V33z8pz
--HG--
extra : rebase_source : 63167965a0e89fd298df3a22a7c5e41ed34dd1e9
Otherwise we risk losing track of the frame if we hit the cache.
MozReview-Commit-ID: ByHGhcBwIfX
--HG--
extra : rebase_source : 4534efa9ef02f4d7f59a33b55c50d9d372ad08a8
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
--HG--
extra : rebase_source : e2a6bd73f4b2b71115abe68b5cce95be57cbd9b2
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
--HG--
extra : rebase_source : 0a920df8809961f784026a14a624d8eafb4cc79f
This patch just moves the calculation of the pseudo type earlier in the method
so we can re-use it in the next patch in this series to get the style context
from the Servo backend for the case where we don't need to resolve style.
This patch also renames the local variable from 'type' to 'pseudoType' since
that seems less ambiguous.
MozReview-Commit-ID: 6pi2F1vZYHJ
--HG--
extra : rebase_source : 1b9c610edbe4f07000b6cc2087f45dd04792228b