Changeset 141226 in webkit


Ignore:
Timestamp:
Jan 29, 2013 10:30:43 PM (11 years ago)
Author:
commit-queue@webkit.org
Message:

Scrollbar and scroll corner composited layers positioned incorrectly
https://bugs.webkit.org/show_bug.cgi?id=108255

Patch by James Robinson <jamesr@chromium.org> on 2013-01-29
Reviewed by Simon Fraser.

ScrollView::updateScrollbars() needs to update the overflow controls composited layers if scrollbars are added
or removed. It was doing this by recording on entry to the function if it had horizontal or vertical scrollbars
and then comparing that to m_horizontal/verticalScrollbar on exit. Unfortunately updateScrollbars is recursive
and exits without running the postamble code when nested on the callstack. As a result, scrollbars may be
added or removed several times during the recursion, possibly leaving the overflow control layers in an
inconsistent state, while ending up with the same set of scrollbars.

This changes the "has anything changed" logic to only compare local state (hasXXXScrollbar vs
newHasXXXScrollbar) so changes in recursive calls are not considered.

  • platform/ScrollView.cpp:

(WebCore::ScrollView::updateScrollbars):

Location:
trunk/Source/WebCore
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • trunk/Source/WebCore/ChangeLog

    r141225 r141226  
     12013-01-29  James Robinson  <jamesr@chromium.org>
     2
     3        Scrollbar and scroll corner composited layers positioned incorrectly
     4        https://bugs.webkit.org/show_bug.cgi?id=108255
     5
     6        Reviewed by Simon Fraser.
     7
     8        ScrollView::updateScrollbars() needs to update the overflow controls composited layers if scrollbars are added
     9        or removed. It was doing this by recording on entry to the function if it had horizontal or vertical scrollbars
     10        and then comparing that to m_horizontal/verticalScrollbar on exit. Unfortunately updateScrollbars is recursive
     11        and exits without running the postamble code when nested on the callstack. As a result, scrollbars may be
     12        added or removed several times during the recursion, possibly leaving the overflow control layers in an
     13        inconsistent state, while ending up with the same set of scrollbars.
     14
     15        This changes the "has anything changed" logic to only compare local state (hasXXXScrollbar vs
     16        newHasXXXScrollbar) so changes in recursive calls are not considered.
     17
     18        * platform/ScrollView.cpp:
     19        (WebCore::ScrollView::updateScrollbars):
     20
    1212013-01-29  Shinya Kawanaka  <shinyak@chromium.org>
    222
  • trunk/Source/WebCore/platform/ScrollView.cpp

    r141053 r141226  
    604604    }
    605605
    606     if (hasHorizontalScrollbar != (m_horizontalScrollbar != 0) || hasVerticalScrollbar != (m_verticalScrollbar != 0)) {
     606    if (hasHorizontalScrollbar != newHasHorizontalScrollbar || hasVerticalScrollbar != newHasVerticalScrollbar) {
    607607        // FIXME: Is frameRectsChanged really necessary here? Have any frame rects changed?
    608608        frameRectsChanged();
Note: See TracChangeset for help on using the changeset viewer.