Open Bug 659715 Opened 11 years ago Updated 8 months ago

Consider preserving scroll position of iframes & other scrolled regions when printing

Categories

(Core :: Printing: Output, defect, P3)

defect

Tracking

()

People

(Reporter: dholbert, Unassigned)

References

()

Details

(Keywords: parity-chrome, Whiteboard: [print2020])

Attachments

(1 file)

STEPS TO REPRODUCE:
 1. Load http://manda.com/iframe/index.html
        (or any other page with scrollable iframe)
 2. Scroll the first iframe (yahoo) down and/or to the right.
 3. Print-preview.

ACTUAL RESULTS: Print preview has the iframe in its initial scroll state (scrolled to the top-left).

Perhaps we should preserve the scroll state of iframes (and "overflow:scroll" type content), so that printed output more directly matches what the user saw on the screen when initiating the 'print' action..
OS: Linux → All
Hardware: x86_64 → All
Keeping the scroll position makes sense. 

Btw, did we preserve scroll position in Fx3.6?
(In reply to comment #1)
> Btw, did we preserve scroll position in Fx3.6?

Nope, we didn't.  The STR here produce the same results for me in my 3.6 nightly as in my trunk nightly.

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18pre) Gecko/20110503 Namoroka/3.6.18pre
This is what Chrome currently does.
Whiteboard: [parity-chrome]
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome
Whiteboard: [parity-chrome]
Duplicate of this bug: 1660921
Whiteboard: [print2020_v83]

While keeping an eye on the recent print related questions on SUMO, this bug came up: https://support.mozilla.org/en-US/questions/1306114

Severity: normal → S3
Priority: -- → P3
Whiteboard: [print2020_v83] → [print2020_v85]
Whiteboard: [print2020_v85] → [print2020_v88]
Duplicate of this bug: 1676870
Whiteboard: [print2020_v88] → [print2020]
You need to log in before you can comment on or make changes to this bug.