1913617 - PDF viewer brings up wrong page when bookmarks are selected

Status: NEW

(Firefox :: PDF Viewer, defect, P3)

Description

[FraC]

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

Steps to reproduce:

I have opened a big PDF file (around 8000 pages), when using bookmarks the wrong pages are shown. It happens with smaller PDF parts of the big one too

Actual results:

When looking at the PDF data through BeCyPDFmetaEdit, the bookmarks are set at their correct correspondent pages (for chapters, paragraphs, etc), but Firefox shows a different page number (instead of page 6 it shows page 9, and so on)

Expected results:

Firefox should redirect to the correct page number correspondent to the PDF bookmarks

Comment 1

[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 correct in case you think the bot is wrong.

Comment 2

[Calixte Denizet (:calixte)]

Unfortunately, without the pdf there's nothing we can do.
So please attach the pdf (or a smaller one) to this bug. If the pdf is private, you can restrict the access to this bug to Mozilla employees (Edit Bug > Security > Confidential Mozilla Employee Bug (non-security) checkbox) or you can send me the pdf on my pro email.

Comment 3

[FraC]

I'm sorry, didn't really think about it. I'll attach the smaller PDF, behaviour is the same as the big one

Hopefully it's useful and I'm not just sending a broken PDF o_o

Thanks

Comment 4

[FraC]

Attachment: mr325-kangoo-0-general.pdf

selecting bookmarks brings up wrong (non-corresponding) page

Comment 5

[Calixte Denizet (:calixte)]

I can reproduce the issue in nightly.
It works correctly with the pdfium viewer.
:Snuffleupagus could you have a look please ?

Comment 6

[Jonas Jenwald [:Snuffleupagus]]

First of all, that PDF document has an /Outline that specifies "bad" destinations in the following format: /Dest [ 11 0 R /XYZ null null null ], i.e. using null arguments for the x/y-coordinates. We have code in the viewer that should be able to fallback to something usable, however there's additional things at play here.
Note that all the pages have both /MediaBox and /CropBox entries that cause the view-getter to return a viewport that doesn't start at zero in the y-coordinate; e.g. for page 1 the result is [ 0, 2421, 550, 3240 ].
It now appears that various methods in the PageViewport class don't correctly handle the situation where the viewport starts at a non-zero value in either the x/y-coordinates, unless I'm misunderstanding things completely here.

One immediate and simple idea is that we could try to work-around this by normalizing the viewport, in the worker-thread view-getter, such that we always start at zero in both coordinates!?
Obviously this might be totally wrong in general, and I've not tested it, but it would be a much easier solution than re-factoring PageViewport to handle these cases correctly.

Comment 7

[Jonas Jenwald [:Snuffleupagus]]

Another possible solution, which might be less risky overall, could be to change these computations to use the viewport "end-points" rather than just the effective width/height?
As long as the viewport start at zero in both coordinates those values should agree anyway, so I don't believe that it would affect the normal case.

Comment 8

[BMO Github Automation]

Attachment: [mozilla/pdf.js] Handle incomplete destinations in PDF documents with where the viewport starts at non-zero coordinates (bug 1913617) (#18639)