1872292 - Investigate different page name found during block reflow and computed page value on first reflow of the new page

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, task)

Description

[Emily McDonough [:alaskanemily]]

During the work on bug 1865172 I found that sometimes an incorrect page value is found by nsIFrame::ComputePageValue, while a different but correct one is pushed during block reflow.

I believe this is caused either because of the change in bug 1819335, or because of the known limitations of the solution presented there. Given that it seems that the pushed page value is the correct value, and we are making breakpoints in the correct places, we probably don't need to hold up gsuite work for this investigation. We should still understand why this is how it is.

See https://docs.google.com/document/d/1SetfZ2cx7J0BJanXnWTABzKexzwP4p-dQ--XSEAeiqs/ as an example where this occurs.

Comment 1

[Daniel Holbert [:dholbert]]

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.)

Comment 2

[Emily McDonough [:alaskanemily]]

This was solved in the eventual solution to the provoking bug.