1829574 - Chunks of GitHub diff view background turn blue

Status: RESOLVED DUPLICATE of bug 1836052

(Core :: Print Preview, defect)

Description

[Martin Thomson [:mt:]]

This page is throwing up a very strange bug. For scroll positions other than the very top or very bottom of the page, the entire diff view gets a strong blue background. This background is not visible to devtools, leading me to conclude that there is some sort of graphical glitch involved.

I have not been successful in finding another GitHub page that exhibits this same weirdness, though I have confirmed that it works on two different machines and in a clean profile. It acts completely normally in other browsers. It also worked well on the second machine, which was a bit over a week out of date, which suggests that it is bisect time for me (yay).

Resizing the page reduces the distance you have to scroll before you get the background (meaning that the page is blue while resizing, but it can return to black or white once the resizing ends). I've also found that opening menus by hitting Alt can disable the "effect".

Comment 1

[Martin Thomson [:mt:]]

Attachment: Blue.png

This is what I am/was getting, more or less (it doesn't matter whether this is dark or light content).

Running build 20230423212458 shows the bug, but I was not able to find it in the very same build as downloaded using mozregression.

After going through about:support, I noticed that I had adjusted printer settings on what I had thought was a clean profile. That seemed to be the only difference though. So I hit "Clear saved print settings", then reloaded the page. The bug went away. I managed to successfully replicate that result in other profiles. That is a truly surprising outcome, but a good indication that that button was worth adding. Now I really don't know what to do with this bug.

Comment 2

[Mayank Bansal]

I cant repro this on Win11x64.
Can you post the contents of your about:support in a new Firefox profile that reproduces this bug? That way, we can see which all print preferences are needed to repro this bug.

Additionally, can you try resetting the print preferences one-by-one to see which exact pref triggers this bug?

Comment 3

[Martin Thomson [:mt:]]

The modified print preferences were, as far as about:support is concerned, in total:

1. print_printer = "Brother HL-L2360D series"
2. print.more-settings.open = true

Resetting "more-settings" doesn't fix anything. I'm reluctant to tweak the other setting as the only machine I have left with the bug is needed for diagnosing a separate printing bug related to that printer. I was not able to get the other machine to show the bug again once I cleared print settings.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

I think I saw this but it's related to selection. Clicking somewhere outside of the source table fixes this doesn't it?

Comment 5

[Daniel Holbert [:dholbert]]

A few more questions on top of comment 4:

• can you reproduce regardless of whether you're signed in to GitHub?
• what technique are you using to scroll -- e.g. dragging on touchscreen, vs. two-finger-scrolling on touchpad, vs. mousewheel, vs. keyboard arrows & pageup/pagedown? (I wonder if your scroll method is inadvertently generating a large selection, as Emilio noted.) Does the reproducibility seem related to what method of scrolling you use? (starting from a freshly-reloaded page to avoid any persistent issues sticking around)

Comment 6

[Daniel Holbert [:dholbert]]

though I have confirmed that it works on two different machines and in a clean profile

Also, to clarify, when you said "it works", did you mean "the bug reproduces" or "the bug does not reproduce"?

Comment 7

[Daniel Holbert [:dholbert]]

(I'm extremely skeptical that this is related to print preferences; I would bet that there's some other flakiness or not-yet-known factor here, and it was just "luck" that the bug seemed to go away after the print settings were reset in comment 0. This probably doesn't belong in Print Preview since print-preview isn't directly involved here; I suspect this wants to be reclassified to e.g. Web Painting or a selection-related component, but I'll hold off on doing that, pending answers to the above questions, to avoid reclassification-churn as we learn more.)

Comment 8

[Martin Thomson [:mt:]]

To try to answer all of these questions...

• I get this in browsers that are logged in and are not (also, being logged in gives me a side-by-side diff, which has no observable effect)
• I get this regardless of selection state. Note that the screenshot includes a selection, which is a different color (line 163-165, right, you can just make it out).
• I get this in all types of scrolling. Two fingers on a touchpad, scroll bar, arrows, page-up/down, touch screen. All of these work with no prior interaction with the page, so probably no preexisting selection. All active the blue at about the same place.
• I do not get this in a clean profile. I was only able to get it to work in a nearly-clean profile: the one I created for testing bug 1824470 in which all I had done was printed some garbage pages a few times. Hence the decision to try clearing print state and my surprise at that working. Of course that is annoying now because in doing so I destroyed a profile that I might be willing to share.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

That's rather bizarre. I think I saw it once, but I can't repro it, and it'd be indeed super-weird that it's related to print prefs... Can you still repro this reliably?

Comment 10

[Martin Thomson [:mt:]]

I seem to have lost the ability to reproduce it. :(

Comment 11

[Emilio Cobos Álvarez (:emilio)]

Ok, let's call it incomplete, maybe it was a bug on GH's side or something... If it pops up again we can reopen.