Bug 21931 – [GTK] Scrollbars have to be reseted

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Dirk Schulze]

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)"

[Dirk Schulze]

Created attachment 24725 [details]
screenshot

a screenshot

[Alp Toker]

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]

This is fixed in trunk now, see  https://bugs.webkit.org/show_bug.cgi?id=23621