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