Bugzilla

Also: if a web page does something like...
```
    // Cause overflow on a descendant of a reflow root:
    inner.style.height = "200px";
    // Inspect the scrollHeight of some ancestor of that reflow root
    // (which is our first opportunity to react to the layout change):
    dump("scrollHeight: " + scrollable.scrollHeight + "\n");
```
...we still report the right result (e.g. `200` in this case), even though we haven't reflowed the scrollable frame yet when we get to the end of this block! (This surprised me.)

We report the right result because the `.scrollHeight` implementation queries the overflow areas (i.e. `nsIScrollableFrame::GetScrollRange` ends up calling `nsIFrame::GetOverflowRect`, a few stack levels down) -- and we **do update the scrollframe's overflow areas synchronously** as part of the first reflow (in step (3) from comment 10 -- not in the later reflow in step (5)).

Also: if a web page does something like...
```
    // Cause overflow on a descendant of a reflow root:
    inner.style.height = "200px";
    // Inspect the scrollHeight of some ancestor of that reflow root
    // (which is our first opportunity to react to the layout change):
    dump("scrollHeight: " + scrollable.scrollHeight + "\n");
```
...we still report the right result (e.g. `200` in this case), even though we haven't reflowed the scrollable frame yet when we get to the end of this JS! (This surprised me.)

We report the right result because the `.scrollHeight` implementation queries the overflow areas (i.e. `nsIScrollableFrame::GetScrollRange` ends up calling `nsIFrame::GetOverflowRect`, a few stack levels down) -- and we **do update the scrollframe's overflow areas synchronously** as part of the first reflow (in step (3) from comment 10 -- not in the later reflow in step (5)).

Also: if a web page does something like...
```
    // Cause overflow on a descendant of a reflow root:
    inner.style.height = "200px";
    // Inspect the scrollHeight of some ancestor of that reflow root
    // (which is our first opportunity to react to the layout change):
    dump("scrollHeight: " + scrollable.scrollHeight + "\n");
```
...we still report the right result (e.g. `200` in this case), even though we aren't guaranteed to have reflowed the scrollable frame yet when we get to the end of this JS!

This surprised me -- I was expecting that `.scrollHeight` would just flush the first reflow described in comment 10 [this expectation is correct], and I thought we might report the wrong value because we woudln't have reached the later reflow for the scrollframe yet (the reflow labeled as (5) in comment 10).

But we do in fact report the right result because the `.scrollHeight` implementation works by querying the overflow areas (it uses `nsIScrollableFrame::GetScrollRange` which ends up calling `nsIFrame::GetOverflowRect`, a few stack levels down) -- and we **do update the scrollframe's overflow areas synchronously** as part of the first reflow (in step (3) from comment 10 -- not in the later reflow in step (5)).