I saw tests fail in bug 615386 because the in-process message-manager was delivering MozAfterPaint events differently than out-of-process (out-of-process was actually passing the test, in-process failing it). Tentatively marking as a blocker of bug 615386, but not a hard blocker. I can work around this, but I'd rather not (obviously). Test coming up. (smaug, please let me know if this is the preferred component for mm bugs.)

STR (1) Apply patch, rebuild (2) Run $ firefox -no-remote -chrome chrome://global/content/test-ipcbrowser.xul 2>&1 | grep '\[content\]' (3) Edit layout/ipc/test-ipcbrowser.xul so that the <browser> has remote="false" (4) Rebuild (5) Repeat step (2) The results I see are remote="true" [content] Saw MozAfterPaint for subdocument (data:text/html,<font%20color=red>old%20innermost) [content] Saw MozAfterPaint for subdocument (http://people.mozilla.com/~cjones/subdoc-inner.html) [content] Saw MozAfterPaint for document (http://people.mozilla.com/~cjones/subdoc.html) [content] Saw MozAfterPaint for subdocument (data:text/html,<body%20onload='function%20w(md,%20t)%20{%20%20%20%20t.p(0);%20%20%20%20md.write(t.replacementForMiddleFrame);%20%20%20%20t.p(3);%20%20%20%20t.p(md.documentElement.innerHTML);%20%20%20%20md.close();%20%20%20%20t.p(4);}w(parent.document,%20top);'><font%20color=blue>new%20innermost) [content] Saw MozAfterPaint for document (http://people.mozilla.com/~cjones/subdoc.html) remote="false" [content] Saw MozAfterPaint for document (http://people.mozilla.com/~cjones/subdoc.html) [content] Saw MozAfterPaint for subdocument (data:text/html,<body%20onload='function%20w(md,%20t)%20{%20%20%20%20t.p(0);%20%20%20%20md.write(t.replacementForMiddleFrame);%20%20%20%20t.p(3);%20%20%20%20t.p(md.documentElement.innerHTML);%20%20%20%20md.close();%20%20%20%20t.p(4);}w(parent.document,%20top);'><font%20color=blue>new%20innermost) I expect the events delivered to be the same for remote=true and =false. I can work around this in reftests by attaching my MozAfterPaint listener to the top-level window.

Also FTR, the test page linked from test-ipcbrowser.xul, http://people.mozilla.com/~cjones/subdoc.html, is just a slightly modified version of layout/reftests/bugs/212563-2.html.

Another data point: With remote="false" and this change to test-ipcbrowser-content.js, //addEventListener("MozAfterPaint", logMozAfterPaint, false); const CI = Components.interfaces; var gTopWindow = docShell.QueryInterface(CI.nsIDocShellTreeItem) .parent.QueryInterface(CI.nsIInterfaceRequestor) .getInterface(CI.nsIDOMWindow); gTopWindow.addEventListener("MozAfterPaint", logMozAfterPaint, false); I see the event log [content] Saw MozAfterPaint for subdocument (undefined) [content] Saw MozAfterPaint for document (http://people.mozilla.com/~cjones/subdoc.html) [content] Saw MozAfterPaint for subdocument (data:text/html,<body%20onload='function%20w(md,%20t)%20{%20%20%20%20t.p(0);%20%20%20%20md.write(t.replacementForMiddleFrame);%20%20%20%20t.p(3);%20%20%20%20t.p(md.documentElement.innerHTML);%20%20%20%20md.close();%20%20%20%20t.p(4);}w(parent.document,%20top);'><font%20color=blue>new%20innermost) [content] Saw MozAfterPaint for document (http://people.mozilla.com/~cjones/subdoc.html) [content] Saw MozAfterPaint for subdocument (undefined) which is different than either of the other two. *scratches head*

This is still untested.

For remote=false, this patch gives a fourth, different result. [content] Saw MozAfterPaint for document (http://people.mozilla.com/~cjones/subdoc.html) [content] Saw MozAfterPaint for subdocument (data:text/html,<body%20onload='function%20w(md,%20t)%20{%20%20%20%20t.p(0);%20%20%20%20md.write(t.replacementForMiddleFrame);%20%20%20%20t.p(3);%20%20%20%20t.p(md.documentElement.innerHTML);%20%20%20%20md.close();%20%20%20%20t.p(4);}w(parent.document,%20top);'><font%20color=blue>new%20innermost) [content] Saw MozAfterPaint for document (http://people.mozilla.com/~cjones/subdoc.html) This includes the MozAfterPaints important to this reftest (the ones to "document"), so ought to work. Will give a full rundown when other work settles.

I'm really not the right guy to review this change, but I can feedback+ that it seems to fix the reftest issue I saw. smaug, would roc perhaps be better?