WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
24358
[GTK] Scrollbars not clipped correctly
https://bugs.webkit.org/show_bug.cgi?id=24358
Summary
[GTK] Scrollbars not clipped correctly
Xan Lopez
Reported
2009-03-04 10:06:11 PST
The expose handler in WebKitWebView has two branches. One coalesces all the damage regions in one big area and sends that to frame()->view()->paint(), and other sends each region individually. In both cases the clip area is passed as an IntRect in the second parameter of paint(), but there's a problem: our Scrollbar ::paint method ignores that and always uses the bounding box of all the regions in the Expose event as the clip rectangle. This works ok when we also merge the regions ourselves, but does not work when we send each one separatedly: in that case we'll use as clip rectangle a much bigger area than what we actually have to paint, and will risk painting the scrollbars outside of the visible area. The simple fix is to change the Widget::paint method to use the clip rectangle parameter always. Unfortunately this introduces another problem: the floatingdiv.html manual test stops working, the scrollbar there is invisible again. I must say that I'm not 100% sure why, but my theory is that since we are now using the correct clip rectangle, we only send an expose event with the minimum area, instead of a much larger one, and thus we uncover a new bug: we are not applying the needed coordinate translation for our Scrollbar widgets in the ::paint method. The first patch fixes these two problems. The second one moves the ::paint method to ScrollbarGtk, since it's now scrollbar specific and this is the only actual widget we have anyway. The third one changes the frameRectsChanged method to only take into account non ScrollView scrollbars, since our ScrollView scrollbars are native and won't go through this codepath (the same is done in the ::paint method).
Attachments
cliprect.patch
(3.39 KB, patch)
2009-03-04 10:25 PST
,
Xan Lopez
zecke
: review+
Details
Formatted Diff
Diff
movepaint.patch
(5.32 KB, patch)
2009-03-04 10:26 PST
,
Xan Lopez
zecke
: review+
Details
Formatted Diff
Diff
onlyrenderscrollbar.patch
(2.81 KB, patch)
2009-03-04 10:26 PST
,
Xan Lopez
zecke
: review+
Details
Formatted Diff
Diff
subframescrollbars.patch
(3.47 KB, patch)
2009-03-07 04:01 PST
,
Xan Lopez
zecke
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Xan Lopez
Comment 1
2009-03-04 10:25:50 PST
Created
attachment 28268
[details]
cliprect.patch
Xan Lopez
Comment 2
2009-03-04 10:26:14 PST
Created
attachment 28269
[details]
movepaint.patch
Xan Lopez
Comment 3
2009-03-04 10:26:33 PST
Created
attachment 28270
[details]
onlyrenderscrollbar.patch
Holger Freyther
Comment 4
2009-03-06 07:52:32 PST
Comment on
attachment 28268
[details]
cliprect.patch
> --- a/WebCore/platform/gtk/WidgetGtk.cpp > +++ b/WebCore/platform/gtk/WidgetGtk.cpp > @@ -101,7 +101,7 @@ void Widget::hide() > * 2.) We assume that GTK_NO_WINDOW is set and that frameRectsChanged positioned > * the widget correctly. ATM we do not honor the GraphicsContext translation.
maybe we can update the comment? I think this was meant with GraphicsContext...
> */ > -void Widget::paint(GraphicsContext* context, const IntRect&) > +void Widget::paint(GraphicsContext* context, const IntRect& rect) > { > if (!platformWidget()) > return; > @@ -114,7 +114,13 @@ void Widget::paint(GraphicsContext* context, const IntRect&) > > GdkEvent* event = gdk_event_new(GDK_EXPOSE); > event->expose = *context->gdkExposeEvent(); > - event->expose.region = gtk_widget_region_intersect(widget, event->expose.region); > + event->expose.area = static_cast<GdkRectangle>(rect);
this is using the operator GtkRectangle()...
Holger Freyther
Comment 5
2009-03-06 07:59:54 PST
Comment on
attachment 28269
[details]
movepaint.patch
> +/* > + * Strategy to painting a Widget: > + * 1.) do not paint if there is no GtkWidget set > + * 2.) We assume that GTK_NO_WINDOW is set and that frameRectsChanged positioned > + * the widget correctly. ATM we do not honor the GraphicsContext translation.
okay, if you update the comment in the previous patch then update this as well..
Holger Freyther
Comment 6
2009-03-06 08:10:34 PST
Comment on
attachment 28270
[details]
onlyrenderscrollbar.patch
> From a0e3df34a1bfd4fb3234e2459226cf485ce036f8 Mon Sep 17 00:00:00 2001 > From: Xan Lopez <
xan@gnome.org
> > Date: Wed, 4 Mar 2009 20:23:06 +0200 > Subject: [PATCH 3/3] 2009-03-04 Xan Lopez <
xan@gnome.org
> > > Reviewed by NOBODY (OOPS!). > >
https://bugs.webkit.org/show_bug.cgi?id=24358
> [GTK] Scrollbars not clipped correctly > > Do not take into account the case of being a ScrollView scrollbar, > since those are native in our case. > > * platform/gtk/ScrollbarGtk.cpp: > (ScrollbarGtk::frameRectsChanged): > --- > WebCore/ChangeLog | 17 +++++++++++++++-- > WebCore/platform/gtk/ScrollbarGtk.cpp | 16 +++------------- > 2 files changed, 18 insertions(+), 15 deletions(-) > > diff --git a/WebCore/ChangeLog b/WebCore/ChangeLog > index c6352e7..cd3f559 100644 > --- a/WebCore/ChangeLog > +++ b/WebCore/ChangeLog > @@ -5,8 +5,21 @@ >
https://bugs.webkit.org/show_bug.cgi?id=24358
> [GTK] Scrollbars not clipped correctly > > - Move Widget::paint to ScrollbarGtk::paint, since it's scrollbar > - specific and it's our only Widget anyway. > + Do not take into account the case of being a ScrollView scrollbar, > + since those are native in our case.
^^^ oh, tabs vs. space? for the rest, let us try it :) >
Xan Lopez
Comment 7
2009-03-06 11:07:37 PST
Thanks, landed in r4149{0,1,2}.
Xan Lopez
Comment 8
2009-03-06 14:20:24 PST
Ok, remember what I said in the last patch about our scrollbars always being renderlayout because the other ones are native? Not true. Turns out there are scrollview scrollbars that are not native apparently. This happens in gmail for example. Seems I either didn't follow the code correctly or there's some bug somewhere, not sure. Anyway something like this fixes a new bug in gmail, where the scrollbars disappear when you scroll: diff --git a/WebCore/platform/gtk/ScrollbarGtk.cpp b/WebCore/platform/gtk/ScrollbarGtk.cpp index be4c1c4..0bd2dda 100644 --- a/WebCore/platform/gtk/ScrollbarGtk.cpp +++ b/WebCore/platform/gtk/ScrollbarGtk.cpp @@ -72,7 +72,12 @@ void ScrollbarGtk::frameRectsChanged() // Translate our coordinates, we are a RenderLayout scrollbar because our // ScrollView scrollbars are native. - IntPoint loc = parent()->contentsToWindow(frameRect().location()); + IntPoint loc; + + if (parent()->isScrollViewScrollbar(this)) + loc = parent()->convertToContainingWindow(frameRect().location()); + else + loc = parent()->contentsToWindow(frameRect().location()); // Don't allow the allocation size to be negative IntSize sz = frameRect().size(); @@ -141,7 +146,13 @@ void ScrollbarGtk::paint(GraphicsContext* context, const IntRect& rect) event->expose = *context->gdkExposeEvent(); event->expose.area = static_cast<GdkRectangle>(rect); - IntPoint loc = parent()->contentsToWindow(rect.location()); + IntPoint loc; + + if (parent()->isScrollViewScrollbar(this)) + loc = parent()->convertToContainingWindow(rect.location()); + else + loc = parent()->contentsToWindow(rect.location()); + event->expose.area.x = loc.x(); event->expose.area.y = loc.y(); I'll try to go through this again tomorrow though. Thoughts about it welcome.
Xan Lopez
Comment 9
2009-03-06 14:22:10 PST
Adding Holger in CC, see previous comment :)
Xan Lopez
Comment 10
2009-03-07 04:01:43 PST
Created
attachment 28387
[details]
subframescrollbars.patch
Xan Lopez
Comment 11
2009-03-07 04:04:00 PST
Committed in
r41509
, reviewed on IRC.
Holger Freyther
Comment 12
2009-03-07 04:32:35 PST
Comment on
attachment 28387
[details]
subframescrollbars.patch just for the record.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug