Bug 534751  is about a similar issue with tables.

Do we have some documentation that describes how pagination works in Blink? I don't really know how that works at all.

Also -- in the general case we'd like to avoid relaying out when positioning the object. How does that work for general block layout?

(...codesearch...)

Are you saying we need something like this code in LayoutBlockFlow that relays out in certain pagination conditions?

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/layout/LayoutBlockFlow.cpp&sq=package:chromium&l=682&rcl=1461612017

Do we need adjustBlockChildForPagination as well?

Eventually we should support breaking before and after flex items or flex lines, and then we'd need something like the things you're mentioning above. But that's not what this bug report is about.

The only thing we need to do for now, is to always set the position correctly *before* layout. Sometimes that's obviously impossible, especially for things like flexbox, but then we need to consider going back to re-lay out at the correct position when we've figured out what the correct position is. We should probably let markForPaginationRelayoutIfNeeded() decide whether or not to mark for layout in those cases, BTW.

I've written some documentation for multicol, but here we're dealing with a generic breaking issue (printing, multicol, whatever), which that document only covers briefly:

https://sites.google.com/a/chromium.org/dev/developers/design-documents/multi-column-layout

The documentation does mention pagination struts, though, which really is pretty much everything we care about on the generic fragmentation side. Pagination struts is currently very much a block flow layout thing, but should eventually be supported everywhere. We have code to prevent struts from being propagated to objects that don't support them (flexbox, tables, etc). But we still need to support them on block flows *inside* such objects. So we cannot lay out and move the object later, because then page breaks (pagination struts) inside the objects will potentially be wrong.

Regarding previous comment: See bug 660611, which is about supporting control of fragmentation between flexbox internal elements (such as flex items and lines). Before we can even get there, though, we should fix this bug. Pretty hard to figure out where to break, when block direction position isn't set correctly before layout.

Issue 703664 has been merged into this issue.

Any news on this issues or are there other issues that needs to be tackled first?

I don't think this is blocked on anything. If it gets prioritized, I could give it a try, unless @cbiesinger wants to.

I'm also blocked by this issue. When will it get prioritized?

hskjoet: can you elaborate in what way this bug blocks you?

It's blocking this issue that i'm also suffering from: https://bugs.chromium.org/p/chromium/issues/detail?id=640187

I'm not sure I understand how this bug causes a performance issue; Morten, can you explain? It seems like fixing this will make performance *worse*.

The problem here is that fragmentation comes in conflict with the vertical alignment and stretching that's done in flexbox. There are dependencies between the two, which are hard to satisfy, or maybe even unsatisfiable (circular) in some cases.

On one hand, the fragmentation (pagination) machinery inserts soft fragmentainer (page) breaks where necessary. On the other hand, the flexbox machinery may vertically stretch and align content, to take up all space in a flex container or on a flex line.

Fragmentation may affect the size of a flex line or container, so that we may have to re-stretch or re-align afterwards. Stretching and aligning may in turn affect where to insert fragmentainer breaks. If we change where we insert fragmentainer breaks, that may in turn affect the size of the flex line or container, so that we have to re-stretch or re-align. Which of course may require to change where the fragmentainer breaks are inserted. And so on. :)

To fix this, we need to do what https://drafts.csswg.org/css-flexbox/#pagination says. While the goal is to "attempt to minimize distortion of the flex container with respect to unfragmented flow", we may need to disable some flexbox features when fragmenting - at least when the flex container or line crosses a fragmentainer boundary (if it all ends up fitting on the same page, on the other hand, we may not have to do anything special). I'm pretty sure we need to be able to figure out the final vertical position of a flex item BEFORE laying it out. In other words: no vertical stretching or alignment under such circumstances.

I've picked apart the testcase in bug 640187 somewhat now, and it does indeed seem that this is the source of the performance problem.

I guess that's one more argument for prioritizing this ticket

Issue 806453 has been merged into this issue.

Issue 863004 has been merged into this issue.

 Issue 906635  has been merged into this issue.