Here's how to reproduce: Go to http://forums.compuserve.com/vlforums/default.asp?SRV=Literary In the page you get re-directed to click on "Be Our Guest" button Click on a "Message Board" on the left hand side Now, you'll be on a page with a couple of frames Click on a "Topic" on the left frame - Another frame should get displayed Click on the Print toolbar button - Bottom left pane does not get printed at all

The problem is Frames and IFrame are being reflowed to 5 pages in height to ensure they "looked" clipped. If I comment out the line of code it works but there is now some extra white-space at the bottom of the frame. Patch: Index: nsDocumentViewer.cpp =================================================================== RCS file: /cvsroot/mozilla/content/base/src/nsDocumentViewer.cpp,v retrieving revision 1.147 diff -u -r1.147 nsDocumentViewer.cpp --- nsDocumentViewer.cpp 2001/09/20 12:13:48 1.147 +++ nsDocumentViewer.cpp 2001/09/20 19:16:39 @@ -2849,7 +2849,7 @@ } else if (mPrt->mPrintFrameType == nsIPrintOptions::kFramesAsIs) { if (aPO->mFrameType == eFrame || aPO->mFrameType == eIFrame) { - height = pageHeight*kHundredPagesHigh; + //height = pageHeight*kHundredPagesHigh; adjRect.SetRect(aPO->mRect.x != 0?margin.left:0, aPO->mRect.y != 0?margin .top:0, width, height); }

Here is the other part of the patch: Index: nsSimplePageSequence.cpp =================================================================== RCS file: /cvsroot/mozilla/layout/html/base/src/nsSimplePageSequence.cpp,v retrieving revision 3.47 diff -u -r3.47 nsSimplePageSequence.cpp --- nsSimplePageSequence.cpp 2001/07/25 07:52:15 3.47 +++ nsSimplePageSequence.cpp 2001/09/21 19:25:46 @@ -307,6 +307,13 @@ pageSize.height = 0x0FFFFFFF; } + // *** Special Override *** + // if this Document is in the upper left hand corner + // we need to suppress the top margin or it will reflow too small + if (adjSize.x == 0 && adjSize.y == 0) { + suppressTopMargin = PR_TRUE; + } + // only use this local margin for sizing, // not for positioning nsMargin margin(suppressLeftMargin?0:mMargin.left,

Here is what happened: When I originally wrote the code I didn't realize that sub-docs printing at 0,0 were not suppressing the top margin and therefore were reflowing too small. I add the hack for setting the pages to be a large value to compensate for this, thinking that is just what needed to be done. But this didn't work in all cases which is why we got this bug. So the fix is to remove the "5 page height" hack and then have a special case for when we are printing a page at 0,0 when isn't the entire page height and width.

Comment on attachment 50301 [details] [diff] [review] final patch sr=attinasi - I'm glad you figured it out!

Comment on attachment 50301 [details] [diff] [review] final patch r=kmcclusk@netscape.com

I have done a lot of testing of this, it only happens when printing "AsIs" with framesets and iframes. It also only effects the top frame that is positioned at 0,0. Low to medium risk, if I didn't catch something it means the top frame will print smaller than it should.

Updated status

ok, lets get this in. a=chofmann

fixed and checked in on branch and tip

I'll verify this in 9/26 build.

When printing with "As Laid out on the screen option" it prints fine..I get all the frames But, when selecting "Each Frame separately", it takes forever to get the print job to come out. I had to Cancel the print job... Rod, any ideas whats going on here?

even after trying to cancel the print job, the print manager doesn't go away. looks like trying to print each frame separately is exhausting this particular print job. I'm gonna reboot and try again.

ok this time I waited for the print job to coem out. it eventually came out and there's definitely a problem when chosing "print each frame separately" for this page(follow Rod's instructions going to that particular page). I don't get all the content for each frame..Instead I just get buttons and icons for each frame printed... AsIs option works fine. REOPENING I'm using 9/26 branch build.

okay I tried again and this time the print job never came out(print manager still alive) but I noticed something: The prior time I had all 3 radio buttons available to me to select. I chose print each frame separately. the print job came out eventually. But when I had only 2 radio buttons available(AsIs and Print each frame Sep.) then the print job never came out.

works for Rods.....moving to FIXED..I need to try on another NT system with more memory and fast machine. if it works there, then I will open a separate bug.

verified in 9/27 branch build. however on my Win98 laptop it takes forever to print and the output is not correct....memory problems I think. I will reopen a new bug for that. also I will remember to verify this bug on the trunk.

verified on 10/31 trunk build also.

Tested with 11_14_22_0.9.4ec branch build onWin2000. Could not reproduce this bug. Printed 'As laid out on the screen' with no problem; printed 'Each frame separately' (10 of them) with no problem and no extended waiting time.

Tested with 11_14_22_0.9.4ec branch build onWin98. Printed 'As laid out on the screen' with no problem. However, with the 'Each frame separately' (10 of them), all frames did not print out completely.

Sujay - is this really fixed on the trunk? Your 9/27 comments say: however on my Win98 laptop it takes forever to print and the output is not correct....memory problems I think. Do these comments apply to the branch and the trunk?

is this fixed verified on the trunk? if that's the case then we should make it 0.9.4+, if not could somebody verify it on the trunk?

verified on 11/29 trunk build using Windows

adding + to edt0.9.4

Tested with 11_29_09_trunk on Win98. Printing frames separately causes app to crash on Win98. Need to see if this is written up separately in another bug.

Retested on same 11_20_09_trunk build on Win98. Now, the app doesn't crash but I can only print 6 frames. It looks like it will either crash or print out less than the full number of frames when the 'Each Frame Separately' option is selected. Reopening again.

Not printing all of the frames might be fixed by recent table checkins on the trunk.

Karnaze: I tested usingthe 11/29 trunk - are the table changes you mention after that date?

I was referring to comment #26. The last table changes went in 2001/11/29 15:41:07. They wouldn't fix the crash you are reporting, but might help the other problem.

looks like this is REOPEN...lemme know what action I need to take..

removing plus for now. looks too risky.

From: http://bugscape.netscape.com/show_bug.cgi?id=8511

minusing this for edt0.9.4. taking this at this point is too risky.

Can we set the target milestone to mozilla0.9.7 or above ? (Please have a look at www.MozillaQuest.com . I think its not good for the image of moz.)

Could someone please retarget this to another milestone? Mozilla 0.9.5 is long gone.

This is fixed on the trunk. Closing bug WFM.

verified.

verified.