Closed Bug 1657550 Opened 4 years ago Closed 4 years ago

nsDocumentViewer::PrintPreviewScrollToPage is broken

Categories

(Core :: Print Preview, defect, P2)

defect

Tracking

()

RESOLVED FIXED
81 Branch
Tracking Status
firefox81 --- fixed

People

(Reporter: hiro, Assigned: hiro)

References

(Blocks 1 open bug)

Details

(Whiteboard: [print2020_v81])

Attachments

(6 files)

The function uses BaseRect::Contains to tell which printed sheet frame is including the current scroll position, but there are gaps between each sheet frame in the print preview content, so if the scroll position is in one of the gaps, it fails.

Also since bug 1651947, the content is scaled, we need to factor the scale value there.

I suppose this should block bug 1631440.

Are you able to take this, hiro?

Flags: needinfo?(hikezoe.birchill)

Yep, I will figure out a reasonable way to scroll a given position once after we agreed on bug 1657763.

Assignee: nobody → hikezoe.birchill
Status: NEW → ASSIGNED
Flags: needinfo?(hikezoe.birchill)
See Also: → 1657763
Whiteboard: [print2020_v81]
Priority: -- → P2

As discussed in #print Matrix, we should keep the old behavior for the old print preview UI, so I am going to copy the current behavior and use it if print.tab_modal.enabled is false.

So that we can keep using the logic in the old print preview UI.

For the new print preview UI, the original PrintPreviewScrollToPage will be
modified gradually in subsequent changes.

I suppose PRINTPREVIEW_END doesn't mean the last page.

Depends on D87543

That's what we've done for PRINTPREVIEW_PREV_PAGE, PRINTPREVIEW_NEXT_PAGE
and PRINTPREVIEW_GOTO_PAGENUM.

Depends on D87544

We have to use the logic in the function for
nsDocumentViewer::PrintPreviewScrollToPage in subsequent changes.

Depends on D87545

We need the current sheet frame for PRINTPREVIEW_NEXT_PAGE and
PRINTPREVIEW_PREV_PAGE cases.

Depends on D87546

This change consists of;

  1. Use switch statement for the given PrintPreview Navigation type.

  2. Simply iterate over the children of nsPageSequenceFrame for
    PRINTPREVIEW_GOTO_PAGENUM

  3. Use GetCurrentSheetFrameAndPageNumber for PRINTPREVIEW_PREV_PAGE and
    PRINTPREVIEW_NEXT_PAGE so that it should now match
    printPreviewCurrentPageNumber
    (that means the edge case where the current scroll position is in
    the gap between pages has been fixed by this change)

  4. Scroll to the position where the target frame is positioned at the center of
    the print preview scroll port in the cases of PRINTPREVIEW_PREV_PAGE,
    PRINTPREVIEW_NEXT_PAGE and PRINTPREVIEW_GOTO_PAGENUM

  5. is a bit debatable but it can be now easily modified by changing
    ComputeScrollPositionFrameAtCenter later if it turns out the current way is not
    reasonable.

Depends on D87547

Pushed by hikezoe.birchill@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4d7aa93b9b82
Copy nsDocumentViewer::PrintPreviewScrollToPage for the old print preview UI. r=emilio
https://hg.mozilla.org/integration/autoland/rev/07766c2a11d0
Use `scrollTopMax` position for PRINTPREVIEW_END. r=emilio
https://hg.mozilla.org/integration/autoland/rev/1a7fb3e1e8e8
Preserve x-axis scroll position on printPreviewScrollToPage call in any cases. r=emilio
https://hg.mozilla.org/integration/autoland/rev/364e2943979b
Factor out the function to get the current page number in the print preview. r=emilio
https://hg.mozilla.org/integration/autoland/rev/b818ca5a2fed
Make GetCurrentPageNumberInPrintPreview return the current sheet frame along with the current page. r=emilio
https://hg.mozilla.org/integration/autoland/rev/1b228ca5d679
Rewrite nsDocumentViewer::PrintPreviewScrollToPage. r=emilio
Regressions: 1660213
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: