Closed Bug 1833733 Opened 2 years ago Closed 2 years ago

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

Categories

(Toolkit :: Printing, defect)

defect

Tracking

()

RESOLVED FIXED
115 Branch
Tracking Status
firefox115 --- fixed

People

(Reporter: dholbert, Assigned: emilio)

References

(Blocks 1 open bug)

Details

Attachments

(4 files)

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

STR:

  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 https://en.wikipedia.org/wiki/Alice%27s_Adventures_in_Wonderland
  3. Ctrl+P to open Print Preview
  4. Mousewheel-scroll the print preview area.

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

EXPECTED RESULTS:
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 ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/12975d519459 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:
https://searchfox.org/mozilla-central/rev/b891c79ab6bccbeba86ce7db11cbcb004f37d319/layout/reftests/pagination/820496-1.html#3

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

...which failed here:
https://treeherder.mozilla.org/logviewer?job_id=416366367&repo=autoland&lineNumber=3568
...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.
Linux: https://treeherder.mozilla.org/logviewer?job_id=416366286&repo=autoland&lineNumber=3590
macOS: https://treeherder.mozilla.org/logviewer?job_id=416366907&repo=autoland&lineNumber=4942
Windows: https://treeherder.mozilla.org/logviewer?job_id=416368509&repo=autoland&lineNumber=8320

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 ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/387a305972af Properly detect page sequence background from FindEffectiveBackgroundColor. r=dholbert
Pushed by emilio@crisal.io: https://hg.mozilla.org/integration/autoland/rev/6e529b723570 Tweak fuzz of a test that now is intermittently fuzzy on Linux too.
Pushed by emilio@crisal.io: https://hg.mozilla.org/integration/autoland/rev/c96dcc483022 content-url-element.html is also fuzzy in swgl. https://hg.mozilla.org/integration/autoland/rev/1c86169a6ab3 Mark a test as failing with useDrawSnapshot temporarily.
Blocks: 1835864
Regressions: 1835951
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: