As I've said before, as module owner I prefer that MOZ_ASSERT_IF not be
used in the module because I consider it to be unreadable. However, a
few uses have crept in, and this patch removes them.
I consider it to be unreadable because the name looks like a name that
uses smalltalk-ish naming conventions, i.e., with a part of the name
corresponding to each parameter, in order. However, the parameters are
in the order opposite the name.
This was written primarily with the vim commands:
:%s/MOZ_ASSERT_IF(\([^,]*\),/MOZ_ASSERT(!\1 ||/
:wn
followed by manual cleanup for indentation and removal of !!.
MozReview-Commit-ID: G6rLbOn7k8d
This is less expensive than sending nsChangeHint_AllReflowHints, and it should
be sufficient since hiding/showing scrollbars is basically just changing the
available space.
MozReview-Commit-ID: 4KyyLzvplAN
--HG--
extra : rebase_source : 4ecb585961ae300e9016f93c4ae0b30fed738151
Some changes to animations don't affect the computed style and yet still
require the layer to be updated. Therefore, we also need to call
AddLayerChangesForAnimation in ServoRestyleManager. In this patch, we
factor out this function from GeckoRestyleManager, so we can reuse it.
MozReview-Commit-ID: LL7D1oGS65l
--HG--
extra : rebase_source : cd028a3d8f5dc251ec6615918a0f9569f0af44f5
This also adds assertions to ensure attributes and state don't change during
layout or frame construction.
MozReview-Commit-ID: BANcpxnRsYS
--HG--
extra : rebase_source : 5d1bc424d3ed90fda3047d3c92c09251346b7bec
This avoids conflicts with mozilla::dom::FrameType.
MozReview-Commit-ID: 7aEMbHRaTFk
--HG--
extra : rebase_source : 2d01321f5ce0ec8c0e3f70984674f82678034b3c
This protects all accesses to the frame property table with a bit stored
on the frame. This means we avoid hashtable operations when asking
about frame properties on frames that have no properties.
The changes to RestyleManager, and the new HasSkippingBitCheck API, are
needed because RestyleManager depended on being able to ask for
properties on a deleted frame (knowing that the property in question
could not have been set on any new frames since the deleted frame was
destroyed), in order to use the destruction of the properties that
happens at frame destruction as a mechanism for learning that the frame
was destroyed. The changes there preserve the use of that mechanism,
although it becomes a bit uglier. The ugliness is well-deserved.
MozReview-Commit-ID: BScmDUlWq65
--HG--
extra : transplant_source : %C8%C0%CD%DC%12g%5B%8ER%3A%FF%A7a%F8%91%D4%2C%9BF%2B
This protects all accesses to the frame property table with a bit stored
on the frame. This means we avoid hashtable operations when asking
about frame properties on frames that have no properties.
The changes to RestyleManager, and the new HasSkippingBitCheck API, are
needed because RestyleManager depended on being able to ask for
properties on a deleted frame (knowing that the property in question
could not have been set on any new frames since the deleted frame was
destroyed), in order to use the destruction of the properties that
happens at frame destruction as a mechanism for learning that the frame
was destroyed. The changes there preserve the use of that mechanism,
although it becomes a bit uglier. The ugliness is well-deserved.
MozReview-Commit-ID: BScmDUlWq65
--HG--
extra : transplant_source : %95%A2%9B%A1M%1F%86%A8%E0%FF%7B%E4%83%24%83%16%BE%FA%08T
48d5d4b398c2 (Bug 1187851 patch 3) renamed this change hint, but didn't
fix the code that prints change hints when debugging.
This is particularly confusing since 5fd6dd2bdbfa (Bug 1301500)
reintroduced a different change hint with that name.
Both ServoRestyleManager and RestyleManager need AnimationsWithDestroyedFrame,
so move it to the base class.
MozReview-Commit-ID: BswoDYm0gS1
--HG--
extra : rebase_source : 7c5aad5189ad425b0dcefab12d465d579704030d
This fixes a problem where we fail to update animations on layers when an
EffectSet is destroyed. In this case when we call
RestyleManager::GetAnimationGenerationForFrame in
ElementRestyler::AddLayerChangesForAnimation(), it will return zero but the
animation generation on the layer will be set to some positive non-zero value.
If we compare the two generation numbers using < we will think the layer is
up-to-date. Using != fixes this. We only used < while we had independent
generation numbers of animations and transitions but that was fixed in bug
1229280.
MozReview-Commit-ID: Jsunjc145GR
--HG--
extra : rebase_source : 75a6e324bdefeb12d1a8edc31b745b59a50bda61
The class ViewportFrame doesn't have ns-prefix, so it's better to drop the
ns-prefix in the file names to avoid confusion.
MozReview-Commit-ID: 8Jrmfzb3tVR
--HG--
rename : layout/generic/nsViewportFrame.cpp => layout/generic/ViewportFrame.cpp
rename : layout/generic/nsViewportFrame.h => layout/generic/ViewportFrame.h
extra : rebase_source : d2c6a80275d696a2886983a4bbb46821784c7fe6
This patch introduces a new functions named HasEffectiveAnimationOfProperty.
This function checks that a given CSS property is overridden by !important
rules.
On the other hand, now KeyframeEffetReadOnly::HasAnimationOfProperty() does
just check that the effect has a given CSS property. This is used to create
a stacking context because we should create a stacking context for opacity or
transform animations even if the property is overridden by !important rules.
Note about no-stacking-context-(opacity|transform)-removing-animation-in-delay.html
Before this patch we don't create any stacking context for animations overridden
by !important rules, but after this patch we do create a stacking context for
such animations. As a result, in the test case we did paint a stacking context
in the first rAF callback and then in the second rAF callback we did clear the
painted stacking context. Unfortunately sometimes the second rAF callback was
called prior to clear the stacking context on the compositor because of
compositor delay. To avoid this situation, we have to wait for MozAfterPaint
instead of rAF callback.
MozReview-Commit-ID: AG1Y0IgoB3U
