Closed Bug 362275 Opened 13 years ago Closed 13 years ago
Hang with testcase on print preview, using -moz-column-count and table related stuff
See upcoming testcase, which hangs Mozilla on print preview. It hangs on trunk, reflow branch trunk, and 1.8.1 branch (didn't test 1.8.0.x branch) This testcase was also derived with the help from the script of bug 362120 (should I add dependancies?).
I get these assertions before the hang occurs on print preview: ###!!! ASSERTION: data loss - incomplete row needed more height than available, on top of page: 'rowMetrics.height <= rowReflowState.availableHeight', file c:/m ozilla/mozilla/layout/tables/nsTableRowGroupFrame.cpp, line 1134 (this assertion is also filed as bug 362084) ###!!! ASSERTION: Creating a circular frame list, this is very bad.: 'this != aN extSibling', file c:/mozilla/mozilla/layout/base/../generic/nsIFrame.h, line 677 ###!!! ASSERTION: loop in frame list. This will probably hang soon.: 'Error', f ile c:/mozilla/mozilla/layout/generic/nsFrameList.cpp, line 593
(In reply to comment #0) > See upcoming testcase, which hangs Mozilla on print preview. It hangs on trunk, > reflow branch trunk, and 1.8.1 branch (didn't test 1.8.0.x branch) > Wfm (no hang) on 22.214.171.124 with Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:126.96.36.199pre) Gecko/20061128 Firefox/188.8.131.52pre
crashes with talkback on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a1) Gecko/20061129 Minefield/3.0a1 ID:2006112916 [cairo]
<textarea style="display: table-cell;"></textarea> the display will be a no op once bug 243159 lands.
Robert, didn't you promise that will not invoke the breaking of tables inside columns. The paginate protection is of course meaningless once we are in print preview. (in short Aaargggh)
Good point! Hmm
Robert: I guess we need to implement the splitting, otherwise at least one of them (Martijn, Mats or Jesse) will pierce trough any of our band aid fixes. Thats the lesson I learned over the past year, you can run but you cannot hide. Do you have an idea whats wrong with the current table splitting? My understanding is that autoheight columns are unique in sense that they first reflow the thing unconstrained (where pages have a finite height) and then decide to divide the required space and reflow it again multiple times and see how it splits. My bet is that the pulling back from the nextinflow is not correctly implemented.
Right. I believe table splitting code has not been designed to handle incremental reflows. I'm afraid of trying to get that to work on branch as a security update. Getting it to work with blocks was hard enough. In some ways tables are harder, for example header/footer replication and rowgroup reordering. How about a stronger band-aid. We could add a flag to nsHTMLReflowState that is set to true when table splitting is allowed. False at the root, inherits down into children, nsPageFrame sets the flag for its children, nsColumnSetFrame clears it for its children.
Assignee: nobody → bernd_mozilla
Status: NEW → ASSIGNED
Does this actually allow tables to split at all? I think you need to inherit mTableIsSplittable from parent reflow states to child reflow states.
I thought that http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/generic/nsHTMLReflowState.cpp&rev=1.247&mark=135#123 does the inheritance and that http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/generic/nsHTMLReflowState.cpp&rev=1.247&mark=163#150 is just overkill
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.