288222 - Widget reconfiguration doesn't always happen in a timely manner

Status: RESOLVED FIXED

(Core :: Web Painting, defect)

Description

[Robert O'Callahan (:roc) (email my personal email if necessary)]

While debugging my new scrollframe patch I noticed that during rapid resizing I
was sometimes drawing garbage for a moment. What's happening is that during the
resize reflow of the content area, we resize the scrolling view. Its widget
resize is deferred because of the batch around the reflow. After the reflow we
enable refresh, but we defer processing of pending updates. Before that event
happens, we get an expose event, I presume from the window system because the
widgets in the chrome have resized. We repaint poorly because the widget is not
in sync with its view.

I have a patch that fixes this by running ProcessPendingUpdates inside
Refresh(), but not triggering the pending paints, just reconfiguring widgets. (I
presume based on Boris' comments there that triggering invalidates would cause
problems.) I'm not 100% sure this is the best way to fix the issue...

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

Comment 2

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 178996 [details] [diff] [review]
fix

r+sr=bzbarsky, but I think aDoInvalidate may be better than aDoPaint... We
aren't really painting, just telling the widget the area needs to be painted.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I checked this in.

Comment 4

[Simon Fraser [no longer active]]

Is this related to bug 268320?

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It certainly could be.