1906370 - PDF text rendering issue on Linux

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[D]

Attachment: FireFoxPDFBackgroundBug.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:127.0) Gecko/20100101 Firefox/127.0

Steps to reproduce:

Opened a PDF file Firefox in a new tab.

Usually (and up until recently) the PDF would appear in a new tab and be readable.

Now the PDF appears, only the desktop image shows through, and the text is blocky and illegible.

Version:
Mint 001 - 1.0

127.0.2 64bit version for old version of Linux Mint.

Operating System: Linux Mint 21
Kernel: Linux 5.15.0-113-generic
Architecture: x86-64

GPU: Nvidia 3090
nvidia-driver-555: installed: 555.42.06-0ubuntu1 available: 555.42.06-0ubuntu1 (auto-install) [third party] non-free

Actual results:

PDF file shows, with black text over the desktop background image.

Changing from dark mode to auto mode / light mode didn't change issue.

Expected results:

PDF should have appeared in a readable format.

Pdf from Nvidia:
https://resources.nvidia.com/en-us-tensor-core?ncid=no-ncid

Report of others having the same issue on Reddit:
https://www.reddit.com/r/firefox/comments/1dkih34/pdf_rendering_error/

Alt-Printscreen Flashes the background white, and captures the background white. Clicking/scrolling etc reflashes the background back to the desktop background image.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Graphics' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Jim Mathies [:jimm]]

Well that certainly looks bad. Doesn't reproduce on macos and windows, so Linux specific.

Comment 3

[Jim Mathies [:jimm]]

A regression range would be helpful. We have a tool that helps find these, you can try it out here https://mozilla.github.io/mozregression/.

Comment 4

[D]

I have distinctly unhelpful news on the bug...

It's INTERMITTENT !

As I prepared to run the regression testing, I went to get the exact url used in the bug report above only to see that it's currently working.

Since the bug report, I've rebooted a number of times, and have closed many tabs... I was running 100ish tabs in 5 or 6 instances just before placing the report.

If memory serves, I've seen this bug across other reboots, so I'm likely to see it again, and I can try to stress things a little to make it appear, but for now, give me a little time and I'll see what additional info I can procure.

I'm open to advice/suggestions.

Thanks

Comment 5

[Jeff Muizelaar [:jrmuizel]]

When you do see the problem are all pdfs affected or only some?

Comment 6

[D]

It seemed like all pdfs were affected.

Comment 7

[Kelsey Gilbert [:jgilbert]]

Can you attach an about:support for the affected browser?

Comment 8

[D]

Attachment: about:support

about:support

Comment 9

[D]

about:support

Comment 10

[D]

This is going to be harder than I thought... Hopefully someone has an idea...

I had the issue happen again, and numerous days of using Firefox without rebooting, but with quite a few tabs open etc.

So, just to test that we'd be able to really do a regression test, I xkilled Firefox, and opened it back up.

Unfortunately pdf's are working again... for now...

I can regress to some older version... I didn't see the problem about a month, maybe a little longer ago, but it's going to be a slow process unless I figure out some magic steps to recreate the issue reliably.

Thoughts? Suggestions? Anything to try first?

Comment 11

[D]

Through some more testing I found out that suspending or hibernating the computer would invoke the error more reliably, so I embarked on a marathon regression session.

Long story short, that didn't work, but not before I developed a whole rain dance which included hibernating twice during each test, opening and closing multiple tabs, etc. Eventually I noticed more and more display/window quirks, or screen refresh issues.

I'm now starting another test where I don't ever put the computer to sleep.

As ever, I'm open to ideas, etc, and starting to think that this might be a hardware/firmware issue.

Comment 12

[mirh]

Can you try what I suggested in bug 1901789, comment 7?

Comment 13

[D]

Sure... Turn webgl.gl_khr_no_error to true in about:config

I'm inclined to wait for the problem to occur, and I'll leave the power on to avoid any chance it's a suspend issue, that way I can turn it on and reload a pdf at a point in time that the problem is actively occurring for confirmation.

It seems like if I turn it on now, then we'd only get actionable information if the problem reoccurred.

Comment 14

[mirh]

Not sure if it may not need a browser restart to actually apply.
But have the experiments as you wish.

Comment 15

[Bob Hood [:bhood]]

Jonathan, any insights on this one?

Comment 16

[D]

Avoiding sleeping on this computer does seem to correlate with the issue not reappearing.

I, of course, will keep testing over the next several weeks just to push it farther, but I'm open to closing or whatever is advised.

I believe that their is a bug somewhere, but I don't think it's in Firefox, and it's probably the sort of bug that's extremely difficult to isolate between hardware / software / firmware, etc.

Comment 17

[Jonathan Kew [:jfkthame]]

(In reply to Bob Hood [:bhood] from comment #15)

Jonathan, any insights on this one?

Not really.... "the desktop image shows through" (from comment 0) makes it sound like an issue with compositing at some level, but whether within Firefox itself, or the window manager, or somewhere deep in graphics drivers... no idea, sorry.

Comment 18

[mirh]

(In reply to D from comment #16)

I believe that their is a bug somewhere, but I don't think it's in Firefox, and it's probably the sort of bug that's extremely difficult to isolate between hardware / software / firmware, etc.

Meaning that my webgl.gl_khr_no_error=true pitch failed?

Comment 19

[D]

So far, I can't reproduce the bug with webgl.gl_khr_no_error set to false if I don't put the computer to sleep...

Would being able to reproduce the bug with webgl.gl_khr_no_error set to true and having the computer sleep give you any additional info?

Alternately, would setting it to true and not sleeping and not seeing the error add information to the situation?

I'm happy to do it.

Comment 20

[mirh]

For pete's sake.. Just enable it and see if the problem presents ever again.

Comment 21

[D]

Enabled and restarted.

Comment 22

[D]

Progress update:

Enabling webgl.gl_khr_no_error seemed to make my system unstable... I was forced to reboot 3 times in about 3 days. To better confirm that was the factor effecting the instability, I disabled webgl.gl_khr_no_error, and my system was more stable again... and I started to see the disappearing background issue again.

To better confirm, I've reenabled webgl.gl_khr_no_error now, and will try another week or two run, first without ever putting the computer to sleep.

Comment 23

[D]

Best guess at the current patterns:

webgl.gl_khr_no_error seems to cause the system to crash from exiting sleep mode when a program is left resident in the gpu. (In my case, the program is usually ollama.

If the computer is not put to sleep, or ollama is not left running during sleep mode, the computer seems to be much more stable.

and webgl.gl_khr_no_error seems to work fine if the computer is not put to sleep.

Comment 24

[mirh]

Nvidia issues with suspension might be this
https://wiki.archlinux.org/title/NVIDIA/Tips_and_tricks#Preserve_video_memory_after_suspend

But nonetheless, it's really not something up to the browser to fix.

Comment 25

[D]

In one case, the computer did crash after running and closing gpu apps before putting the computer to sleep, and I haven't seen the issue during the tests where I don't put the computer to sleep for a few days, but the results are very intermittent, and it's been very difficult finding a consistent sequence to recreate the crashes. The problem usually presents as the computer is unable to restart from sleep without a full power cycle.

I had noticed a new interesting issue. When returning from sleep, one of the copies of firefox would not display until I brought it into the foreground. Two other instances would appear fine, the the third would be invisible. I've now enabled the preserve NVidia memory during sleep configuration mentioned by mirh, and haven't seen the issue again in my short stint of testing.

Comment 26

[D]

I've gone rather longer than usual between reboots recently.

I'm planning to close this soon, as the issue seems to be an intractable intermittent issue that may not even be related to Firefox.

Comment 27

[D]

Up until now all crashes has occurred with webgl.gl_khr_no_error = true... Today I had a crash with webgl.gl_khr_no_error = false.

I'm currently convinced I'm wasting everyone's time and am just going to close the bug...

Comment 28

[D]

Not resolved, but closed all the same.