243842 - Print selection print only the first page

Status: RESOLVED DUPLICATE of bug 428339

(Core :: Printing: Output, defect)

Description

[J.L Gascon]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.7b) Gecko/20040421
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.7b) Gecko/20040421

Priting a selection with more a one page only print the first page.
This bug is related with the 68142 bug.

Reproducible: Always
Steps to Reproduce:
Take the attachment for example 

1. Select all or select with the mouse
2. File >> Print >> Selection 
3. Print

Actual Results:  
The actual result is that the first page is printed.

Expected Results:  
It should be printed all pages.

Comment 1

[J.L Gascon]

Attachment: Attachment for the test case.

Comment 2

[Boris Zbarsky [:bzbarsky]]

OK, so here's the story.  This worked after bug 153964  was checked in.  Then it
broke in November 2002 (between 2002-11-21-21 and 2002-11-22-21 builds, to be
exact).

The most likely culprit there is bug 181228.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Verified via local backout that the culprit here is bug 181228.

Basically, it looks like our aEndFrame is being clobbered by whatever the last
frame in the last childlist is.  This page has a floating image, so we end up
with the image as the last frame.

In my opinion, this code is just totally bogus.  As a stopgap measure, we can
probably bail once the start frame is null, but this code probably breaks in all
sorts of ways on selections that, say, have one end in an in-flow child and the
other end in a float... :(

Is there a reason we aren't just using the primary frames of the anchor nodes of
the DOM selection range?

Comment 4

[Boris Zbarsky [:bzbarsky]]

OK, I know why.  We don't actually care about the first and last _frame_.  We
care about the first and last _page_ that the selection spans into.  The 
"right" way to do this (which may be expensive!) is to walk everything looking
for selected frames and for each one look up the page involved....

Alternately, we could do a walk over the in-flow frames as we do now, and then
do a second walk, over all frames, looking up the page only for out-of-flow
frames or their descendants (though if everything is in an absolutely positioned
div as is the fad nowadays, that's just as bad).

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Why do we care at all about how expensive printing the selection is? As long as
it's not O(n^2) in the size of the selection or whatever...

Comment 6

[Boris Zbarsky [:bzbarsky]]

I think the algorithm proposed in comment 4 paragraph 1 is O(N*M) where N is the
size of the page and M is the average nesting depth of the selection (since
nsLayoutUtils::GetPageFrame is O(M)).

That may be acceptable, indeed.  Thoughts on doing it that way?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Also for any given selected frame we can determine the right page, but then we
have to determine whether that comes before our first page thus far or after our
last page thus far.  I guess we can use the fact that the pages are all kids of
the same parent and just compare their coords against each other....

Comment 8

[Robert Parenton]

*** Bug 203287 has been marked as a duplicate of this bug. ***

Comment 9

[Wayne Mery (:wsmwk)]

*** Bug 299029 has been marked as a duplicate of this bug. ***

Comment 10

[Wayne Mery (:wsmwk)]

*** Bug 219391 has been marked as a duplicate of this bug. ***

Comment 11

[Wayne Mery (:wsmwk)]

Deer Park Alpha 2 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4)
Gecko/20050715 Firefox/1.0+

test case from comment 1 no longer fails.

But URL from bug 219391 fails by printing only 2 pages
http://www.theage.com.au/articles/2003/09/12/1063341758375.html

Comment 12

[Mike Williams]

(In reply to comment #11)
Only prints one page for this link: http://www.diabetesnet.com/diabetes_technology/insulin_pump_models.php (Mozilla 1.7.12 and Seamonkey 1.0)

Comment 13

[Boris Zbarsky [:bzbarsky]]

Comment 12 is not related to this bug -- that page has all the content in an absolutely positioned div.  That is, the problem there happens independently of the "print selection" issue this bug is about.

Comment 14

[brazz]

Hello.
I just downloaded Namoroka 3.6 for testing. Bravo to the improved speed. However, in this version, as in the current 3.5.4, there is always an annoying bug: printing a web page results in a lot of cases by only printing the first page, but this is not general. Thus, for example, of course, http://www.mozilla.org/projects/firefox/3.6a1/releasenotes/ print well:) but http://www.clubic.com/actualite-293072-mozilla- firefox-3-6-alpha.html is truncated when printed. This does not happen if I use a competing browser, such as Opera.

Comment 19

[:Hb]

Recent work on this issue has been done in bug 433373, bug 425094 and in bug
428339.  Meta for regression between FF2 and FF3 is bug 431588. 

This report is over five years old and all mentioned products have passed away
so duplicate of the current bug in this case.