[Webkit-unassigned] [Bug 25889] [GTK] scrollbar policy for main frame is not implementable

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=25889





------- Comment #20 from gns at gnome.org  2009-06-09 16:15 PDT -------
(In reply to comment #17)
> You will have to bite the bullet and add it to EmptyClients, Qt, Win, Mac,
> Wx... all of *Client.h should be pure virtual to get the analogy of an
> interface. I was recently reinforcing this.

No problem (although PLATFORM(MAC) has some methods that go against this, are
those just historical artifacts?).

> >      GtkAdjustment* m_verticalAdjustment;
> >      void setScrollOffset(const IntSize& offset) { m_scrollOffset = offset; }
> > +    virtual Frame* frame() const = 0;
> >  #endif
> 
> we can't do this, it is a layering violation and hyatt will deep fry us. more
> on this later.
[...]
> > +    Page* page = frame() ? frame()->page() : 0;
> > +    if (page)
> > +        page->chrome()->client()->scrollbarsPolicyDidChange(frame());
> > +}
> > +
> 
> You can look at the "scrollRectIntoView". It is used by the mac to send
> information into the ChromeClient. I think we can adopt a strategy like that.
> What you can do either in the method above, or preferable in the ChromeClient
> implementation itself, is ask the ScrollView if it is a FrameView (isFrameView)
> and then cast it to a FrameView.

I had to make that cast in the ScrollView code, because I needed a way to get
to the chrome client, anyway. Let's see if it looks good.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.