[Webkit-unassigned] [Bug 32080] Make it possible to keep track of scrolls

[bugzilla-daemon at webkit.org]

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





--- Comment #9 from Rafael Antognolli <antognolli at profusion.mobi>  2010-02-11 05:45:47 PST ---
(In reply to comment #7)
> (From update of attachment 44169 [details])
> > This patch makes sure that there is no behaviour change for Haiku.
> ...
> > +bool ChromeClientHaiku::scroll(const IntSize& scrollDelta, const IntRect& rectToScroll, const IntRect& clipRect, bool canBlit)
> >  {
> >      notImplemented();
> > +    return true;
> 
> There is a behavior change here.  Haiku previously would have repainted the
> entire viewport for a slow scroll.  Now it won't since it returns true
> indicating it 'canBlit'.
> 
> > This patch makes sure that there is no behaviour change for Mac.
> ...
> > -void WebChromeClient::scroll(const IntSize&, const IntRect&, const IntRect&)
> > +bool WebChromeClient::scroll(const IntSize&, const IntRect&, const IntRect&, bool)
> >  {
> > +    return true;
> >  }
> 
> There is a behavior change here.  Mac previously would have repainted the
> entire viewport for a slow scroll.  Now it won't since it returns true
> indicating it 'canBlit'.
> 
> You don't need to add a bool return value to scroll IMHO.  I'd prefer you add a
> new 'slowScroll' notification to the various ChromeClient's instead of doing it
> this way.

So would this new 'slowScroll' substitute the call to hostWindow()->repaint()
when canBlitOnScroll() is false?

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