Re: Unsafe CPOWs are about to be outlawed in browser code

[Kris Maglione]

On Tue, Feb 02, 2016 at 01:39:00AM +0300, Dmitry Gutov wrote:

On 02/02/2016 12:29 AM, Kris Maglione wrote:

That falls into the category of "unless it is calling browser code and
making it do something unsafe".


That's too bad. I'm just reusing a querying function from there, and a 
pretty small one.


It's not as small as you might think. In the best case, that 
function makes two CPOW calls, one for getElementsByTagName, and 
one to check its length. If any  tags are returned, it 
makes as many as 5 calls for each one, and a sixth for the first 
one that matches.


In the cases where the content process isn't blocked on sync 
message, any or all of those requests might go out while the 
content process is in the middle of executing a slow script. The 
contents of those elements could change between each call. The 
browser could navigate to a different page.


Yes, that will add some complexity. It seems I can just copy 
getDescriptionFromDocument's definition until I get around to 
supporting E10s properly.


You could, but it would really be better not to. Unsafe CPOW 
usage is called unsafe for a reason.


Should be a plus, but the user's just waiting for the action to 
complete at this point, so it's not like there are many other things 
for the browser process to do.


You might be surprised. In your case, the difference between 
making simultaneous asynchronous requests to look up existing 
bookmarks and to get the description, and making blocking, 
synchronous calls for both, could easily be the difference 
between the action appearing to complete immediately, and it 
taking, at the very least, a noticeable amount of time.


In the mean time, since you're blocking the event loop on the 
requests, it means that the UI is essentially frozen. Animations 
and roll-over effects are stopped. If the content process is in 
the middle of a slow script, and the hard drive is busy, the UI 
could easily be completely unresponsive for seconds at a time.


There are definitely worse times to do synchronous bookmark 
queries and unsafe CPOW requests than in response to a user 
clicking a button, but that doesn't mean they don't cause 
problems.


--
Kris Maglione
Firefox Add-ons Engineer
Mozilla Corporation

If C gives you enough rope to hang yourself, C++ gives you enough rope
to bind and gag your neighbourhood, rig the sails in a small ship and
still have enough rope left to hang yourself from the yardarm.
--Anonymous

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Unsafe CPOWs are about to be outlawed in browser code

[raaahh]

четверг, 28 января 2016 г., 19:57:59 UTC+3 пользователь Dave Townsend написал:
> 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.

Hi!

My addon is reportedly broken in the Nightly: 
https://github.com/dgutov/bmreplace/issues/32#issuecomment-176126946

It imports PlacesUIUtils.jsm and calls three functions from it, most notably 
PlacesUIUtils.getDescriptionFromDocument.

How do I "fix" that in the addon, aside for doing the big transition to an 
E10s-friendly architecture?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Unsafe CPOWs are about to be outlawed in browser code

[Dave Townsend]

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  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

Re: Unsafe CPOWs are about to be outlawed in browser code

[Bill McCloskey]

On Thu, Jan 28, 2016 at 10:16 AM, Mike Conley  wrote:

> Add-ons that are not yet marked multi-process compatible will use our
> shimming layer, which allows usage of unsafe CPOWs within add-on code /
> compartments.
>
> At least part of the problem here appears to be that FireGestures has
> "multiprocessCompatible" set to true in its install.rdf:
>
>
> https://github.com/gomita/firegestures/blob/7bd7db329c985dece9717105b07ede6303827a3d/install.rdf#L317
>
> This will cause it to bypass our shim layer, which means it doesn't get a
> free pass on using CPOWs anymore.
>

I'm not sure this is the problem. The patch in bug 1233497 just looks at
whether an add-on is making the CPOW request. It doesn't know anything
about shims or multiprocessCompatible.


>
> I'll see if I can make some recommendations to that add-on author in the
> associated GitHub issue: https://github.com/gomita/firegestures/issues/116
>
> On 28 January 2016 at 11:57, Dave Townsend  wrote:
>
> > 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 
> 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/
> 

Re: Unsafe CPOWs are about to be outlawed in browser code

[Honza Bambas]

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

Re: Unsafe CPOWs are about to be outlawed in browser code

[Mike Conley]

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