Is it okay to call canvas.drawWindow() from the "onload" handler?

Question

The note at the bottom of this Mozilla wiki page currently says: "Using canvas.drawWindow() while handling a document's onload event doesn't work. In Firefox 3.5 or later, you can do this in a handler for the MozAfterPaint event to successfully draw HTML content into a canvas on page load." Which is fine, except that I tried it in Firefox 3.6.6 and it did work, leading me to believe that perhaps it used to not work, due to some bug which has since been fixed. I'd rather not use MozAfterPaint since it won't work in versions earlier than 3.5. Is there an important reason not to use the "load" event, and if so what can I do instead that will be compatible with older versions of Firefox?

EDIT: This is how my code works. In the init() function of my extension, I call gBrowser.addEventListener("load", MyExtension.onPageLoad, true); Then MyExtension.onPageLoad is essentially:

onPageLoad : function(e) {
  var win = e.originalTarget.defaultView;
  // create an html:canvas, adjust its size, etc. following the example of the "TabPreview" extension
  var ctx = canvas.getContext("2d");
  ctx.drawWindow(win, 0, 0, w, h, "rgb(255, 255, 255");
  // add the canvas to the DOM
},

Answer 1

@MatrixFrog, I'm struggling to solve the same problem, could you post your complete code if not proprietary.

Answer 2

Looks like the Mozilla documentation is wrong, and it is okay to call canvas.drawWindow() from the "load" event.

Answer 3

I expect it's not a case of won't work "at all", but rather a case of won't work "correctly".

Traditionally, onload ran when the html of the page was finished loading. The CSS and scripting would happen later, or possibly at the same time ¹.

This is why the MozAfterPaint was introduced. It lets you inject code after Gecko has enough information to render the page.

You might be able work around the absence of MozAfterPaint, by listening for DOM mutation events. It's not as clean, but I think it will work if you use it to clear and reset a 100-200 ms tineout. That shouldn't cause too much of a performance hit. When the timeout finally expires you know the page has been stable for at least that long.

_{[1] I spent a week chasing a global variable that went from undefined to defined during the execution of the onload handler. It turned out to be a script tag pulled in a JS file that had some top-level code and it was executing in parallel with the onload handler.}