Bug 26152 - [WebKitGTK] GtkAdjustment for WebKitWebFrame
Summary: [WebKitGTK] GtkAdjustment for WebKitWebFrame
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Enhancement
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-02 17:53 PDT by Leon Winter
Modified: 2011-10-15 14:02 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Leon Winter 2009-06-02 17:53:59 PDT
At the moment we can attach a GtkAdjustment to a WebkitWebView which enables us to scroll by modifying our GtkAdjustment. This is a good way if we want to scroll more than one step (currently the GTK-Binding only supports one step scrolling). Unfortunately websites can contain frames and the GtkAdjustment only scrolls the outter WebView. In order scroll the inner frames there should be a way to attach GtkAdjustment to WebFrame, this way we could call webkit_web_view_get_focused_frame () and attach the Adjustment to it.
Comment 1 Christian Dywan 2009-06-02 17:59:46 PDT
I think this sounds like a good idea. We probably want "hadjustment" and "vadjustment" properties on WebKitWebFrame like several Gtk widgets do.
Comment 2 Holger Freyther 2009-06-08 06:00:25 PDT
The question is who would provide the scrollbar in this use case?
Comment 3 Leon Winter 2009-06-08 13:26:59 PDT
(In reply to comment #2)
> The question is who would provide the scrollbar in this use case?

The WebKitWebFrame should contain the two GtkAdjustment objects (vertical/horizontal) as properties in my opinion.
Comment 4 Gustavo Noronha (kov) 2009-06-08 15:31:09 PDT
(In reply to comment #3)
> (In reply to comment #2)
> > The question is who would provide the scrollbar in this use case?
> 
> The WebKitWebFrame should contain the two GtkAdjustment objects
> (vertical/horizontal) as properties in my opinion.
 
I think you misunderstood. Currently, the main frame scrolling is handled by whatever widget holds the webview; the actual scrollbars are drawn by that widget (say, a GtkScrollWindow). I think what zecke is asking is who would draw the scrollbars if we add adjustment objects to subframes?

I don't think WebKitWebFrame is a widget, btw.
Comment 5 Christian Dywan 2009-06-09 09:04:29 PDT
I would think it would work the same way it does currently, only that adjustments make it possible to scroll individual frames. And since frames are not widgets WebCore provides the scrollbars.

As far as I realize the main use cases are a) being able to read the state, ie. to save scroll positions in a session, and b) to manipulate the scroll position by changing the adjustments. So there's no need to control the scrollbars.
Comment 6 Martin Robinson 2011-10-15 14:02:55 PDT
This isn't a good idea. GtkAdjustment works asynchrnoously, but WebCore really expects scrollbars to work synchronously. Inserting GtkAdjustment into WebCore will only cause headaches and crashes.  Additionally, this will be impossible with WebKit2. I hope you don't mind that I'm closing this issue. If anyone is interested in working on it, feel free to re-open, but be aware that I'm incredibly opposed to it. :)