Mutating the frame tree shape from reflow code.

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Mutating the frame tree shape from reflow code.

Emilio Cobos Álvarez
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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Mutating the frame tree shape from reflow code.

Emilio Cobos Álvarez
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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Mutating the frame tree shape from reflow code.

Robert O'Callahan-3
You would need to design a completely different approach to handle vertical
and horizontal breaking. I agree the current approach has severe problems
but even just designing something significantly better is not easy ... and
actually switching Gecko to it would be a mountain of work.

Maybe you should get really good break-handling into Servo layout and then
import Servo layout into Gecko a la Stylo ("Layo"?).

Rob
--
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout