Hang in printing with floats with overflow:auto

VERIFIED DUPLICATE of bug 285608

Status

()

Core
Layout: Floats
--
critical
VERIFIED DUPLICATE of bug 285608
12 years ago
11 years ago

People

(Reporter: Eli Friedman, Unassigned)

Tracking

({hang, testcase})

Trunk
hang, testcase
Points:
---
Bug Flags:
blocking1.9 -
wanted1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(4 attachments)

(Reporter)

Description

12 years ago
Testcase coming up.
(Reporter)

Comment 1

12 years ago
Created attachment 215587 [details]
Testcase

Note that the overflow: auto is necessary.
(Reporter)

Comment 2

12 years ago
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

Comment 3

12 years ago
Created attachment 223054 [details] [diff] [review]
FWIW, some trace code...

Comment 4

12 years ago
Created attachment 223055 [details]
HTML-ified trace output

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.

Comment 6

12 years ago
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.
(Reporter)

Comment 7

12 years ago
Attachment 215587 [details] doesn't hang for you?  I just tested on a current trunk build, and it still causes the hang.

Comment 8

12 years ago
Yesterday I tried under windows and it didn't hang, now in linux it definitely hangs.

Comment 9

12 years ago
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

Comment 10

12 years ago
does it fail in the same way with overflow: hidden; - as in bug 285608?
Created attachment 247059 [details]
testcase2

This is a similar testcase, but it uses body::first-line to get the hang on print preview.

Updated

11 years ago
Duplicate of this bug: 367508

Comment 13

11 years ago
Bug 376218 and bug 360224 look like duplicates of either this bug or bug 285608.
Duplicate of this bug: 376218

Updated

11 years ago
Duplicate of this bug: 378072

Updated

11 years ago
Flags: blocking1.9?
(Reporter)

Comment 16

11 years ago
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?
(Reporter)

Comment 17

11 years ago
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.
(Reporter)

Comment 19

11 years ago
(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]

Comment 20

11 years ago
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
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 285608
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.