[Webkit-unassigned] [Bug 16310] Scroll bars dont render correctly on some HTML pages, even though there is a portion of the view reserved for them
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed Dec 5 23:09:25 PST 2007
http://bugs.webkit.org/show_bug.cgi?id=16310
------- Comment #5 from agiyengar at yahoo.com 2007-12-05 23:09 PDT -------
(From update of attachment 17728)
Index: WebCore/ChangeLog
===================================================================
--- WebCore/ChangeLog (revision 28482)
+++ WebCore/ChangeLog (working copy)
@@ -1,3 +1,31 @@
+2007-12-05 Ananta iyengar <agiyengar at yahoo.com>
+
+ Reviewed by NOBODY (OOPS!).
+
+ Proposed fix for http://bugs.webkit.org/show_bug.cgi?id=16310,
which is an intermittent
+ scrolling observed in Safari. This is a bug in webkit. Details
as below:-
+
+ The decision on whether the frame view needs
horizontal/vertical scroll bars is made in
+ the webkit function WebCore::ScrollView::updateScrollbars. In
certain cases it
+ makes this decision based on whether the view size is
wider/larger than the frame
+ width/height. It runs the corresponding loop twice apparently
to cover for the case where
+ a view had scroll bars initially and loses them. This is the
reverse case, where the view
+ originally did not have scroll bars and the first pass of the
loop decides that it needs
+ them. The second pass of the loop, first causes a frame layout
to occur, which reduces the
+ height/width of the view by the height and width of the
horizontal and vertical scroll bars
+ respectively. It then checks if the view size is greater than
the frame size, which is not
+ the case anymore and thus removes the scrollbars from the view.
+
+ As a result we are left with a dead region in the view which is
not painted and is not responsive
+ to user input. Resizing the window causes the scrollbars to
show up in some cases.
+
+ We also need to suppress new scroll bar calculations during
resize. These calculations can
+ occur when the first layout after resize is done.
+
+ * platform/win/ScrollViewWin.cpp:
+ (WebCore::ScrollView::setFrameGeometry):
+ (WebCore::ScrollView::updateScrollbars):
+
2007-12-05 Darin Adler <darin at apple.com>
Reviewed by Maciej.
Index: WebCore/platform/win/ScrollViewWin.cpp
===================================================================
--- WebCore/platform/win/ScrollViewWin.cpp (revision 28433)
+++ WebCore/platform/win/ScrollViewWin.cpp (working copy)
@@ -281,7 +281,11 @@ void ScrollView::setFrameGeometry(const
return;
if (newGeometry.width() != oldGeometry.width() || newGeometry.height() !=
oldGeometry.height()) {
+ // Suppress new scroll bar calculations until the first
+ // layout after resize has occured.
+ suppressScrollbars(true);
updateScrollbars(m_data->m_scrollOffset);
+ suppressScrollbars(false);
static_cast<FrameView*>(this)->setNeedsLayout();
}
@@ -464,23 +468,36 @@ void ScrollView::updateScrollbars(const
const int cVerticalWidth = PlatformScrollbar::verticalScrollbarWidth();
const int cHorizontalHeight =
PlatformScrollbar::horizontalScrollbarHeight();
- for (int pass = 0; pass < 2; pass++) {
- bool scrollsVertically;
- bool scrollsHorizontally;
+ bool scrollsVertically = false;
+ bool scrollsHorizontally = false;
+ for (int pass = 0; pass < 2; pass++) {
if (!m_data->m_scrollbarsSuppressed && (hScroll == ScrollbarAuto ||
vScroll == ScrollbarAuto)) {
// Do a layout if pending before checking if scrollbars are
needed.
if (hasVerticalScrollbar != oldHasVertical ||
hasHorizontalScrollbar != oldHasHorizontal)
static_cast<FrameView*>(this)->layout();
- scrollsVertically = (vScroll == ScrollbarAlwaysOn) || (vScroll ==
ScrollbarAuto && contentsHeight() > height());
+ // The frame view needs horizontal/vertical scrollbars if either
of the following
+ // conditions are true:-
+ // 1. The decisions from the first pass of this loop.
+ // 2. The frame view height/width is greater than the frame
height/width.
+ // This fixes the following scenario.
+ // The first pass of the loop determines that we need a horizontal
or vertical scroll bar.
+ // As a result we invoke the layout call on the FrameView in the
second pass. This reduces
+ // the view size by the height and width of the
horizontal/vertical scroll bars. The code
+ // below decides whether the view needs a horizontal/vertical
scroll bar by checking
+ // if the view width/height is greater than the frame
width/height. These checks fail
+ // thus causing the view to not have scrollbars when it should,
thus resulting in a view
+ // which is not painted correctly. The scroll bar region of the
view is a dead region
+ // unresponsive to input.
+ scrollsVertically |= (vScroll == ScrollbarAlwaysOn) || (vScroll ==
ScrollbarAuto && contentsHeight() > height());
if (scrollsVertically)
- scrollsHorizontally = (hScroll == ScrollbarAlwaysOn) ||
(hScroll == ScrollbarAuto && contentsWidth() + cVerticalWidth > width());
+ scrollsHorizontally |= (hScroll == ScrollbarAlwaysOn) ||
(hScroll == ScrollbarAuto && contentsWidth() + cVerticalWidth > width());
else {
- scrollsHorizontally = (hScroll == ScrollbarAlwaysOn) ||
(hScroll == ScrollbarAuto && contentsWidth() > width());
+ scrollsHorizontally |= (hScroll == ScrollbarAlwaysOn) ||
(hScroll == ScrollbarAuto && contentsWidth() > width());
if (scrollsHorizontally)
- scrollsVertically = (vScroll == ScrollbarAlwaysOn) ||
(vScroll == ScrollbarAuto && contentsHeight() + cHorizontalHeight > height());
- }
+ scrollsVertically |= (vScroll == ScrollbarAlwaysOn) ||
(vScroll == ScrollbarAuto && contentsHeight() + cHorizontalHeight > height());
+ }
}
else {
scrollsHorizontally = (hScroll == ScrollbarAuto) ?
hasHorizontalScrollbar : (hScroll == ScrollbarAlwaysOn);
--
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the webkit-unassigned
mailing list