(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
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
We have about 11,500 of these when loading gmail in a Stylo-enabled build, from
SpecifiedUrls; the objects themselves account for about 1.3 MiB of memory, and
the strings within them about 2.9 MiB.
We also have a very small number of them on the Gecko side.
We have about 11,500 of these when loading gmail in a Stylo-enabled build, from
SpecifiedUrls; the objects themselves account for about 1.3 MiB of memory, and the
strings within them about 2.9 MiB.
We also have a very small number of them on the Gecko side.
MozReview-Commit-ID: AduCIaDIzGG
We were getting the proper app units value for transform matrix offset before
Bug 1384656. But after that bug we started using GetCalcValue() method and
it wasn't converting length to app units and this was cousing to miscalculate
translate functions in transform property.
MozReview-Commit-ID: HHlrSg00252
CSSparserImpl::ParserShadowItem stores shadow items in a different order that
does not match the order we use when serializing computed shadow items.
The items order of storing by parser:
<length> <length> <length> <length> <color> <inset>
The items order of serializing:
<color> <length> <length> <length> <length> <inset>
Spec of this serialized order is as follow:
5c46d78107
This patch will shuffle the order of this items in the shadow array when
serializing it.
MozReview-Commit-ID: CIawpYKKIRy
Specifically:
* This patch uses a flag added in a prior patch to let us use the author's
chosen prefix (-webkit or -moz) when serializing. (We treat the -moz version
as a special case, because that makes it more straightforward to unsupport
-moz if/when we can.)
* This patch makes us share the linear-gradient() side-or-corner serialization
codepath when serializing points for -webkit-linear-gradient. (The
alternative is the -moz-linear-gradient codepath, which defaults to
serializing with percent values 0%/100% for sides & corners -- and raw
percentages are invalid in -webkit-linear-gradient(), so we can't share that
codepath.) Notably, we have to skip the "to " token that the
linear-gradient() codepath would normally print out -- that was a late
addition to the spec and so it only exists in the unprefixed modern syntax.
(Instead, -webkit-linear-gradient syntax is implicitly "from" the given
point).
MozReview-Commit-ID: 9Oqo8nG1XDU
This patch doesn't change our behavior -- we'll still produce the same serialization that we would've before.
MOTIVATION: A later patch will make us share this codepath to serialize into
-webkit-linear-gradient() syntax. That syntax uses the same representation for
points as unprefixed modern linear-gradient() (with box-side-or-corner keywords
"top", "right", etc.), but it does *not* use the word "to". So we'd like to
allow "to"-and-its-subsequent-space-character to be optional. Hence, this patch
groups the space together with "to", rather than as a prefix on the next token,
so that we can skip right to printing the point (without a leading space)
when we add support for -webkit-linear-gradient() serialization.
MozReview-Commit-ID: 5fCzx4NmpcC
IsLocalRefURL is originally designed to be used by URLValue only. Since we need
this function in SVGUseElement::LookupHref too, move it to nsContentUtils as a
util function.
MozReview-Commit-ID: FDjWVbTfB0V
This switches over from using nsStringBuffer to nsString for URLValueData's
|mString| member. This avoids various tedious conversions and can provide
potential performance improvements by avoiding length calculations.
MozReview-Commit-ID: 5eRifUZrAso
This patch does the following in addition to a simple move:
* change the type of the pointers from RefPtr to nsCOMPtr
* move it from mozilla::css namespace to mozilla
MozReview-Commit-ID: 72MYq6kWm4s
If nsStyleImageRequest::Resolve() has been called, we cache the DocGroup and
use it for dispatching events for the clean up task. Otherwise, it's safe to
do clean up task on non-main thread.
MozReview-Commit-ID: BXalEkc6dBm
