Mozilla

debugging painting with MozAfterPaint

This was originally posted by Robert O’Callahan in the Mozilla web-tech blog. It’s an interesting feature in Firefox 3.5 and is worth repeating here as part of our 35 days effort.

In addition, Thomas Robinson has created a very handy bookmarklet for debugging painting on a page you’ve loaded in the browser.

Due to popular demand, we’ve created a very experimental API for Firefox 3.5 to fire an event every time content is repainted. The event is is called MozAfterPaint and is fired at the document, bubbling up to the window. The event offers two attributes, clientRects and boundingClientRect, which tell you what was repainted, using the same objects and coordinate system as the getClientRects and getBoundingClientRect methods.

This is very useful for Firefox extensions and other “chrome” code that might be using the canvas.drawWindow method to capture the contents of windows. It might also be useful for tools like Firebug. But it’s also potentially useful for regular content, for example if you want to add some lightweight JS instrumentation to a page to measure what gets painted by Firefox, and when.

Caveats:

  • This is Gecko-only. Do not use this for actual functionality on public Web pages – although I’m not sure why anyone would, so I don’t currently see this as a candidate for standardization.
  • For security reasons, regular Web content is only notified of repainting that occurred in its own document – repainting caused by IFRAMEs is not reported to untrusted listeners attached to the IFRAME’s ancestors. (Listeners added by “trusted” content such as Firefox chrome are notified of all repaints to the window, however.)
  • Currently the event might fire before the actual repainting happens. This shouldn’t matter much, and we’ll fix that at some point.
  • If your event handler does anything that triggers repainting, such as changing the style of an element, you will probably trigger an infinite loop. The browser should stay responsive but your machine will contribute to global warming.
  • Repainting of areas scrolled outside the viewport is reported, but repainting of areas scrolled outside overflow:auto elements and the like is not reported.
  • Repainting in windowed plugins (i.e. most plugins in Windows and GTK) is not reported.

4 comments

Comments are now closed.

  1. Wired Earp wrote on June 23rd, 2009 at 02:05:

    Even more awesome would be a “MozBeforePaint” event that I could preventDefault (), maybe combined with a setup to trigger repaint on command. Maybe even something like:

    window.__disableRepaint ();
    // build DOM structures and change 1000 classNames…
    window.__enableRepaint ();
    window.__repaint ();

    Question to the comment readers: Can anyone imagine a setup that would emulate this setup using chrome code? Haven’t found anything useful, maybe I just don’t know where to look.

  2. Boris wrote on June 23rd, 2009 at 16:53:

    Wired Earp, the problem with a setup like you propose is that authors would tend to forget to _enableRepaint().

    On the other hand, if you’re just building DOM structures, there’s no repainting going on anyway, unless you take special pains to allow it (e.g. setTimeout to put off the rest of the work to later). So it’s not clear to me exactly what you’re asking for here.

  3. Pingback from 颠覆网络35天 ─ 使用MozAfterPaint调试绘图 < MJiA on June 23rd, 2009 at 19:44:

    [...] 原文地址:debugging painting with MozAfterPaint 系列地址:颠覆网络35天 [...]

  4. lrbabe wrote on June 24th, 2009 at 12:47:

    @Wired Earp: Switching the visibility of the body and changing some classes of the DOM in the meantime is already possible without the user noticing it. And it is cross-browser : )

Comments are closed for this article.