1068678 - Add support for message manager in Mozmill

Status: RESOLVED WONTFIX

(Testing Graveyard :: Mozmill, defect, P1)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

As what Szabolcs found out we miss support for the message manager in Mozmill. That is necessary so we can pass messages between the chrome process and all the content processes.

Here some info from bug 1060238:

(In reply to Szabolcs Hubai (:xabolcs) from bug 1060238 comment #4)
> Created attachment 8490483 [details]
> POC Addon v0 - fueled with the original windows.js
> 
> Just uploading wbamberg's example addon injected with Mozmill's windows.js.
> 
> I uncommented almost all the dump statements. Should I uncomment the last
> two (map.update(), map.updatePageLoadStatus()) too?

(In reply to Szabolcs Hubai (:xabolcs) from bug 1060238 comment #5)
> Created attachment 8490489 [details]
> POC Addon WIP - fueled with MessageManager and frame scripts
> 
> Current version of the addon.
> 
> The greatest news is that the chrome script is able to respond an
> outerWindowID to frame script. :)
> 
> 
> Packed from the current head [1] of 'branch-bug-1060238-mm-poc' branch [2].
> 
> [1]
> https://github.com/xabolcs/e10s-example-addons/tree/
> 185e88dade10112c791f8e611cdabc73e1b9f9bd/run-script-in-all-pages/ported-
> message-manager/src
> [2]
> https://github.com/xabolcs/e10s-example-addons/tree/branch-bug-1060238-mm-
> poc/run-script-in-all-pages/ported-message-manager/src

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This is great. Seems like it will not be that hard to setup the communication. But I wonder how best we have to do that, and which parts of Mozmill will be affected here. I assume that for each element retrieval method in elementslib we would even need code in chrome and content.

I wonder how other add-ons are doing the communication between the chrome and content scope.

Mike, I haven't had the time to check any documentation. So if you would know a good lecture to read about that, we would appreciate any kind of feedback! Thanks!

Comment 2

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

Hey whimboo,

So we have a number of structures in place to let add-ons manipulate elements in the content process from the parent process.

The first structure is the most basic - CPOWs (cross-process object wrappers) use synchronous messaging from the parent to create proxy objects on the parent side to manipulate things. CPOW's aren't great for performance (they block the main thread), and are really just a stop-gap to allow some add-ons to continue to function until they're redesigned to use framescripts and messaging.

A CPOW begets other CPOWs - so, an example:

Suppose I have some remote <xul:browser> element called "browser". I can access the CPOW for the content document like this:

browser.contentDocumentAsCPOW

And then do things like:

let foo = browser.contentDocumentAsCPOW.getElementById("foo");
// foo is now a CPOW representing the element with id "foo" in the content process
foo.setAttribute("bar", true);
// This forwards a request to the child process that synchronously sets the "bar" attribute to true.

Using CPOWs directly is one possible technique - however, we also have a layer of "shims" that make this CPOW business more transparent specifically for add-ons.

When browser.tabs.remote.autostart is set to true, the shims are enabled, and allow us to intercept requests to various components, and mirror them on the child side, and set up forwarding.

The carrot is that these should "just work". The stick comes from the performance not being great, and we will soon be able to measure traffic across those shims to help figure out which add-ons are using them too much and need to be converted to using framescripts and messaging instead.

So, that's how some add-ons are able to communicate with the content scope - via CPOWs and the shims.

Good documentation to read about communications between chrome / content:

https://developer.mozilla.org/en-US/docs/The_message_manager
http://timtaubert.de/blog/2011/08/firefox-electrolysis-101/
http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/#cpows

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

So we had a meeting lately together with the A-Team about the e10 implementation work for Mozmill. As it turned out the work to do here is way too much, and we should better focus on getting Marionette ready for replacing Mozmill as what we wanted to do anyway. Therefore we have a new project up here: https://wiki.mozilla.org/Auto-tools/Projects/m21s.

I'm going to close this bug as wontfix.