Bugzilla

I'm not entirely sure if it's what's going on here, but I have one thought about what might be going on here.

When we start reflowing a page, I think some of what-will-eventually-be-our-child-frames are actually located in the overflow lists on the previous page.

And then when we start reflowing the frames that we *do* have, the first thing we do is to transfer those overflow frames over from the prev-in-flow.  For nsBlockFrame, that happens here:
https://searchfox.org/mozilla-central/rev/f465027ef4d334dbc9ad270718c8a5e8045e7a2b/layout/generic/nsBlockFrame.cpp#5619-5627

So: maybe we need to make `ComputePageValue` a virtual function, whose implementation on a given frame will traverse not only its own child frame, but also the child frames that it knows it's going to steal as soon as it starts its Reflow method?

I'm not entirely sure if it's what's going on here, but I have one thought about what might be going on here.

When we start reflowing a page, I think some of what-will-eventually-be-our-child-frames are actually located in the overflow lists on the previous page.

And then when we start reflowing the frames that we *do* have, the first thing we do is to transfer those overflow frames over from the prev-in-flow.  For nsBlockFrame, that happens here:
https://searchfox.org/mozilla-central/rev/f465027ef4d334dbc9ad270718c8a5e8045e7a2b/layout/generic/nsBlockFrame.cpp#5619-5627

So: maybe we need to make `ComputePageValue` a virtual function, whose implementation on a given frame will traverse not only its own child frame, but also the child frames that it knows it's going to steal as soon as it starts its Reflow method?  (Probably those stolen frames first, if we know they're going to get prepended to the frame list, as I imagine they typically would be.)

I'm not entirely sure if this is the exact problem we're hitting, but I have one thought about what **might** be going on here.

When we start reflowing a page, I think some of what-will-eventually-be-our-child-frames are actually located in the overflow lists on the previous page.  So if we're doing a traversal to learn our page-name from our child frames, we might overlook some because we don't have them yet.

And then when we start reflowing the frames that we *do* have, the first thing we do is to transfer those overflow frames over from the prev-in-flow.  For nsBlockFrame, that happens here:
https://searchfox.org/mozilla-central/rev/f465027ef4d334dbc9ad270718c8a5e8045e7a2b/layout/generic/nsBlockFrame.cpp#5619-5627

So: maybe we need to make `ComputePageValue` a virtual function, whose implementation on a given frame will traverse not only its own child frame, but also the child frames that it knows it's going to steal as soon as it starts its Reflow method?  (Probably those stolen frames first, if we know they're going to get prepended to the frame list, as I imagine they typically would be.)

I'm not entirely sure if this is the exact problem we're hitting, but I have one thought about what **might** be going on here.

When we start reflowing a page, I think some of what-will-eventually-be-our-child-frames are actually located in the overflow lists on the previous page.  So if we're doing a recursive traversal to learn our page-name from our direct descendants, we might not get the right answer because we some of our eventual-descendants aren't technically our descendants yet; they're stashed in a list on a prev-in-flow, to be handed-off when we're ready for them.

When we start reflowing the descendant frames that we *do* have, the first thing each one does is to transfer those overflow frames over from its prev-in-flow.  For nsBlockFrame, that happens here:
https://searchfox.org/mozilla-central/rev/f465027ef4d334dbc9ad270718c8a5e8045e7a2b/layout/generic/nsBlockFrame.cpp#5619-5627

So: maybe we need to make `ComputePageValue` a virtual function, whose implementation on a given frame will traverse not only its own child frame, but also the child frames that it knows it's going to steal as soon as it starts its Reflow method?  (Probably those stolen frames first, if we know they're going to get prepended to the frame list, as I imagine they typically would be.)