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.
(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,
void webkit_web_view_get_vscrollbar_position (WebKitWebView *web_view,
and if any application would also need a setter, then possibly:
void webkit_web_view_set_hscrollbar_position (WebKitWebView *web_view,
void webkit_web_view_set_vscrollbar_position (WebKitWebView *web_view,
But you might come with something more elegant and generic.
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:
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.
If you're looking for workarounds, I would try the scroll-x and scroll-y properties of WebKitDOMDOMWindow.
Thanks for the tip. It's pretty sufficient , 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.
(In reply to comment #6)
> Thanks for the tip. It's pretty sufficient , 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.
>  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.