1729199 - Blank pages on some PDF files

Status: RESOLVED DUPLICATE of bug 1720282

(Firefox :: PDF Viewer, defect, P3)

Description

[starline98]

Attachment: 1.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

Open PDF file with Firefox browser

Actual results:

PDF opens with blank pages

Expected results:

File must be opened not with blank pages

Comment 1

[starline98]

Attachment: IMSLP96384-PMLP113759-Chopin_Walzer_B_150_Op_P2-11_piupianissimo_2011.pdf

Comment 2

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

The Bugbug bot thinks this bug should belong to the 'Firefox::PDF Viewer' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[Petruta Horea [:phorea], PTO until 8/22/25]

Reproduced on latest Nightly 93.0a1 2021-09-06 under Win 10 64-bit.
This particular pdf was blank also on older Fx versions, like 63.0a1.

Comment 4

[Calixte Denizet (:calixte)]

The console shows:

Message: 
Stack: putBinaryImageData@resource://pdf.js/build/pdf.js:4895:11
paintInlineImageXObject@resource://pdf.js/build/pdf.js:6638:25
paintImageXObject@resource://pdf.js/build/pdf.js:6589:10
executeOperatorList@resource://pdf.js/build/pdf.js:5241:20
....

Comment 5

[Calixte Denizet (:calixte)]

I can reproduce the bug using pdf.js from upstream and a local server with Firefox nightly but it works well in chrome.
So it's likely a Firefox issue, the guilty line is:
https://github.com/mozilla/pdf.js/blob/d95f680d66dd46e2995a7784109a1b3af2b84bdd/src/display/canvas.js#L596

In checking stderr with a local build, I get this:
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Failed to allocate a surface due to invalid size (CDT) Size(9927,14043) (t=38.0922) [GFX1-]: Failed to allocate a surface due to invalid size (CDT) Size(9927,14043)

Comment 6

[starline98]

It opens well in Edge too. Hope you guys can figure out what's wrong cause i don't understand all these codes 😀

Comment 7

[Calixte Denizet (:calixte)]

Increasing gfx.max-alloc-size to 600000000 in about:config fixes the issue.
The default value for this pref is 500000000 and here we're requesting 9927 * 14043 * 4 = 557619444 bytes.
So we should likely find a way in pdf.js to split too big images into tiles.

Comment 8

[starline98]

Nice! 👍

Comment 9

[Kelsey Gilbert [:jgilbert]]

Is pdf.js canvas2d-only, or does it have a webgl path too?

Comment 10

[Brendan Dahl [:bdahl]]

canvas2d only

Comment 11

[Calixte Denizet (:calixte)]

:jgilbert, could we consider to increase the value of gfx.max-alloc-size to have the same as in Chrome ?

Comment 12

[Kelsey Gilbert [:jgilbert]]

That would only be a bandaid, as some hardware/drivers cannot support higher values. (and therefore we're probably not robust to them failing, if we did raise this higher than they support) ~500MB is the lowest maximum allocation size that DirectX supports, though this scales upwards based on GPU RAM size. To avoid problems where this works on some devices and not others, it can be useful to have just one limit that's universal.

This is a constraint that we should be surfacing up the stack from the browser back to the application.
We may need a new API for this, if we don't have one already. (It doesn't look like we have one)
On WebGL this is handled by OUT_OF_MEMORY errors.

Therefore:

1. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/canvas#maximum_canvas_size needs to be updated, and
2. the web platform needs a way to tell apps that an allocation like this failed, and
3. pfd.js will need to be able to deal with limits being too small for some allocations.

Comment 13

[Kelsey Gilbert [:jgilbert]]

A fourth thing to consider is downgrading a gpu-accelerated canvas to cpu-accelerated, which lets us have basically arbitrarily large canvases (memory allowing) but is considerably slower for operations that touch large parts of the canvas. I'm unsure if we have code to handle this live-downgrading yet.

Comment 14

[Marco Castelluccio [:marco]]

Could the difference with Chrome cause web compat issues other than pdf.js? Or is this mostly a corner case?

Comment 15

[Kelsey Gilbert [:jgilbert]]

Possible web-compat for sure, but likely quite rare. Worth noting though that if it fails on Firefox, then there are machines for which it likely fails on Chrome.
The largest canvas sizes we expect from most content are full-screen resolution sizes, which plateaus around 4k (32MB) or so. "8k" is still only 128MB.

Comment 17

[laitanner]

Attachment: pdf that wont render completely

Comment 18

[laitanner]

Not sure if the root cause is the same but I'm attaching this PDF pdf that wont render completely which also does not display properly in firefox, but will display properly in edge. In this case some elements are rendered so its not completely blank, but there are elements which do not show up at all.

Comment 19

[Marco Castelluccio [:marco]]

(In reply to laitanner from comment #18)

Not sure if the root cause is the same but I'm attaching this PDF pdf that wont render completely which also does not display properly in firefox, but will display properly in edge. In this case some elements are rendered so its not completely blank, but there are elements which do not show up at all.

I think it's a different root cause, could you open a new bug?

Comment 20

[Calixte Denizet (:calixte)]

:laitanner, it's a different bug: you can open a console to get some warnings (JPX issues). As Marco said, please open a new bug with the warnings.

Comment 21

[laitanner]

Opened the bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=1748489

Comment 24

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

The severity field for this bug is relatively low, S4. However, the bug has 3 duplicates.
:calixte, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.