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

webkit/port/platform/chromium/ScrollbarThemeChromiumLinux.cpp

Index: webkit/port/platform/chromium/ScrollbarThemeChromiumLinux.cpp
diff --git a/webkit/port/platform/chromium/ScrollbarThemeChromiumLinux.cpp b/webkit/port/platform/chromium/ScrollbarThemeChromiumLinux.cpp
index d7acec10f7f5592f82dc096cc92b061abbd8a910..008b875a1992bfe07101e0ccf703da11b8677b3d 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;