If an OOP-iframe has rasterized content with webrender, we should scale it if it's under a transform in a different remote browser. This is supported for layers using EffectsInfo [1] [2].

[1] https://searchfox.org/mozilla-central/rev/928742d3ea30e0eb4a8622d260041564d81a8468/layout/generic/nsSubDocumentFrame.cpp#1420
[2] https://searchfox.org/mozilla-central/rev/928742d3ea30e0eb4a8622d260041564d81a8468/layout/painting/nsDisplayList.cpp#2882

Would this fix some of the regressions caused by bug 1558482?

No, but those regressions should be fixed by bug 1560272.

How far do we want to go with this. For CSS animations we try to evaluate the min/max scale that will be applied during an animation and use that to determine the size of surfaces under that transform.

I don't think this is super important, since WebRender will be rasterizing most content on the compositor side, when all cross-process display items have been merged.

For non-WebRender this is much more important, but Ryan has implemented that already.

Tentatively moving all bugs whose summaries mention "Fission" (or other Fission-related keywords) but are not assigned to a Fission Milestone to the "?" triage milestone.

This will generate a lot of bugmail, so you can filter your bugmail for the following UUID and delete them en masse:

0ee3c76a-bc79-4eb2-8d12-05dc0b68e732

This is not a Fission MVP blocker.

This is handled correctly by WR during scene builds.