Bug 160958 – [GTK] Add API to get (/set?) scrollbar position and upper value from WebKitWebView

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKitGTK

[Milan Crha]

As of WebKit2 the WebKitWebView implements GtkScrollable interface and thus as such provides vadjustment property. The problem with this vadjustment is that ut reports incorrect values, namely always value=0.0, even when it's scrolled a bit down, the page size is equal to max value, which in turn is equal to allocated web view's height. It might not be a problem on its own, due to WebKit2 drawing and handling the scrollbars on its own, but the evolution uses the scrollbar position to know, and eventually manipulate, the scroll offset for a feature called "magic spacebar". As of now, the evolution code things that the whole page is shown, thus there is no need to scroll down and it searches for the next unread message when the spacebar is pressed, even it should scroll down instead.

[Carlos Garcia Campos]

WebKitWebView is a GtkContainer and it doesn't implement any interface. If you try to use GtkScrollable API you should be getting the default values used by g_return macros, or if you have g_return macros disabled, you would still receive default values because it uses g_object_set/get that should work for any GObject and the only vfunc (get_border) is optional and thus null-checked. It's a programmer error in any case. Another thing is that you might want to know the scrollbars position or even monitor them. I think you can get the values with javascript, I don't know if you can monitor them. We could try to add API for that since several applications seem to need it.

[Milan Crha]

(In reply to comment #1)
> WebKitWebView is a GtkContainer and it doesn't implement any interface. If
> you try to use GtkScrollable API you should be getting the default values
> used by g_return macros

Weird, I have g_return macros enabled and do not get them, though I see my expectation is wrong. I do not know from where the value gets, but I can receive the vadjustment and no runtime warning is printed. My fault by mixing things together, I'm sorry for that.

If you'll be able to add some API to WebKitWebView to be able to know current and upper scrollbar position for horizontal and vertical scrolling, ideally as some GObject properties with proper g_object_notify() signals, then it'll be great, but a simple API to get (synchronously) current position and current upper at the time of the call of the function for both scrollbars would also be useful. Say something like:

  void webkit_web_view_get_hscrollbar_position (WebKitWebView *web_view,
                                                gint *position,
                                                gint *upper_value);
  void webkit_web_view_get_vscrollbar_position (WebKitWebView *web_view,
                                                gint *position,
                                                gint *upper_value);

and if any application would also need a setter, then possibly:

  void webkit_web_view_set_hscrollbar_position (WebKitWebView *web_view,
                                                gint position);
  void webkit_web_view_set_vscrollbar_position (WebKitWebView *web_view,
                                                gint position);

But you might come with something more elegant and generic.

[Milan Crha]

It seems people are used to this, the evolution is getting more bug reports about the "magic spacebar" feature being broken in 3.22.x, which is since WebKit2 port landed.

Here's the upstream bug reference:
https://bugzilla.gnome.org/show_bug.cgi?id=771821

[Milan Crha]

I forgot to add, if there are any workarounds how to get to the actual vertical scrollbar position and its max, then it'll be helpful too. I can mimic the change by (virtually) pressing PageUp/PageDown keys in the WebView.

[Michael Catanzaro]

If you're looking for workarounds, I would try the scroll-x and scroll-y properties of WebKitDOMDOMWindow.

[Milan Crha]

Thanks for the tip. It's pretty sufficient [1], nothing new is need here (at least for now; I was told that you plan to drop some GObject DOM-related API in the future, which might mean for us to do things differently). We'll see when the time will come. I'm closing this bug report for now. By the way, I also noticed the page-y-offset, which seemed to mimic scroll-y for the main (top) window. I think it's expected, just mentioning I noticed it.

[1] https://git.gnome.org/browse/evolution/commit/?id=06dc346

[Carlos Garcia Campos]

(In reply to comment #6)
> Thanks for the tip. It's pretty sufficient [1], nothing new is need here (at
> least for now; I was told that you plan to drop some GObject DOM-related API
> in the future, which might mean for us to do things differently). We'll see
> when the time will come. I'm closing this bug report for now. By the way, I
> also noticed the page-y-offset, which seemed to mimic scroll-y for the main
> (top) window. I think it's expected, just mentioning I noticed it.
> 
> [1] https://git.gnome.org/browse/evolution/commit/?id=06dc346

We are dropping unused DOM API, if you miss any API we will bring it back, and the same if you now need any API that we have dropped.