2010-03-02 15:36:33 +00:00
|
|
|
load 483584-1.svg
|
2017-05-16 20:50:58 +00:00
|
|
|
load 483584-2.svg
|
|
|
|
|
load 523188-1.svg
|
2009-10-29 21:08:02 +00:00
|
|
|
load 525099-1.svg
|
2010-01-12 20:00:50 +00:00
|
|
|
load 526536-1.svg
|
2009-11-11 21:41:43 +00:00
|
|
|
load 526875-1.svg
|
|
|
|
|
load 526875-2.svg
|
2009-12-10 17:26:27 +00:00
|
|
|
load 529387-1.xhtml
|
2010-11-23 23:31:17 +00:00
|
|
|
load 531550-1.svg
|
2010-01-06 17:20:50 +00:00
|
|
|
load 537157-1.svg
|
2010-05-25 00:38:25 +00:00
|
|
|
load 541297-1.svg
|
2010-02-25 18:20:44 +00:00
|
|
|
load 547333-1.svg
|
2010-03-02 15:36:31 +00:00
|
|
|
load 548899-1.svg
|
2010-06-09 00:53:08 +00:00
|
|
|
load 551620-1.svg
|
2015-10-31 23:35:27 +00:00
|
|
|
load 554141-1.svg
|
2010-05-28 12:43:17 +00:00
|
|
|
load 554202-1.svg
|
|
|
|
|
load 554202-2.svg
|
2010-04-06 21:39:29 +00:00
|
|
|
load 555026-1.svg
|
2010-04-05 16:59:42 +00:00
|
|
|
load 556841-1.svg
|
2010-11-09 23:21:03 +00:00
|
|
|
load 572938-1.svg
|
|
|
|
|
load 572938-2.svg
|
|
|
|
|
load 572938-3.svg
|
2017-08-02 11:01:08 +00:00
|
|
|
load 572938-4.svg
|
2010-10-13 00:15:32 +00:00
|
|
|
load 588287-1.svg
|
|
|
|
|
load 588287-2.svg
|
2017-01-31 16:37:08 +00:00
|
|
|
load 590425-1.html
|
|
|
|
|
load 592477-1.xhtml
|
2010-10-13 00:17:55 +00:00
|
|
|
load 594653-1.svg
|
2010-10-13 00:20:12 +00:00
|
|
|
load 596796-1.svg
|
2010-11-09 23:22:02 +00:00
|
|
|
load 605345-1.svg
|
2010-11-06 19:13:01 +00:00
|
|
|
load 606101-1.svg
|
2017-02-14 07:26:10 +00:00
|
|
|
load 608295-1.html
|
2015-10-31 23:35:27 +00:00
|
|
|
load 608549-1.svg
|
2010-11-23 23:31:17 +00:00
|
|
|
load 611927-1.svg
|
2010-12-14 00:38:14 +00:00
|
|
|
load 615002-1.svg
|
2010-12-23 05:48:31 +00:00
|
|
|
load 615872-1.svg
|
2013-05-18 18:38:34 +00:00
|
|
|
load 641388-1.html
|
|
|
|
|
load 641388-2.html
|
2011-08-23 23:33:43 +00:00
|
|
|
load 650732-1.svg
|
2011-07-19 00:23:21 +00:00
|
|
|
load 665334-1.svg
|
2011-07-25 17:44:42 +00:00
|
|
|
load 669225-1.svg
|
2011-09-02 13:03:08 +00:00
|
|
|
load 669225-2.svg
|
2011-09-02 13:15:54 +00:00
|
|
|
load 670313-1.svg
|
2011-08-16 00:58:52 +00:00
|
|
|
load 678822-1.svg
|
2011-09-02 13:15:54 +00:00
|
|
|
load 678847-1.svg
|
|
|
|
|
load 678938-1.svg
|
2011-11-14 03:58:30 +00:00
|
|
|
load 690994-1.svg
|
2011-11-15 19:56:32 +00:00
|
|
|
load 691337-1.svg
|
|
|
|
|
load 691337-2.svg
|
2011-11-14 03:58:30 +00:00
|
|
|
load 697640-1.svg
|
2011-11-04 07:21:58 +00:00
|
|
|
load 699325-1.svg
|
2011-12-16 00:27:05 +00:00
|
|
|
load 709907-1.svg
|
2012-05-16 05:30:45 +00:00
|
|
|
load 720103-1.svg
|
Bug 849593 - Skip samples of active SMIL timed elements when the sample time precedes the current interval; r=dholbert
In some circumstances it is possible to sample a timed element in the active
state with a time that precedes is current interval.
One possible sequence of steps leading to this situation is as follows:
1. A timed element (e.g. <set>, <animate>) with a non-zero begin time is the
child of <svg> element A (its "time container") but has yet to be sampled.
2. In order to resolve its initial interval, the timed element registers a
startup milestone with its time container at time 0.
3. However, before the sample is performed where the timed element's initial
current interval is resolved, <svg> element A is detached from the document
tree.
4. The timed element is then attached to a different <svg> element B that has
a current time greater than the begin time of the timed element and less than
that of <svg> element A.
5. Since the timed element is still in its startup state it registers its
startup milestone again, this time with its new time container, i.e. <svg>
element B.
6. A tick occurs or the document has its style flushed such that a sample is
performed.
This includes running the milestone sample which causes the timed element to
resolve its initial current interval. Furthermore the subsequent regular
sample of the timed element causes it to transition into its active state
because the current time of <svg> element B is greater than the begin time of
the timed element.
7. <svg> element A is re-attached to the document.
8. When we go to run the next sample, we iterate through all time containers
associated with the document's animation controller which includes both <svg>
element A, and <svg> element B.
9. <svg> element A renders up its 0 milestone from step (2) since it has yet to
run it. It converts this to parent time, i.e. the time space of the animation
controller, which will be zero or less depending on the current time of <svg>
element A when it was re-attached.
10. Since the milestone from <svg> element A will be the earliest milestone
time, it will be used as the next milestone sample time.
11. The timed element is then sampled using this time, but first it is converted
to a time in the time space of the timed element's time container, which is
now <svg> element B.
As a result of this conversion, the sample time may end up being *before*
the beginning of the timed element's current interval. Since timed elements
never expect the time to go backwards an assertion fails when it detects
that it is active, but is being sampled before its current interval.
For this particular case, ignoring the "early" sample seems to be the most
appropriate action.
More generally, however, we can anticipate other cases similar to this where
milestones are registered that cause the sample time to temporarily go
backwards. A quick audit of nsSMILTimedElement::DoSampleAt suggests that, with
the code changes from this patch, that is probably ok.
As an alternative we could, perhaps, try to drop and re-create all milestones
when time containers are re-attached to the document tree but that would add
more complexity and would not necessarily cover other similar cases of this
situation.
I have verified that the crashtest included in this changeset fails without the
code changes also in this changeset.
MozReview-Commit-ID: KKGYRayNkpo
--HG--
extra : rebase_source : 832d4b357a2a2fe07abf9eab3a6046599aff3ef5
2017-10-24 04:06:04 +00:00
|
|
|
load 849593-1.xhtml
|
2014-05-28 05:15:30 +00:00
|
|
|
load 1010681-1.svg
|
2017-10-17 21:19:54 +00:00
|
|
|
load 1322849-1.svg
|
2017-07-18 07:24:28 +00:00
|
|
|
load 1375596-1.svg
|
2017-10-02 05:04:24 +00:00
|
|
|
load 1402547-1.html
|
Bug 1411963 - Drop assertion about GetBaseValue not returning null in nsSMILCompositor::ComposeAttribute; r=dholbert
This assertion was originally added in bug 1353208 because in that bug we
changed the type of nsSMILCompositor::mCachedBaseValue from
nsAutoPtr<nsSMILValue> to just nsSMILValue. When using nsAutoPtr,
mCachedBaseValue had two null states: one where the pointer is null, and one
where the pointed-to nsSMILValue is null. Coalescing these two states simplifies
the code but there is one case where the difference is significant as described
in the commit message for that changeset (mozilla-central changeset
ad7060dae117):
"There's a subtle difference in behavior with regards to the first sample.
Previously we would compare the (initially) null mCachedBaseValue pointer with
the passed-in nsSMILValue and set mForceCompositing to true. With this patch,
however, we will only set mForceCompositing to true if the passed-in
mCachedBaseValue is not null."
That is, if the base value we get back is a null nsSMILValue, previously we
would set mForceCompositing to true unconditionally, but with the changes in bug
1353208 we would only set that to true if the passed-in nsSMILValue was not
null.
We believed that would never matter since the passed-in nsSMILValue would never
be null if we called GetBaseValue. Quoting from that same commit message:
"... if we do call GetBaseValue the result should not be a null nsSMILValue
(except in some OOM cases where we don't really care if we miss a sample).
This patch adds an assertion to check that GetBaseValue does, in fact, return
a non-null value. (I checked the code and this appears to be the case. Even in
error cases we typically return an empty nsSMILValue of a non-null type. For
example, the early return in nsSMILCSSProperty::GetBaseValue() does this.)"
We added an assertion to validate that assumption but the crashtest included in
this patch demonstrates a case where it does not hold (specifically, when
nsStyleUtil::CSPAllowsInlineStyle returns false, nsCSSProperty::GetBaseValue
will return a null nsSMILValue).
That would seem to suggest that there is at least one case where we might fail
to set mForceIsCompositing to true and hence fail to update style on this first
sample (and presumably thereonwards too since future comparisons of
mCachedBaseValue will compare equal). However, for the case of an initial sample
mForceCompositing should already be set to true since set we update
mForceCompositing in nsSMILCompositor::GetFirstFuncToAffectSandwich() and will
make it true if *anything* in the animation function has changed and at this
point, the initial sample, *everything* will have changed. Hence, I believe
dropping this assertion is acceptable.
I have confirmed that in the crashtest in this patch, during the first sample
mForceCompositing is set to true.
I would create a reftest to test the behavior on the first sample but, at least
for the specific case where inline style is disabled due to CSP, not updating
style *is* the expected behavior so there will be no difference in behavior
regardless of whether or not the mForceCompositing flag is set.
MozReview-Commit-ID: Li0pZEH2PNl
--HG--
extra : rebase_source : a1c12a019b8481600afa4295447dc1e6fb281b22
2017-10-31 07:22:04 +00:00
|
|
|
load 1411963-1.html
|