1965005 - The "Print backgrounds" option is changes the color scheme of the print preview's scroll bar

Status: RESOLVED FIXED

(Core :: Print Preview, defect)

Description

[Daniel Bodea [:danibodea]]

Note

• The "Print backgrounds" checkbox changes the color scheme of the print preview's scroll bar.

Found in

• Beta v139.0b4

Affected versions

• Beta v139.0b4
• ESR v128.10.0esr

Tested platforms

• Affected platforms: Windows 10, MacOS 11, Ubuntu 24 ARM
• Unaffected platforms: none

Steps to reproduce

1. Load a page long enough to display a scrollbar in print preview, like https://en.wikipedia.org/wiki/Main_Page
2. Open print preview.
3. Check/uncheck the "Print backgrounds" checkbox.

Expected result

• The backgrounds in question are being added to the print preview
• The print preview's scroll bar does not change its color scheme.

Actual result

• The print preview's scroll bar changes its color scheme.

Regression range

• This is not a recent regression.

Comment 1

[Emily McDonough [:alaskanemily]]

I don't see this behavior in 140 nightly or 137 release, Linux amd64 (default GTK theme, tested with disabled hidden scrollbars and then tried again with re-enabling hidden scrollbars). Does this only happen with certain firefox themes or OS themes (light/dark)?

Comment 2

[Daniel Holbert [:dholbert]]

I can reproduce this on Linux (Ubuntu 24.04) in my regular browsing profile, but not in a fresh profile, so for me at least there might be some additional state required (or there might be a race condition involved). I'll see if I can bisect my profile to find out what's needed... (Leaving ni=dbodea as well for now in case he has additional tips/insights on reproducing.)

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screencast showing the bug

Comment 4

[Daniel Holbert [:dholbert]]

Actually: the reason I was seeing a difference was that I hadn't restarted my regular browsing profile to accept a nightly update. After doing that, the bug went away.

This seems to have been fixed for me in the past day.

In still-bad builds, I can reliably repro the bug on Ubuntu 24.04, with an OS-level dark color-scheme, and a fresh Firefox profile, with the only customization being to check the box for "always show scrollbars" in Firefox preferences (which is only present on Linux; on mac/Windows we defer to an OS checkbox for that, which presumably needs to be checked to trigger the bug there).

mozregression --find-fix gives me this range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c18424fd2f841eae18f0d621e718b485cdc3fd50&tochange=fe234ae1de7c534e9f75cb1fbb9ab2008f01b6a6

In there, I'm guessing this would've been fixed by bug 1964293.

dbodea, could you confirm that this is fixed for you as well in latest Nightly?

Comment 5

[Daniel Bodea [:danibodea]]

This issue no longer occurs in the latest Nightly v140.0a1 from 2025-05-07.
According to my mozregression investigation on Windows 10, the issue was fixed in bug 1963424.

Please feel free to update the report as you see fit. Thank you.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Daniel Bodea [:danibodea] from comment #5)

This issue no longer occurs in the latest Nightly v140.0a1 from 2025-05-07.
According to my mozregression investigation on Windows 10, the issue was fixed in bug 1963424.

I think you mean "this was fixed by a pushlog range that includes bug 1963424". For me at least, bug 1963424 was the first commit in the fix range (the one I linked in comment 4) (and its backout was the last commit in that fix range). But bug 1963424 is not itself the fix. Per comment 4, bug 1964293 (related to background painting) seems like the most likely thing to have fixed this in the fix-range, so let's close this as FIXED by that bug.