[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


Mark Mentovai <mark at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #39036|                            |review?
               Flag|                            |




--- Comment #16 from Mark Mentovai <mark at chromium.org>  2009-09-03 21:52:12 PDT ---
Created an attachment (id=39036)
 --> (https://bugs.webkit.org/attachment.cgi?id=39036)
v4, Eliminate duplicated (and incorrect) scrollbar mode tracking between
FrameView and ScrollView

I figured out why fast/dom/Window/new-window-opener.html was failing in
DumpRenderTree on the Mac.  Both FrameView and its superclass ScrollView
maintain members that track the off/on/auto state of each scrollbar.  In
certain cases, they could become desynchronized.

The problem occurs when setCanHaveScrollbars is called.  In this layout test,
that method was being called to turn off the scrollbars in response to a
JavaScript window.open(..., "scrollbars=no").  In the existing code,
FrameView::setCanHaveScrollbars first calls the superclass method
ScrollView::setCanHaveScrollbars, and then updates its m_[hv]mode members used
to track the scrollbar state.  Unfortunately (for me),
ScrollView::setCanHaveScrollbars eventually enters FrameView::layout, which
uses m_[hv]mode before they have been properly set.

I can't see any good reason to maintain the duplication between m_[hv]mode in
FrameView and m_{horizontal|vertical}ScrollbarMode in ScrollView.  In this
patch, I'm getting rid of the duplicated fields in FrameView, along with some
extra bookkeeping methods and members that were supposed keep everything
synchronized.

The ScrollView.cpp and WebDynamicScrollBarsView.mm parts of this patch already
had r+ from hyatt in v2, and are unchanged in this version.

This produced no layout test regressions on the Mac in DumpRenderTree, or on
any of Chromium's three platforms.

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