905439 - Infrastructure for e10s addon compatibility code

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

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

Attachment: base-patch

It seems like a good idea to put this stuff in separate JSMs for the parent and child processes. This just sets that up.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Didn't notice this bug before commenting in the dependencies - I don't like having this stuff live in a separate layer, disconnected from the core code. Can we avoid that?

Comment 2

[:Gavin Sharp [email: [e-mail]]]

(see bug 905443 comment 4)

I still think we should avoid using this wherever possible (and I might want to bikeshed the name a little :), but I don't have any objection to landing it now.

Comment 3

[:Felipe Gomes (needinfo for replies!)]

Comment on attachment 790515 [details] [diff] [review]
base-patch

Review of attachment 790515 [details] [diff] [review]:
-----------------------------------------------------------------

What you think about making RemoteAddonsParent.init() to be in remote-browser.xml, and RemoteAddonsChild.init in browser-child.js?  This way you won't have to check for the e10s pref, and it will all live in toolkit.  But for that you will need to add a .initialized safeguard to RemoteAddonsParent too, so that only the first remote browser being created triggers it.

Comment 4

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

Thanks, I've made those changes.

https://hg.mozilla.org/integration/mozilla-inbound/rev/3937711b3e10

Comment 5

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/3937711b3e10