1515460 - Come up with way to tag frames as "speculative reflow roots" if they only have a BSize dependency on content, with graceful fallback to more thorough reflow if their size changes

Status: NEW

(Core :: Layout, enhancement, P3)

Description

[Daniel Holbert [:dholbert]]

The web console text-entry area is *almost* a good candidate for being a reflow root, except that its bsize occasionally (rarely) changes[1] in response to its content.  So it doesn't satisfy the "fixed size" invariant (and hence we can't tag it as "contain:size" without changing its behavior). 

See bug 1502524 comment 1 for info on the sorts of speedups (50% cheaper reflows in my test scenario) that we currently get if we cheat & make that element a reflow root (and break it slightly) - hence, it's tempting to find a way to make this work.

We can't tag it as "contain:layout size" (because its BSize depends on its content) so we can't take that easy path to reflow-root-ness from bug 1497414.   However: given that its bsize changes *are relatively rare*, it feels tempting to mark it as a "speculative reflow root" somehow -- i.e. to allow ourselves to initiate incremental reflows from it, and then if its BSize does change, we'd notice & react to that with an immediate more-thorough reflow from its next reflow-root ancestor.

I'm not sure what the conditions for this "speculative reflow root" would be -- perhaps good candidates would be elements that have...
 - "contain:layout"
 - ...and a specified inline-size that doesn't depend on content

(To avoid churning too much, we could perhaps do internal bookkeeping on such elements, to see how often they "fail over" and have a BSize change that triggers a broader reflow.  If it happens often for a given frame, we could suppress the frame from being considered as a speculative-reflow-root from that point on, to prevent thrashing.)

[1] The console text-entry area's BSize changes if: you enter more than 1 line of text, or if you hit "shift+enter" to add a newline, or if you delete the newline that you entered.

Comment 1

[Daniel Holbert [:dholbert]]

The goal here for the web console use-case would be to improve responsiveness by making reflows as targeted as possible, when you type a medium-length amount of input like e.g....
  document.documentElement.setAttribute("foo", "bar")
...into the web console.  The web console isn't a true textfield (in part due to its fancy syntax coloring / autocompletion features, and its smart sizing behavior noted above), so it doesn't get the "for free" reflow root tagging that we have on real textfields.  But I'd like to be able to get as close to that as possible.