It appears that the GTK theme doesn't always draw the full rectangle

when we ask it to draw a scrollbar button. It's not clear if it expects
the background to already be filled in, or if we are brearking it by
giving it WebKit metrics. Either way, it's messing up our pixeltest
baselines with undefined pixels so we paint seafoam-green under
scrollbar buttons before GTK draws.

Review URL: http://codereview.chromium.org/14477


git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7081 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 11 insertions, 0 deletions

diff --git a/webkit/port/platform/chromium/ScrollbarThemeChromiumLinux.cpp b/webkit/port/platform/chromium/ScrollbarThemeChromiumLinux.cpp
index d7acec1..008b875 100644
--- a/webkit/port/platform/chromium/ScrollbarThemeChromiumLinux.cpp
+++ b/webkit/port/platform/chromium/ScrollbarThemeChromiumLinux.cpp
@@ -126,6 +126,17 @@ void ScrollbarThemeChromium::paintTrackPiece(GraphicsContext* gc, Scrollbar* scr
 void ScrollbarThemeChromium::paintButton(GraphicsContext* gc, Scrollbar* scrollbar,
                                     const IntRect& rect, ScrollbarPart part)
 {
+    // TODO(port): It appears the either we're upsetting GTK by forcing WebKit
+    // sizes on it, or the buttons expect the track to be drawn under them.
+    // Either way, we end up with unpainted pixels which are upsetting the
+    // pixel tests. Thus we paint green under the buttons to, at least, make
+    // the pixel output the same between debug and opt builds.
+    SkPaint paint;
+    paint.setARGB(255, 0, 255, 128);
+    SkRect skrect;
+    skrect.set(rect.x(), rect.y(), rect.x() + rect.width() - 1, rect.y() + rect.height() + 1);
+    gc->platformContext()->canvas()->drawRect(skrect, paint);
+
     const bool horz = scrollbar->orientation() == HorizontalScrollbar;
     gint flags = horz ? 0 : MOZ_GTK_STEPPER_VERTICAL;
     flags |= ForwardButtonEndPart == part ? MOZ_GTK_STEPPER_DOWN : 0;