433284 - Print selection inside overflow:hidden div causes same text to be repeated on every page

Status: VERIFIED FIXED

(Core :: Printing: Output, defect)

Description

[Thomas Rutter]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008050806 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008050806 Minefield/3.0pre

Printing a selection from the linked URL causes the first page of text to be printed on all four pages, and the rest of the text is omitted.

All four pages printed are identical (apart from the page number on the bottom left) and contain the first 1/4 of text.

This cannot be reproduced in 'Print Preview' because as far as I know Print Preview does not support Print : Selection (a separate issue).

Reproducible: Always

Steps to Reproduce:
1. Go to the supplied URL (http://www.visionaustralia.org.au/info.aspx?page=1653&event=48)
2. Highlight all of the main text from top top heading to the email address at the bottom
3. Go to Print, and select "Selection" and print it.
Actual Results:  
Four pages are printed, all identical except for the page number, and all containing the first one quarter of the text selected.  The rest of the selected text is not printed.

Expected Results:  
All selected text should be printed and none should be repeated.  

Printing a selection really needs to be reliable as there is no way to preview it before printing.

Comment 1

[Thomas Rutter]

Attachment: Illustration of bug (result captured using a PDF printer driver)

Comment 2

[Mats Palmgren (inactive)]

Confirmed, Firefox 2008051009 on Linux.

Comment 3

[Daniel Holbert [:dholbert]]

FWIW, a regression range will be probably be hard/impossible to track down, due to bug 428339.  (up until 4/22ish, print-selection output was limited to 1 page)

Comment 4

[Daniel Holbert [:dholbert]]

Firefox 2.0.0.14 / Linux gives me expected output.  So, this is a regression. ( --> adding keyword)

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

This bug is due to the fact that all of the content is in an overflow:hidden div.

This simple testcase reproduces the bug in FF3 (currently using 2008050904 nightly).  FF2 gives the correct output.

Comment 6

[Daniel Holbert [:dholbert]]

NOTE: In both FF3 and FF2, normal printing (not print selection) will clip "overflow:hidden" divs to 1 page.   (e.g. testcase 1 gets clipped to 1 page when printed normally)  There's already a bug filed on that, though it's not high-priority because it's not a regression.

That's a separate bug, and it shouldn't stop us from doing print-selection correctly, since print-selection uses the "toilet-paper" printing model. (render to one long page, and then slice up that page.)

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: trivial patch

Easy fix -- after we print each page, we shift the long page-content frame's position to prepare for the next page.  So, since we're tweaking frame position, we need to reposition its child views.

(very similar to patch for bug 430878)

This patch fixes testcase 1.

The patch reveals a follow-up issue on the original URL, though -- while there's no repeated content anymore, it looks like the content is shifted up too high on pages beyond the first, and is clipped too early on all pages.

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to comment #7)
> The patch reveals a follow-up issue on the original URL, though -- while
> there's no repeated content anymore, it looks like the content is shifted up
> too high on pages beyond the first, and is clipped too early on all pages.

This follow-up issue is bug 433373.

Comment 9

[Daniel Holbert [:dholbert]]

Comment on attachment 320573 [details] [diff] [review]
trivial patch

requesting review -- see comment 7 for patch explanation.

Comment 10

[Daniel Holbert [:dholbert]]

(In reply to comment #8)
> (In reply to comment #7)
> > The patch reveals a follow-up issue on the original URL, though...
> This follow-up issue is bug 433373.

...and the patch on that bug (attachment 320591 [details] [diff] [review]) does indeed fix the remaining issues on this bug's supplied URL. (I just tested it.)

Comment 11

[Daniel Holbert [:dholbert]]

Requesting wanted-1.9.0.x, as this is a significantly broken print-selection
regression with respect to FF2.  (with an easy & safe fix)

Comment 12

[Daniel Holbert [:dholbert]]

(In reply to comment #11)

(Changing 'wanted' request to blocking1.9.0.1, now that that flag's available.)

Comment 13

[Damon Sicore (:damons)]

Yep, let's get this into 1.9.0.1.  blocking1.9.0.1+=damons

Comment 14

[Daniel Holbert [:dholbert]]

Comment on attachment 320573 [details] [diff] [review]
trivial patch

Requesting approval for inclusion in 1.9.0.1 (see justification in comment 11)

Sadly, we don't have a way to make automated tests for print-selection yet (that's bug 428037), so this patch doesn't include tests.

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 320573 [details] [diff] [review]
trivial patch

a=beltzner

Comment 16

[Daniel Holbert [:dholbert]]

Checked in to mozilla-central.
Changeset 0608490c13d5
http://hg.mozilla.org/mozilla-central/index.cgi/rev/0608490c13d5

Comment 17

[Daniel Holbert [:dholbert]]

Checked in to 1.9.0.x CVS branch.
Checking in nsSimplePageSequence.cpp;
/cvsroot/mozilla/layout/generic/nsSimplePageSequence.cpp,v  <--  nsSimplePageSequence.cpp
new revision: 3.173; previous revision: 3.172
done

Comment 18

[Mike Beltzner [:beltzner, not reading bugmail]]

Is this fixed on CVS? If so, please mark it fixed1.9.0.1 so QA knows to look at it.

Comment 19

[Daniel Holbert [:dholbert]]

(In reply to comment #18)
> Is this fixed on CVS? If so, please mark it fixed1.9.0.1 so QA knows to look at
> it.

Yup -- done.  Thanks for the heads-up.

Comment 20

[Hasham]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1

Verified on 1.9.0.1. Prints normally based on STR in comment 0.

Comment 21

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

Verified with the following builds and STR in comment 0:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008071203 Minefield/3.1a1pre ID:2008071203

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a1pre) Gecko/2008071202 Minefield/3.1a1pre ID:2008071202

Due to the patch was also checked-in to mozilla-central the TM should be 1.9.1a1.