RFC: Add a way for System Add-ons to dynamically register handlers for nsIContentPermissionRequests
mconley at mozilla.com
Tue Sep 6 13:39:41 UTC 2016
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,
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.
> 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.
> firefox-dev mailing list
> firefox-dev at mozilla.org <mailto:firefox-dev at mozilla.org>
More information about the firefox-dev