Closed Bug 573933 Opened 13 years ago Closed 13 years ago

More test changes for bug 564991


(Core :: Layout, defect)

Not set





(Reporter: roc, Assigned: roc)


(Depends on 1 open bug, )



(4 files)

Various parts of bug 564991 change things that tests implicitly depend on. Some of these tests need to be fixed.
Marquees scroll themselves during setup, even if they have a scrollamount of 0. This makes them an "active scrolling" element, so we create a layer for their contents for a brief time initially, and so the text in the marquee is drawn without subpixel AA.
Assignee: nobody → roc
Attachment #453327 - Flags: review?(dbaron)
This is a tricky one. I'm seeing a few pixels in the antialiased rounded borders of GTK themes being rendered inconsistently (consistently). Karl and I theorize that what is happening is that in dynamic situations we're painting a theme background with a clip rect we can't handle directly with GTK, so we execute fallback, and have to draw to temporary surfaces and recover alpha values, and the alpha recovery process is losing some precision when it calculates alpha values.

Karl is working on a plan to fix this by avoiding alpha recovery, but in the meantime I'm turning off moz-appearance on the troublesome tests. Hopefully we can back this out when Karl's solution arrives.
Attachment #453345 - Flags: review?(dbaron)
To be honest, I don't understand this one too well. There was a very small error in a few pixels at the edge of this test on Mac, and it seemed to be because of pixel-sampling. Drawing a few pixels around the button fixed the problem.
Attachment #453548 - Flags: review?(dbaron)
Attached patch more test fixesSplinter Review
FWIW, the following tests fails with rev e318bbaed556 from

(Firefox debug build, Ubuntu 10.04 x86-64)
This is a wallpaper patch that makes them succeed.
Comment on attachment 453327 [details] [diff] [review]
Part 1: Fix marquee tests to not depend on subpixel AA

r=dbaron, although I'm not crazy about having to do this
Attachment #453327 - Flags: review?(dbaron) → review+
Comment on attachment 453345 [details] [diff] [review]
Part 2: Don't render troublesome native themes

This wasn't fixed by that native theme overflow patch I reviewed recently, where you swapped the ordering of some 'overflow' handling with native theme handling?
Comment on attachment 453548 [details] [diff] [review]
Part 3: Fix button-state test to render a margin around the button so we don't get into any weird sampling issues. Also, use a canvas that's just as big as necessary

This seems ok, but I also wonder if it would have been fixed by that other patch.
Attachment #453548 - Flags: review?(dbaron) → review+
Part 2 definitely wasn't fixed by the clipping patch. Part 3, I'm not sure, but the new test is better anyway.
Comment on attachment 453345 [details] [diff] [review]
Part 2: Don't render troublesome native themes

I'm ok with this landing, but please make sure there's a bug on file specifically about backing it out (which should depend on the bug on Karl's work).
Attachment #453345 - Flags: review?(dbaron) → review+
(In reply to comment #9)
> (which should depend on the bug on Karl's work).

Bug 576143.
Whiteboard: [needs landing]

Note that I folded Mats' changes into part 2.
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing]
Depends on: 580499
Bug 576143 will allow us to back out all of attachment 453345 [details] [diff] [review],
and most of attachment 454226 [details] [diff] [review] (assuming I can trust the try server).

The parts of attachment 454226 [details] [diff] [review] that bug 576143 will not fix are:

layout/reftests/bugs/376375-1 has scrollbars on a div with opacity:0.99999.

  I'm guessing the scrollbars are on a layer with an alpha channel.

  The reftest is meant to test an alpha-recovery path, so the alpha channel is
  probably intentional, so the only ways I can imagine modifying the test are
  to use different widgets or cover the bad bits, as done here.

In layout/reftests/bugs/331809-1.html,

  the native widget is actually bleeding out of the iframe.  Covering the
  portion of the widget in the iframe as done here causes the
  native widget not to get painted, obscuring the problem.

  I filed 580499 on this.
URL: 576143
Depends on: 576143
You need to log in before you can comment on or make changes to this bug.