This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSProperty\b/nsCSSPropertyID/g' -i''
Then:
hg mv layout/style/nsCSSProperty.h layout/style/nsCSSPropertyID.h
... and finally, manually renaming nsCSSProperty in the include guard in
nsCSSProperty.h.
MozReview-Commit-ID: ZV6jyvmLfA
--HG--
rename : layout/style/nsCSSProperty.h => layout/style/nsCSSPropertyID.h
The merge from inbound to central conflicted with the merge from
autoland to central, it appears. Per tree rules, the commit from the
autoland repo wins and the inbound commit gets backed out.
CLOSED TREE
--HG--
extra : amend_source : 927e1cdfa8e55ccbd873d404d905caf6871c8c4f
extra : histedit_source : 07095868c3f767258e1d7d2645193bf4811b13bb%2Ca49ae5a28bf6e67298b6208ee9254c25a2539712
This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSProperty\b/nsCSSPropertyID/g' -i''
Then:
hg mv layout/style/nsCSSProperty.h layout/style/nsCSSPropertyID.h
... and finally, manually renaming nsCSSProperty in the include guard in
nsCSSProperty.h.
MozReview-Commit-ID: ZV6jyvmLfA
--HG--
rename : layout/style/nsCSSProperty.h => layout/style/nsCSSPropertyID.h
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
They are kept around for the sake of the standalone glue, which is used
for e.g. webapprt, which doesn't have direct access to jemalloc, and thus
still needs a wrapper to go through the xpcom function list and get to
jemalloc from there.
The distinction between moz_malloc/moz_free and malloc/free is not
interesting. We are inconsistent in our use of one or the other, and
I wouldn't be surprised if we are mixing them anyways.
This implements the bulk of the FontFace JS constructor, which parses
the descriptors passed in. We need a notion now of whether a FontFace is
"initialized", since the spec requires us to go through the event loop
before parsing the 'src' descriptor. So a couple of places now have to
check whether the FontFace is fully initialized, and we have a method to
inform the FontFaceSet when a FontFace becomes initialized, in case we
added it to the FontFaceSet before it was initialized (easy to do with
|document.fonts.add(new FontFace(...))|.
This adds support for a CSS-connected FontFace to be disconnected from
its rule. This causes it to get its own copy of the descriptors on the
nsCSSFontFaceStyleDecl, and for the pointers between the FontFace and
the nsCSSFontFaceRule to be nulled out.
We start tracking now whether a given FontFace is in the FontFaceSet
(in the sense that it will appear on the DOM FontFaceSet object if we
inspect it with script). All FontFace objects created though, whether
they are currently "in" the FontFaceSet or not, are still tracked by the
FontFaceSet. We use the new mUnavailableFaces array on the FontFaceSet
for that.
We need to track these FontFaces that aren't in the FontFaceSet as
that's where we store their user font entry -- important if we call
load() on a FontFace before adding it to the FontFaceSet.
Here we change FontFaceSet's records array to associate gfxUserFontEntry
pointers with FontFace pointers, rather than with nsCSSFontFaceRule
pointers. This will make it more uniform to handle both CSS-connected
and unconnected FontFace objects when rebuilding the user font entries
under UpdateRules.
These set the descriptors, but don't cause anything to update, just
like setting descriptors on an @font-face rule's style declaration
doesn't do anything yet.
We add an mDescriptors that will be used to store the descriptor values
of an unconnected FontFace object. For CSS-connected FontFace objects,
the descriptors are stored in the nsCSSFontFaceRule::mDecl.mDescriptors.
(Both of these use the same type, though, CSSFontFaceDescriptors.)
Ideally we could have the descriptors always stored on the FontFace,
and for the nsCSSFontFaceStyleDecl go and fetch them from the FontFace,
but it turned out to be impossible to ensure that a FontFace could be
created whenever a nsCSSFontFaceStyleDecl was cloned, since it needs
access to the window object to create the FontFace's promise objects!
We make gfxUserFontEntry::SetLoadState virtual so that we can hook into
changes and update FontFace::mStatus. We can't just reflect the
gfxUserFontEntry's value in FontFace::Status() since the spec has
requirements about when exactly the status is set.