1660502 - Give nsIWebBrowserPrint an attribute to represent the total number of pages (without discounts for pages-per-sheet/page-range)

Status: RESOLVED FIXED

(Core :: Printing: Output, task)

Description

[Daniel Holbert [:dholbert]]

nsIWebBrowserPrint has some page-number/page-count related attributes which actually return the number/count of printed sheets. This is mostly fine, for two reasons:

• For now, the number of pages and the number of sheets are the same (though our new platform support for page ranges [in bug 1659005] and for pages per sheet [in bug 1631452] will decouple those values, so this is going to change)[1]
• In most cases, the number of printed sheets (the quantity that the APIs return) is indeed what the frontend code wants.

But there's at least one scenario where the frontend code needs the real "raw" page count: the code to select & validate page ranges. If there's a 40-page document, we need to validate that the selected page range is a subset of 1-40, regardless of what the pages-per-sheet ratio is & regardless of whether the user has a current page range selection that happens to only be 2 pages long.

So: in this bug I'm adding a new API that returns the "raw" number of pages, that we can use for this purpose.

[1] (e.g. if the user selects "from:4; to:6" as a page range, the print operation's number of printed sheets will be 3, even though the document's "raw" number of pages is probably larger. Or: if the user selects 3 pages per sheet, then the number of sheets will be roughly 1/3 the "true" number of pages.)

Comment 1

[Daniel Holbert [:dholbert]]

Ideally we would also rename all of the existing APIs (and all the variables that deal with their values, etc) to use the term "sheets" instead of "pages".

I started looking into doing that, but that's a pretty large change; it should be non-functional, but there's a decent amount of room for human error since there's a lot of code that needs hand adjusting. (And I'm also not confident I understand or caught all of the frontend pieces.)

So for now, I'm leaving the existing APIs in-place (with a XXXdholbert comments clarifying that they return sheet count, added in https://hg.mozilla.org/mozilla-central/rev/b13b671dfec9 ); and I'm going to call this new API "rawNumPages" (where "raw" = "unprocessed by page-ranges/pages-per-sheet").

And we can distinguish variables/etc. using the same "raw" terminology for things that do really want this version.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: Bug 1660502 part 1: Give nsIWebBrowserPrint a "rawNumPages" attribute. r?TYLin

This is backed by an existing nsPageSequenceFrame API, which this patch also
renames to use the word "Raw" for consistency across the full callstack.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: Bug 1660502 part 2: Rename nsSharedPageData::mTotNumPages to mRawNumPages, for consistency. r?TYLin

Depends on D87886

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b4483df28731
part 1: Give nsIWebBrowserPrint a "rawNumPages" attribute. r=TYLin
https://hg.mozilla.org/integration/autoland/rev/ef8a093c01aa
part 2: Rename nsSharedPageData::mTotNumPages to mRawNumPages, for consistency. r=TYLin

Comment 5

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/b4483df28731
https://hg.mozilla.org/mozilla-central/rev/ef8a093c01aa

Comment 6

[Jonathan Watt [:jwatt]]

Reminder to request beta uplift.

Comment 7

[Daniel Holbert [:dholbert]]

Comment on attachment 9171435 [details]
Bug 1660502 part 1: Give nsIWebBrowserPrint a "rawNumPages" attribute. r?TYLin

Beta/Release Uplift Approval Request

• User impact if declined: The "Page Range" feature (i.e. "only print pages 3-5") won't work, in the print preview portion of the new print redesign (bug 133787). For that to work, we need this bug & bug 1659005 & bug 1660908.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This bug just adds a chrome-only API (currently with no users of that API). There are no user-facing changes and no behavior changes.
• String changes made/needed: None

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9171435 [details]
Bug 1660502 part 1: Give nsIWebBrowserPrint a "rawNumPages" attribute. r?TYLin

Approved for 81.0b2.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/0d3326810464
https://hg.mozilla.org/releases/mozilla-beta/rev/b3c6a1a79679