Closed Bug 1660166 Opened 4 years ago Closed 4 years ago

Clean up determination of page numbers

Categories

(Core :: Printing: Output, task)

Product:
Core
Component:
Printing: Output
Type:
task

Tracking

()

Status:
RESOLVED FIXED
Milestone:
81 Branch
Tracking Flags:
Tracking Status
firefox81 --- fixed

People

(Reporter: dholbert, Assigned: dholbert)

References

Details

Attachments

(4 files)

Bug 1660166 part 1: In PrintedSheetFrame's reflow loop, cast the child frame to nsPageFrame (which is the concrete type that we know it has). r?hiro
(deleted), text/x-phabricator-request
Details
Bug 1660166 part 2: Let nsPageFrame determine its own page number, and store total number of pages in one central spot. r?hiro
(deleted), text/x-phabricator-request
Details
Bug 1660166 part 3: Remove a redundant member-variable that represents the total number of pages. r?hiro
(deleted), text/x-phabricator-request
Details
Bug 1660166 followup: Mark nsPageFrame::GetPageNum as 'const'. r?hiro
(deleted), text/x-phabricator-request
Details

We use a somewhat clumsy mechanism for computing & handling page numbers and the page-count.

In support of bug 1631452 and bug 1659005, let's clean that up a bit.

We already do this static_cast'ing before this patch, for a single
nsPageFrame-specific method call. This patch just captures the result of that
static_cast in a reusable variable, so that I can easily add another
nsPageFrame-specific function call in the next patch of this patch series.

(We can be confident this casting is valid, because we only ever give
PrintedSheetFrame this one type of child frame.)

(Two more patches coming, in phabricator processing limbo right now)

These patches don't represent any functional changes, given the current state of our tree. They should not impact behavior at this point.

They are meant to simplify code & prevent bugs that would crop up once we have more than one nsPageFrame on a given PrintedSheetFrame, which I intend to support in bug 1631452 and bug 1659005. Once we have multiple nsPageFrames per PrintedSheetFrame, we cannot simply count the pages by counting the number of nsPageSequenceFrame child-frames anymore, since strictly speaking that gives us the number of sheets.

In particular, they prevent us from reporting e.g. "Page 7 of 3" on page footers (where "3" is mistakenly a sheet count rather than a page count).

Before this patch stack, nsPageSequenceFrame and every nsPageFrame each
individually tracked the number of pages.

As of the previous patch, we've coalesced the nsPageFrame variables into a
single variable that lives on nsSharedPageData. This patch here replaces
nsPageSequenceFrame's member-var with that nsSharedPageData variable, too.

Depends on D87696

I am going to land these patches once after I've confirmed it's ok on a try run.

Thank you!!

Pushed by hikezoe.birchill@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/5fe1dd9f3bad part 1: In PrintedSheetFrame's reflow loop, cast the child frame to nsPageFrame (which is the concrete type that we know it has). r=hiro https://hg.mozilla.org/integration/autoland/rev/d64d22e30483 part 2: Let nsPageFrame determine its own page number, and store total number of pages in one central spot. r=hiro https://hg.mozilla.org/integration/autoland/rev/c3fe601df6e1 part 3: Remove a redundant member-variable that represents the total number of pages. r=hiro
Pushed by dholbert@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/00693a176876 followup: Mark nsPageFrame::GetPageNum as 'const'. r=TYLin

https://hg.mozilla.org/mozilla-central/rev/5fe1dd9f3bad
https://hg.mozilla.org/mozilla-central/rev/d64d22e30483
https://hg.mozilla.org/mozilla-central/rev/c3fe601df6e1

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
status-firefox81: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 81 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: