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.
forms.css sets overflow: -moz-hidden-unscrollable on all select elements.
ApplyOverflowClipping in nsFrame.cpp applies overflow clips that are not managed by scroll frames.
nsCSSFrameConstructor::ConstructSelectFrame creates an nsListControlFrame for listbox select elements.
nsListControlFrame is an nsHTMLScrollFrame.
As a result, the clip as applied twice - once by the nsHTMLScrollFrame, and then again by ApplyOverflowClipping.
Adding an exception for nsListControlFrame to ShouldApplyOverflowClipping gets rid of the double clip.
But we still need to apply the clip when calculating the frame's visual overflow rect, so we add the
list box frame type to the list of special-cased frames in UnionBorderBoxes.
--HG--
extra : rebase_source : d334647f84e5ebda2e7121c772e3b1ecec0d23a4
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.
For frame statistics to work properly, we have to notify an ImageContainer
when it has been composited. This requires a few changes, which have
been lumped together in this patch:
-- Create PImageContainer and ImageContainerParent/ImageContainerChild.
-- Add mFrameID and mProducerID everywhere we're passing around images.
-- Route composition notifications from the compositor back to
ImageContainerChild.
--HG--
extra : commitid : 7atVkOgdEhG
extra : rebase_source : caaba6a708ed267368df44609fb047abde9c3ca1