[webkit-reviews] review denied: [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]

mitz at webkit.org has denied Mark Mentovai <mark at chromium.org>'s request 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 mitz at webkit.org
I haven’t tested it yet, but based on my experience with bug 30517, I am afraid
that this does not fix the GarageBand issue (even though it fixes the test
case), the reason being that without calling initScrollbars() from
WebFrameView, the FrameView resets to “can have scroll bars” after navigation
(which is the real GarageBand scenario; I haven’t been able to recreate it in a
layout test).

I also think that it’s wrong to name the variable m_canScroll. A frame without
scroll bars may still be scrolled programmatically, as a side-effect of
find-in-page, and by dragging to select.