Advertisement
Guest User

Untitled

a guest
Jan 29th, 2016
280
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 2.52 KB | None | 0 0
  1.  
  2. TL;DR: Shortly, I’ll be flipping a pref to outlaw unsafe CPOWs in almost
  3. all browser code. Unsafe CPOWs inside add-on scopes should continue to work
  4. properly. If you start seeing "unsafe CPOW usage forbidden” errors being
  5. throw for a feature you’re working on in the Browser Console, it’s because
  6. unsafe CPOWs have been outlawed and you should stop using them. Talk to me
  7. if you run into problems.
  8.  
  9. Details:
  10.  
  11. “unsafe” CPOWs[1][2] are CPOWs that are accessed when the other process is
  12. not currently blocked waiting for information from you. For example, if you
  13. access gBrowser.selectedBrowser.contentDocumentAsCPOW.body when the content
  14. process is garbage collecting, the parent will be blocked until the child
  15. decides that it has a moment to service the synchronous message and return
  16. the information that the parent needs. Unsafe CPOWS are generally pretty
  17. horrible for performance, especially because we cannot know what state the
  18. other process is in.
  19.  
  20. “safe” CPOWs are when the other process is in a known blocked state - for
  21. example, the content process sends a synchronous message to the parent
  22. asking for some information, and is blocked waiting for a response. The
  23. parent then accesses CPOWs in the content process safely, because the
  24. content process is in a known state. The only overhead here is the IPC
  25. traffic.
  26.  
  27. “unsafe” CPOWs are often used by add-ons to synchronously manipulate
  28. content. A year or so back, a bunch of browser code also used unsafe CPOWs
  29. in this way, but we’ve been slowly but surely weeding them out. We’re at
  30. the state now where we believe we’ve eliminated most of the in-browser
  31. unsafe CPOW uses[3].
  32.  
  33. Within the next day or so, I’m going to be landing bug 1233497[4] which
  34. will cause unsafe CPOW usage in non-addon browser code to throw. In the
  35. event that this breaks things horribly, there is a pref[5] that we can flip
  36. to turn unsafe CPOWs back on while we fix things.
  37.  
  38. Again, this work is occurring in bug 1233497[4]. If there are any major
  39. concerns, please bring them up here before I throw the spaghetti into the
  40. machine.
  41.  
  42. For more details on unsafe CPOWs, please read [1] and/or [2].
  43.  
  44. [1]:
  45. https://mikeconley.ca/blog/2015/02/17/on-unsafe-cpow-usage-in-firefox-desktop-and-why-is-my-nightly-so-sluggish-with-e10s-enabled/
  46. [2]: http://blog.lassey.us/2015/01/10/unsafe-cpow-usage/
  47. [3]: Outside of tests, and a few other little things that there are
  48. follow-ups for.
  49. [4]: https://bugzilla.mozilla.org/show_bug.cgi?id=1233497
  50. [5]: dom.ipc.cpows.forbid-unsafe-from-browser
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement