Last Comment Bug 768766 - css-valid reftest failures with DLBI
: css-valid reftest failures with DLBI
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Layout (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal (vote)
: mozilla16
Assigned To: Matt Woodrow (:mattwoodrow)
:
Mentors:
Depends on:
Blocks: dlbi 764117
  Show dependency treegraph
 
Reported: 2012-06-26 21:14 PDT by Matt Woodrow (:mattwoodrow)
Modified: 2012-10-03 07:31 PDT (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Convert tests to use MozReftestInvalidate and mark them fuzzy (50.12 KB, patch)
2012-06-27 17:33 PDT, Matt Woodrow (:mattwoodrow)
roc: review+
Details | Diff | Review

Description Matt Woodrow (:mattwoodrow) 2012-06-26 21:14:52 PDT
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
Comment 1 Matt Woodrow (:mattwoodrow) 2012-06-27 17:33:38 PDT
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.
Comment 2 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2012-06-27 17:50:04 PDT
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

?
Comment 3 Matt Woodrow (:mattwoodrow) 2012-06-27 17:59:42 PDT
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.
Comment 4 Matt Woodrow (:mattwoodrow) 2012-06-29 20:18:29 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/d14ec506f28f
Comment 5 Ryan VanderMeulen [:RyanVM] 2012-06-30 12:42:16 PDT
https://hg.mozilla.org/mozilla-central/rev/d14ec506f28f
Comment 6 Ed Morley [:emorley] 2012-09-27 08:57:25 PDT
Backed out (see bug 539356 comment 337):
https://hg.mozilla.org/integration/mozilla-inbound/rev/d3f86e3a3240
Comment 7 Ed Morley [:emorley] 2012-09-28 16:20:49 PDT
https://hg.mozilla.org/mozilla-central/rev/a736bb8d45aa

Note You need to log in before you can comment on or make changes to this bug.