Filed by: dholbert [at] mozilla.com
Parsed log: https://treeherder.mozilla.org/logviewer?job_id=426306026&repo=try
Full log: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Ny-0CHoHQXWLLddOgMJHBQ/runs/0/artifacts/public/logs/live_backing.log
Reftest URL: 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/Ny-0CHoHQXWLLddOgMJHBQ/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

I ran into this on a try run, which had zero changes to Gecko itself and zero changes to this particular test.  Treeherder doesn't have any suggested matches, so I'm assuming this is a latent intermittent failure that I just got lucky enough to be the first one to notice.

In the reftest failure analyzer, the screenshot of the testcase shows a 400px tall blue area, while the screenshot of the reference case shows a 100px tall blue area.

I can briefly see the 400px-tall-blue-area rendering, when I load (or shift+reload) the test directly, e.g. at http://wpt.live/css/css-contain/content-visibility/content-visibility-resize-observer-no-error.html

(Really, the 400px tall area is two 200px-divs.)

It looks like we're doing an initial paint of the page with the contain-intrinsic-size-granted heights on these divs, which we perhaps should not be doing...? That's what's creating an opportunity for the reftest snapshot to capture this initial unexpectedly-tall rendering.