gecko-dev/dom/smil/crashtests/crashtests.list
Brian Birtles c0aa9c7ed3 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 16:22:04 +09:00

60 lines
1.1 KiB
Plaintext

load 483584-1.svg
load 483584-2.svg
load 523188-1.svg
load 525099-1.svg
load 526536-1.svg
load 526875-1.svg
load 526875-2.svg
load 529387-1.xhtml
load 531550-1.svg
load 537157-1.svg
load 541297-1.svg
load 547333-1.svg
load 548899-1.svg
load 551620-1.svg
load 554141-1.svg
load 554202-1.svg
load 554202-2.svg
load 555026-1.svg
load 556841-1.svg
load 572938-1.svg
load 572938-2.svg
load 572938-3.svg
load 572938-4.svg
load 588287-1.svg
load 588287-2.svg
load 590425-1.html
load 592477-1.xhtml
load 594653-1.svg
load 596796-1.svg
load 605345-1.svg
load 606101-1.svg
load 608295-1.html
load 608549-1.svg
load 611927-1.svg
load 615002-1.svg
load 615872-1.svg
load 641388-1.html
load 641388-2.html
load 650732-1.svg
load 665334-1.svg
load 669225-1.svg
load 669225-2.svg
load 670313-1.svg
load 678822-1.svg
load 678847-1.svg
load 678938-1.svg
load 690994-1.svg
load 691337-1.svg
load 691337-2.svg
load 697640-1.svg
load 699325-1.svg
load 709907-1.svg
load 720103-1.svg
load 849593-1.xhtml
load 1010681-1.svg
load 1322849-1.svg
load 1375596-1.svg
load 1402547-1.html
load 1411963-1.html