1480566 - Fission: Someday support filters on cross-origin OOP iframes

Status: RESOLVED WONTFIX

(Core :: Graphics, enhancement, P3)

Description

[Ryan Hunt [:rhunt] (on leave until early May)]

Currently filters will always fallback to inactive layers and render locally in it's content process. When OOP iframes are enabled, this will result in a blank space where an OOP iframe should be.

WebRender, which works in the compositor with a view of all content, supports rendering a subset of filters natively, but not all. For the filters we support, everything should continue working. For the filters it doesn't support, we fallback to blob rendering.

Blob rendering works by taking a recording of content we don't natively support in WebRender. Currently there is no way to express content unknown to the recording, such as an OOP iframe. So with these filters we will also have a blank space where an OOP iframe should be.

We have a couple of options here.

1. Don't support filters on OOP iframes. Or possibly iframes of different origin. This seems to be the behavior Safari has. We could add a telemetry probe to see how common this behavior is relied on, to know if it's worth the effort. This might also be viable as a V1 for OOP iframes.

2. Add slow support in the compositor/webrender for filters on OOP iframes

  1. For current Gecko, we could support filters in the compositor fairly easily if we were to reuse our software FilterNode implementation and take a readback hit
  2. For WebRender, we could extend our blob images to support referencing unknown content and resolve the iframes in the compositor. This could be a tricky as it would make blob images depend on output from WebRender.

  Both of these options would not be optimal, but they would be on the lower end of implementation difficulty.

3. Add native support in the compositor/webrender for filters on OOP iframes

  1. For our D3D11 compositor, we could use our D2DFilterNode with some DirectX interop.
  2. For our OpenGL compositor, we would need to write shaders or maybe use SkiaGL
  3. For our basic compositor, we could use our SoftwareFilterNode with readback.
  4. For WebRender, we would need to write new shaders for the missing filters.

  Each of these would be much faster than the naive approach, but would require more work. Especially as it requires specific support for each backend.

Comment 1

[Ryan Hunt [:rhunt] (on leave until early May)]

From the use counter in beta 66, we see about 0.007% filtered cross-origin iframes out of all top-level page loads [1].

Because this is used so infrequently, we won't support it for an initial implementation of fission or prioritize it.

[1] https://georgf.github.io/usecounters/index.html#kind=page&group=FILTEREDCROSSORIGINIFRAME&channel=beta&version=66

Comment 2

[Ryan Hunt [:rhunt] (on leave until early May)]

We actually support filters for OOP-iframes with webrender today. Supporting it in our existing codepaths will be very challenging, so we would like to plan on not supporting filters for OOP-iframes without webrender. With that, I'm going to mark this as WONTFIX.

Bug 1559251 will track making sure our fallback behavior for filters without webrender is sane.