260896 - Browser hangs on print or print preview of page with float and clear style information

Status: VERIFIED FIXED

(Core :: Printing: Output, defect)

Description

[James Napolitano]

Mozilla will hang on a printing or print preview of 
http://appro.mit.jyu.fi/essikurssi/malli.html.  I've experienced this with
Seamonkey, Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a4) Gecko/20040916, and
the Firefox 1.0 Preview Release, Mozilla/5.0 (Windows; U; Win98; rv:1.7.3)
Gecko/20040913 Firefox/0.10.  I believe people were able to print preview this
webpage earlier, so this may be a regression.

Comment 1

[James Napolitano]

Attachment: reduced testcase

The HTML that causes the hang.

Comment 2

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

For some reason we decide that "footer"'s clear needs to put its top edge at the
bottom of the page. Then we reflow "footer" with zero available height. Bummer.
We try to reflow the floats inside it, and we spin forever looking for available
space and continually getting back an available space rect of height zero
(because the maxSize parameter to nsSpaceManager::GetAvailableSpace has height
zero). There's probably three bugs here: one that's causing "footer" to have
massive unnecessary clearance, another about how we handle blocks that get
reflowed with available height zero, and another about always placing some float
somewhere even if available height is zero. The latter case should probably be
handled by making block reflow always push a line to the next in flow as soon as
we have zero available height.

Comment 3

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

Attachment: more reduced

This testcase is even smaller. It doesn't hang but it shows that the clearance
is totally wrong. Replacing the first-letter psuedo with a normal floated DIV
wrapping the first letter doesn't trigger the bug. So it must be some
interaction between the first-letter code, floats, and clearance in the context
of constrained height.

Comment 4

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

Here's what's happening. When we reflow a floating first-letter-frame, it says
it's not complete (hey, it has next-in-flows). But if we reflowed the float in a
paginated context, we interpret "not complete" to mean "the float has a
continuation on the next page" so we tell the space manager that the float
occupies space all the way down to the bottom of the page, to make sure nothing
gets put below it. So then, if you have a 'clear' element below that float, it
gets pushed to the next page.

Comment 5

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

Attachment: fix

Turns out that nsLineLayout::ReflowFrame had some code that corrects the reflow
status for floated first-letters to make them always complete. I've just pushed
that code down into nsBlockFrame::ReflowFloat. (nsLineLayout::ReflowFrame calls
AddFloat which eventually calls ReflowFloat, so nsLineLayout still sees the
fixup.) This fixes the testcases in this bug.

Comment 6

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

There's still another bug here where you could create a page with a float of
exactly the page height and again get into an infinite loop situation where the
space manager is reporting regions of zero height. I'm not too excited about
working on that right now.

Comment 7

[James Napolitano]

(In reply to comment #2 and comment #6)
> There's probably three bugs here

Do we want to at least file a bug report or two on the remaining issue(s) now,
just so we don't forget about them?  BTW, great job roc on the quick analysis
and fix.

Comment 8

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

Sure, but wait until the patched build is available so you can make a testcase
for it.

Comment 9

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

Comment on attachment 159811 [details] [diff] [review]
fix

This is just making this happen for more codepaths, right?

Comment 10

[Stephen Donner [:stephend] Not actively reading bugmail]

Roc, does http://bugzilla.mozilla.org/attachment.cgi?id=135617&action=view now
work?  It used to hang, before this patch.  I'll check again once this has been
checked in to the new builds...

Comment 11

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

Stephen: that is probably not yet fixed.

dbaron: this makes the status correction visible at more places, yes.

Comment 12

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

fix checked in.

Comment 13

[James Napolitano]

I opened up bug 262377 to deal with the remaining issue(s).  I made a testcase
that hangs based on roc's comment 6, but you may want to check that I did it right.

Comment 14

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED on Windows XP/Seamonkey trunk with build 2004-10-15-05 using the
testcase James created:
https://bugzilla.mozilla.org/attachment.cgi?id=159668&action=view