After explicitly define default value for RestyleResult, we have a value
starting from 0 now. So, we can drop the explicity numbering.
MozReview-Commit-ID: 1UlpkUT6mAL
--HG--
extra : rebase_source : 441da4a5def8b9c8340cc3048d8dba5ddaae3b87
Remove NS_STYLE_HINT_NONE definition in nsChangeHint.
Fix related debug log in RestyleManager.
MozReview-Commit-ID: 4pA8u8MQDnv
--HG--
extra : rebase_source : 66bbfa54eb35f1de2318787a610b6e401262b28a
To create a stacking context for animations on transform:none segment,
we need to set NS_FRAME_MAY_BE_TRANSFORMED. The fix is comming in part 2.
Note that in case of animations which has properties preventing running on
the compositor, e.g., width or height, corresponding layer is not created
at all, but even in such cases, we normally set valid change hint for such
animations in each tick, i.e. restyles in each tick. For example:
div.animate([{ opacity: 1, width: '100px' }, { opacity: 0, width: '200px' }], 1000);
This animation causes restyles in every ticks without this patch, this patch
does not affect such animations at all. The only animations which will be
affected by this patch are animations which has opacity/transform but
did not have those properies. e.g, setting transform by setKeyframes or
changing target element from other target which prevents running on the
compositor, etc.
MozReview-Commit-ID: 78fYqyX8uDX
--HG--
extra : rebase_source : c4a6ef244f26f3d808fd2c6a5f80c1a15478ae31
Use ReconstructFrame to replace NS_STYLE_HINT_FRAMECHANGE in many places, such
as HTML*Element::GetAttributeChangeHint and HTMLFrameSetElement::SetAttr.
MozReview-Commit-ID: EHbc4RMeuu0
--HG--
extra : rebase_source : afffc0d2ee2861a58dee82f0af06a67f4b8e3a78
Use ReconstructFrame to replace NS_STYLE_HINT_FRAMECHANGE in many places, such
as HTML*Element::GetAttributeChangeHint and HTMLFrameSetElement::SetAttr.
MozReview-Commit-ID: EHbc4RMeuu0
--HG--
extra : rebase_source : f5163608c88362595ef5af5fcd36fa64c9c79ce7
This is useful for writing tests that test particular optimizations,
such as that a particular operation doesn't cause restyles. It sits
next to similar counters for frames constructed and frames reflowed.
I also snuck in a preference for the less-expensive mPresContext over
the more expensive mFrame->PresContext() (which dereferences multiple
pointers).
(Originally written for work I planned to be part of bug 1189598.)
MozReview-Commit-ID: 8PN7nwLJG9r
Theoretically we should do the same for nsTreeBodyFrame, but that frame type is
harder to detect and I'm not sure it's worth adding code to support updating
background-position on XUL trees.
MozReview-Commit-ID: 8HPT53MX6bO
--HG--
extra : rebase_source : 1e84e83616832debe8f6da394630a5a2e014e7df
Theoretically we should do the same for nsTreeBodyFrame, but that frame type is
harder to detect and I'm not sure it's worth adding code to support updating
background-position on XUL trees.
MozReview-Commit-ID: 8HPT53MX6bO
--HG--
extra : rebase_source : 1e84e83616832debe8f6da394630a5a2e014e7df
Theoretically we should do the same for nsTreeBodyFrame, but that frame type is
harder to detect and I'm not sure it's worth adding code to support updating
background-position on XUL trees.
MozReview-Commit-ID: 8HPT53MX6bO
--HG--
extra : rebase_source : 1e84e83616832debe8f6da394630a5a2e014e7df
We also want to cancel transitions with destroyed frames, so the simplest way
is to extend the ability of AnimationsWithDestroyFrame to cancel transitions as
well.
--HG--
extra : rebase_source : 87d09b6204240b51d425269cbdc07103df5d24ef
While processing restyles and starting transitions, we may trigger
a call to EffectCompositor::UpdateCascadeResults which may, in turn, call
EffectCompositor::RequestRestyle with RestyleType::Layer, which ultimately
results in a call to RestyleManager::IncrementAnimationGeneration().
Typically, nsTransitionManager::StyleContextChanged compares the animation
generation on its collection with that of the restyle manager and uses this
to ignore the restyle that it generates. However, given the sequence of events
above, that check may no longer help since the restyle manager's animation
generation will be out of step. As a result,
nsTransitionManager::StyleContextChanged will fail to ignore a subsequent
and redundant restyle. With certain combinations of content, this can mean that
restyles are posted in such a manner than an infinite cycle of restyles ensues.
This patch causes RestyleManager to ignore calls to IncrementAnimationGeneration
when it is already processing restyles such that the animation generation is
only ever updated once per restyle. This makes the check for a matching
animation generation in nsTransitionManager::StyleContextChanged work as
expected, preventing us from generating needless transitions which can produce
this endless loop.
MozReview-Commit-ID: 9HYDrknKPAI
--HG--
extra : rebase_source : f7d9f251d20805fcb4d0d9be04d4343336e69836
This was added in bug 780692 to work around assertions that arose due to the
inconsistent state introduced by mini-flushes. However, that workaround
no longer seems necessary. In particular, the crashtest for bug 813372 no
longer reports failed assertions when we remove this method and nor do any
other tests.
I'm not sure exactly what changed about how we do mini-flushes but I suspect
it was bug 960465 or one of the related follow-ups.
Ting-Yu Lin
Jeremy Chen
Emilio Cobos Álvarez
Carsten "Tomcat" Book
Hiroyuki Ikezoe
Masayuki Nakano
Brad Werth
Phil Ringnalda
Astley Chen
Tooru Fujisawa
Jonathan Watt
Sebastian Hengst
L. David Baron
Markus Stange
Cameron McCormack
Botond Ballo
Xidorn Quan
Boris Chiou
Jonathan Kew
Brian Birtles