Have seen failure now printing a mail message from Mac and Windows, and printing from browser in Windows. Did a simple test case with just one digit in each line of text that was unique for a total of 5 pages. Each time the text needs to go to a new page a line of text is lost. Was also able to reproduce in a more complex example. Using today's branch commercial build on Mac.

Seen on 2001-07-20-06-0.9.2 win32 build. Open the attached file in the browser and print (portrait). You will see the line drop off.

I see this behavior on W2k build 2001-07-20-06-0.9.2

confirmig this with one of the latest 0.9.2 branch pulls, 07-20-2001

adding dataloss

Seen on windows 98 (branch build: 2001-07-20-06-0.9.2)

for 7/19 branch builds on win2k/macos9.0/linux-redhat6.1, I drop a line at each new page for the test case.

PDT+, looking for a cause & a fix. If you can help out, please do!

Any progress?

dcone has two critical bugs for shipping n6.1. this one and the linux print crash bug. we should figure out a plan to get some help.

adding dbaron to cc: list. he's got some modified pagination code that may or may not address this but he won't be available to look at it until after 10am PST on Monday 7/23

ignore the patches, sorry, wrong bug

I have been looking at the bug, basically this layout the correct size, the movement of the page is off by a line, or clipped. I will continue to look at this.

confirming on win 98 w/ 7/23 branch build.. yes I see the dropped lines... I should add this to the printing testcase library.

We're holding for this bug and hoping to have final builds 7/24 AM. No pressure :-)

Is this a recent regression? Does anyone know when it started happening?

I am looking for that now..I do know that it worked fine in May so it is a regression.

I stuck in some frame tree dumps after each reflow. There are three reflows: an InitialReflow call from DocumentViewerImpl::Print a second InitialReflow call from DocumentViewerImpl::ReflowPrintObject a StyleChangedReflow call from DocumentViewerImpl::ReflowPrintObject After the third one the frame tree is missing the first line on each continuation page. This third reflow call was added (according to the comment before it) to fix bug 84017. It is causing us to hit the big while loop at the end of nsBlockFrame::ReflowDirtyLines that I thought was unused code and that I had removed from my tree in some block changes I'm working on. It probably was unused code before the patch for bug 84017.

This is the bug.. if I take out that StyleChangedReflow.. the line will print. The problem is.. that text fields will not print because a reflow is needed for the history. I am trying a resize reflow.. see if thats anybetter.

I can't reproduce bug 84017 even with that patch backed out. What does the history have to do with it?

waterson says adding a DrainOverflowLines to the style changed reflow case fixes this bug. That suggests that switching to a resize reflow would fix this.

This patch uses a resize reflow.. the lines no longer disapear.. and I tested with 84017 and the text in a field will draw. We use the history object to update the content.. which will not get update unless we reflow.

Heh, I was about to try this, too. r/sr=waterson.

FWIW, a style-change reflow should probably cause the block code to DrainOverflowLines(), too. (Although we'd never hit this unless we end up doing style-changes in a paginated context...)

[s]r=attinasi

Checked into the trunk, waiting for PDT OK for the branch.

Please check this into the branch. I'll give the OK for PDT :-) Sujay - pls be sure to run some of the printing tests you have on the next build with this fix. Thanks.

bonsai says this is checked in. Thanks!!!

Checked in to the branch. Thanks Chris and David for the help finding where the problem was..

verified on 7/24 branch build on windows Also verified bug 84017(data in text fields causes grey page). that works fine also... I will test printing some more later this morning.. Feel free to throw bug numbers at me of other bugs this fix might have impacted.

verified on Mac /24 branch build. tested this bug fix along with 84017 also. also did further basic functionality testing on windows 7/24 branch build. adding vtrunk keyword to make sure we verify this on trunk later.

verified on 8/1 trunk build. removing vtrunk keyword.