[Webkit-unassigned] [Bug 28614] New: 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

           Summary: Unnecessary horizontal scrollbar in Gmail under
                    Chromium.  ScrollView::updateScrollbars uses stale
                    value for off/on/auto scrollbar mode.
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Other
        OS/Version: Mac OS X 10.5
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Frames
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: mark at chromium.org
                CC: hyatt at apple.com, sam at webkit.org


While using Gmail in Chromium on Mac and Linux, WebKit shows a horizontal
scrollbar when it shouldn't.

http://crbug.com/7976
http://crbug.com/14647

Assuming that the window is wide enough to not need a horizontal scrollbar in
Gmail, and assuming that Chromium doesn't pop open any info bars or anything
that change the size of the view causing a relayout:

The document width is remaining at the frame width when the page is loaded,
even though the appearance of the vertical scrollbar should cause the document
width to be constrained to the visible width.  This causes a horizontal
scrollbar to appear.

When the window is resized, the horizontal scrollbar disappears (assuming that
the visible width is at least the page's minimum width).

ScrollView::updateScrollbars is using stale data for the scrollbar modes,
hScroll and vScroll, by setting them prior to performing the initial layout. 
In the case of Gmail, the vertical scrollbar mode is ScrollbarAuto prior to
layout, but after the call to visibleContentsResized(), it changes to
ScrollbarAlwaysOn.  However, for the remainder of updateScrollbars, even after
visibleContentsResized() returns, the stale cached value of ScrollbarAuto will
be used.  This results in no vertical scrollbar being set during this initial
run of updateScrollbars, because the document size at that point matches the
frame size exactly.

The above describes the underlying bug.  The appearance of the horizontal
scrollbar is actually a symptom of this bug in conjunction with peculiarities
of Gmail.  With no vertical scrollbar, Gmail will remember the visible width as
the width of the frame without the scrollbar, and will adjust itself to fill
that space.  The next time updateScrollbars is reached, a vertical scrollbar
will be enabled (owing to its being set to ScrollbarAlwaysOn), shrinking the
actual visible width, but Gmail will continue to use the original value.  When
updateScrollbars recurses back into itself, a horizontal scrollbar will be
enabled: the horizontal scrollbar is set to ScrollbarAuto, and the document
width is now narrower than the visible width, because the vertical scrollbar is
present.

I have a patch, which I'll attach to this bug shortly.

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