Bug 1918762 - Don't paint the scrollbar track twice on macOS. r=mac-reviewers,bradwerth

This was caught by Markus. When you hover over an overlay scrollbar,
you'd hit this the PaintScrollbar() code-path (or rather, you won't bail
out from the if (overlay && !hovered)), but macOS draws the track in
PaintScrollbarTrack().

Android doesn't hit this because android scrollbars can't ever be
hovered (they have pointer-events: none).

Differential Revision: https://phabricator.services.mozilla.com/D222172

widget/ScrollbarDrawing.cpp

@@ -201,6 +201,17 @@ bool ScrollbarDrawing::DoPaintDefaultScrollbar(
     ScrollbarKind aScrollbarKind, nsIFrame* aFrame, const ComputedStyle& aStyle,
     const ElementState& aElementState, const DocumentState& aDocumentState,
     const Colors& aColors, const DPIRatio& aDpiRatio) {
+  // GTK and Windows draw the track here, cocoa and Android draw it in
+  // PaintScrollbarTrack... TODO: unify this somehow.
+  switch (mKind) {
+    case Kind::Cocoa:
+    case Kind::Android:
+      return true;
+    case Kind::Gtk:
+    case Kind::Win11:
+    case Kind::Win10:
+      break;
+  }
   const bool overlay = aFrame->PresContext()->UseOverlayScrollbars();
   if (overlay && !aElementState.HasAtLeastOneOfStates(ElementState::HOVER |
                                                       ElementState::ACTIVE)) {