RFC: Add a way for System Add-ons to dynamically register handlers for nsIContentPermissionRequests

Mike Conley mconley at mozilla.com
Wed Sep 21 20:01:13 UTC 2016


Just following up here.

Paolo and I settled on an API for this work, which I just autolanded in bug
1297475. I've added a PermissionUI.jsm under browser/modules that has some
documentation on how to use it, and I've also modified the FlyWeb system
add-on to use the new mechanism to show its permission prompt.

Thanks all,

-Mike

On 6 September 2016 at 09:39, Mike Conley <mconley at mozilla.com> wrote:

> Hey bsmedberg,
>
> Sorry I didn't respond to this last week.
>
> >> Since we've identified this already as a pain point, would it make sense
> >> to do the work to build a real WebExtensions API surface for this? That
> >> way we're not perpetuating unfrozen XPCOM APIs and are making progress
> >> towards having system addons be webextensions.
> >>
> >> And if this is a total wrench in the works, or we'd implement a
> >> webextensions API on top of this XPCOM API change, then go for it! I
> >> don't mean to be stop-energy; I just want to make sure we're headed
> >> toward the new world and not taking steps backwards.
>
> The approach that paolo and I have gone with in bug 1297475 doesn't
> involve a change to any XPIDL's, thankfully. Instead, we're using the
> Integration.jsm module to expose a hook for extensions written in JS to
> supply permission handling. Writing a WebExtension API surface on this
> is certainly within the realm of possibility.
>
> All the best,
>
> -Mike
>
> On 29/08/2016 4:31 PM, Benjamin Smedberg wrote:
> > I have a concern about this, although it's not related to this
> > particular API.
> >
> > One of the big quality concerns about any old-style XPCOM/XUL addon, is
> > that they are not isolated from Firefox. So they currently put a fairly
> > large burden on QA to verify that these addons aren't accidentally
> > breaking Firefox or eachother.
> >
> > Our goal with system addons is that they will end up being written in
> > terms of webextensions APIs. We haven't put a date on this, but I'd like
> > us to be pretty aggressive about it.
> >
> > Since we've identified this already as a pain point, would it make sense
> > to do the work to build a real WebExtensions API surface for this? That
> > way we're not perpetuating unfrozen XPCOM APIs and are making progress
> > towards having system addons be webextensions.
> >
> > And if this is a total wrench in the works, or we'd implement a
> > webextensions API on top of this XPCOM API change, then go for it! I
> > don't mean to be stop-energy; I just want to make sure we're headed
> > toward the new world and not taking steps backwards.
> >
> > --BDS
> >
> > On Tue, Aug 23, 2016 at 2:25 PM, Mike Conley <mconley at mozilla.com
> > <mailto:mconley at mozilla.com>> wrote:
> >
> >     I just filed bug 1297475.
> >
> >     Here's the story:
> >
> >     Both bug 1292639 and bug 1289974 are currently in flight, and both
> >     involve requesting permission from the user to do something (open a
> >     server for FlyWeb, connect to a screen for Presentation API).
> >
> >     Both of those bugs are also implementing their UIs via the system
> add-on
> >     mechanism, especially since these are both somewhat experimental.
> >
> >     nsContentPermissionHelper and nsIContentPermissionRequest exist as a
> way
> >     for platform code to request permissions from the user, and this
> seems
> >     like the logical choice for both of these bugs.
> >
> >     The problem, however, is that our current nsIContentPermissionPrompt
> >     implementation requires that we manually add handlers for these
> >     permission request types. This means bleedover from the System
> Add-ons
> >     into the browser code. That's not unheard of (I believe Hello did
> this a
> >     bit), but we might want to try to avoid it.
> >
> >     What I suggest is that we alter nsIContentPermissionPrompt with
> methods
> >     for dynamically registering handlers for requests that might come up
> >     from content.
> >
> >     Normally I'd just go ahead and do this, but I know there's movement
> >     going on in the permission space right now (although I understand
> >     Control Center 2 is distinct from permissions), and I wanted to make
> >     sure I wasn't going to step on any toes before I did this.
> >
> >     Feedback? I'll put together a strawman patch in the meantime, but I
> hope
> >     to have something landable in the short-term to unblock both of these
> >     bugs unless there are any serious objections or concerns.
> >
> >     Thanks,
> >
> >     -Mike
> >     _______________________________________________
> >     firefox-dev mailing list
> >     firefox-dev at mozilla.org <mailto:firefox-dev at mozilla.org>
> >     https://mail.mozilla.org/listinfo/firefox-dev
> >     <https://mail.mozilla.org/listinfo/firefox-dev>
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20160921/e70e0c39/attachment-0001.html>


More information about the firefox-dev mailing list