1109869 - [e10s] [meta] Eliminate uses of "unexpected" CPOWs in Firefox

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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.

Comment 1

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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.

Comment 2

[Jim Mathies [:jimm]]

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.

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

(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.

Comment 4

[Jim Mathies [:jimm]]

(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?

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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.

Comment 7

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 8

[Mike Kaply [:mkaply]]

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)

Comment 9

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(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.

Comment 10

[:Gijs (he/him)]

No more open deps, wheee