hang (infinite loop) printing floats over page break where containing box contains no non-float items




14 years ago
6 years ago


(Reporter: ed, Assigned: mats)


({hang, testcase})

hang, testcase
Bug Flags:
blocking1.9 -
wanted1.9 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)



(8 attachments)



14 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040813 Epiphany/1.3.2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040814

Mozilla, Firefox, etc. stall/hang with 99% CPU utilisation on print layout (inc.
print preview) with this page:

<div style="width: 60%; float: left; height: 20cm;">a float</div>
<div style="width: 60%; float: left; height: 20cm;">overlaps page break</div>
<div style="width: 60%; float: left;">3rd float</div>
<div style="width: 60%; float: left;">4th float</div>

This is a minimal testcase for a problem observed at e.g.
http://www.gamefaqs.com/ and others.

I will attach testcases and analysis.

Reproducible: Always
Steps to Reproduce:
1. Load page
2. Select File->Print or File->Print Preview
Actual Results:  
Hang with 99% CPU utilisation

Seen on Linux (mozilla CVS 20040816, mozilla 1.7.2 Gecko/20040813, firefox 0.9.3
Gecko/20040813) and on Windows (firefox 0.9.2 Gecko/20040707)

Comment 1

14 years ago
Created attachment 156421 [details]
First testcase - causes hang

1. The <!DOCTYPE HTML> is to force Mozilla into standards mode, to demonstrate
that this is not a quirks mode bug.
2. I have only tested this on A4 paper; if you are using a different paper size
you may need to adjust the div heights to ensure that the second div falls
across the page break.

Comment 2

14 years ago
Created attachment 156422 [details]
Debug output for first testcase

Mozilla+GDB is run from within the build tree with this command (bash):

MOZILLA_FIVE_HOME=dist/bin LD_LIBRARY_PATH=dist/bin:dist/bin/plugins
NSPR_LOG_FILE=foo.log NSPR_LOG_MODULES=printing-layout:4
GECKO_BLOCK_DEBUG_FLAGS=reflow,really-noisy-reflow gdb dist/bin/mozilla-bin

Output when run outside the debugger is identical.

The output from three reflows is given. The breakpoint in between is
nsSimplePageSequence.cpp:440 as the infinite loop is the for loop from
nsSimplePageSequence.cpp:378 to nsSimplePageSequence.cpp:449.

Comment 3

14 years ago
Created attachment 156423 [details]
Second testcase - <br /> prevents hang

Here a <br /> is inserted in the flow. This prevents the hang and causes the
page to layout correctly.

Comment 4

14 years ago
Created attachment 156424 [details]
Debug output for second testcase

Comment 5

14 years ago
Created attachment 156426 [details]
Third testcase - small amount of text, hang still occurs

A small amount of text is inserted into the flow - not enough for a line break.
The hang still occurs.

Comment 6

14 years ago
Created attachment 156427 [details]
Debug output for third testcase

Comment 7

14 years ago
Created attachment 156428 [details]
Fourth testcase - enough text for a line break prevents hang

Comment 8

14 years ago
Created attachment 156429 [details]
Debug output for fourth testcase

Comment 9

14 years ago
This is what I believe is happening (just guesswork; someone who understands the
code can confirm/correct this).
The infinite loop in nsSimplePageSequenceFrame::Reflow occurs because when the
extra continuing page is added at
reflow starts from the top of the new page and no content is left on previous pages.
This is because there is one line object that contains all the floats and reflow
views line objects as atomic; thus a line object that is greater in height than
the page height breaks the layout model.
The text with a line break causes the line object to be split; the first line
object is then placed on the first page and the second line object on the second
I've tried to think what the fix would look like but haven't got anywhere yet.
Hopefully someone who understands the line layout model is watching.

Comment 10

14 years ago
Is bug 255748 caused by this as well?

Comment 11

14 years ago
I don't think so; the code paths are different.


14 years ago
Last Resolved: 14 years ago
Keywords: hang
Resolution: --- → FIXED

Comment 12

14 years ago
Reopening the bug, how does this get fixed without a checkin?
Resolution: FIXED → ---

Comment 13

13 years ago
First test case does not fail for me, but the others fail as described

DP alpha 2 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4)
Gecko/20050715 Firefox/1.0+
Ever confirmed: true
Keywords: testcase

Comment 14

12 years ago
*** Bug 343191 has been marked as a duplicate of this bug. ***

Comment 15

12 years ago
(In reply to comment #14)
> *** Bug 343191 has been marked as a duplicate of this bug. ***

Here's yet another test case to try. This causes a hang on 1.0.7, 1.0.8, and on CentOS and 1.0.7 on Gentoo, but works fine with on Windows.



12 years ago
Blocks: 360224


11 years ago
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]

Comment 16

11 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007071105 Minefield/3.0a7pre

None of the attached testcases hang for me in yesterday's trunk build. In a build without the patch for 285608, I hang on the "Third" and "Fourth" testcase. This should probably be duped to that bug or resolved as FIXED and marked as dependent.
No longer blocks: 360224
All the testcases and url are worksforme, with current trunk build.
Adam mentioned in comment 16 that this got fixed by the patch for bug 285608, so I'm marking this fixed and make it dependent on that bug.
Last Resolved: 14 years ago11 years ago
Depends on: 285608
Resolution: --- → FIXED


11 years ago
Flags: in-testsuite?
Flags: wanted1.9+
Whiteboard: [wanted-1.9]

Comment 18

6 years ago
Added crashtests:
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.