1685264 - First page/ Last page print preview paginator buttons show inaccurate page number on first click for a certain paper size type

Status: NEW

(Toolkit :: Printing, defect, P3)

Description

[Anca Soncutean, Desktop QA]

Attachment: screencast_issue .gif

Affected versions

• 86.0a1 (2020-01-05)
• 85.0b5

Affected platforms

• Windows 7
• Windows 10

Steps to reproduce

1. Open the new Print modal on a longer page
2. Select Microsoft XPS Document Writer as destination
3. Set paper size to Japan Envelope Chou #4 (or Japan Envelope Chou #4 Rotated)
4. Click the First page/ Last page inside the print preview paginator

Expected result

• The corresponding page number is the first, respectively the last

Actual result

• The corresponding page number is the second one, respectively the penultimate one

Regression range

• Not a regression, issue present since paginator implementation.

Additional notes

• The preview content shows the desired outcome
• Second click on First page/ Last page returns the expected result
• The same problem on the same paper size option is present with Foxit Reader PDF Printer destination
• Set the severity as S4 since I didn't trigger the issue on other paper size and the functionality of the buttons is not entirely broken

Comment 1

[Blake Winton (:bwinton) (:☕️)]

Hey Sam, could you take a quick look at this and see whether it's something in the front-end code, or a platform thing?

Comment 2

[Mark Striemer [:mstriemer]]

This seems somewhat expected to me, since the page number is determined by what page is intersecting the middle of the viewport. If you shrink the window vertically so a page takes more than half of the viewport it shouldn't happen.

The page number comes from the platform side, so this could potentially be a platform issue. Alternatively, in PrintingChild.jsm we could likely check if we're close to the top/bottom of the scrollable area and fix the page to first/last.

This is sort of just how determining page numbers works when there are multiple pages on the screen though. Even with the workaround for first/last if you can fit say 4+ pages on screen at once then you'd probably get something where you can't have the number show the second-to-last page number.

Comment 3

[Sam Foster [:sfoster] (he/him)]

Yeah when you click the "end" button, we send a "Printing:Preview:Navigate" message with pageNum: {sheetCount} and preemptively update the paginator with the current value (sheetCount), but when we get the preview update from the platform side, the number we get back in this case is whatever sheet is at the middle of the viewport, e.g. sheetCount - 1.

So we could fix this either on the front-end or the platform side. I'm inclined to fix it in the front-end as we have more context there - we know what the user just clicked and can better determine what the expected "current" sheet/page is.