Currently, the end state of overflow:auto scrollbars can depend on the previous state of the scrollbars at the time layout started.  That's wrong: the state of scrollbars should not depend on the previous state of scrollbars.  That is fundamentally at odds with constraint-driven layout, and it can produce surprising results.

Here's an example of how this can go wrong:

https://jsbin.com/lenatuzifi/edit?html,output

Press the "State 0" button, then press it again.  The final state should be the same as the initial state, i.e., no scrollbars.  Instead, once the vertical scrollbar is added, it is never removed.

Currently, the logic is:

- Do a first pass layout using the state of scrollbars from the previous layout (on first layout, there are no scrollbars).

- Add or remove scrollbars based on the state of overflow after layout.

- If scrollbars were added or removed, do a second pass layout based on the new state of scrollbars.

In the jsbin example, during the first transition from the initial state to "State 1":

- the first line of text overflows the container, so a horizontal scrollbar is added.

- the addition of a scrollbar triggers second-pass layout.

- with the addition of a horizontal scrollbar, the second-pass layout produces vertical overflow.

- at this point, it's too late to add a vertical scrollbar.  So, there's vertical overflow, which you can scroll using the mouse wheel, but there's no vertical scrollbar.

During the transition from "State 1" back to "State 0":

- The first pass layout is done with a horizontal scrollbar but no vertical scrollbar.

- The presence of the horizontal scrollbar causes vertical overflow.

- updateAfterLayout adds a vertical scrollbar, triggering a second pass layout.

- The second-pass layout is done with a vertical scrollbar, which causes line breaks between "lorem" and "ipsum".

One possible solution is to always do first pass layout without scrollbars.  However, that can lead to a lot of extra work laying out children, since the scrolling container's logical width has changed.  Here's a bug that hit such a condition:

 crbug.com/621644 

So for performance reasons, we actually *do* want to do first pass layout using the previous state of scrollbars, on the assumption that in most cases, the existence of scrollbars will not change.

This is particularly messy with flexbox, since flexbox always does two layout passes: an unconstrained pass and a final, constrained pass.  Presumably, in a perfect world, the first (unconstrained) pass should be done without scrollbars, but that would hit the same performance problem mentioned above.

Looking ahead to LayoutNG, we may want to do something weird, like: when flexbox does it's first (unconstrained) layout pass, assume no scrollbars, and keep a reference to the result.  Then, do the usual thing for the constrained layout.  On subsequent layouts, if the flexbox constraints haven't changed and the children haven't changed, then reuse the previous unconstrained layout result for the first pass.