Closed Bug 1719375 Opened 3 years ago Closed 3 years ago

SVG images are inactive

Categories

(Core :: Layout, defect)

Firefox 91
defect

Tracking

()

RESOLVED FIXED
91 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox89 --- unaffected
firefox90 --- unaffected
firefox91 --- fixed

People

(Reporter: aminomancer, Assigned: emilio)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

  • Check out this SVG file
  • If you open the file itself as a media document, the animation works fine.

Actual results:

  • But if you just click the above link to view the image in the page, or if you use that SVG file inline, or for a CSS property like background-image or list-style-image, the animation doesn't play. It gets stuck at a random frame and only updates when you hover the element bearing the image.
  • If the same animation is converted into <animateTransform> it works fine. For example:
<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16" viewBox="0 0 16 16">
    <path d="M7 3V1s0-1 1-1 1 1 1 1v2s0 1-1 1-1-1-1-1z" />
    <path opacity=".93"
        d="M4.63 4.1l-1-1.73S3.13 1.5 4 1c.87-.5 1.37.37 1.37.37l1 1.73s.5.87-.37 1.37c-.87.57-1.37-.37-1.37-.37z" />
    <path opacity=".86"
        d="M3.1 6.37l-1.73-1S.5 4.87 1 4c.5-.87 1.37-.37 1.37-.37l1.73 1s.87.5.37 1.37c-.5.87-1.37.37-1.37.37z" />
    <path opacity=".79" d="M3 9H1S0 9 0 8s1-1 1-1h2s1 0 1 1-1 1-1 1z" />
    <path opacity=".72"
        d="M4.1 11.37l-1.73 1S1.5 12.87 1 12c-.5-.87.37-1.37.37-1.37l1.73-1s.87-.5 1.37.37c.5.87-.37 1.37-.37 1.37z" />
    <path opacity=".65"
        d="M3.63 13.56l1-1.73s.5-.87 1.37-.37c.87.5.37 1.37.37 1.37l-1 1.73s-.5.87-1.37.37c-.87-.5-.37-1.37-.37-1.37z" />
    <path opacity=".58" d="M7 15v-2s0-1 1-1 1 1 1 1v2s0 1-1 1-1-1-1-1z" />
    <path opacity=".51"
        d="M10.63 14.56l-1-1.73s-.5-.87.37-1.37c.87-.5 1.37.37 1.37.37l1 1.73s.5.87-.37 1.37c-.87.5-1.37-.37-1.37-.37z" />
    <path opacity=".44"
        d="M13.56 12.37l-1.73-1s-.87-.5-.37-1.37c.5-.87 1.37-.37 1.37-.37l1.73 1s.87.5.37 1.37c-.5.87-1.37.37-1.37.37z" />
    <path opacity=".37" d="M15 9h-2s-1 0-1-1 1-1 1-1h2s1 0 1 1-1 1-1 1z" />
    <path opacity=".3"
        d="M14.56 5.37l-1.73 1s-.87.5-1.37-.37c-.5-.87.37-1.37.37-1.37l1.73-1s.87-.5 1.37.37c.5.87-.37 1.37-.37 1.37z" />
    <path opacity=".23"
        d="M9.64 3.1l.98-1.66s.5-.874 1.37-.37c.87.5.37 1.37.37 1.37l-1 1.73s-.5.87-1.37.37c-.87-.5-.37-1.37-.37-1.37z" />
    <animateTransform attributeType="xml" attributeName="transform" type="rotate" dur="0.5s" repeatCount="indefinite"
        calcMode="discrete"
        values="0 0 0; 30 0 0; 60 0 0; 90 0 0; 120 0 0; 150 0 0; 180 0 0; 210 0 0; 240 0 0; 270 0 0; 300 0 0; 330 0 0" />
</svg>

Expected results:

  • For some reason as of July 6, 2021, animations in SVG files that are added with keyframes and style attribute are broken in a weird way, but other forms of animation are not. So hopefully this should go back to the way it was earlier this week.
Status: UNCONFIRMED → NEW
Component: Untriaged → Layout
Ever confirmed: true
Product: Firefox → Core
Regressed by: 1717983
Has Regression Range: --- → yes

Maybe this if (changed) is a culprit? The changed status is for the root document in each process, not for each subdocument.

That seems promising. By the way, I'm not sure if this is related but I noticed another weird bug around the same time which has a similar effect.

progress[value]::-moz-progress-bar {
  background: linear-gradient(#6572b3 20%, #3f46a6 55%, #362d86 85%);
}
progress:indeterminate::-moz-progress-bar {
  width: calc(100% + 2px);
  background-image: linear-gradient(90deg, transparent 0%,
                                           rgba(255,255,255,0.5) 25%,
                                           transparent 50%,
                                           rgba(255,255,255,0.5) 75%,
                                           transparent 100%);
  background-blend-mode: lighten;
  background-size: 200% 100%;
  animation: progressSlideX 1.5s linear infinite;
}
@keyframes progressSlideX {
  0% {
    background-position: 0 0;
  }
  100% {
    background-position: -100% 0;
  }
}

This animation doesn't stop playing when the progress bar stops being indeterminate. If I add value="0.5", the background-image property updates but the animation property seems to be "sticky" somehow. It just keeps playing, even if I delete the keyframes at-rule. I can only get it to stop by deleting the whole animation property. Doesn't seem to matter if the above rules are in a UA sheet, user sheet, or author sheet. At first I thought this was expected behavior because I haven't tried to do something like this before. So I decided to use this instead:

progress:indeterminate::-moz-progress-bar {
  background-image: url("resource://content-accessible/progress-bar-indeterminate.svg");
}

Where the entire animation is contained within an SVG file, and it uses an <animate> element. This way the whole background-image property updates when the value changes, and the animation no longer exists since it's inside the image, not cached somewhere in CSS-land. But after I noticed this other bug with the style attribute I started to think these might be connected.

Set release status flags based on info from the regressing bug 1717983

Assignee: nobody → emilio
Flags: needinfo?(emilio)

These are ticked when painted, so it is fine and it's effectively what
happened before bug 1717983 (because we didn't get into this condition:
https://hg.mozilla.org/mozilla-central/rev/cb704553fc64#l3.73).

Not sure what the best way of testing this is really.

Flags: needinfo?(emilio)
Summary: SVG animations added by the style attribute are broken → SVG images are inactive
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/271f9fc82697
Consider documents used-as-an-image always active. r=tnikkel
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 91 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: