The idea is to disable CPOWs in compartments associated with add-ons that are multiprocessCompatible. That will guarantee that these add-ons aren't getting CPOWs through some accidental route (i.e., something other than the shims).
3 years ago
Assignee: nobody → wmccloskey
Summary: [e10s] Forbid CPOW usage is add-on declares it is multiprocessCompatible → [e10s] Forbid CPOW usage if add-on declares it is multiprocessCompatible
We're getting back some data showing that add-ons are setting multiprocessCompatible but still using CPOWs. This patch will prevent that. It's enabled in two ways: 1. Unless we set dom.ipc.cpows.forbid-cpows-in-compat-addons, it does nothing. 2. If that pref is set, then we check if the add-on ID is listed in dom.ipc.cpows.allow-cpows-in-compat-addons. If it is, then the patch does nothing. Otherwise we block the CPOW. The patch also will collect telemetry about which add-ons marked as being compatible use CPOWs. We can use this to generate the initial whitelist and then contact those add-on authors.
Attachment #8764442 - Flags: review?(mrbkap)
Attachment #8764442 - Flags: review?(mrbkap) → review+
3 years ago
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/14928a6b38f3 Forbid CPOW usage if add-on declares it is multiprocessCompatible (r=mrbkap)
e10s debug devtools (which means Mac and Win7, those being the only place they run), leaked a StringBuffer, https://treeherder.mozilla.org/logviewer.html#?job_id=31029495&repo=mozilla-inbound Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/0a03bb6af6043ce323142d24fb43c2d63deefbcb
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/960aa6832bf7 Forbid CPOW usage if add-on declares it is multiprocessCompatible (r=mrbkap)
You need to log in before you can comment on or make changes to this bug.