Currently ShumwayStreamConverter creates channel with resource:// permissions that contains Shumway "webapp". Currently the stream converter's chrome code is using DOM events [2] and [3] and window.postMessage [4] to communicate with the webapp to provide such functionality as cross domain I/O, clipboard and external interface. It will be nice to move entire logic into the content with elevated permissions. At the moment, I think we can create intermediate "chrome://" hosted page and illuminate events/postMessage communication replacing them with message listeners and CPOW for OOP, see [5]. At the moment the page will host iframe that will point to the resource:// Shumway webapp. In the future I expect to move all logic that requires elevated permissions to this page out of the stream converter code. (That might simplify testing and development of this code as well) Also the solution at the bug 558184 expects that plugin code will start from some "chrome://" page -- that will make transition easier. [1] http://mxr.mozilla.org/mozilla-central/source/browser/extensions/shumway/content/ShumwayStreamConverter.jsm#1027 [2] http://mxr.mozilla.org/mozilla-central/source/browser/extensions/shumway/content/ShumwayStreamConverter.jsm#1018 [3] http://mxr.mozilla.org/mozilla-central/source/browser/extensions/shumway/content/ShumwayStreamConverter.jsm#783 [4] http://mxr.mozilla.org/mozilla-central/source/browser/extensions/shumway/content/ShumwayStreamConverter.jsm#384 [5] https://github.com/mozilla/shumway/pull/1835

Dave, can you provide feedback for this approach? I want to apply the same to the pdf.js in the future. Have chrome:// resources the same behavior in the e10s frames as in non-e10s?

Sounds like a good plan to me. chrome:// should run fine in e10s though XUL isn't available there.

Make bugs with "[shumway-fb2]" whiteboard tag block shumway-fb2 meta bug 1110300.

That's fixed (by https://github.com/mozilla/shumway/pull/1835), rest of that will be addressed by jsplugins (e.g. bug 1092119 or bug 944929).