Closed Bug 331039 Opened 19 years ago Closed 17 years ago

Hang in printing with floats with overflow:auto

Categories

(Core :: Layout: Floats, defect)

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

Tracking

()

Status:
VERIFIED DUPLICATE of bug 285608

People

(Reporter: sharparrow1, Unassigned)

References

(
URL
)

Details

(Keywords: hang, testcase)

Attachments

(4 files)

Testcase
204 bytes, text/html
Details
FWIW, some trace code...
2.70 KB, patch
Details | Diff | Splinter Review
HTML-ified trace output
11.37 KB, text/html
Details
testcase2
291 bytes, text/html
Details 
Testcase coming up.
Attached file Testcase — 
Note that the overflow: auto is necessary.
Oops, didn't mean to put it in tables.

And to reproduce, just print/print preview the testcase.
Component: Layout: Tables → Layout: Floats
QA Contact: layout.tables → layout.floats
We decide the floats does not fit, push them onto the overflow,
create a continuation for <body> on a new page, where we pick up
the overflow -- and then decide they don't fit again...
The way this is supposed to be prevented in general is that when content is being reflowed at the top of a page (or column) with no content before it, so pushing it to the next page would be futile, then we set mIsTopOfPage in the reflow state and that stops it from being pushed. So either someone isn't setting that right or else someone isn't honouring it.
In beta 2 the testcase doesn't hang anymore (I suppose by accident, since I see no activity on this bug) but the wikipedia page still hangs.
Attachment 215587 [details] doesn't hang for you?  I just tested on a current trunk build, and it still causes the hang.
Yesterday I tried under windows and it didn't hang, now in linux it definitely hangs.
testcase is hanging on Win98
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b2) Gecko/20060901 BonEcho/2.0b2
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b2) Gecko/20060901 SeaMonkey/1.1b
does it fail in the same way with overflow: hidden; - as in bug 285608?
Attached file testcase2 — 
This is a similar testcase, but it uses body::first-line to get the hang on print preview.
Bug 376218 and bug 360224 look like duplicates of either this bug or bug 285608.
Flags: blocking1.9?
Okay, this is just wonderful; here's a summary of what happens:

The first float fits, and gets placed normally.  No issue.  But then, the time comes for the second float to be placed.  And that float doesn't fit.  So the float code tells the line it can't fit.  So the line tells the block it can't fit because of a placeholder.  So therefore, the block pushes the whole line onto the next page.  Therefore, we make no progress and hang.

You might ask, why exactly is the block pushing the whole line onto the next page, rather than just the placeholder?  It's done to preserve the contents of the float.  The way placeholders work, each continuation of a placeholder must be associated with a continuation of its associated float.  If the float doesn't occur on the same page as the placeholder, this can't work.  Therefore, our only choices are either incorrectly pushing the line onto the next page or losing part of the float.

As a stupid/ugly hack, we could fix this by never pushing the first line of a block that's on the top of the page.  This stops the hang, but of course this means we lose part of the content in cases like this.  It's probably worth doing as a stopgap if we can't fix this properly for 1.9, though.

Any suggestions for a real fix?
For anyone following along, there's a hack along the lines I outlined in my previous comment in bug 285608 (which I was unaware of because I neglected to CC myself on that bug).
> As a stupid/ugly hack, we could fix this by never pushing the first line of a
> block that's on the top of the page.

This is, in fact, what we always intend to do.

I think we could make this better by breaking the line between the first float and the second float. This would sometimes cause content to be pushed to the next page that might otherwise fit, but generally would be OK.
(In reply to comment #18)
> I think we could make this better by breaking the line between the first float
> and the second float. This would sometimes cause content to be pushed to the
> next page that might otherwise fit, but generally would be OK.

Oddly enough, there's actually already code to do this in 
nsBlockReflowState::AddFloat.  It doesn't work, though, because the force-fit calclulation is broken, and truncation code in nsBlockFrame overrides it.
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

Both testcases WFM in a current trunk build, but hung in a build from 2007-06-26-04. I'm guessing Eli's patch in bug 285608 fixed this.
No longer blocks: 323652
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Verified dup
Status: RESOLVED → VERIFIED
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: