<div dir="ltr"><div><div>I have a concern about this, although it's not related to this particular API.<br><br>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.<br><br></div>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.<br><br>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.<br><br></div><div>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.<br></div><div><br></div>--BDS<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 23, 2016 at 2:25 PM, 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">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>
<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.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>
</blockquote></div><br></div>