This patch templatizes the type of Animation stored in an AnimationCollection.
This allows us to remove a number AsCSSAnimation() calls in nsAnimationManager.
This patch also removes the AnimationPtrArray typedef. In its place we
introduce OwningCSSAnimationPtrArray and OwningCSSTransitionPtrArray but we
don't use these as widely. There was some comment previously that the typedefs
in animation code make it hard to read, particularly when these typedefs don't
make it clear if the data type is an owning reference or not.
In doing this we need to templatize CommonAnimationManager as well and move the
implementation of its (few) methods to the header file. We may be able to
remove the need for templatizing CommonAnimationManager later in this patch
series depending on how we ultimately decide to handle the lifetime of
AnimationCollection objects.
CommonAnimationManager::GetAnimationCollection is a bit messy but this will be
significantly tidied up in subsequent patches in this series.
MozReview-Commit-ID: 3ywatY53pRR
It's not obvious that it does this (unless you read the comment or the code), and we don't gain much by doing it.
Also we need to split it up for the next patch in this bug.
Without this patch, patch 2 will cause assertions since
nsFrame::DestroyFrom calls nsFrame::HasCSSAnimations (at a time when the
child frame has been destroyed), which calls into the code modified in
patch 2 to call GetStyleFrame.
This restores the quirky behavior for text inputs, which was removed by
patch 2, but only halfway (for width but not max-width), which matches
Chromium and Edge.
This just reorders the if-else chain to change which conditions are
tested first. Prior to patch 1, the order didn't matter, but with patch
1, the order does matter, and the order that we happened to have was the
opposite of the one that matches Chromium and Edge.
This (modulo changes in later patches) matches the behavior of Chromium
and Edge. It increases the set of elements to which this quirky
behavior applies.
Displayport margins change by small amounts on almost every single scroll. We do not want to update image visibility nearly that often.
As the comment, and the original bug (bug 1169881) suggest this is only meant to catch rather large changes in display ports as we already have means to trigger an image visibility update via a scroll position change and via any style or layout flush.
Even though the content of the root scroll frame is the root element, the primary frame of the root element is never the root scroll frame. This is even true if the normal primary frame of the root element is not created (say because it is display: none). Leaving the primary frame of the root element to be null even though there are frames (the root scroll frame, and the canvas frame) that have the root element as their content.
This behaviour is more consistent by not ignoring a root scroll frame when it exists.
Instead do it when we first encounter the root scroll frame.
Doing this goes back to bug 635053, where we did it because fixed position items weren't getting included. However in bug 974643 we learned that this was wrong. Displayports aren't relevant to fixed pos content, displayports are only relevant to scrolled content. And we set the dirty rects of fixed pos content specially. The only other thing that should be affected is scrollbars, and we already carefully set their dirty rects too.
