after some more pondering. I don't think this is the same bug as the race condition i mentioned. The bug you are describing sounds like widgetstack is reporting the wrong visible area.

I see this very frequently on desktop and n810

It happens with about:config a lot

DougT noticed that we seem to have some rectangles still in the queue, after the page loads and CanvasBrowser.endLoading() flushes the queue. Then, when we start panning, we flush the queue again and the rectangles are drawn. Is it possible that is the reason we see this bug?

As far as I test on http://www.yahoo.com/, the flush in endLoading() is unrelated to this bug. On http://www.yahoo.com/, when clicking a topic name ("Featured", "Entertainment" or something), MozAfterPaint event can be received and redraw correct region, but sometimes the region is not updated. On linux, focusing to other window from fennec triggers the region update (At that time, no MozAfterPaing event happens). As far as I investigated so far, when this issue happens, mIsFrameInvalid in nsCanvasRenderingContext2D stays PR_TRUE until panning or focus changes. http://hg.mozilla.org/mozilla-central/file/d2b77efac151/content/canvas/src/nsCanvasRenderingContext2D.cpp#l900

I see also this issue, when I click a input filed, the field is usually painted with yellow color, but sometimes happens nothing.

I am seeing something a bit different. I do see content in the visualable area of the screen. I was looking at the time it took between mouse down and mouse move. Basically during a pageload, i see that there are some rects offscreen that haven't been drawn to. For example: The browser rect is: [0,0,1024,800] The visible bounds on my device (htc touch pro in portrait) [0,0,610,671] As we load the page, we only update stuff in the visual bounds, so we filter out the following rects (viewingBoundsOnly is true in the call to flushRegion()): [610,0,414,671] [0,671,1024,129] At the end of the page load, these two rect have not been painted. When the user pans or clicks, startPanning calls flushRegion() which paints all dirty regions.

(In reply to comment #7) > I am seeing something a bit different. I do see content in the visualable area > of the screen. > What's a visuable area? How would painting this off-screen rectangles ([610,0,414,671],[0,671,1024,129]) help with corrupted display(ie stuff in visible bounds)?

I guess Vladimir patch in bug 487693 will fix this issue. I will confirm that patch fixes this issue now.

(In reply to comment #9) > I guess Vladimir patch in bug 487693 will fix this issue. > > I will confirm that patch fixes this issue now. Confirmed the patch fixes this issue both on Windows and Linux. To be on safe side, please someone test the patch.

(In reply to comment #10) > (In reply to comment #9) > > I guess Vladimir patch in bug 487693 will fix this issue. > > > > I will confirm that patch fixes this issue now. > > Confirmed the patch fixes this issue both on Windows and Linux. > To be on safe side, please someone test the patch. After applying the patch on Linux, I have not seen any painting problems after loading a page. DHTML changes (expand/collapse) seem to be working fine too. Textboxes and <a> links become yellow, as they should. The only problem I still see, even with the patch, is buttons and radiobuttons not painting properly in the pressed state. Might be a different problem.

(In reply to comment #11) > > The only problem I still see, even with the patch, is buttons and radiobuttons > not painting properly in the pressed state. Might be a different problem. For pressed state see bug 492831, it should not be hard to extend the patch to radiobutton too.

Though bug 487693 had been fixed, does this bug leave open until bug 492831 is fixed?

(In reply to comment #13) > Though bug 487693 had been fixed, does this bug leave open until bug 492831 is > fixed? I supposed you can closed it, these are not directly related, bug 492831 is not a redraw problem as here, is much more related to event dispatching and focus.

Thank you, Vivien. I am closing.

verified in 20090827 winmo alpha3 rc candidate.