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

Mike Conley mconley at mozilla.com
Tue Sep 6 13:39:41 UTC 2016


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



More information about the firefox-dev mailing list