[webkit-gtk] GtkLauncher scrolling problem

[Brendan Taylor]

(Restating the problem: I want to be able to scroll the contents of a 
WebView without displaying any scrollbars.  Assume for simplicity that 
we're talking about really boring HTML, I realise that frames and the 
CSS overflow property are separate issues.)

On Wed, May 25, 2011 at 12:14:46PM -0300, Gustavo Noronha Silva wrote:
> The problem is GtkScrolledWindow does not have a "make it scrollable 
> but
> do not draw scrollbars" mode, because it assumes the widget does not
> scroll by itself - so when you set the policy to NEVER you are
> essentially telling it to respect the widget's size request. GTK+ 2
> widgets request as big a size as is required for the whole of the
> contents to be shown, which in this case is the full size of the page
> contents.

This has been quite helpful in clearing up why I'm getting the results I 
am, but I don't know if I'm any closer to a solution.

I tried hooking this up to the ScrolledWindow's size-request signal:

    void scrolled_win_size_allocate(GtkWidget *scrolled_win, GtkAllocation *allocation) {
      gtk_widget_size_allocate(GTK_WIDGET(uzbl.gui.web_view), allocation);
    }

But this seems to have the same result as gtk_scrolled_window_set_policy(sw, AUTO, AUTO),
i.e. scrollbars appear when the page content is bigger than the size 
that has been allocated to the WebView.

> This is not specific to WebKitGTK+, it's also how GtkTextView works. 

This is why I'm confused; there's some difference between the two, 
because I can easily make a TextView in a ScrolledWindow that is 
scrollable, limited to the size of its parent container, and does not 
display scrollbars.[1]

The same technique used to work with a WebView. At some point it stopped 
working; now the WebView ends up in its natural size, most of which is 
offscreen.

> I asked if the problem was in a specific page because even after you've
> done all of the above, some pages will still display scrollbars, like
> gmail, because it uses tricks to make the contents be the size of the
> browser's viewport and then uses html structures to create the
> scrollable part.

Yes, I'm aware that this is a separate issue.

[1]: Demoed in the second attachment to https://bugs.webkit.org/show_bug.cgi?id=59197