[webkit-reviews] review requested: [Bug 29167] REGRESSION(r48064): mint.com loses scrollbars after coming out of edit mode : [Attachment 42627] Track "can have scrollbar" state within FrameView independently of the individual scrollbar states in ScrollView

[bugzilla-daemon at webkit.org]

Mark Mentovai <mark at chromium.org> has asked  for review:
Bug 29167: REGRESSION(r48064): mint.com loses scrollbars after coming out of
edit mode
https://bugs.webkit.org/show_bug.cgi?id=29167

Attachment 42627: Track "can have scrollbar" state within FrameView
independently of the individual scrollbar states in ScrollView
https://bugs.webkit.org/attachment.cgi?id=42627&action=review

------- Additional Comments from Mark Mentovai <mark at chromium.org>
I started with attachment 39408, which I always thought was more than was
necessary to fix this bug, and whittled it away until it contained just the
minimum bits needed to get the right behavior.

Now that it's done, I see that it's very similar to what mitz came up with in
bug 30517 attachment 42576.

This does take mitz's suggestion to track "can have scrollbars" as a single
boolean instead of tracing m_hmode and m_vmode separately.  FrameView shouldn't
need to track each scrollbar's on/off/auto mode on its own.  The mode tracking
belongs in ScrollView, and I got rid of the duplicate mode tracking in
FrameView in bug 28614 and was hoping to not have to bring it back to fix this
bug.

I've run this through the WebKit test suite on the Mac, and have fed it to the
Chromium layout test trybots (http://codereview.chromium.org/376009).  I've
confirmed that it fixes this bug and the attached testcase, and doesn't regress
bug 28614.  I haven't tested GarageBand from bug 30517, but the testcase from
that bug (and in this patch) does the same thing that mint.com does - it sets
overflow:hidden and then clears overflow.