We seem to lose cleartype rendering in fission oop iframes on Windows, at least while running reftests in automation.

Example: https://treeherder.mozilla.org/#/jobs?repo=try&revision=dd5f6e44f6f56dfd113866025f751f0b9f28d840

(that is a try push with my work to make the reftest harness work better with fission, the same failure mode happens without my patches but you also get a failure mode where the test or reference iframe isn't drawn at all https://treeherder.mozilla.org/#/jobs?repo=try&revision=a83daddd6656ccde123884299e8c821dbd2dc90a for examples)

Matt informed me of the following: since the iframe doesn't have a bg color and the win7 machines are using basic compositor losing subpixel AA is expected there.

The win10 failure is different, they should have advanced layers and hence component alpha so they should still get subpixel AA. He suggests it might be a FrameLayerBuilder bug preventing it from getting component alpha.

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

Blocks enabling Fission in Nightly (M6).

According to tnikkel, this bug causes reftest fission tests to be orange.

This feels like it belongs in Web Painting because of the background color issue. Please feel free to push back if not.

Does this happen with WR enabled?

Here is a recent try run with fission reftests: https://treeherder.mozilla.org/#/jobs?repo=try&revision=14cae9c8e8e455c30127fb8819cd41bb4fd88d3d

The four WebRender reftest failures do look like it could be caused by subpixel AA not working properly.

Matt, you're the triage owner for the Web Painting component. Do these Windows reftest failures need to block shipping Fission MVP? If so, do they also need to block enabling Fission in Nightly?

The test failures from Miko's try run in comment 7 look pretty minor in the reftest analyzer, but I don't know if these failures might hint at bigger problems with Fission rendering.

https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/JSyR8MD2SSeC6GE2YtkJcw/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/WETghQ2MS12mnFA80HlNIA/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

I don't think we need to block MVP/Nightly on these.

The issue is likely that we have OOP-iframes without a background color, that would normally have an opaque background from the outer doc.

That's not going to be a super common case, so I don't think it needs to block (except maybe Release?).

That said, it seems like WR should be able to render this fine, so we should try investigate at some point.

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

I don't think we need to block MVP/Nightly on these.
...

That's not going to be a super common case, so I don't think it needs to block (except maybe Release?).

In that case, I'll track this bug for Fission M7 Beta as a reminder to re-evalutate these tests before we ride the trains.

Matt, can you please find an owner for this for Fission M7?

I don't think anything has changed since my comment 9 here, unless you're aware of pages where this causes an issue?

Given that we're planning to require WebRender for Fission, is this an issue anymore (based on comment 9)?

Moving bug to MVP based on comment 9

I'm going to close this for now, since the code in question definitely won't be running with WebRender.

If we find specific examples of regressions with WebRender enabled, then we can file a new bug for those.