1559251 - OOP-iframe inside of a CSS filter is not rendered for non-WebRender

Status: RESOLVED WONTFIX

(Core :: Graphics, defect, P5)

Description

[Ryan Hunt [:rhunt]]

See the following page with 'fission.oopif.enabled=true' [1]. The iframe is not rendered at all within the filter. We don't need to apply the filter, but I think we should still be able to see the iframe.

I believe we're falling back to inactive layers for nsDisplayFilter [2], and then failing to paint the nsDisplayRemote here [3].

[1] https://eqrion.github.io/web-tests/fission/filters.html
[2] https://searchfox.org/mozilla-central/rev/1133b6716d9a8131c09754f3f29288484896b8b6/layout/painting/LayerState.h#22
[3] https://searchfox.org/mozilla-central/rev/1133b6716d9a8131c09754f3f29288484896b8b6/layout/generic/nsSubDocumentFrame.cpp#1458

Comment 1

[Ryan Hunt [:rhunt]]

Matt, is this going to be an easy or hard thing to fix?

Comment 2

[Matt Woodrow (:mattwoodrow)]

I think it depends on what behaviour you want exactly.

To do proper filtering of remote iframe, we need filtering to happen in the compositor. That should be the case already for WebRender, and is a huge amount of work to add for non-WebRender.

If you want to skip filtering for OOP iframes in non-WebRender, what should happen to other in-process content within the filter (if any exists?).

If just the presence of an OOP iframe should disable filtering on all ancestors, then that's fairly easy to implement. We have existing code in nsDisplayListBuilder/BuildDisplayListForStackingContext that tracks if any descendant has a mix-blend mode. We'd want something similar for detecting OOP iframes, and then skip the creation of the nsDisplayFilters if it's set.

Comment 3

[Jonathan Watt [:jwatt]]

(In reply to Matt Woodrow (:mattwoodrow) from comment #2)

If just the presence of an OOP iframe should disable filtering on all ancestors

I think this is probably the best compromise. (At the very least we should ignore filters that are directly applied to an oop-iframe.)

Comment 4

[Chris Peterson [:cpeterson]]

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

Comment 5

[Chris Peterson [:cpeterson]]

Not a problem for Fission MVP because it will require WebRender for all users, but we might need this if we need to ship Fission Zero supporting both WebRender and non-WebRender.

Comment 6

[Chris Peterson [:cpeterson]]

WONTFIX because we've decided we won't support Fission without WebRender.

Comment 7

[Chris Peterson [:cpeterson]]

Reopening and tracking for Fission M7 Beta because we might need to support Fission on Windows without WebRender after all.

Comment 8

[Chris Peterson [:cpeterson]]

We plan to allow Fission on macOS and Linux without WR, so we will want to test APZ bugs both with and without WR.

Comment 9

[Chris Peterson [:cpeterson]]

Moving Fission-without-WebRender backs to Fission Future because we are assuming again Fission MVP can depend on WebRender (via SW-WR) being enabled for all platforms.

Comment 10

[Frank Griffith Jr]

Questions:

• Is Bug 1495940 still dependent on this item?
• Is this a blocker for M7, a future Fission Milestone or is it truly a (far) future item? If so, can we update to the appropriate linkages so we can have the appropriate visibility to see where this would be a risk? ty

Comment 11

[Jim Mathies [:jimm]]

We fixed some filter issues with WebRender in the bugs attached to bug 1672470. We do not plan to ship non-webrender with Fission, and we've landed code to make sure that config never happens. WONTFIX'ing.