This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
(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
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
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
--HG--
extra : rebase_source : ee2a20921a17b9091b60a5d9e389a6c6f2fa192b
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
--HG--
extra : rebase_source : dfc96f7905a8b501c0427519bbe5c2cb5010424e
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
--HG--
extra : rebase_source : 9b4f5d20543980baa45c07c950fa0baa59d9cc93
All the instances are converted as follows.
- nsAFlatString --> nsString
- nsAFlatCString --> nsCString
--HG--
extra : rebase_source : b37350642c58a85a08363df2e7c610873faa6e41
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
--HG--
extra : rebase_source : b15218d9cd97d3371e89365fc472d0bcd2672861
This patch doesn't change our behavior -- we won't actually act on the new flag
until the next patch in this series.
MozReview-Commit-ID: EONsLM54eG1
--HG--
extra : rebase_source : cabd4a140d575794a8a656c47692bb9d3a02de88
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
--HG--
extra : rebase_source : 9f8b5c801b2f4352dd2ace3b79c40edb1795b361
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
--HG--
extra : rebase_source : a3e1133f08ffad59a05c6e829f4ff416b897b917
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
--HG--
extra : rebase_source : 400fe0d7cc422f22592c302cfd4e457830b77e3e
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
--HG--
extra : rebase_source : ccc7c43a385f3149b53763030419561fc64efbfa
Emilio Cobos Álvarez
Daniel Holbert
Nicholas Nethercote
Cameron McCormack
Bobby Holley
Josh Matthews
Sebastian Hengst
Nazım Can Altınova
Brad Werth
Mantaroh Yoshinaga
Andrew Osmond
Bevis Tseng
Xidorn Quan
cku
Phil Ringnalda
Hiroyuki Ikezoe
Iris Hsiao
Eric Rahm
JerryShih
Ting-Yu Lin
Manish Goregaokar