On Thu, Jan 28, 2016 at 10:16 AM, Mike Conley <mcon...@mozilla.com> 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 <dtowns...@mozilla.com> 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 <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
> >
> _______________________________________________
> 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