For example:

1. parent.html

  <div style="height: 300px; display: none;">
    <iframe src="remote/index.html" width="300" height="300"></iframe>
  </div>

2. remote/index.html

<style>
  @keyframes anim {
    from { color: red; }
    to { color: blue; }
  }
</style>

<div style="width: 100px; height: 100px; animation: anim 2s;"></div>

<script>
  const anim = target.getAnimations()[0];
  console.log(anim);
</script>

Basically, we don't generate animations for better performance. Therefore, with Fission, we shouldn't have the animation object in the OOP iframe which is in the display:none tree.

However, common animations don't waste too much CPU, so I think this is not a high-priority issue. Just a backlog for this.

To be precise it's not for performance, any CSS animations/transitions in display:none subtree should NOT be generated. I suppose it's spec-ed.

(In reply to Hiroyuki Ikezoe (:hiro) from comment #1)

To be precise it's not for performance, any CSS animations/transitions in display:none subtree should NOT be generated. I suppose it's spec-ed.

Thanks for the clarification.

From https://drafts.csswg.org/css-animations/#animations:

Setting the display property to none will terminate any running animation applied to the element and its descendants. If an element has a display of none, updating display to a value other than none will start all animations applied to the element by the animation-name property, as well as all animations applied to descendants with display other than none.

(In reply to Hiroyuki Ikezoe (:hiro) from comment #1)

To be precise it's not for performance, any CSS animations/transitions in display:none subtree should NOT be generated. I suppose it's spec-ed.

Emilio, did you recently add some code to check display:none subtree for OOP iframes? If so, Nika thinks this bug might be easy to fix.

Tracking for Fission MVP. If there is a known webcompat issue with a real site, then we should prioritize this bug sooner for Fission M8.

(In reply to Chris Peterson [:cpeterson] from comment #3)

Emilio, did you recently add some code to check display:none subtree for OOP iframes? If so, Nika thinks this bug might be easy to fix.

I did not. We have code to detect visibility of the frame (that's all the BrowserChild::IsVisible etc). But this check should be different as that would return false for frames scrolled out of view or what not.

However this is related to the work that's going on in bug 1716762, where we likely need to add something like this.

Nika says this bug probably doesn't need to block Fission MVP, so I am moving it from Fission MVP to Future.