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
Adds a new chrome-only MutationObserverInit option called nativeAnonymousChildList
that will cause a mutation to fire when a native anonymous root is bound or unbound
We will pass the preparsed value into AttributeWillChange.
--HG--
extra : commitid : HCiY4DRKWkC
extra : rebase_source : aa17a819a20578322380d388299279e4e41a690b
Having created composite ordering methods for the different kinds of animations
this patch adds a Comparator class so that they can be used to sort an
array of such animations.
This patch uses this Comparator object to sort the results returned by
Element.getAnimations. For this case, the order in which we create animations
and transitions happens to almost perfectly correspond with the composite
ordering defined so that no sorting is necessary.
One exception is that some -moz-* transitions may be created after transitions
that they should sort before when sorting by transition property. In this
case the sorting added in this patch should ensure they are returned in the
correct sequence.
Unfortunately, we can't easily test this since the test files we have are
intended to be cross-browser (where -moz-* properties won't be supported).
Once we implement AnimationTimeline.getAnimations (bug 1150810) we'll have
a better opportunity to test this sorting. For now, the added tests in this
patch just serve as a regression test that the sorting hasn't upset the
already correct order (and an interop test in future once we move them to
web-platform-tests).
--HG--
extra : commitid : KkfoSE69B0F
extra : rebase_source : ee4e47f44281504eb4d35e0f6cc3392ee0cffb94
This patch was generated with the following command:
find . -name "*.h" -o -name "*.cpp" | xargs perl -pi -e 's/return ([a-zA-Z0-9]+)\.ErrorCode\(\);/return \1.StealNSResult();/'
This patch is a fairly minimal rename of the AnimationPlayer interface. It
leaves a bunch of local variables and helper classes still using the word
"player". These will be addressed in subsequent patches that don't require DOM
peer review.
--HG--
rename : dom/animation/AnimationPlayer.cpp => dom/animation/Animation.cpp
rename : dom/animation/AnimationPlayer.h => dom/animation/Animation.h
rename : dom/webidl/AnimationPlayer.webidl => dom/webidl/Animation.webidl
Note that with this patch I'm also changing the priority order of the given
proto and the custom proto; the former takes priority. This makes sense to me:
if the caller is doing |new Foo| they really should get something with
Foo.prototype as its proto. This should not be a problem for custom elements
in general so far, because nodes/elements are mostly not constructible anyway.
For now. When they become that way, I think this is the behavior we'll want.
- Implemented scroll snapping at the end of a middle-mouse-button scroll.
- As this scrolling occurs within chrome Javascript, chrome-only DOM methods
had to be added: window.MozScrollSnap and element.MozScrollSnap
- Bug 1137937 tracks implementation of a replacement for these chome-only DOM methods,
to be replaced with a web accessible API.
--HG--
extra : rebase_source : f511296dbdbfd97e3da391d2a0b67fd3f6edca6b
Xidorn Quan
Nathan Froyd
Brian Grinstead
Jeff Walden
Boris Zbarsky
Andrew McCreight
Masayuki Nakano
William Chen
Robert O'Callahan
Franziskus Kiefer
Olli Pettay
Brian Birtles
Dragana Damjanovic
Cameron McCormack
Anthony Tseng
Jonathan Watt
Tooru Fujisawa
Kearwood (Kip) Gilbert
Andrea Marchesini