1978317 - HTML Spec page printed to PDF cannot be opened in Firefox

Status: VERIFIED FIXED

(Firefox :: PDF Viewer, defect, P1)

Description

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Found in

• Firefox 142.0a1

Affected versions

• Firefox 141.0
• Firefox 142.0a1

Tested platforms

• Affected platforms: Windows 11, Ubuntu 24
• Unaffected platforms: macOS 15.5

Steps to reproduce

1. Access this page
2. Open the print preview and wait for the preview to fully load
3. Print the page to PDF
4. Open the printed PDF with Firefox

Expected result

• The PDF is loaded in Firefox

Actual result

• The PDF is not loaded in Firefox

Regression range

• Logged as a follow up for Bug 1970805.

Additional notes

• Print preview will take some time to be shown as there are ~1000 pages to load
• Nothing is shown in browser console

Comment 1

[Calixte Denizet (:calixte)]

The generated pdf fails to open in Firefox because of Invalid Root reference..
I can open it correctly in Chrome and PDFBox but not in Acrobat (where I got There was an error opening this document. The root object is missing or invalid.)
If I uncompress the pdf with qpdf then the result can be open in Firefox.
So there's something wrong in the pdf structure which should be workaround-able but the size of the pdf doesn't help to make the problem easy to figure out.
:Jonathan, would you have any idea on how we could find out what's wrong ?

Comment 2

[Calixte Denizet (:calixte)]

I think I found what's wrong with this pdf.
For the root object, in the xref table we've that it belongs the cross reference stream 282446 at index 4588.
But in the N entry of this xref stream, the reference of the pointed object is 14527 (which is a link annotation).
If the xref table would have been correct, the index would have been 266732.
I'll try to find a fix for this bug (we could use the data at the beginning of the stream with the pairs reference/offset), but for sure there is bug in Cairo here, cc :Jonathan.

Comment 3

[Jonathan Kew [:jfkthame]]

Thanks for looking into this! Yes, sounds like this is caused by a bug in the Cairo PDF backend. We could really use some kind of reduced/simplified testcase if we're going to get this addressed upstream, though; we can hardly expect the Cairo developers to debug the generation of a thousand-page document via Firefox's printing code.

I wonder if the issue is triggered by the overall size of the output, or the number of pages, or some specific part of the content, or some other combination of factors....

Comment 4

[BMO Github Automation]

Attachment: [mozilla/pdf.js] Fix the xref table with the values we've at the beginning of a xref stream (bug 1978317) (#20113)

Comment 5

[Jonathan Kew [:jfkthame]]

I tried a couple of experiments:

(a) Created an HTML doc that generates 1000 pages, but they're really simple: just a large box and a page number. Save to PDF (on Linux) results in a file of about 550K which Firefox can then re-open just fine. So it's not the page count (alone, at least) that leads to the problem.

(b) Used Chromium to save the HTML spec to a PDF. That resulted in a 994-page PDF that is over 90MB. But it still loads fine in Firefox. So it's not the large file size (alone) that leads to the problem, either.

(c) With the Chromium-generated PDF of the HTML spec opened in Firefox, used our Save to PDF to generate a new PDF copy. This is still a 994-page PDF, of course (because pagination doesn't change when we're dealing with a PDF original), but is only 22MB. This file can be re-opened in Firefox without problems. (Visually, it looks OK, but I note that the links that were in the original spec, and worked in the Chromium-generated PDF, are no longer present in this version.)

Comment 6

[Jonathan Kew [:jfkthame]]

I notice you've got a pdf.js patch up - cool! If we do apply a workaround there, we should file a followup about the problem on the pdf-generation side. We'll still be potentially creating broken PDFs that fail to load in various other applications, even if pdf.js is able to handle them.

Comment 7

[Calixte Denizet (:calixte)]

(In reply to Jonathan Kew [:jfkthame] from comment #6)

I notice you've got a pdf.js patch up - cool! If we do apply a workaround there, we should file a followup about the problem on the pdf-generation side. We'll still be potentially creating broken PDFs that fail to load in various other applications, even if pdf.js is able to handle them.

Yeah and the crazy thing is that it doesn't break our ref tests... I'm really surprised tbh :).

Anyway, after some debugging I found that: the first wrong reference is 141676, it's index in the xref stream is 65536 and the index found in the xref table is 0.
For an object in a xref stream, it should be referenced in the xref table as the xref stream reference followed by the index in the xref stream.
Usually the second number in the xref table is the generation number. The gen number is 5 digits, its min is 0, its max value is 65535 and there is a special meaning for 65535 (the ref cannot be reused). So usually the gen number is stored on 2 bytes which is very likely why we've this issue.
So I guess having a single web page with enough links should trigger the issue.

Comment 8

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

The patch landed in nightly and beta is affected.
:calixte, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox142 to wontfix.

For more information, please visit BugBot documentation.

Comment 9

[Calixte Denizet (:calixte)]

It's a corner case bug with pdfs containing a lot of links and which have been created in using Firefox on Windows or Linux.

Comment 10

[Jonathan Kew [:jfkthame]]

We're nominating bug 1970805 for esr140 uplift; if we take that, I think we should probably consider uplifting this as well.

Comment 11

[Calixte Denizet (:calixte)]

Attachment: Bug 1978317 - Fix the xref table with the ref in a xref stream

Comment 12

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined: Some users printing large HTML to pdf won't be able to open them
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: See comment#0
• Risk associated with taking this patch: Low
• Explanation of risk level: It's a corner case
• String changes made/needed: no
• Is Android affected?: yes

Comment 13

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/9d1adb3c5900

Comment 14

[Ciprian Georgiu, Desktop QA]

I've repro this issue with an affected Nightly build (2025-07-21) on Win 11.

The issue is verified as fixed on Win 11 and Ubuntu 24.04 using Firefox 143.0 and Esr 140.3.0.

Comment 15

[Ciprian Georgiu, Desktop QA]

I've forgotten to add this. cdenizet, while checking this issue, we noticed that PDFs take a long time to load in Firefox. In Edge, for example, they load much faster. Is this a known issue, or should we file a new bug for it?

Comment 16

[Calixte Denizet (:calixte)]

(In reply to Ciprian Georgiu, Desktop QA from comment #15)

I've forgotten to add this. cdenizet, while checking this issue, we noticed that PDFs take a long time to load in Firefox. In Edge, for example, they load much faster. Is this a known issue, or should we file a new bug for it?

Yep, I noticed that while debugging the file and it's mainly due having a bit too much annotations in the file and a too big struct tree.
:Ciprian, yes can file a bug please.

Comment 17

[Ciprian Georgiu, Desktop QA]

(In reply to Calixte Denizet (:calixte) from comment #16)

(In reply to Ciprian Georgiu, Desktop QA from comment #15)

I've forgotten to add this. cdenizet, while checking this issue, we noticed that PDFs take a long time to load in Firefox. In Edge, for example, they load much faster. Is this a known issue, or should we file a new bug for it?

Yep, I noticed that while debugging the file and it's mainly due having a bit too much annotations in the file and a too big struct tree.
:Ciprian, yes can file a bug please.

Thanks! Filed bug 1987914.