The connection between an Animation and an AnimationTimeline is optional. That
is, it is possible to have an Animation without an AnimationTimeline. Until now
we have often just assumed the timeline will be set but eventually we need to
support the possibility of the timeline being null. Indeed, later in this patch
series we will set the timeline out-of-band (i.e. not in the constructor) using
SetTimeline which opens up the possibility that timeline will be null for
a period of time.
This patch paves the way for having an optional timeline by storing the global
used for, e.g. creating promises, on the Animation object itself.
--HG--
extra : commitid : Ew9Zp4t36lV
extra : rebase_source : 16c9de9525a3562ff10e41fdf1602384a4e366e3
This is needed not only for supporting other kinds of timelines, but also for
when we come to implement SetTimeline(AnimationTimeline* aTimeline).
--HG--
extra : commitid : B836jCSbgNL
extra : rebase_source : 2592e66b2a9009f85ec0189ebecf5dba3c9bf8e0
Earlier in this patch series we added an assertion to the destructor for
CSSAnimation and CSSTransition to check that the owning element has been
cleared when the animation is destroyed.
This assertion fails, however, for transitions because there are a two
code paths where a transition may be destroyed without being cancelled.
This patch adjusts those two code paths to ensure transitions are always
cancelled before being destroyed.
--HG--
extra : commitid : 6kwqrE1A55J
extra : rebase_source : 86df7ec85ede5d2015e0239efd90b531e16b8aa1
This patch is quite similar to the code added for CSS animations. We'll factor
out some the common code in a subsequent patch in this series.
--HG--
extra : commitid : LYlmnoyUUsn
extra : rebase_source : 8ffc3e4283887e53a3e00d7fa43536c4203a5c92
This patch adds a convenience method for getting the transition property for
a CSS transition (so we can use this when ordering CSS transitions).
We already have ElementPropertyTransition::TransitionProperty() so this might
seem to be redundant, however we add this now because:
* In the proposed CSS Transitions <-> Web Animations integration, the
CSSTransition interface has a transitionProperty member so we'll need this
function for that.
* Once we allow script to modify the transition, we'll need to track the
original transition property for sorting purposes which is what this method
should do.
* We'll possibly drop ElementPropertyTransition::TransitionProperty() in the
future.
--HG--
extra : commitid : 9toNZe3xt0K
extra : rebase_source : d29addc5a82e3b4aedf6cc9191f48393c88b90d1
Similar to the earlier patch in this series that changed the sequence number
handling for animations, this patch re-uses Animation::mSequenceNum to store
the animation generation number when each transition was generated. When the
transition is cancelled it reverts to using the default animation composite
ordering.
--HG--
extra : commitid : 9wCREIUfPRz
extra : rebase_source : 85a20c1f8a4c9507606b479b8787b4aa2ec28821
This patch also extends the tests for Element.getAnimations(). It doesn't
actually exercise the code added (it's not actually called yet since it doesn't
need to be for Element.getAnimations) but simply provides a useful regression
and interop test.
--HG--
extra : commitid : KWpAsc2Aj54
extra : rebase_source : abe26dc3d79a50239c62dd156dc0a0aa29c11d52
This patch re-uses Animation::mSequenceNum to store the index of CSS animations
within their corresponding animation-name property. When the animation is
removed from an animation-name property it reverts to using the default
animation composite order.
This patch also updates Animation::DoCancel to call UpdateTiming instead of
UpdateEffect. This is because UpdateTiming is responsible for updating the
sequence number (when custom composite order is not in effect). When we remove
an animation from animation-name it will be cancelled and at that point we
expect its sequence number to be cleared which will only happen if
UpdateTiming gets called.
--HG--
extra : commitid : 2KrTezItH3q
extra : rebase_source : 50de87465deef85558ca50de5e6286f7b5603051
These will be needed for sorting animations and transitions in a const-correct
fashion.
--HG--
extra : commitid : BhuFfkAvse7
extra : rebase_source : a97039f06b9f257ccb9b6aa206653d6b5d5d43d4
This patch applies the same treatment to CSS transitions that we applied to CSS
animations in the previous patch in this series.
--HG--
extra : commitid : 1XNVVYTh0C2
extra : rebase_source : 4e27eaaab5e2b734636fa29406b42ae799e1f493
In order to sort CSS animation objects correctly, we need to know which
element's animation-name property they appear in, if any. Normally that's
simply the target element of the animation's keyframe effect but it can differ
in the following cases:
1) When script modifies a CSSAnimation's effect to target a different element
(or simply removes the effect altogether). In this case we use the
*owning* element to determine the priority of the animation, not the target
element.
This scenario does not yet occur (bug 1049975).
2) When script creates a CSSAnimation object using the CSSAnimation constructor.
In this case, the owning element should be empty (null) and we should
determine the priority of the animation in the same way as any other
Animation object.
Again, this is not yet supported (or even specced) but will be eventually.
3) When script holds a reference to a CSSAnimation object but then updates the
animation-name property such that the animation object is cancelled. In this
case the owning element should be cleared (null) so we know to not to try and
sort this with regard to any animation-name property.
This is possible using code such as the following:
elem.style.animation = 'a 5s';
var a = elem.getAnimations()[0];
elem.style.animation = 'b 5s';
a.play(); // Bring a back to life
document.timeline.getAnimations();
// ^ At this point we need to know how to sort 'a' and 'b' which depends
// on recognizing that a is no longer part of an animation-name list.
Until we implement bug 1049975, we could support sorting animations without
adding the reference to the owning element by setting a flag on the CSSAnimation
object but (having tried this) it turns out to be cleaner to just introduce this
reference now, particularly since we know we will need it later.
Note that we will also need this information in future to dispatch events to the
correct element in circumstances such as (1) once we separate updating timing
information (including events) from applying animation values.
--HG--
extra : commitid : 8o9bf6l7kj7
extra : rebase_source : 391a4e8769cc96584ebd625d4b1d0e873373fd41
Prior to this patch we cancel animations in AnimationCollection::Destroy but
this is not called automatically when the property holding the collection is
destroyed via its destructor. When an element is unbound from the tree we
destroy its animation properties but don't call AnimationCollection::Destroy.
This means, that in such circumstances:
* We won't create animation mutation records for the removed animations
* Once we start registering animations with a timeline they won't have a
chance to remove themselves from the timeline (meaning
document.timeline.getAnimations()) will keep returning them
* Once we go to implement the animationcancel and transitioncancel events we
won't fire them in this case (assuming we implement the queueing/dispatch of
those events as part of the cancel code)
This patch addresses this by moving the call to cancel each animations to the
property destructor for the animation properties.
We do this first so we can land this change separately to ease bisecting any
regressions it might trigger.
--HG--
extra : commitid : KzukSO91RMH
extra : rebase_source : 54ed2aeb69d8bceca424c70c7f33d4bf92d54546
The original motivation for the Iterator/RemovingIterator split was that
PLDHashTable Checker class would treat them differently. But that didn't end up
happening (see bug 1131308). So this patch merges them. This is a small code
size win now but it will become bigger when I add iterators to nsTHashTable and
nsBaseHashtable.
The only complication is that PLDHashTable::Iter() is now non-const, which is
a problem if you use it in a const method. So I added PLDHashTable::ConstIter()
which is used in just two places. It's a bit of a hack -- effectively a
const_cast -- but I don't think it's too bad.
There is no retained rendering data for non-visible images, so FrameLayerBuilder::IterateRetainedData never calls it's callback, the callback is the only thing that calls nsSVGEffects::InvalidateDirectRenderingObservers. We need to call nsSVGEffects::InvalidateDirectRenderingObservers always.
frame->Preserves3D() is whether the frame's parent has transform-style:
preserve-3d, which means that the frame is part of the same 3-D scene as
its parent. frame->Preserves3DChildren() is whether the frame itself
has transform-style: preserve-3d, which means that the frame is part of
the same 3-D scene as its children.
Neither of these are valid cases for doing off-main-thread (OMT)
animation because all of the layers in a preserve-3d scene are currently
siblings of each other, rather than preserving ancestor/descendant
relationships. This means that it's not valid to animate transform of
the parent on the compositor because the compositor animation won't
update any of its children that have layers. Likewise, it's not valid
to animate transform of the child on the compositor because the code
that sends transform information to the compositor doesn't handle the
accumulation of transforms needed to get the "right" transform for the
child (i.e., with the transforms of its ancestors up to the top of the
3-D scene merged in).
This means that we do OMT animation for slightly fewer cases with the
patch than we did without the patch. This means it's pretty low risk in
terms of correctness, although there's a chance it might regress
performance on one of the (somewhat limited) set of cases where the
optimization was valid. (Bug 779598 covers doing OMT animation for
preserve-3d cases, and depends on the work ongoing in bug 1097464.)
The animate-preserve3d-parent.html reftest doesn't fail without the
patch, since something seems to invalidate in the test; it was testing
the testcase that showed correct behavior when the mouse was moving, so
this isn't incredibly surprising (although that invalidation from mouse
movement is itself worth debugging). The animate-preserve3d-child.html
test does fail without the patch, though.
(With an initial transform of none instead of the 30deg transform, both
tests also show an invalidation bug without the patch.)
Ignoring sheets added by add-ons, all sheets in the eAgentSheet and
eUserSheet levels should come from the nsLayoutStylesheetCache and thus
allow multiple documents to make use of a shared rule processor.
This was added in bug 897763, but the current name no longer makes sense
in the context of the renaming in 2d8810ba0412 (bug 779968, patch 4).
(I think the old name was also missing a negation -- it meant hints that
were never *non*-inherited.)
Destroying large arrays of css::Rules during page teardown can take
multiple milliseconds in incremental CC. To reduce CC pauses, this
patch introduces a new class nsIncrementalClearCOMRuleArray that uses
the deferred finalizer to incrementally destroy these rule arrays.
AllocateByObjectID() is infallible. Therefore the |operator new| of nsFrameList,
nsLineBox and nsRuleNode are too, as is nsRuleNode::CreateRootNode().
The patch also removes a couple of comments duplicated in both .h and .cpp
files.
--HG--
extra : rebase_source : 0b9e195fd547fdd53ddad7bb461ff5f5c2016fce
This is straightforward mapping of PR_LOG levels to their LogLevel
counterparts:
PR_LOG_ERROR -> LogLevel::Error
PR_LOG_WARNING -> LogLevel::Warning
PR_LOG_WARN -> LogLevel::Warning
PR_LOG_INFO -> LogLevel::Info
PR_LOG_DEBUG -> LogLevel::Debug
PR_LOG_NOTICE -> LogLevel::Debug
PR_LOG_VERBOSE -> LogLevel::Verbose
Instances of PRLogModuleLevel were mapped to a fully qualified
mozilla::LogLevel, instances of PR_LOG levels in #defines were mapped to a
fully qualified mozilla::LogLevel::* level, and all other instances were
mapped to us a shorter format of LogLevel::*.
Bustage for usage of the non-fully qualified LogLevel were fixed by adding
|using mozilla::LogLevel;| where appropriate.
|mOps| is always non-null now, and there's no longer any distinction between
and uninitialized and initialized table. Yay.
--HG--
extra : rebase_source : 3d1fb72aee4dd21ff20db0ff3166d4e932ade897
This also rearranges the list of default fonts and changes the preferred font to Latin Modern Math on all platforms.
--HG--
extra : rebase_source : 806b5f8ffcf5305e55f67c60756c438987646fd5
CLOSED TREE
Backed out changeset 12ce98475c6e (bug 1119980)
Backed out changeset bdb8d05f8870 (bug 1119980)
Backed out changeset a68a18840492 (bug 1119980)
This patch simplifies nsStaticCaseInsensitiveNameTable greatly by taking
advantage of the following observations.
- |new| is infallible, so |new nsStaticCaseInsensitiveNameTable()| calls don't
need their return value checked.
- nsStaticCaseInsensitiveNameTable::Init() checks if any of the added entries
differ only in case, so the callers of that function don't need to do the
same check.
- nsStaticCaseInsensitiveNameTable::Init() never returns false because
moz_xmalloc() is infallible. (Its callers never check the return value
anyway.) So it can be merged into the constructor. And
~nsStaticCaseInsensitiveNameTable() need not null-check |mNameArray|.
- PLDHashTable now has an initializing constructor and destructor, so these can
be used in nsStaticCaseInsensitiveNameTable, thus avoiding manual
PLD_HashTable{Init,Finish}() calls.
This patch converts easy cases, i.e. where the PL_DHashTableInit() call occurs
in a constructor and the PL_DHashTableFinish() call occurs in a destructor.
--HG--
extra : rebase_source : d8dc450f80ac23b8455141b471cc9ae823e1e384
They're not needed now that there is (temporarily) PLDHashTable2, which has an
initializing constructor and a destructor.
--HG--
extra : rebase_source : 78d3eeb326935ad7a19e3bdf9b2092eb2a4208a7
Now that calling pause from the idle state resolves the current time, we don't
need to worry about calling play first when creating a CSS Animation.
--HG--
extra : rebase_source : d139f32cc655936e197414641d9769e2619d7ade
extra : histedit_source : 8094a211a264cb2b1dcaf6a760e1d6fb9fea4b2b
We want AccessibleCaret be of the same size regardless of the zoom
level. We simply divide the caret's width, height, margin-left, and the
text selection bar's margin-left by current zoom level.
The margin-left of the caret is adjusted from -23px to -23.5px for better
looking.
Due to Android startup regressions (bug 1163066) and plugin crashes (bug
1165155).
--HG--
extra : rebase_source : 380f79e67dff4c4eaa2614f286a4d0669666b652
Animation::ResumeAt contains an assertion that, when we exit the play-pending
state, checks we either have a resolved start time or a resolved hold time.
That's normally true but if we are aborting a pause on animation that is
finished we can end up with a resolved start time (since we don't clear the
start time when we're aborting a pause) and a resolved hold time (either
because the regular finishing behavior set one, or, because play() applied
auto-rewinding behavior and set it).
In that case we should actually respect the hold time and update the start time
when resuming the animation. However, ResumeAt won't update the start time if it
is already set.
This patch fixes that by clearing the start time in DoPlay in the case where we
are aborting a pause and have a hold time.
--HG--
extra : rebase_source : 83f980d6cbc34375274f30f6527992b4fec7f639
See AccessibleCaret.h for the class description.
Technical difference between AccessibleCaret and Touch/SelectionCarets:
The anonymous dom element containing a caret image will be created by
AccessibleCaret by using the API landed in bug 1020244 instead of being
created by nsCanvasFrame.
This patch seems to be leading to too many complications; it requires us
to predict whether a layer that would be created for an element will use
off-main-thread compositing prior to the creation of that layer, which
has led to complications on both Mac (fixed by the other patches in bug
947753) and Android (bug 1161049).
This patch converts easy cases, i.e. where the PL_DHashTableInit() call occurs
in a constructor and the PL_DHashTableFinish() call occurs in a destructor.
Wilmer Paulino
Masatoshi Kimura
Brian Birtles
Cameron McCormack
Carsten "Tomcat" Book
Nicholas Nethercote
Ryan VanderMeulen
Hiroyuki Ikezoe
Timothy Nikkel
Emanuel Hoogeveen
Jonathan Kew
Matt Woodrow
Lee Salzman
L. David Baron
Muhsin A. Steiman
Boris Zbarsky
Daniel Holbert
Michael Layzell
Andrew McCreight
Xidorn Quan
Karl Dubost
Tim Nguyen
Kathy Brade
Simon Montagu
Kyle Zentner
Chris Peterson
Wes Kocher
J. Ryan Stinnett
Eric Rahm
Mats Palmgren
Birunthan Mohanathas
Phil Ringnalda
Kang-Hao (Kenny) Lu
Ting-Yu Lin
Jonathan Watt
David Major
Botond Ballo
Morris Tseng
Frédéric Wang
Geoff Brown
Ehsan Akhgari
Mike Taylor
Tom Tromey