Testcase coming up.
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
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.
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?
Created attachment 247059 [details] testcase2 This is a similar testcase, but it uses body::first-line to get the hang on print preview.
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-
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.