Closed Bug 255982 Opened 20 years ago Closed 17 years ago

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

Categories

(Core :: Layout: Floats, defect)

Product:
Core
Component:
Layout: Floats
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: ed, Assigned: MatsPalmgren_bugz)

References

Details

(Keywords: hang, testcase)

Attachments

(8 files)

First testcase - causes hang
298 bytes, text/html
Details
Debug output for first testcase
20.75 KB, text/plain
Details
Second testcase - <br /> prevents hang
305 bytes, text/html
Details
Debug output for second testcase
11.63 KB, text/plain
Details
Third testcase - small amount of text, hang still occurs
308 bytes, text/html
Details
Debug output for third testcase
20.55 KB, text/plain
Details
Fourth testcase - enough text for a line break prevents hang
343 bytes, text/html
Details
Debug output for fourth testcase
13.63 KB, text/plain
Details
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: <!DOCTYPE HTML> <html> <body> <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> </body> </html> 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)
Note: 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.
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.
Here a <br /> is inserted in the flow. This prevents the hang and causes the page to layout correctly.
A small amount of text is inserted into the flow - not enough for a line break. The hang still occurs.
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 http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsSimplePageSequence.cpp#440 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 page. 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.
Is bug 255748 caused by this as well?
I don't think so; the code paths are different.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Keywords: hang
Resolution: --- → FIXED
Reopening the bug, how does this get fixed without a checkin?
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
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+
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
*** Bug 343191 has been marked as a duplicate of this bug. ***
(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 1.5.0.2 on CentOS and 1.0.7 on Gentoo, but works fine with 1.5.0.1 on Windows. http://www.mmm.ucar.edu/wrf/OnLineTutorial/WRF_real/arw_install2.htm
Blocks: 360224
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
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.
Status: NEW → RESOLVED
Closed: 20 years ago → 17 years ago
Depends on: 285608
Resolution: --- → FIXED
Flags: in-testsuite?
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Added crashtests: https://hg.mozilla.org/integration/mozilla-inbound/rev/a66fa7e626b4
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: