Self replying since I had a conversation with Xidorn... So apparently we just use frames for everything that ends up being a rect (unlike WK, for example, that doesn't mutate the "render tree" while doing layout).
So we just create more frames / delete frames while reflowing because we've run out of space for example, or because we managed to complete a reflow and the rest of the in-flow continuations are now useless. And thus probably pursuing this is much harder than what I thought in the first time... If people think it's still worth I'm happy to hear discussion, otherwise, I guess you can disregard the previous email :) -- Emilio On 09/12/2017 12:05 AM, Emilio Cobos Álvarez wrote: > Hi, > > So today I was looking at a bug[1] that happens to be a combination of > edge cases (as usual) ending up badly. In particular, a columnset frame > removing a not-first-in-flow frame via DeleteNextInFlow that happens to > hold the pseudo-elements of a nested display: contents element, thus > unbinding them from the tree and breaking the counter manager invariants. > > I've noticed recently in other bug I've recently fixed a similar pattern > (that bug crashed creating a first-letter continuation during bidi > resolution, though the underlying issue ended up being other). > > I think the frame tree would be much easier to reason about and manage > if it didn't mutate during reflow, though there seem to be a bunch of > places that do that (grepping for StealFrame, CreateContinuation, ...). > > Note: I mean mutate as "creating / destroying frames", not as in "not > change any member variable of any frame", obviously. > > My questions are (for those who know more about Gecko layout than me): > > * Do you think it is reasonably doable to stop mutating the frame tree > from layout? > * Would it be worth it? (I think it would!) > * Would it be reasonable to spend some time on it? (perhaps in the > medium / long term, given right now everyone has other important things > to do :P) > > I could believe that most of these changes may require some rework of > some parts of layout and frame construction (I'm looking at float / > out-of-flows / first-letters, etc), but I also think some of those are > the ones where the frame constructor handles dynamic changes poorly > (ib-splits certainly enter in this category, though I'm not sure that we > mutate those during reflow). > > Anyway I could believe that if we refactor things with this in mind we > could make frame construction better for dynamic changes. > > There are also a few CreateContinuationFor calls in block layout that > could also be hard to replace, haven't checked in detail yet... > > Anyway, just wanted to know if other people think this goal would be > reasonable / worth it. > > Thanks in advance, > > -- Emilio > > [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1381134 > _______________________________________________ dev-tech-layout mailing list dev-tech-layout@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-layout
