[Webkit-unassigned] [Bug 28614] Unnecessary horizontal scrollbar in Gmail under Chromium. ScrollView::updateScrollbars uses stale value for off/on/auto scrollbar mode.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=28614





--- Comment #6 from Mark Mentovai <mark at chromium.org>  2009-08-26 09:50:02 PDT ---
(In reply to comment #5)
> When both scrollbars are forced on, this is because of overflow:scroll.  That's
> why we checked that case... since you know you don't need to do a layout if
> both scrollbars are locked on.  That was my concern.  I don't think you want to
> cause a layout to happen in that case.

Dave, I still think that there is still a reason that layout might be necessary
in that case.  For example:

 - page has overflow:scroll
 - page is resized
 - page's JS responds to resize by changing the value of overflow

The only way to handle that case properly is to do the layout before even
looking at the state of m_horizontalScrollbarMode and m_verticalScrollbarMode. 
If you're worried about "too much layout," FrameView::visibleContentsResized
should only do the layout if one is actually needed, and the common case is
"auto" anyway and there doesn't seem to be "too much layout" with the code
structured as-is.  I do think that the existing patch (v2) is the correct one.

I'm primarily concerned with fixing the horizontal scrollbar bug as it relates
to Gmail, so if you really think that further limiting the conditions in which
visibleContentsResized is called, I'm happy to change it.  I'll upload another
patch in a moment, feel free to pick which one you prefer.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.