492084 - sometimes canvas doesn't paint after page load until the user pans or clicks

Status: VERIFIED DUPLICATE of bug 487693

(Firefox for Android Graveyard :: Panning/Zooming, defect)

Comment 1

[(dormant account)]

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.

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

I see this very frequently on desktop and n810

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

It happens with about:config a lot

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

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?

Comment 5

[Hiroyuki Ikezoe (:hiro)]

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

Comment 6

[Hiroyuki Ikezoe (:hiro)]

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

Comment 7

[Doug Turner (:dougt)]

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.

Comment 8

[(dormant account)]

(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)?

Comment 9

[Hiroyuki Ikezoe (:hiro)]

I guess Vladimir patch in bug 487693 will fix this issue.

I will confirm that patch fixes this issue now.

Comment 10

[Hiroyuki Ikezoe (:hiro)]

(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.

Comment 11

[Mark Finkle (:mfinkle) (use needinfo?)]

(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.

Comment 12

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(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.

Comment 13

[Hiroyuki Ikezoe (:hiro)]

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

Comment 14

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(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.

Comment 15

[Hiroyuki Ikezoe (:hiro)]

Thank you, Vivien. I am closing.

Comment 17

[Joel Maher ( :jmaher ) (UTC -8)]

verified in 20090827 winmo alpha3 rc candidate.