Bug 175235

When using non-overlay scrollbars, ScrollView::updateScrollbars can reach its cMaxUpdateScrollbarsPass recursion limit, leaving layout in a state that's inconsistent wrt the presence of scrollbars. For example, starting with a page that's vertically scrollable, resize the window to reduce its width. Here's what happens in updateScrollbars: 1) The totalContentsSize() is wider than the visibleWidth(), so a horizontal scrollbar is added. This triggers another layout and a recursive call into updateScrollbars. 2) Layout changes the totalContentsSize() so that is no longer wider than the visible width. So the horizontal scrollbar needs to be removed. But updateScrollbars always removes both scrollbars when one needs to be removed, so the vertical scrollbar is removed as well. Another layout and recursive call into updateScrollbars happens. 3) Layout changes the width of totalContentsSize() under the assumption that there's no vertical scrollbar. But totalContentsSize() is still taller than visibleHeight(), so the vertical scrollbar is added back. We need to trigger another layout to account for this, but we can't since m_updateScrollbarsPass is already 2 (that is, cMaxUpdateScrollbarsPass). So we're left with the layout that was done under the assumption of no vertical scrollbar, even though we do have a vertical scrollbar. And that means the layout viewport is wider than it should be, by the width of the scrollbar. It does get the right size the next time something triggers layout. One way to fix this is to not remove the vertical scrollbar in step 2. Then there won't be any scrollbar change in step 3. Alternatively, we could increase cMaxUpdateScrollbarsPass.