Changes

If you would like The simplest way to help out, please consult the is to file bugs when you find them. The tracking bugs are [https://bugzilla.mozilla.org/show_bug.cgi?id=fxe10s fxe10s] and [https://bugzilla.mozilla.org/show_bug.cgi?id=core-e10s core-e10s]. Most bugs in electrolysis occur because code in the chrome process tries to access data in a content process. All of the DOM objects for a XUL browser element, as well as its DocShell, live in the content process. Typical access paths are via <code>browser.contentWindow</code>, <code>browser.docShell</code>, or some variation of them. Often, these property accesses will generate errors in the console, which makes these bugs fairly easy to detect. The ideal way to solve these problems is with [https://developer.mozilla.org/en-US/docs/The_message_manager the message manager]. Any code that touches data in the content process should run in a content script. Content scripts communicate with chrome by message passing. Often, it's fairly easy to partition code into content and chrome portions and use message passing to communicate. However, there are cases where it is awkward to partition code in this way. In these cases, it may be beneficial to use [https://developer.mozilla.org/en-US/docs/Cross_Process_Object_Wrappers CPOWs]. CPOWs make it easy to transparently access content objects from chrome. The main drawback of CPOWs is that they are slow and they cause the chrome process to block, which can lead to jank. However, there are times when it might make sense to use CPOWs. For example, CPOWs are used to generate the menu items for the Firefox content menu. Creating the content menu sends a small number of CPOW messages since it doesn't touch the content document very much. And while the main event loop will be blocked while generating the menu, users are unlikely to notice since they're just waiting for the menu to appear.