As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact bugzilla-admin@mozilla.org
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)
:
: Jet Villegas (:jet)
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 | Splinter Review

Description User image 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 User image 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 User image David Baron :dbaron: ⌚️UTC-8 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 User image 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 User image Matt Woodrow (:mattwoodrow) 2012-06-29 20:18:29 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/d14ec506f28f
Comment 5 User image Ryan VanderMeulen [:RyanVM] 2012-06-30 12:42:16 PDT
https://hg.mozilla.org/mozilla-central/rev/d14ec506f28f
Comment 6 User image 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 User image 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.