This is one (somewhat heavy-handed) approach we've considered for bug 847592. At the very least, if this approach solves our problem, it would help us understand what's going wrong. I have a wip patch for this that seems to work...

This patch is based on a previous patch where I changed CPU priorities, so the language still speaks about lowering a process's CPU priority. Read that as "stop sending and receiving messages from it".

Do we want to do this? It feels to me like this cure may be worse than the disease, because it will cause the phone to completely freeze for a second or two until we handle the call, but it probably would fix bug 847592 in many cases. We're still not protected from the case when the browser process spins the CPU e.g. in a JS loop. With a simple testcase that spins the CPU (http://bit.ly/mozloop), I can get a ~3s delay. I suspect that if I was doing graphics-intensive stuff which put a burden on the main-process compositor, I could get a longer delay. I'm not sure who should be making this UX call, particularly in light of the time-frame we have (I don't even know what the precise timeframe is, to be honest). jst, can you please advise as to who decides whether this is an acceptable solution?

I think this decision ultimately comes down to a combination of sicking, bent, and release drivers as to whether we want to take the risk in making a change like this at this late a time. Personally I'd be ok with taking this change, but I'm not exactly an expert in this field.

I think we can wontfix this; it looks like what we have in bug 870480 was the missing piece here.