[webkit-gtk] Scrolling issues, and a crazy proposal

[Gustavo Noronha Silva]

Hey,

A few hours ago I was telling Martin what kinds of problems I've had
with the scrolling code, and the requirements that were initially set
for it. Essentially, the idea is that WebKitWebView be a normal GTK+
widget that can be added to any scrolling controller widget, such as
GtkScrolledWindow, or MokoFingerScroll, and work.

The problem we have is that having it this way, there are a whole lot of
complexities we have to deal with, one of the more annoying ones being
that since the main frame scrollbars are part of the parent widget, when
they appear the WebView changes size, which fires a "resize" DOM event,
which some pages use to (doh) reload the page, so we get into a reload
infinite loop.

We discussed a few possibilities, including dropping the idea of being a
"normal" scrollable, and inheriting directly from GtkScrolledWindow,
thus fixing the problem from the inside.

Something just came to my mind just a few minutes ago, that I'd like to
explore, though: what if we create a WebKitScrolledWindow, derived from
GtkScrolledWindow that does not draw scrollbars, thus never stealing
space from the WebView, and is handled specially by the WebKitWebView?
When that widget is the parent, the WebView would then behave more
"normally".

This would be the recommended parent widget for normal browsers, and
tools such as devhelp, but we would retain the ability of using other
widgets whenever web compatibility is not a problem, or can be worked
around in other ways (for MokoFingerScroll there should be no problem as
it doesn't draw scrollbars AFAIk).

This new widget would be part of WebKit. Another option is to try to
propose a patch to GtkScrolledWindow to give it a mode that makes it
avoid drawing the scrollbars itself in a way that the child could
set/detect the mode.

What do you think?

Cheers,

-- 
Gustavo Noronha Silva <gns at gnome.org>
GNOME Project