RESOLVED FIXED 21931
[GTK] Scrollbars have to be reseted 
https://bugs.webkit.org/show_bug.cgi?id=21931
Summary [GTK] Scrollbars have to be reseted
Dirk Schulze
Reported 2008-10-28 13:10:42 PDT
Visit a page and scroll down a bit. Click on a link to a side, that is large enough to need a scrollbar too. You'll be at the beginning of the side, but the scrollbar is on the same place like the side before. Example: Search for "svg w3c". Scroll down a bit. Open the link "Scalable Vector Graphics (SVG)"
Attachments
screenshot (138.27 KB, image/png)
2008-10-28 13:12 PDT, Dirk Schulze 		no flags
Details
Always update scrollbars (messy patch) (2.60 KB, patch)
2008-11-07 20:03 PST, Alp Toker 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Dirk Schulze
Comment 1 2008-10-28 13:12:47 PDT
Created attachment 24725 [details] screenshot a screenshot
Alp Toker
Comment 2 2008-11-07 20:03:49 PST
Created attachment 24983 [details] Always update scrollbars (messy patch) This is a pretty serious problem. It was re-introduced during recent ScrollView re-factoring. The problem is that the native scrollbar code in ScrollView thinks it doesn't need to update the GtkAdjustments when it thinks they're not visible (they wouldn't be visible if the themed WebCore scrollbar codepath was enabled, for example). In fact, our GtkAdjustments should be updated whenever there is any change in either the scroll position or the scroll bounds, allowing the GtkAdjustment's client (typically a GtkScrollbar) to do the right thing. Attached proof-of-concept patch should fix the issues. I'm a bit snowed under in patches right now -- Dave, can you take a look into getting this one fixed?
Xan Lopez
Comment 3 2009-02-09 01:27:09 PST
This is fixed in trunk now, see https://bugs.webkit.org/show_bug.cgi?id=23621
Note You need to log in before you can comment on or make changes to this bug.