I don't think that this is meant to impact add-on code at all, unless
it is calling browser code and making it do something unsafe, in which
case it would be up to the add-on developer to fix that. It's probably
worth filing a bug to track what is going on there though.

On Thu, Jan 28, 2016 at 6:36 AM, Honza Bambas <hbam...@mozilla.com> wrote:
> Do we have any agenda for extensions? I'm using FireGestures and it's broken
> since this has landed, just shouting out a lot of "unsafe CPOW usage"
> (missing the "forbidden" tho).
>
> Is the action here limited to just file a bug on the add-on side to fix this
> or can we do anything on our side?  (I presume and also support that add-ons
> should be fixed here.)
>
> Thanks.
>
> -hb-
>
>
> On 1/27/2016 17:42, Mike Conley wrote:
>>
>> The spaghetti was put in the machine last night - this work has now
>> landed on mozilla-central.
>>
>> If you start seeing "unsafe CPOW usage forbidden" in the Browser Console
>> for various things, please mark them blocking bug 1233497.
>>
>> Thanks all,
>>
>> -Mike
>>
>> On 20/01/2016 3:54 PM, Mike Conley wrote:
>>>
>>> (cross-posted to both dev-platform and firefox-dev)
>>> *
>>> *
>>> TL;DR: Shortly, I’ll be flipping a pref to outlaw unsafe CPOWs in almost
>>> all browser code. Unsafe CPOWs inside add-on scopes should continue to
>>> work properly. If you start seeing "unsafe CPOW usage forbidden” errors
>>> being throw for a feature you’re working on in the Browser Console, it’s
>>> because unsafe CPOWs have been outlawed and you should stop using them.
>>> Talk to me if you run into problems.
>>>
>>> Details:
>>>
>>> “unsafe” CPOWs[1][2] are CPOWs that are accessed when the other process
>>> is not currently blocked waiting for information from you. For example,
>>> if you access gBrowser.selectedBrowser.contentDocumentAsCPOW.body when
>>> the content process is garbage collecting, the parent will be blocked
>>> until the child decides that it has a moment to service the synchronous
>>> message and return the information that the parent needs. Unsafe CPOWS
>>> are generally pretty horrible for performance, especially because we
>>> cannot know what state the other process is in.
>>>
>>> “safe” CPOWs are when the other process is in a known blocked state -
>>> for example, the content process sends a synchronous message to the
>>> parent asking for some information, and is blocked waiting for a
>>> response. The parent then accesses CPOWs in the content process safely,
>>> because the content process is in a known state. The only overhead here
>>> is the IPC traffic.
>>>
>>> “unsafe” CPOWs are often used by add-ons to synchronously manipulate
>>> content. A year or so back, a bunch of browser code also used unsafe
>>> CPOWs in this way, but we’ve been slowly but surely weeding them out.
>>> We’re at the state now where we believe we’ve eliminated most of the
>>> in-browser unsafe CPOW uses[3].
>>>
>>> Within the next day or so, I’m going to be landing bug 1233497[4] which
>>> will cause unsafe CPOW usage in non-addon browser code to throw. In the
>>> event that this breaks things horribly, there is a pref[5] that we can
>>> flip to turn unsafe CPOWs back on while we fix things.
>>>
>>> Again, this work is occurring in bug 1233497[4]. If there are any major
>>> concerns, please bring them up here before I throw the spaghetti into
>>> the machine.
>>>
>>> For more details on unsafe CPOWs, please read [1] and/or [2].
>>>
>>> [1]:
>>> https://mikeconley.ca/blog/2015/02/17/on-unsafe-cpow-usage-in-firefox-desktop-and-why-is-my-nightly-so-sluggish-with-e10s-enabled/
>>>
>>> [2]: http://blog.lassey.us/2015/01/10/unsafe-cpow-usage/
>>> [3]: Outside of tests, and a few other little things that there are
>>> follow-ups for.
>>> [4]: https://bugzilla.mozilla.org/show_bug.cgi?id=1233497
>>> [5]: dom.ipc.cpows.forbid-unsafe-from-browser
>>>
>> _______________________________________________
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>
>
>
> _______________________________________________
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to