Closed Bug 1833733 Opened 5 months ago Closed 4 months ago

Overlay scrollbar is really hard to see over the gray background area in Print Preview dialog


(Toolkit :: Printing, defect)




115 Branch
Tracking Status
firefox115 --- fixed


(Reporter: dholbert, Assigned: emilio)


(Blocks 1 open bug)



(4 files)

(Not sure which component to file this under, printing vs. Layout:Scrolling vs. Widget. Starting out in the print dialog.)


  1. Ensure you have overlay scrollbars enabled (steps vary by platform; on Linux and Win10, this is in Firefox preferences "always show scrollbars", which should be un-checked. On macOS / Win11, it's a system setting with a similar name.)
  2. Visit some multi-page document like
  3. Ctrl+P to open Print Preview
  4. Mousewheel-scroll the print preview area.

The scrollbar is nearly impossible to see as it moves. It's dark-gray-on-a-dark-gray background.

More-easily-visible scrollbar.

Note: if the Firefox window does not have focus then the scrollbar shows up as a much brighter white color, which is much easier to see. But when the window has focus (as it normally would when you're using Firefox), this bug reproduces.

emilio, I recall you having looked into similar issues with hard-to-see scrollbars in the past -- I'm hoping maybe you could take a look here. Thanks!

Flags: needinfo?(emilio)
Assignee: nobody → emilio
Flags: needinfo?(emilio)

Thanks for taking this! I just tested the patch, and I see the scrollbar is lighter now, and I have good & bad news.

Good news: the scrollbar is now visible at the top of the print preview area.
Bad news: the scrollbar is now invisible at the bottom of the print preview area.

(Because the print-preview background is a gradient, with a lighter color at the bottom, which happens to match the lighter scrollbar color)

So I think we need some additional changes here to fully address this.

The patch is still correct / strictly an improvement tho. IMO we should consider make the background a bit darker, much like the image document background perhaps? But that can probably happen in a separate bug.

Yeah, that's true. Plus, the new behavior is arguably an improvement UX-wise (on top of being strictly more-correct under the covers), since the scrollbar is becoming visible at its initial position.

So: I'm happy to proceed with the approach here & take further improvements in a followup.

Pushed by
Properly detect page sequence background from FindEffectiveBackgroundColor. r=dholbert

So there are two types of test-failure that we hit here:
(1) In one of the reftest failures, it looks like we're mistakenly using the reftest-paged reftest's body element to determine the background color for the scrollbar -- specifically this one:

<body style="margin:0; height:10000px; background:blue;">

...which failed here:
...with the testcase drawing with a blue scrollbar track (vs. the reference case drawing with a transparent scrollbar track, since it has no background specified on the body).

(2) We've got a handful of tests that start reliably failing with a 1-3 pixel difference, with a max-difference of 1, specifically with software WebRender, over a particular area of the gray-gradient background area.

On Linux, we fail one test: content-url-pseudo.html.
On macOS and Windows, we fail that test and two more: content-url-element.html and inline-block-frag-simple-2.html. (Though on macOS, only content-url-element.html gets reported as an unexpected failure, because the other two have a fuzzy annotation that we're inside the bounds of.)

So maybe this change happens to tickle a preexisting software-WebRender bug in a strange way? In any case, these category-(2) issues are all imperceptible and could easily be put behind a swgl-specific fuzzy annotation.

Blocks: 1835421

I would bet the category-(2) issue has to do with the fact that we're adding a background color behind the gradient, and maybe that barely leaks through in software-WebRender for some reason, because we mistakenly think some of the gradient pixels are partially transparent.

(The rest of this patch has to do with the scroll track, I think, so it's really hard to see how it would impact a pixel in the middle of the print preview background area.)

I think I fixed those trivially by properly propagating the page sequence background to canvas in print preview.

Flags: needinfo?(emilio)
Pushed by
Properly detect page sequence background from FindEffectiveBackgroundColor. r=dholbert
Pushed by
Tweak fuzz of a test that now is intermittently fuzzy on Linux too.
Pushed by
content-url-element.html is also fuzzy in swgl.
Mark a test as failing with useDrawSnapshot temporarily.
Blocks: 1835864
Pushed by
increase fuzzyness by 1 pixel. CLOSED TREE
Pushed by
Fix the previous fuzz adjustment.
Pushed by
Fix the previous fuzz adjustment.
Regressions: 1835951
You need to log in before you can comment on or make changes to this bug.