This appears to be a regression from bug 764117, hidden by the fact that the tests aren't using MozReftestInvalidate. Adding MozReftestInvalidate to these tests causes them to fail on trunk, and backing out bug 764117 fixes them. Paint timing issues with DLBI cause these to fail more frequently. Will attach a patch marking these tests as fuzzy
Created attachment 637324 [details] [diff] [review] Convert tests to use MozReftestInvalidate and mark them fuzzy I think we should land these test fixes, along with marking them fuzzy so that it doesn't block DLBI. Bas can then decide what to do about them from there. Note that this bug appears to be triggered by painting the borders twice instead of just once. We were just getting lucky previously and modifying the test case before the first paint. Adding MozReftestInvalidate forces two separate paints. This suggests some sort of additive effects, but that doesn't really make sense since we should be painting an opaque background first.
Maybe it's related to a combination of: * nsDisplayBackground::GetOpaqueRegion saying the background is opaque * the optimization in nsCSSRendering::PaintBackgroundWithSC that calls IsOpaqueBorder(), and when it's true, changes background-clip:border to background-clip:padding * the new border drawing code not actually being fully opaque in cases where said IsOpaqueBorder() function thinks borders should be opaque ?
I think that could be it. I was thinking the page would also have a white background behind, but that isn't necessarily in the same layer as the 'opaque' border.