92215 - [Table Printing] Mozilla crashes when printing the front page of slashdot - N610 & Trunk [@ nsLineLayout::ReflowFrame][@ 0x00000000 - nsFrameList::DestroyFrames]

Status: VERIFIED FIXED

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

Description

[Shao Zhang]

Go to http://slashdot.org
File -> print, choose print to file,
Mozilla will crash after hitting the print button

I don't have strace installed here, so cannot give you a stack trace. Produced
using the fresh cvs build 2001072510 on FreeBSD 4.2
I also see this problem with older nightlies as well.

Comment 1

[Erich 'Ricky' Iseli]

I just sent in a lot of talkback data. A crash happens always, no matter if the
page is local or on the web, no matter what the content of the page is. Even a
minimal html page (without DOCTYPE) produced this crash. Always reproducible. I
tried this with build 2001-07-25-03. Going to attach my minimal testcase. By the
way, crash also occurs on http://bugzilla.mozilla.org when trying to print this
page.

Comment 2

[Erich 'Ricky' Iseli]

Attachment: Minimal testcase

Comment 3

[Erich 'Ricky' Iseli]

Happened on Win98, so setting all/all. Also, since this is a major loss of
functionality, setting the severity accordingly.

Comment 4

[sujay]

is it possible this bug is a DUP of 92325 ?

Comment 5

[dcone (gone)]

This may be because of 92325.. all printing crashes because of that one.  I will 
keep on eye on this.. when that blocker is fixed.. I or we can check this one.

Comment 6

[Erich 'Ricky' Iseli]

I for one would say it is a dupe of bug 92325, however I don't know if the
slashdot page doesn't show another error. When I was looking for bugs, I never
would have found the printing bug 92325 because it was recorded under
browser/layout...

Comment 7

[dcone (gone)]

StackTrace suggests that the table is not cleaning up correctly.
Adding the [Table Printing] comment so I can help out sometime with 
these issues.

nsFrameList::DestroyFrames(nsIPresContext * 0x04bb2e20) line 114 + 13 bytes
nsBlockFrame::Destroy(nsBlockFrame * const 0x0488ddb8, nsIPresContext * 
0x04bb2e20) line 311
nsContainerFrame::DeleteChildsNextInFlow(nsIPresContext * 0x04bb2e20, nsIFrame * 
0x0488d6dc) line 926
nsContainerFrame::DeleteChildsNextInFlow(nsIPresContext * 0x04bb2e20, nsIFrame * 
0x0488cf98) line 896
nsContainerFrame::DeleteChildsNextInFlow(nsIPresContext * 0x04bb2e20, nsIFrame * 
0x04852244) line 896
nsContainerFrame::ReflowChild(nsIFrame * 0x04852244, nsIPresContext * 
0x04bb2e20, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, 
int 0, unsigned int 0, unsigned int & 0) line 763
nsTableCellFrame::Reflow(nsTableCellFrame * const 0x048521e8, nsIPresContext * 
0x04bb2e20, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, 
unsigned int & 0) line 771
nsContainerFrame::ReflowChild(nsIFrame * 0x048521e8, nsIPresContext * 
0x04bb2e20, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 
1260, int 0, unsigned int 0, unsigned int & 0) line 727 + 31 bytes
nsTableRowFrame::ReflowChildren(nsTableRowFrame * const 0x0484c8b0, 
nsIPresContext * 0x04bb2e20, nsHTMLReflowMetrics & {...}, const 
nsHTMLReflowState & {...}, nsTableFrame & {...}, unsigned int & 0, int 0) line 
877 + 45 bytes
nsTableRowFrame::Reflow(nsTableRowFrame * const 0x0484c8b0, nsIPresContext * 
0x04bb2e20, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, 
unsigned int & 0) line 1243 + 37 bytes
nsContainerFrame::ReflowChild(nsIFrame * 0x0484c8b0, nsIPresContext * 
0x04bb2e20, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, 
int 0, unsigned int 0, unsigned int & 0) line 727 + 31 bytes
nsTableRowGroupFrame::ReflowChildren(nsTableRowGroupFrame * const 0x0484c874, 
nsIPresContext * 0x04bb2e20, nsHTMLReflowMetrics & {...}, nsRowGroupReflowState 
& {...}, unsigned int & 0, nsTableRowFrame * 0x00000000, int 0) line 374 + 45 
bytes
nsTableRowGroupFrame::Reflow(nsTableRowGroupFrame * const 0x0484c874, 
nsIPresContext * 0x04bb2e20, nsHTMLReflowMetrics & {...}, const 
nsHTMLReflowState & {...}, unsigned int & 0) line 1044 + 29 bytes
nsContainerFrame::ReflowChild(nsIFrame * 0x0484c874, nsIPresContext * 
0x04bb2e20, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, 
int 0, unsigned int 0, unsigned int & 0) line 727 + 31 bytes
nsTableFrame::ReflowChildren(nsTableFrame * const 0x0484c80c, nsIPresContext * 
0x04bb2e20, nsTableReflowState & {...}, int 1, int 0, unsigned int & 0, int * 
0x00000000) line 2943 + 47 bytes
nsTableFrame::Reflow(nsTableFrame * const 0x0484c80c, nsIPresContext * 
0x04bb2e20, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, 
unsigned int & 0) line 1862
nsContainerFrame::ReflowChild(nsIFrame * 0x0484c80c, nsIPresContext * 
0x04bb2e20, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 
49, int 0, unsigned int 3, unsigned int & 0) line 727 + 31 bytes
nsTableOuterFrame::OuterReflowChild(nsTableOuterFrame * const 0x0484c27c, 
nsIPresContext * 0x04bb2e20, nsIFrame * 0x0484c80c, const nsHTMLReflowState & 
{...}, nsHTMLReflowMetrics & {...}, int * 0x00000000, nsSize & {...}, nsMargin & 
{...}, nsMargin & {...}, nsMargin & {...}, nsReflowReason eReflowReason_Resize, 
unsigned int & 0) line 969 + 47 bytes
nsTableOuterFrame::Reflow(nsTableOuterFrame * const 0x0484c27c, nsIPresContext * 
0x04bb2e20, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, 
unsigned int & 0) line 1513 + 69 bytes
nsBlockReflowContext::DoReflowBlock(nsHTMLReflowState & {...}, nsReflowReason 
eReflowReason_Resize, nsIFrame * 0x0484c27c, const nsRect & {...}, int 1, int 0, 
int 0, nsMargin & {...}, unsigned int & 0) line 577 + 36 bytes
nsBlockReflowContext::ReflowBlock(nsIFrame * 0x0484c27c, const nsRect & {...}, 
int 1, int 0, int 0, nsMargin & {...}, unsigned int & 0) line 342 + 50 bytes
nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & {...}, nsLineBox * 
0x0487a61c, int * 0x0012ad48) line 2959 + 59 bytes
nsBlockFrame::ReflowLine(nsBlockReflowState & {...}, nsLineBox * 0x0487a61c, int 
* 0x0012ad48, int 0) line 2242 + 23 bytes
nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 2050 + 27 bytes
nsBlockFrame::Reflow(nsBlockFrame * const 0x048494d4, nsIPresContext * 
0x04bb2e20, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, 
unsigned int & 0) line 797 + 15 bytes
nsBlockReflowContext::DoReflowBlock(nsHTMLReflowState & {...}, nsReflowReason 
eReflowReason_Resize, nsIFrame * 0x048494d4, const nsRect & {...}, int 1, int 0, 
int 0, nsMargin & {...}, unsigned int & 0) line 577 + 36 bytes
nsBlockReflowContext::ReflowBlock(nsIFrame * 0x048494d4, const nsRect & {...}, 
int 1, int 0, int 0, nsMargin & {...}, unsigned int & 0) line 342 + 50 bytes
nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & {...}, nsLineBox * 
0x0487b6ac, int * 0x0012b8bc) line 2959 + 59 bytes
nsBlockFrame::ReflowLine(nsBlockReflowState & {...}, nsLineBox * 0x0487b6ac, int 
* 0x0012b8bc, int 0) line 2242 + 23 bytes
nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 2050 + 27 bytes
nsBlockFrame::Reflow(nsBlockFrame * const 0x04848394, nsIPresContext * 
0x04bb2e20, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, 
unsigned int & 0) line 797 + 15 bytes
nsBlockReflowContext::DoReflowBlock(nsHTMLReflowState & {...}, nsReflowReason 
eReflowReason_Resize, nsIFrame * 0x04848394, const nsRect & {...}, int 1, int 0, 
int 1, nsMargin & {...}, unsigned int & 0) line 577 + 36 bytes
nsBlockReflowContext::ReflowBlock(nsIFrame * 0x04848394, const nsRect & {...}, 
int 1, int 0, int 1, nsMargin & {...}, unsigned int & 0) line 342 + 50 bytes
nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & {...}, nsLineBox * 
0x0487b724, int * 0x0012c430) line 2959 + 59 bytes
nsBlockFrame::ReflowLine(nsBlockReflowState & {...}, nsLineBox * 0x0487b724, int 
* 0x0012c430, int 0) line 2242 + 23 bytes
nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 2050 + 27 bytes
nsBlockFrame::Reflow(nsBlockFrame * const 0x04848100, nsIPresContext * 
0x04bb2e20, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, 
unsigned int & 0) line 797 + 15 bytes
nsContainerFrame::ReflowChild(nsIFrame * 0x04848100, nsIPresContext * 
0x04bb2e20, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, 
int 0, unsigned int 0, unsigned int & 0) line 727 + 31 bytes
nsPageFrame::Reflow(nsPageFrame * const 0x04847c8c, nsIPresContext * 0x04bb2e20, 
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) 
line 186
nsContainerFrame::ReflowChild(nsIFrame * 0x04847c8c, nsIPresContext * 
0x04bb2e20, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 
720, int 720, unsigned int 0, unsigned int & 0) line 727 + 31 bytes
nsSimplePageSequenceFrame::Reflow(nsSimplePageSequenceFrame * const 0x04847b34, 
nsIPresContext * 0x04bb2e20, nsHTMLReflowMetrics & {...}, const 
nsHTMLReflowState & {...}, unsigned int & 0) line 346
nsContainerFrame::ReflowChild(nsIFrame * 0x04847b34, nsIPresContext * 
0x04bb2e20, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, 
int 0, unsigned int 0, unsigned int & 0) line 727 + 31 bytes
ViewportFrame::Reflow(ViewportFrame * const 0x04847af8, nsIPresContext * 
0x04bb2e20, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, 
unsigned int & 0) line 538
PresShell::ResizeReflow(PresShell * const 0x04bb2500, int 11520, int 15206) line 
2802
DocumentViewerImpl::ReflowPrintObject(PrintObject * 0x03c0af80) line 2921
DocumentViewerImpl::ReflowDocList(PrintObject * 0x03c0af80) line 2697 + 12 bytes
DocumentViewerImpl::SetupToPrintContent(nsIWebShell * 0x0371c794, 
nsIDeviceContext * 0x03c2d8d0, nsIDOMWindowInternal * 0x00000000) line 3216 + 24 
bytes
DocumentViewerImpl::DocumentReadyForPrinting() line 3991 + 42 bytes
DocumentViewerImpl::Print(DocumentViewerImpl * const 0x041dccd8, int 0, _iobuf * 
0x00000000, nsIPrintListener * 0x00000000) line 4587 + 11 bytes

Comment 8

[karnaze (gone)]

Erich, your test case does not crash for me, but the url does. Did you attach 
the right test case?

dcone, just because there is a table in the stack doesn't imply the conclusion 
you draw. 

beppe, I'm noninating this for topembed, and we could use a reduced test case.

Comment 9

[Erich 'Ricky' Iseli]

karnaze, right, my testcase doesn't crash any more. Its crash was related to
another bug, which has been fixed in the meantime.

Comment 10

[karnaze (gone)]

Attachment: somewhat reduced test case from slashdot that crashes (with a different stack)

Comment 11

[karnaze (gone)]

Attachment: attachment #2 reduced to a minimum

Comment 12

[anthonyd]

Doing a little investigation on this wierd and I stumbled onto code that 
hyatt added in back in May: 

nsLineLayout.cpp: 
line #1030 
outOfFlowFrame->GetStyleData(eStyleStruct_Display, (const nsStyleStruct* 
                                                             &)display); 

where GetStyleData fills in display.  well, apparently with the attached test 
case, for some reason, something in this test case is causing GetStyleData to 
not fill in the display variable. 

therefore, a few lines further down: 
nsLineLayout.cpp: 
line #1031 
        if (!display->IsAbsolutelyPositioned()) { 

will crash because display is null. 

and according to:
NS_IMETHODIMP nsFrame::GetStyleData(nsStyleStructID aSID, const nsStyleStruct*&
aStyleStruct) const 

the only way the could happen, is if there isnt a style context.
I have already talked to hyattt about this, and he says that it is definitely 
his bug, and that this shouldnt be happening.  I am cuyrrently investigating a 
solution with hyatt.

--> reassigning to hyatt

Comment 13

[karnaze (gone)]

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

Comment 14

[kinmoz]

Attachment: TestCase: same as above, with increased height to invoke crash

Comment 15

[kinmoz]

I'm not seeing the issue anthonyd pointed out above regarding display. The 
problem I'm seeing has to do with the fact that frames are being deleted out 
from underneath placeholder frames when nsContainerFrame::ReflowChild() [line 
760] calls nsContainerFrame::DeleteChildsNextInFlow().

Should this really be assigned to hyatt?

Before bug 95420 was dup'd, I was trying to figure out why this 
DeleteChildsNextInFlow() call only happens when the content in the placeholder 
frame is pushed to the 2nd page (it's y position is greater than the height of 
the 1st page).

Comment 16

[kinmoz]

I'll take this one.

Comment 17

[kinmoz]

Here's an update of what I'm seeing so far while debugging. Just
keep in mind I'm a bit new to some of this table/floater reflow
code, so if I'm explaining things badly, or just plain wrong, bare
with me. :-)

For my debugging, I'm using the attatchment from bug 95420:


  http://bugzilla.mozilla.org/attachment.cgi?id=48615&action=view


because it makes differenciating some of the frames easier while
in the debugger.


----


The print code makes 2 calls to InitialReflow(), followed by a
ResizeReflow().

During both InitialReflow() calls, nsTableRowGroupFrame::SplitRowGroup()
is called, which triggers various calls to 
nsCSSFrameConstructor::CreateContinuingFrame() for each row in the group,
which also creates continuing frames for each TableCellFrame in the row,
and finally each AreaFrame underneath each TableCellFrame.

Note that, SplitRowGroup() does not get called during the reflow of frames
intended for rendering on screen because the aReflowState passed into
nsTableRowGroupFrame::Reflow() has an availableHeight of NS_UNCONSTRAINEDSIZE.
While printing, this availableHeight is equivalent to the page height.

The problem seems to be that the frames on the floater list of the BlockFrame
under the TableCellFrame, are also being placed on the floater list of the
newly created continuing BlockFrame ... note that this is dangerous because
frames are not refcounted, so if either of these BlockFrames are destroyed,
so are the frames on their floater list.

Here's what the frame tree looks like at the TableCellFrame level:


Frame Tree:                                       Continuing Frames:
--------------------------------------------------------------------

TableCell(td) <    -------> next-in-flow --------> TableCell(td) <
  Block(td) <      -------> next-in-flow -------->   Block(td) <
    line state=block <                                 Floater-list<
      Block(p) <                           +----->       Frame(img)
        line state=inline <                |           >
          Text(0) <                        |         >
            "Paragraph"                    |       >
          >                                |
        >                                  |
      >                                    |
    >                                      |
    line state=inline <                    |
      Placeholder(img)                     |
    >                                      |
    Floater-list <                         |
      Frame(img)   <--- Same Image Frame --+
    >
  >
>


When the Print code calls ResizeReflow(), the primary TableCellFrame calls
nsContainerFrame::ReflowChild() on it's primary BlockFrame, which completes
and is successful, so it then tries to destroy the NextInFlow of the primary
BlockFrame, because it is no longer needed ... note that this destroys
the frames on the continuing BlockFrame's floater list also.

After this happens, we now have dangling pointers in the primary BlockFrame
floater list, as well as any placeholder that was referencing something in the
floater list.

So now that I know what's happening, I have a few questions:

- Were block frames intended to have continuing frames? I ask cause I'm not
  exactly sure how to create that scenario without going through the table
  code I've been stepping through.

- If block frames are allowed to have continuing frames, shouldn't the
  continuing frame's floater list contain a list of placeholders to prevent
  this problem? Or are placeholders only for use by lineboxes? Or should
  these floater frames be duplicated just like the continuing frames are?

Comment 18

[Marc Attinasi]

Excellent analysis Kin. I'll stick my neck out and say that the floater list on
the continuing frame should have copies of the frames, continuing floater
frames, if you will. I think placeholder frames might just confuse the access to
the frames in the floater list. I have no clue if the block frame was really
desigend to have continuations though - I've never seen them, but it makes sense
for other printing scenarios (any block frame that extends beyond a single page
could use them, if we decided not to just chop the block off).

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'd think block frames should have continuations in simple cases, e.g.,
"<p>enough text here to fill more than one page blah blah blah ... blah blah
blah</p>"

I would think we'd want the floater list of each continuation to contain the
floaters that are inside that continuation.  This could get messy if we have to
split a floater (which I think would happen only if it would be taller than the
page).  (Either that, or have the whole floater list maintained by the first
frame.)  But that could mean that the placeholder could be in one continuing
frame for a block and its corresponding floater could be in the list of another.
 What's the existing code written to do?

Comment 20

[Jaime Rodriguez, Jr.]

Should 93116 be duped against this bug. Is there a fix availble for this one? - PDT

Comment 21

[kinmoz]

Attachment: Patch version 1

Comment 22

[kinmoz]

I just attatched version 1 of a patch that prevents the crash by allowing the 
blockframe to remove floaters from it's next-in-flow's floater list, when 
pulling lines inside ReflowDirtyLines().

FYI, I still need to run the layout regression tests to make sure the 
patch doesn't break anything. I'll report my findings.

The patch fixes the crashes caused by all urls and testcases mentioned in this 
bug as well as bug 95420.

Not sure why Jaime is asking about 93116, the bugs don't look related. Wrong bug 
number?

Comment 23

[Kevin McCluskey (gone)]

Added nsbranch+ keyword

Comment 24

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The fix looks reasonable to me.  I highly doubt you'll see anything other than
noise on the regression tests since that code (the second loop in
ReflowDirtyLines) is only executed during printing.  One question, though --
where is the code that causes the floaters to be put into the floater list of
this block (or back into the list of the next block, which is actually what will
happen all the time, since the attempt to pull a line will never succeed since
nothing has changed since this "incremental" reflow is really only a hack to fix
form controls)?

Comment 25

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 49638 [details] [diff] [review]
Patch version 1

r=dbaron if you add an XXX comment saying that if we remove BuildFloaterList
(there are many comments about what do do if we do that and that we should)
then we need to add the floater to |this|'s floater list too.

Comment 26

[kinmoz]

To answer dbaron's question ...

As the block reflow state reflows each item in a line, it
keeps track of the placeholders it runs across. When it is
done, this list is then transferred to the floaters list
in the LineBox.

Immediately after nsBlockFrame::Reflow() calls ReflowDirtyLines(),
it calls BuildFloaterList() which then runs through all it's lineboxes,
and creates a floater list, based on the contents of each of it's
lineboxes' placeholder list.

My first analysis of the problem was slightly off, since it looks
like when a block frame pushes lines to it's continuing frame, the
floater list for both the primary and continuing block get reconstructed
properly. That is floaters that were in the primary, and that have moved
to the continuing frame, were being removed from the primary floater list
and placed in the continuing frame list.

The crash was happening when reflowing the primary block frame, and it
called ReflowDirtyLines() and it pulled up lines from the continuing frame.
By pull, I mean that it was manually removing the lines from the continuing
frame's mLines list and inserting it into it's own mLines list. If it managed
to pull all the lines from it's continuing frames, it would then destroy it's
continuing frames, cause they weren't needed anymore. The problem was that the
continuing frames were never reflowed yet, so they still had floater lists that
referenced floater frames in the lines that were now in the primary block frame.

Comment 27

[kinmoz]

Attachment: Patch version 2 (Adds XXX comment, requested by dbaron)

Comment 28

[kinmoz]

It looks like I pass the block regression tests with my fix, or at least, I'm
not introducing any new regression. To be safe, I manually loaded the files the
test reported as failing, and none of them caused the code I added to be hit, so
this might be the noise dbaron was referring to.

So can I get an sr= from attinasi or waterson?

Comment 29

[Chris Waterson]

Comment on attachment 49801 [details] [diff] [review]
Patch version 2 (Adds XXX comment, requested by dbaron)

sr=waterson. Do we need to do similar stuff for relatively- and absolutely-positioned,  frames? (And maybe fixed-positioned frames, too?) If so (and the fix isn't immediately obvious), please file a bug for those, too...

Comment 30

[kinmoz]

I'll try to whip up some test cases to see if relative/absolute/fixed frames
have the same problem, if so, I'll file a separate bug.

Comment 31

[karnaze (gone)]

kin, block changes usually require running the table regression tests as well.

Comment 32

[Jaime Rodriguez, Jr.]

Let's get the table regression test ASAP, so we can check it in. - PDT+, check
in after table test regression passes successfully.

Comment 33

[kinmoz]

I think this is ready for checkin. I've run the table regression tests, none of
which exercise this piece of code. If there are no objections, I'd like to land
this today.

I'm a little bothered by the fact that we have failures between baseline and
verify tests ... even when my changes weren't in my source tree. It makes it a
little hard for someone new to the project to figure out what's real and what
isn't. I resorted to putting in printfs to indicate when my code was hit ...
which as I said never got exercised. Are there plans by anyone to fix this?

Also, I'd appreciate any pointers on how to add the various tests from this bug
and it's dups to the tests. In particular, how do I get things to automatically
print during the regression tests?

Comment 34

[karnaze (gone)]

Sorry kin, we should have warned you about all of the pain associated with 
runing those tests (with all of the false positives). When I get a bbox 
difference, I view it in 2 viewers side by side, one without my changes and one 
with them and look for obvious differences. 

To add a new bug regression test to blocks, you need to check the new test case 
in from tests/block/bugs after modifying it to only use local images (any images 
should be checked in from tests/block/images using -kb). You also need to check 
in tests/block/bugs/file_list.txt after adding the new test case to it. I guess 
I'm only 99% sure of this, since I don't run the block tests, but they appear to 
be based on the table regression tests.

Comment 35

[karnaze (gone)]

I forgot to mention a couple of things. I'm not sure if blocks do any printing 
tests. Tables have some in tests/table/printing and rtest.bat there has the 
correct options to viewer to not actually waste any paper. However, it looks 
like viewer's printing capabilities have regressed recently, because viewer now 
pops up dialogs and requires your attention. Also, waterson has fixed viewer in 
the past regarding false positives. It used to be a lot worse than now, but 
maybe things have declined a bit recently.

Comment 36

[kinmoz]

Fix checked into MOZILLA_0_9_4_BRANCH:

    mozilla/layout/html/base/src/nsBlockFrame.cpp  revision 3.452.2.3

Comment 37

[Oliver Klee]

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

Comment 38

[kinmoz]

Fix checked into TRUNK:

    mozilla/layout/html/base/src/nsBlockFrame.cpp  revision 3.458

Comment 39

[sujay]

verified in 9/25 branch.

printed out both URL and KArnaze's mimimizes case. no crash.

will re-verify on trunk later.

Comment 40

[Jay Patel [:jay]]

Added N610 & Trunk  [@ nsLineLayout::ReflowFrame][@ 0x00000000 -
nsFrameList::DestroyFrames] to summary for tracking...since bug 95420 was marked
a dup of this one.

Comment 41

[sujay]

verified in 10/26 trunk also.