458222 - Repetitive dispatches of MozAfterPaint

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[Dave Townsend [:mossop]]

I'm experimenting with the MozAfterPaint method and I'm hitting a case where it is being sent what appears to be an infinite number of times. It is reproducable I guess maybe 10% of the times I load tinderbox. I have it zoomed out a couple of steps, don't know if that makes a difference.

This is in a non-debug build, but dtrace is telling me the following stack which looks kinda recursive but without knowing the pointers I guess it could be a deep frame tree:

  0  18627 nsPresContext::NotifyInvalidation(nsRect const&, int):entry 
              XUL`nsPresContext::NotifyInvalidation(nsRect const&, int)
              XUL`nsHTMLScrollFrame::InvalidateInternal(nsRect const&, int, int, nsIFrame*, unsigned int)+0x11b
              XUL`nsIFrame::InvalidateInternalAfterResize(nsRect const&, int, int, unsigned int)+0x59
              XUL`nsIFrame::InvalidateInternal(nsRect const&, int, int, nsIFrame*, unsigned int)+0xa1
              XUL`nsIFrame::InvalidateInternalAfterResize(nsRect const&, int, int, unsigned int)+0x59
              XUL`nsIFrame::InvalidateInternal(nsRect const&, int, int, nsIFrame*, unsigned int)+0xa1
              XUL`nsBlockFrame::InvalidateInternal(nsRect const&, int, int, nsIFrame*, unsigned int)+0xe5
              XUL`nsIFrame::InvalidateInternalAfterResize(nsRect const&, int, int, unsigned int)+0x59
              XUL`nsIFrame::InvalidateInternal(nsRect const&, int, int, nsIFrame*, unsigned int)+0xa1
              XUL`nsBlockFrame::InvalidateInternal(nsRect const&, int, int, nsIFrame*, unsigned int)+0xe5
              XUL`nsIFrame::InvalidateInternalAfterResize(nsRect const&, int, int, unsigned int)+0x59
              XUL`nsIFrame::InvalidateInternal(nsRect const&, int, int, nsIFrame*, unsigned int)+0xa1
              XUL`nsIFrame::InvalidateInternalAfterResize(nsRect const&, int, int, unsigned int)+0x59
              XUL`nsIFrame::InvalidateInternal(nsRect const&, int, int, nsIFrame*, unsigned int)+0xa1
              XUL`nsIFrame::InvalidateInternalAfterResize(nsRect const&, int, int, unsigned int)+0x59
              XUL`nsIFrame::InvalidateInternal(nsRect const&, int, int, nsIFrame*, unsigned int)+0xa1
              XUL`nsIFrame::InvalidateInternalAfterResize(nsRect const&, int, int, unsigned int)+0x59
              XUL`nsIFrame::InvalidateInternal(nsRect const&, int, int, nsIFrame*, unsigned int)+0xa1
              XUL`nsIFrame::InvalidateInternalAfterResize(nsRect const&, int, int, unsigned int)+0x59
              XUL`nsIFrame::InvalidateInternal(nsRect const&, int, int, nsIFrame*, unsigned int)+0xa1

Comment 1

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

You expect to see deep stacks like that. As long as you're not hitting stack overflow that's fine.

Not sure what you mean by "an infinite number of times". If your MozAfterPaint handler does anything to cause painting in the document you're observering, you'll trigger an infinite series of paints, of course.

Comment 2

[Dave Townsend [:mossop]]

No it doesn't make any changes to the document at all. And by infinite I mean I can sit there and watch it dispatching a paint event for the same region seemingly forever until I close the tab.

Comment 3

[Dave Townsend [:mossop]]

Attachment: fuller stack

This is a fuller stack from a debugger. The clientrect it is claiming has been repainted is well outside of the window in view, in this case the window was 1900x1143 and it was claiming a paint of 4308x4453. This is tinderbox though so I guess the full page is that wide I wasn't expecting to see paint events from outside of the visible area.

Comment 4

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

That stack looks like it's invalidating a chrome window. Where did you attach the event listener?

Comment 5

[Dave Townsend [:mossop]]

It is attached to the xul browser element for the tab.

Comment 6

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

It's actually not clear that this is causing dispatch of the DOM event. You want to set a breakpoint at the call to NS_DispatchToCurrentThread in nsPresContext::NotifyInvalidation.

Comment 7

[Dave Townsend [:mossop]]

Oops my bad. Obviously there are lots of paints going on, that stack is from something in chrome. Once I caught the stack for the html document I realised immediately what was going on. Tinderbox uses an animated gif for burning boxes, MozAfterPaint is just getting dispatched for every frame.