Unexpected CPOWs are CPOWs that are sent when the content process isn't known to be blocking on the parent. For example, CPOWs used when constructing the context menu are *not* unexpected because the child process is known to be blocking here: http://mxr.mozilla.org/mozilla-central/source/browser/base/content/content.js?rev=81daac845113#125 We use lots of unexpected CPOWs though. Searching for "AsCPOW" yields many hits. Here are some examples: 1. Session store flush operations send unexpected CPOWs when closing a tab or a window. This can cause jank. 2. isTabEmpty can send unexpected CPOWs. 3. Any access to browser.sessionHistory sends a CPOW, such as the back/fwd buttons. 4. The page style menu. 5. Selecting some context menu operations uses CPOWs. Examples are "View Source" and "Save Page As". 6. The Page Info window. Unexpected CPOWs can cause jank and we'd like to phase them out over time. We should fix these in order of how often they're used. In some cases unexpected CPOWs can be turned into expected CPOWs by synchronizing with the child process first. In other cases it's probably easier to avoid CPOWs entirely. Much of the UI work can be done by hiding menus until we've received a response from the child while still processing events.

If you search for the phrase "SyncHandler" you'll find a few more of these. One use is to figure out the focus in the content process.

I've started filing crash bugs on some of these. It's a bit tough since the signature gets dumped into a grab bag of crashes, but you can search through those to find the individual callers.

(In reply to Jim Mathies [:jimm] from comment #2) > I've started filing crash bugs on some of these. It's a bit tough since the > signature gets dumped into a grab bag of crashes, but you can search through > those to find the individual callers. I don't think those are related. They're caused by add-ons and they're not unexpected CPOWs. You can see because sendRpcMessage is on the stack.

(In reply to Bill McCloskey (:billm) from comment #3) > (In reply to Jim Mathies [:jimm] from comment #2) > > I've started filing crash bugs on some of these. It's a bit tough since the > > signature gets dumped into a grab bag of crashes, but you can search through > > those to find the individual callers. > > I don't think those are related. They're caused by add-ons and they're not > unexpected CPOWs. You can see because sendRpcMessage is on the stack. Isn't PJavaScriptChild cpow related?

Yes, but the goal of this bug is not to remove all CPOWs. It's just to remove so-called unexpected CPOWs in the Firefox frontend code.

The add-on I wrote and posted in bug 1109713 is helping me to detect more unsafe CPOWs in browser code, in case anybody else wants to give it a shot. I'll file a few more tonight.

Is CPOW usage being used to drive the "Addon might be making nightly run slowly" popup? (I wanted to ask this on your blog, but you don't allow comments)

(In reply to Mike Kaply [:mkaply] from comment #8) > Is CPOW usage being used to drive the "Addon might be making nightly run > slowly" popup? > > (I wanted to ask this on your blog, but you don't allow comments) No, that's driven by time spent in a compartment. See bug 1071880 for more details.