1662367 - print preview shouldn't reuse previously used page format for PDFs, initially always portrait used, even for landscape PDFs

Status: NEW

(Core :: Print Preview, defect, P2)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Attachment: landscape.pdf

Firefox 81.0b4 and 82.0a1 20200831215215 on Windows 8.1

The print preview shouldn't reuse the previously used page format for PDFs. Initially always the portrait format is used, even for landscape PDFs.

Steps to reproduce:

1. Open the attached landscape.pdf in Firefox (rendered in landscape mode)
2. Open the print dialog

Actual result:
Content rendered in portrait mode if that had been used last or it's the first time the print dialog gets used.

Expected result:
Landscape mode used.

Comment 1

[Daniel Holbert [:dholbert]]

This isn't a regression -- I see this in the old print UI, too (both in File|Print Preview and in the actual printed output that you get if you hit the print icon in PDF.js and choose to print to a PDF).

I tried in nightly with print.tab_modal.enabled = false and also in a before-the-print-UI-refresh nightly, from Jan 1 2020 (version 73.0a1), and I ended up with a portrait-mode document in both cases (with "Landscape" displayed across the top, from left to right).

I suspect his is easier to notice now with the print UI, because we show a preview of the printed output more eagerly, but I don't think we need to consider this a regression or something that needs fixing for 81.

Comment 2

[Daniel Holbert [:dholbert]]

(dropping "_81" from whiteboard, since I don't think we need to fix this for 81, per comment 1)

Comment 3

[Jonathan Watt [:jwatt]]

It's probably worth noting that Chrome disables the "Layout" menu in their print preview UI for PDFs. (I think the also disable it if @page sets the orientation.)

I'm not sure offhand how we'd communicate the orientation used in a PDF file from PDF.js to the frontend code though. Emilio, you've been looking at PDF.js; did you spot anything that might be helpful to achieving this at the time?

Comment 4

[Emilio Cobos Álvarez (:emilio)]

I don't think so. I think a combination of named pages and @page { size } could allow this... Pages in PDFs can be heterogeneous and we don't quite support that.

PDF.js is privileged code and we may want / be able to collect some information from the document if needed at print time... Not sure if there's any precedent for that though. Brendan?

Comment 5

[Jonathan Watt [:jwatt]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)

Pages in PDFs can be heterogeneous and we don't quite support that.

That's true, but it's relatively rare. As a first step, using the orientation of the first page would go a long way to fixing the common case.

Comment 6

[Brendan Dahl [:bdahl]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)

I don't think so. I think a combination of named pages and @page { size } could allow this... Pages in PDFs can be heterogeneous and we don't quite support that.

PDF.js is privileged code and we may want / be able to collect some information from the document if needed at print time... Not sure if there's any precedent for that though. Brendan?

Not currently, it's been brought up a few times though. If pdf.js got an event before printing that had paper sizes and DPI we could improve our output.

Comment 7

[Jonathan Watt [:jwatt]]

I'm confused. Is this a regression or not. How did we end up with firefox80:unaffected? Sebastian, maybe the setting of that flag isn't showing up in the bug comment because you set that when you filed this bug? If that's the case, do you disagree with Daniel's comment in comment 1 that this isn't a regression?

Comment 8

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Sorry for the confusion - not a regression.

Comment 9

[Jonathan Watt [:jwatt]]

No worries, thanks for clarifying.