This makes background-image, mask-image and border-image settable
from Servo.
Since imgRequestProxy resolution in nsStyleImages can now happen later than
at computed value setting time, and that resolution can fail,
nsStyleImage::GetImageData() might now return null. So all of the users of
nsStyleImage now null check its result.
MozReview-Commit-ID: FMRUrC3SfOs
This makes background-image, mask-image and border-image settable
from Servo.
Since imgRequestProxy resolution in nsStyleImages can now happen later than
at computed value setting time, and that resolution can fail,
nsStyleImage::GetImageData() might now return null. So all of the users of
nsStyleImage now null check its result.
MozReview-Commit-ID: FMRUrC3SfOs
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
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.
MozReview-Commit-ID: AG1Y0IgoB3U
1. Rename these functions to agree with Mozilla coding style.
2. Use singular naming instead of plural naming since each of these functions
returns an iterator pointing to a singular line.
3. Rename line() and rline() to BeginLineFrom() and RBeginLineFrom(), which
shall improve the readability.
MozReview-Commit-ID: txZjVnv9Yb
KeyframeEffectReadOnly::HasAnimationOfProperty() calls GetAnimationOfProperty()
which checks mWinsInCascade flag and the mWinsInCascade flag is set to true
only if the effect is in-effect.
That means nsLayoutUtils::HasCurrentAnimationOfProperty() actually represents
that a given frame has at least one animation which is current and *in-effect*
(i.e. active).
MozReview-Commit-ID: 93rMMmzrBMi
This takes the second hunk of https://hg.mozilla.org/mozilla-central/rev/82c3b4b81d82 only, but instead of the "in displayport" list we are adding to the "approximately visible" list. The "in displayport" list doesn't exist after the backouts that need to be done.
This ensures that all visible frames are in the approximately visible list.
By not taking the first chunk of the aforementioned changeset we don't remove frames that aren't painted from the approximately visible list. So the list only grows during a paint. But the next time the we do a full update of approximately visible images it can shrink.
We need this because the video element uses visibility to start/stop decoding (bug 1282710, bug 1299065) and we want frames that are painted to for sure be marked as visible.
After using enum class, a switch-case warning in CombineBreakType is caught.
This is one of such kind safty checks that we would like to gain.
Fix it by adding default case for switch-case in CombineBreakType.
MozReview-Commit-ID: BdS3LPN6qzX
