Bug 36697 - [GTK] WebkitWebView's scroll bars ignore requests to always display them
Summary: [GTK] WebkitWebView's scroll bars ignore requests to always display them
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-27 02:34 PDT by Philip Chimento
Modified: 2010-09-07 22:06 PDT (History)
3 users (show)

See Also:


Attachments
Short program to demonstrate the bug (1023 bytes, text/plain)
2010-03-27 02:34 PDT, Philip Chimento
no flags Details
Patch to make documentation clearer on this matter (and fix WebFrame documentation!) (3.42 KB, patch)
2010-09-07 15:38 PDT, Philip Chimento
mrobinson: review+
mrobinson: commit-queue+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Philip Chimento 2010-03-27 02:34:31 PDT
Created attachment 51822 [details]
Short program to demonstrate the bug

From the WebkitGTK docs:

"WebKitWebView is the central class of the WebKitGTK+ API. It is a GtkWidget implementing the scrolling interface which means you can embed in a GtkScrolledWindow."

However, if you tell the GtkScrolledWindow to always display the scroll bars (by setting either the vertical or horizontal scroll bar's 'display policy' to GTK_POLICY_ALWAYS), scroll bars are still not displayed unless the content of the web view is bigger than the window, i.e., the scroll bars behave as if their display policy were set to GTK_POLICY_AUTOMATIC.

The attached sample program displays a window with a short piece of HTML in it. The expected behavior would be for both vertical and horizontal scroll bars to appear, but they do not.
Comment 1 Antonio Gomes 2010-04-27 14:08:57 PDT
I fixed something similar to qt (see https://bugs.webkit.org/show_bug.cgi?id=29431). so that was a real regression caused by r50665

i will build and check it tomorrow.
Comment 2 Antonio Gomes 2010-04-29 13:43:53 PDT
(In reply to comment #0)
> Created an attachment (id=51822) [details]
> Short program to demonstrate the bug

To build the test program use

gcc -o bug scrollbarbug.c `pkg-config --cflags --libs gtk+-2.0 webkit-1.0` -lgthread-2.0


NOTE: -lgthread-2.0 at the end :)
Comment 3 Gustavo Noronha (kov) 2010-04-29 13:57:00 PDT
I believe you are looking for WebKitWebFrame::scrollbars-policy-changed.

Here's the doc:

     * Signal emitted when policy for one or both of the scrollbars of
     * the view has changed. The default handler will apply the new
     * policy to the container that holds the #WebKitWebFrame if it is
     * a #GtkScrolledWindow and the frame is the main frame. If you do
     * not want this to be handled automatically, you need to handle
     * this signal.
     *
     * The exception to this rule is that policies to disable the
     * scrollbars are applied as %GTK_POLICY_AUTOMATIC instead, since
     * the size request of the widget would force browser windows to
     * not be resizable.
     *
     * You can obtain the new policies from the
     * WebKitWebFrame:horizontal-scrollbar-policy and
     * WebKitWebFrame:vertical-scrollbar-policy properties.
     *
     * Return value: %TRUE to stop other handlers from being invoked for the
     * event. %FALSE to propagate the event further.

If you handle this signal, and return TRUE without doing anything, you should have it your way, we believe doing the Right Thing(tm) - i.e. respecting whatever the page expects - is the best default behaviour here.
Comment 4 Antonio Gomes 2010-04-29 14:01:39 PDT
After talking to Gustavo on IRC, he explained me that it is a expected behavior, then the bug is invalid.

<tonikitoo> kov, so it seems like scrollbar policy is broken on webkit-gtk.
<tonikitoo> I am trying to understand the webkit/gtk part of it, more specifically how a policy set to GtkScrolledWindow is passed to WebKit and then to WebCore. currently if one has some code doing:
<tonikitoo> gtk_scrolled_window_set_policy (GTK_SCROLLED_WINDOW (scrolled_window), GTK_POLICY_ALWAYS, GTK_POLICY_ALWAYS); 
<tonikitoo> it should be passed to WebCore somehow, but is not, and no scrollbar bar is shown.
<tonikitoo> by passed to WebCore, I mean call ScrollView::setScrollbarModes , as the Qt does in its API.
<kov> so, the way I designed that is that you cannot tell the web content what to do regarding policy through GtkScrolledWindow, you just follow whatever the page wants you to do
<kov> it's not writtable right now, but I don't think you need to set policy to fix that, why would you?
<tonikitoo> hum, right. So if I do gtk_scrolled_window_set_policy (GTK_SCROLLED_WINDOW (scrolled_window), GTK_POLICY_ALWAYS, GTK_POLICY_ALWAYS); 
<tonikitoo> and web content does "overflow:hidden" there will be no scrollbars?
<tonikitoo> by design
<kov> that should be the case, yeah
<kov> the problem is GtkScrolledWindow is not very flexible in its policies
<tonikitoo> like in qt, if one sets SCROLLBAR_ALWAYS_ON, it would be like overflow:scroll, no matter if the scrollbar are needed or not
<tonikitoo> and would win over any overflow:hidden set in the page, for example
<tonikitoo> kov, so, https://bugs.webkit.org/show_bug.cgi?id=36697 seems invalid. could you confirm?
<kov> it's invalid, yeah, you can "fix" that by connecting to the signal that says the policy was changed, and doing nothing, though
Comment 5 Philip Chimento 2010-04-29 15:45:40 PDT
(In reply to comment #4)
> After talking to Gustavo on IRC, he explained me that it is a expected
> behavior, then the bug is invalid.

OK, I understand now, but maybe this should be spelled out more clearly in the docs, since it breaks the expected behavior of GtkScrolledWindow.
Comment 6 Antonio Gomes 2010-05-03 11:11:55 PDT
(In reply to comment #5)
> (In reply to comment #4)
> > After talking to Gustavo on IRC, he explained me that it is a expected
> > behavior, then the bug is invalid.
> 
> OK, I understand now, but maybe this should be spelled out more clearly in the
> docs, since it breaks the expected behavior of GtkScrolledWindow.

In fact, I also agree that behaviour is not ideal. For qt for example whatever scrollbar policy programmer sets to QWebFrame, it will win to WebCore's policies.

so QWebFrame::setScrollbarPolicy(Qt::Vertical, Qt::ScrollbarAlwaysOn) will show a vertical scrollbar even if it was not needed (content smaller than viewport).

@Gustavo, just out of curiosity:

1) Do you consider to have this bahavior for WebKitGtk? 

2) What is the usecase for this API as is?

3) What are the limitations of GtkScrolledWindow?

:)
Comment 7 Gustavo Noronha (kov) 2010-05-04 05:16:23 PDT
(In reply to comment #6)
> 1) Do you consider to have this bahavior for WebKitGtk? 

Not really.
 
> 2) What is the usecase for this API as is?

Doing what browsers and web pages expect by default.

> 3) What are the limitations of GtkScrolledWindow?

GtkScrolledWindow doesn't know how to "not show" scrollbars. It either makes the content scrollable, and displays scrollbars, or makes it not scrollable, which makes it request the size of the content as its minimum size. It is very unflexible.

Now, like I said, you _can_ override this, you just need to stop the WebView applying the changes required by web content, so if you feel like making the view always have scrollbars, you can. But if you want to get rid of the scrollbars, then you need to use something other than GtkScrolledWindow.
Comment 8 Philip Chimento 2010-05-04 05:49:57 PDT
(In reply to comment #7)
> (In reply to comment #6)
> > 3) What are the limitations of GtkScrolledWindow?
> 
> GtkScrolledWindow doesn't know how to "not show" scrollbars. It either makes
> the content scrollable, and displays scrollbars, or makes it not scrollable,
> which makes it request the size of the content as its minimum size. It is very
> unflexible.
> 
> Now, like I said, you _can_ override this, you just need to stop the WebView
> applying the changes required by web content, so if you feel like making the
> view always have scrollbars, you can. But if you want to get rid of the
> scrollbars, then you need to use something other than GtkScrolledWindow.

Okay, but I don't think most people want to misuse this feature to get rid of the scrollbars. I think the most common use is to make the view always have scrollbars. With _every other_ scrollable GTK widget, the solution is to set the scrollbar policy of the GtkScrolledWindow to 'always'.

Personally I don't care if you break this behavior, WebKit is much more complicated than most GTK widgets anyway. I'm just saying that you should emphasize it more clearly in the docs.
Comment 9 Gustavo Noronha (kov) 2010-05-07 07:48:23 PDT
(In reply to comment #8)
> scrollbars. With _every other_ scrollable GTK widget, the solution is to set
> the scrollbar policy of the GtkScrolledWindow to 'always'.

And this is exactly how you do it with WebKit, the only difference is WebKit also sets policy following web page requests by default, so you have to stop it from doing it if you want. Do you have suggestions on how the documentation could be improved to make that easier to find/understand? =)
Comment 10 Philip Chimento 2010-05-07 08:04:11 PDT
(In reply to comment #9)
> (In reply to comment #8)
> > scrollbars. With _every other_ scrollable GTK widget, the solution is to set
> > the scrollbar policy of the GtkScrolledWindow to 'always'.
> 
> And this is exactly how you do it with WebKit, the only difference is WebKit
> also sets policy following web page requests by default, so you have to stop it
> from doing it if you want. Do you have suggestions on how the documentation
> could be improved to make that easier to find/understand? =)

Sure, I'll submit a patch to the documentation soon when I have time. It's not hard to understand, but it is certainly hard to find -- in fact WebKitWebFrame doesn't have any signals documented in the online docs at http://webkitgtk.org/reference/index.html (generated from version 1.1.23), so ::scrollbars-policy-change isn't even mentioned there.
Comment 11 Philip Chimento 2010-09-07 15:38:07 PDT
Created attachment 66776 [details]
Patch to make documentation clearer on this matter (and fix WebFrame documentation!)

It's been a long time, but here you go. This patch makes the documentation clearer on the matter discussed in this bug report. It also turned out that none of the signals or properties of WebKitWebFrame were showing up at all in the generated HTML documentation. That's because the GtkDoc scanner didn't know WebFrame was a GObject. I have fixed that too.
Comment 12 Martin Robinson 2010-09-07 22:06:48 PDT
Comment on attachment 66776 [details]
Patch to make documentation clearer on this matter (and fix WebFrame documentation!)

View in context: https://bugs.webkit.org/attachment.cgi?id=66776&action=prettypatch

Nice! Thank you for these fixes.