PDF display corrupted after restore of minimized window
Categories
(Core :: Graphics: Canvas2D, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox123 | --- | fixed |
People
(Reporter: douger34, Assigned: lsalzman)
References
(Blocks 1 open bug)
Details
Attachments
(4 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/112.0
Steps to reproduce:
A PDF was display in a tab of a Firefox window. The window was minimized into the dock. Sometime later it was restored to the open state.
Actual results:
The displayed PDF was corrupted.
Expected results:
PDF should have been displayed just as it was before minimization.
| Reporter | ||
Comment 1•3 years ago
|
||
| Reporter | ||
Comment 2•3 years ago
|
||
Comment 3•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::PDF Viewer' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 4•3 years ago
|
||
Can you please provide any example of a pdf file were you reproduced the issue?
Does the issue still persist even after refreshing or restarting Firefox?
Thanks.
| Reporter | ||
Comment 5•3 years ago
|
||
The second and third images both show the complete URL. But I doubt that will be very useful as the images each come from different sites. Though I suppose something the PDFs have in common could cause it, I suspect it's just a general corruption / overwriting of the memory containing the image of the displayed PDF.
The problem goes away by just reloading the page, which makes sense.
The first time it happened I collected the first image. The second episode I collected images 2 and 3, so images in two tabs from the same window were both corrupted.
The pattern of corruption is similar in the first two, but the third is different. So in the second instance, where two tab's images were corrupted, the pattern of corruption was different between the two, but the pattern of 2 matched that of 1 from the earlier episode.
I cannot "reproduce" the problem in any intentional way. It just happens every so often -- very infrequently.
Comment 6•3 years ago
|
||
I don't think it's directly related to pdf.js but probably something is wrong with the canvas itself.
:lsalzman, do you have any idea ?
| Reporter | ||
Comment 7•2 years ago
|
||
I have 15 Mbytes of more Firefox PDF window images of this happening, but unless you think the visual pattern of the corruption provides any clues I won't upload them.
There's been no response from :lsalzman.
| Reporter | ||
Updated•2 years ago
|
Comment 8•2 years ago
|
||
Could you set gfx.canvas.accelerated to false in about:config ? and see if it makes a difference.
| Reporter | ||
Comment 9•2 years ago
|
||
I made that change to the config right when you suggested it and haven't seen the problem for some time now. So I think it worked. I'll set that config value back to true now and see if the problem reappears.
| Reporter | ||
Comment 10•2 years ago
|
||
Bingo! With gfx.canvas.accelerated back to true the problem is occurring again, so I'll put it back to false and leave it that way until the problem gets fixed.
This if FF 121.0
Updated•2 years ago
|
| Assignee | ||
Comment 11•2 years ago
|
||
I can take a look at trying some mitigations for this, but I am still somewhat guessing at the cause. I will see about this next week.
| Assignee | ||
Comment 12•2 years ago
|
||
After a minimize, an unknown amount of time or circumstances may be involved that ultimately lead to
a GL context loss. To try to mitigate this, cache software snapshots of DrawTargetWebgls when we are
about to minimize so that these can hopefully be copied into fallback TextureDatas later if the context
is actually lost.
Updated•2 years ago
|
Comment 13•2 years ago
|
||
Comment 14•2 years ago
|
||
| bugherder | ||
Description
•