Re: How do I inject the WebExtensions API into a ?

[Andrew Swan]

Geoff,

First, I'm moving this over to dev-addons since it is about the internals
of the webextensions implementation and probably not of interest to many of
the people on dev-platform.  Anybody from dev-platform who is interested,
feel free to follow us over to dev-addons.

The short answer is that the ExtensionPolicyService observes
"document-element-inserted" and, for every document created with an
extension principal (ie, for moz-extension: pages), it calls this function:
https://searchfox.org/mozilla-central/rev/55da592d85c2baf8d8818010c41d9738c97013d2/toolkit/components/extensions/extension-process-script.js#275-282

If you trace the calls made from there, you'll eventually end up here,
which is where the actual "browser" and "chrome" objects are created:
https://searchfox.org/mozilla-central/rev/55da592d85c2baf8d8818010c41d9738c97013d2/toolkit/components/extensions/ExtensionPageChild.jsm#170-183

I've glossed over several steps, I'm happy to answer further questions on
dev-addons or in #webextensions on IRC

-Andrew


On Tue, Aug 28, 2018 at 1:54 AM, Geoff Lankow  wrote:

>
> I'm trying to make WebExtensions usable on Thunderbird. My current problem
> is trying to make moz-extension:// pages work in the UI. Everything happens
> as expected except the page has no access to the "browser" API.
>
> Can somebody show me how to set things up so the API is added to new
> browser elements and available when it should be?
>
> GL
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New prefs parser has landed

[Andrew Swan]

On Thu, Feb 1, 2018 at 4:32 PM, Xidorn Quan  wrote:

> What do we show when we disable legacy addons? We can probably borrow
> whatever we did there.
>

There is no explicit notification for disabled legacy addons (you can see
them in about:addons but you have to know to go look there)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Still-supported cases of out-of-tree XPCOM code?

[Andrew Swan]

On Wed, Nov 15, 2017 at 6:12 AM, Henri Sivonen  wrote:

> How many Mozilla-signed special extensions are there? Does an analog
> of https://dxr.mozilla.org/addons/ exist for searching their code?


Unfortunately there is not an index of them.  andym could provide a
complete list but off the top of my head there are two big categories
(shield and test pilot) plus a handful of one-off things including
containers, cliqz, and maybe devtools?  Then there are system addons, but
at least the distributed versions of those should be tested in automation.


> Is
> there a CI system testing that the continue to work?
>

No and this is something I've tried to impress upon people working out of
tree.  Cliqz has already been bitten by this and we had a previous row on
this mailing list about CI for devtools when it moves out of tree.  This
remains an unsolved problem.  The long-term (medium-term?) goal is just to
get these things all off of using bootstrapped extensions.

-Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Change in the way e10s and multi are enabled on Nightly

[Andrew Swan]

On Wed, Oct 18, 2017 at 3:22 PM, Justin Dolske  wrote:

> On Wed, Oct 18, 2017 at 11:52 AM, Blake Kaplan  wrote:
>
>>
>> One more thing to point out: with the removal of e10srollout, I also
>> removed the code that would disable e10s if we detected a
>> non-multiprocessComptaible extension. We are entirely relying on the addon
>> manager to refuse to install such extensions.
>>
>>
> If someone on a pre-release channel enables legacy addons, will that still
> refuse to load non-E10S compatible addons? (I hope so?)
>

Legacy extensions can only be enabled on nightly and unbranded builds (not
on beta).  On Nightly, a non-MPC extension won't load unless you also flip
the preference extensions.allow-non-mpc-extensions.  If both those prefs
are flipped on Nightly, we will load the extension with shims enabled but
will not disable e10s.

Why don't we rip this all out you ask?  We're still using shims in
automation, see bug 1351512.  If anybody reading this has some spare cycles
(ha) and wants to do a good deed, you should be able to find remaining uses
by running tests with extensions.interposition.enabled set to false and
tracing resulting failures...

-Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Retaining Nightly users after disabling of legacy extensions

[Andrew Swan]

On Thu, Aug 24, 2017 at 12:03 AM, Alessio Placitelli <
aplacite...@mozilla.com> wrote:

> 2017-08-24 0:00 GMT+02:00 Andrew McKay :
> > The recommendations are being populated and other changes are being
> > made. For example, on September 1st only WebExtensions will be
> > featured on AMO (as opposed to extensions that expect to upgrade).
>
>
> Does that mean that AMO won't show nor have data for any legacy addon?
>

No, "featured" in this context means extensions that are shown in the
curated list of "Featured Extensions" on the AMO home page.
I don't recall a timeline being announced for actually removing legacy
extensions from AMO.  Jorge provided some more detail in a recent blog post:
https://blog.mozilla.org/addons/2017/08/10/upcoming-changes-compatibility/

-Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Retaining Nightly users after disabling of legacy extensions

[Andrew Swan]

On Mon, Aug 14, 2017 at 6:16 AM, Honza Bambas  wrote:

> Ed already mentioned that the addons manager doesn't automatically suggest
> or even update to webext alternatives.  We really should have something
> like this SOON - the more automatic or fluent the better.


There is a "find a replacement" button next to disabled legacy extensions
in about:addons.  Ed's original comment was that if, eg, Adblock Plus has a
legacy version and a webextension version, we don't automatically direct
users with the disabled legacy version to the webextension.  That's mostly
because we don't actually have a straightforward way to do so, but it's
also only an issue for users on non-release channels.

-Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: Legacy extensions disabled by default on Nightly

[Andrew Swan]

After lots of recent discussion, it is finally happening.  The patch to
flip the default setting to disallow legacy extensions is in autoland at
the moment and, barring some snafu, should be in tomorrow's Nightly
builds.  This is a bit anti-climactic since a few other changes that have
already landed that broke a bunch of existing extensions.

Also this has been discussed in a few other threads but repeating here for
folks that may have missed it: there is a preference that Nightly users can
flip to re-enable loading of legacy extensions in the addons manager (of
course this setting won't magically make extensions that rely on the sdk or
any changed internal interfaces work).  We will continue to honor this
preference in Nightly builds and in unbranded builds, but when 57 (and
later versions) go to beta and eventually to release, that preference will
be ignored.  If you're familiar with addon signing and the circumstances in
which we allow it to be disabled, legacy extensions are handled in the same
way.

If you notice any problems or have questions, you can contact me directly,
use the dev-addons mailing list, or drop into #webextensions on IRC.

:highfive:s all around!

-Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Andrew Swan]

On Mon, Aug 7, 2017 at 10:05 AM, Kris Maglione 
wrote:

> At the moment, legacy add-ons are allowed on nightly, but are officially
> unsupported. We're planning to disable them by default on nightlies, but it
> will still be possible to enable them by flipping a pref.


And we didn't mean to create unnecessary suspense around this, there are a
few loose ends related to things like test pilot, shield, etc. that need to
be tied up before we flip the default on Nightly.  But that should happen
later this week.  The main tracker is bug 1336576 if you'd like to follow
along.

-Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Extensions and Gecko specific APIs

[Andrew Swan]

Sorry for the slow reply, I was half-waiting to see if anybody else would
jump in but I guess product managers don't follow dev-platform :)

I think we're mostly in sync on most of the nuts and bolts and the
unresolved topics are generally pretty high-level concerns.

On Thu, Jul 27, 2017 at 10:02 AM, Steve Fink  wrote:

> Unfortunately, there isn't anything written that explains actual criteria
> in detail (its on our radar but somewhere behind a long list of engineering
> tasks on the short-term priority list).
>
>
> And I guess the parenthetical clause is what worries me. The people
> churning through that workload should be churning through that workload,
> and it's fine that they aren't spending time and mental space on the
> theoretical concerns of future compatibility issues or addon developer
> relations. But this is kind of a big deal for Mozilla strategically, so I
> would expect someone else to be working on the strategic plan before we
> reach the foot-shooting point.
>
> Hopefully, that someone would be in close contact with the engineers doing
> the work, since they have the best context and familiarity with large parts
> of the problem space, and hence their opinions deserve a lot of weight. As
> long as the consultation doesn't get in the way of getting stuff done.
> There's a ton of weight on you people's shoulders, and we don't want to add
> more.
>
> One person can do both strategy and tactics (or implementation) just fine,
> but it's usually not a good idea to do them at the same time. Different
> mindset, different tradeoffs.
>


Again, documenting more formally specifically what it means for an
> extension API to be safe, maintainable, performant, etc. is something we
> know is needed.  Hopefully when we come up for air after 57 we can work on
> this (and complementary things like webextensions experiments).
>
>
> Yeah, that's not really what I'm talking about. In a way, that's the hard
> part. But it's unavoidable, and it's happening in practice, and I'm sure
> there'll be a lag in formalization while things are taking shape. That's
> probably a good thing, since it'll require experience to flesh these things
> out.
>
> But that's about individual APIs. I want high-level answers to the
> simultaneous questions "How are we going to expose sufficient functionality
> to provide extension authors with what they need?" and "How are we going to
> avoid shooting ourselves in the foot when we get further down the road?"
> The sort of things you read in high-level strategy documents that set down
> the goals, direction, and approach to known obstacles. (Not that I
> necessarily want such a document; they're boring and make for dull reading,
> and I'm always suspicious as to whether anyone's paying attention to them.
> But I want the thinking behind it.)
>

I think the basic principles here are pretty simple and I tried to lay them
out before.  We're drawing a line and saying that we'll only expose things
to WebExtensions that can be done in a way that is safe for users and
maintainable for us (ie the people that work on gecko/firefox).  Within
those boundaries, we're willing to provide whatever extension authors
need.  Exactly how the terms "safe for users" and "maintainable for us" are
defined is mostly an engineering decision (and occasionally a product or UX
decision) and to be frank, we're still nailing down exactly how strict we
should be (for what its worth I think we've personally been relatively
conservative thus far).

Anyway, I think the real strategy questions are about how much we will
invest in building these APIs ourselves -- every engineer who is working on
extension APIs is an engineer who is not working on performance or other
new features.  A related question is who exactly should be creating
extension APIs.  We have a dedicated team right now in the midst of a big
blitz to bootstrap (no pun intended) the whole WebExtensions platform but
in the longer term I think it makes a lot more sense for engineers who know
individual areas of the code well to be the ones creating extension APIs
that touch those areas.  On the other hand, that's adding to everybody's
already overfull workloads.  This is a fine problem for engineering
management to wrestle with while the rest of us keep busy writing code :)

For further discussion about the longer term strategy, I would suggest
following up with Kev Needham who oversees all of addons.  Also, Mike Conca
just started as the product manager for WebExtensions.  But to be fair to
him, he's now in his second full week here and if his experience is
anything like mine was, he's still just trying not to get knocked down by
the Mozilla-newcomer-firehose.

-Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Extensions and Gecko specific APIs

[Andrew Swan]

On Wed, Jul 26, 2017 at 4:27 PM, Steve Fink  wrote:

> This thread worries me greatly. Somebody tell me we have a plan and policy
> around this already. Please?
>

We might, but I'm not sure what "this" you're concerned about.  Whether API
names should be prefixed?  Or whether we should expose things at all that
are unique to gecko/firefox to extensions?  There are a whole bunch of
things that get considered when new extension APIs are proposed including
safety, maintainability, performance, and yes, cross-browser
compatibility.  Unfortunately, there isn't anything written that explains
actual criteria in detail (its on our radar but somewhere behind a long
list of engineering tasks on the short-term priority list).

My individual opinion is that something being unique to gecko or firefox
should not disqualify it from being exposed to extensions.  The webcompat
analogy doesn't really work here, the principle that the web should be open
and interoperable demands rigor in what gets exposed to content.  But a
browser extension isn't a web page, it is part of the browser itself, and
different browsers are inherently ... different.  They have different
features, different user interfaces, etc.  The fact that browser extensions
are built with web technology and that they modify or extend the very thing
that displays web content obscures this distinction, but it does make a big
difference.

Anyway, containers is a good example of something that we've exposed to
extensions that isn't likely to be supported in other browsers any time
soon.  Nevertheless, we need to design APIs in a way that doesn't
compromise on the other areas mentioned above: maintainability, safety,
performance.  And, to the extent we can, we should design APIs that could
be adopted by other browsers if they choose to.


> Given our position, it's a bold move that says we're willing to take the
> painful hit of pissing off addon authors and users because we truly believe
> it is necessary to produce a top-quality product.


There are certainly outraged addon authors out there but for what its
worth, we're also already getting a good amount of positive feedback from
both addon authors and users.

That's my argument for why the default answer here should be "Heck yeah! If
> we can provide something that other browsers don't, DO IT!" I could
> describe it as a fairness/good faith argument instead: we just took away a
> bunch of powerful tools from our users, claiming that it was for their own
> long-term good, so it behooves us to give back whatever we can in a more
> manageable form, in order to provide that promised good.
>

I think that's basically the attitude of most of the people working on
webextensions.  To be pedantic, the threshold is higher than "If we can".
I mean, we *could* expose Components to webextensions but of course that
would bring us right back to all the problems we're working on putting
behind us.  Again, documenting more formally specifically what it means for
an extension API to be safe, maintainable, performant, etc. is something we
know is needed.  Hopefully when we come up for air after 57 we can work on
this (and complementary things like webextensions experiments).

-Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: removing "the old way" of signing add-ons

[Andrew Swan]

On Wed, Jul 26, 2017 at 2:49 AM, Frank-Rainer Grahl  wrote:

> I need to look at the notifications for SeaMonkey anyway but how could
> Thunderbird implement the standard doorhanger with no location bar? I think
> the dialog should be retained for projects which do not have a location bar
> and/or tabbrowser.


That was poorly worded -- these applications should create listeners for
the various events that are generated during the install process.  Whether
you try to adapt the Firefox doorhangers somehow or keep some version of
the current dialog (but apropos the original message in this thread, even
that is likely to change) doesn't matter to me, but the existing code that
displays a modal xul dialog from the guts of the addons manager isn't long
for this world...

This is straying off-topic for dev-platform, please follow up with me
individually or on the dev-addons list if you have more questions.

-Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Extensions and Gecko specific APIs

[Andrew Swan]

I believe that Gabor's response to the original question nicely captures
the thinking and plans of everybody working on WebExtensions day-to-day.
The questions about formally defining a policy for what to expose to
extensions and about how to (or if we should) distinguish Firefox-specific
APIs from cross-platform APIs are ones that we have talked about a little
bit but we've been heads-down on our goals for the breadth, stability, and
performance of WebExtensions for 57 when we turn off legacy extensions.

For handling cross-platform versus Firefox-specific APIs, I don't think the
right outcome is perfectly clear.  Of course we should learn from how
web-exposed APIs evolved and avoid the need for the browser extensions
equivalent of jquery.  On the other hand, browser extensions by their
nature work with features that are not standardized and that differ from
browser to browser.  For instance, we have WebExtensions APIs for working
with containers.  There's no doubt in my mind that we should have this API
but of course extensions that use it won't work in other browsers.  Maybe
in this case some sort of moz- prefix would be appropriate but its not hard
to come up with murkier examples.  What about the tabs API?  It is
currently supported in Firefox, Chrome, Edge, and Opera.  But what if one
of the non-tab-based-browser-ui projects takes off and wants to support
browser extensions?  If they simply don't support the tabs API then how
should the API be named to indicate to extension developers that it isn't
universally available?

We're just reaching the point where it is feasible to build interesting
cross-browser extensions and extension authors are starting to ask us to
make it easier to do so.  We've got plenty of other simple things we can do
to make their lives easier (for instance extensions APIs in Chrome all use
callbacks, in Firefox they can use Promises or callbacks, and in Edge they
only use Promises) but this problem of naming/disocvering/etc APIS is a big
architectural issue to work out.  Hopefully when the dust begins to settle
on 57 we can put some energy into this.  For anybody who's interested, we
have the dev-addons mailing list and the #webextensions IRC channel for
Mozilla-specific discussion and the w3c browserext group (
https://browserext.github.io/) for cross-vendor efforts.

Finally, to circle back once again to smaug's original question, I think we
can be more liberal with exposing APIs to extensions than we are with
exposing them to content -- enabling cross-browser extensions is an
important benefit of WebExtensions but limiting WebExtensions APIs to only
those that can run in every browser has never been a goal (in spite of what
you may have read on hacker news).  If we overdo it, we even have a draft
of a policy for deprecating APIs:
https://wiki.mozilla.org/WebExtensions/DeprecationPolicy  I think its much
more important that we take care when designing extension-facing APIs to
ensure that extensions can't do anything "dangerous" by default and that
they are granted access to sensitive parts of the browser, only when we can
explain very clearly to a user so that they can make an informed choice
whether to grant permission or not.

-Andrew


On Tue, Jul 25, 2017 at 2:14 AM, smaug  wrote:

> Hi all,
>
>
> recently in couple of bugs there has been requests to add Gecko specific
> APIs for extensions.
> It isn't clear to me why, and even less clear to me is what the plan is
> there.
> I thought WebExtensions should work in several browsers, but the more we
> add Gecko specific APIs, the less likely
> that will be.
>
> Could someone familiar WebExtensions clarify this a bit? Do we have some
> policy here. Should we be as strict as with web APIs, or allow some
> exceptions or do whatever people want/need?
>
>
>
>
> -Olli
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: removing "the old way" of signing add-ons

[Andrew Swan]

On Fri, Jul 21, 2017 at 12:32 AM, Jörg Knobloch  wrote:

> Since you're saying that we're still using the old interface, in fact
> Andrew said: "old add-on install
> confirmation dialog, that dialog includes a note about the certificate",
> would you be able to give us some exact DXR references which would save us
> a lot of searching.
>

The dialog I mentioned is:
https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/content/xpinstallConfirm.xul

The listbox in that dialog holds instances of:
https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/content/xpinstallItem.xml

The label in those items with the class "xpinstallItemSigned" ends up
holding either certificate details or some default message like "Author not
verified"

While we're on the topic, Thunderbird and Seamonkey should look at moving
over to the doorhanger addon install flow that Firefox uses -- that xul
dialog and everything that supports it are unused in Firefox and its days
are numbered.

-Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: removing "the old way" of signing add-ons

[Andrew Swan]

On Wed, Jul 19, 2017 at 5:02 PM, R Kent James  wrote:

> On 7/19/2017 4:06 PM, David Keeler wrote:
>
>> [dev-apps-thunderbird and dev-apps-seamonkey cc'd, but please discuss on
>> dev-platform]
>>
> ...
>
>> Given all this, the question is do we still need this second API? Does
>> Thunderbird or SeaMonkey use it for any reason, or can we simplify the
>> code-base, reduce build size, etc.?
>>
>
> Thunderbird never implemented required code signing for addons, so I can't
> imagine we would need the API that you want to remove. But there is a lot
> of past history that I do not know, but I'm not sure who else would know
> better.
>

"Required code signing" was not the point of the original question.
David's email distinguishes between the method used to enforce extension
signing in Firefox (which requires that extensions be signed by Mozilla)
and the "second API" that verifies signatures against anything in the app's
certificate store.  As he says, that second verification method isn't used
in Firefox but in other Gecko applications that use the old add-on install
confirmation dialog, that dialog  includes a note about the certificate
(kind of like what's shown in the location bar when browsing with https).
The question is about removing the code that powers that.

-Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Andrew Swan]

On Wed, Jun 14, 2017 at 10:49 AM, Boris Zbarsky <bzbar...@mit.edu> wrote:

> On 6/14/17 12:23 PM, Andrew Swan wrote:
>
>> I would hope that if we have promising or widely used webextension
>> experiments, that the relevant peers would be aware of them when reviewing
>> changes that might affect them
>>
>
> I don't see how they would be, unless we have something like dxr for the
> relevant code.
>
> As a concrete example, how would a necko peer know that some webextension
> experiment uses or doesn't use various necko interfaces?


Sorry, this was misleading, I meant this as a narrow comment about the
(still hypothetical!) scenario where something is prototyped as an
experiment but we're in the process of landing it in m-c along with all the
other built-in apis.  Of course we can't/don't expect reviewers to be aware
of every small experiment that is out there.  And again, we've communicated
to extension developers that they cannot rely on stable internal
interface.  And finally, I agree with sfink and nfroyd that the only way to
really be able to depend on experiments at a larger scale is to get them
into automation.  I personally pledge not to complain about any changes
that break out-of-tree code until then... :)

-Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Andrew Swan]

On Wed, Jun 14, 2017 at 10:07 AM, Nathan Froyd <nfr...@mozilla.com> wrote:

> On Wed, Jun 14, 2017 at 12:54 PM, Steve Fink <sf...@mozilla.com> wrote:
> > On 06/14/2017 09:23 AM, Andrew Swan wrote:
> >> I would hope that if we have promising or widely used webextension
> >> experiments, that the relevant peers would be aware of them when
> reviewing
> >> changes that might affect them but of course changing IDL bindings is
> only
> >> one of a number of ways that a change to central could break an existing
> >> experiment.  This is one of the drawbacks of having out-of-tree code, I
> >> think its up to us (the webextensions maintainers) to either deal with
> >> this
> >> or get experiments worked into automation if this becomes a real problem
> >> in
> >> practice.
> >
> > Whoa. Experiments aren't tested in automation?
>
> Whoa.  We're going to still have to think about interface compat with
> external clients in a post-57 world?  This is the first I've heard of
> this.
>
> > Can they be, please? At least snapshotted versions.
>
> +1  Almost anything automation-related would be better than "hope
> peers think hard about this".
>

I'm not sure what you mean by "they".  We have support in the browser for
loading experiments, but we don't have a way to sign them for running in
release.  So some individuals have created experiments that they have used
locally but there is no centralized list of them and none of them are
widely used.  Making experiments more usable by creating a process for
getting experiments reviewed and signed is something we'd like to do and a
testing strategy certainly needs to be part of that.  But realistically
that is not going to happen until 57 is out the door.

More generally, I think the principle that we can't complain about internal
changes that break out-of-tree code if nothing breaks in automation is fair
(speaking from the webextensions perspective, not for devtools, test pilot,
etc) and we're not asking for any exception from that rule.  Or, as a more
direct answer to nfroyd: no, you don't need to think about compatibility
with out-of-tree code post-57 (at least as far as extensions are concerned).

-Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Andrew Swan]

On Wed, Jun 14, 2017 at 7:09 AM, Ehsan Akhgari 
wrote:

> [6] Note that it's not clear yet how we will be able to remove XPCOM APIs
> post-57 due to the existence of WebExtensions Experiments <
> https://webextensions-experiments.readthedocs.io/en/latest/>. I'm not
> sure who's going to make the call on which APIs we'd want to retain for
> those WebExtensions and which APIs we'd want to freely modify/remove after
> 57.


I don't think this will be a big deal.  Note that users will also be able
to run legacy addons (which can access xpcom) in Nightly with a preference
flipped.  We've tried to be clear in communication to extension developers
that once 57 comes around, we won't be making any efforts to keep internal
interfaces stable for addons so they shouldn't be surprised when interfaces
change.  I would hope that if we have promising or widely used webextension
experiments, that the relevant peers would be aware of them when reviewing
changes that might affect them but of course changing IDL bindings is only
one of a number of ways that a change to central could break an existing
experiment.  This is one of the drawbacks of having out-of-tree code, I
think its up to us (the webextensions maintainers) to either deal with this
or get experiments worked into automation if this becomes a real problem in
practice.

-Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is there a reason for scrapping native.js?

[Andrew Swan]

Sergey, the short and informal answer is that the move to webextensions and
the deprecation of xul and sdk extensions are large pieces of an effort to
limit the ability for folks to run unreviewed and out-of-tree code with
full chrome privileges in Firefox.  Here's a partial list of blog posts
that explain why this is important:
https://blog.mozilla.org/addons/2015/08/21/the-future-
of-developing-firefox-add-ons/
https://blog.mozilla.org/addons/2016/03/14/webextensons-whats-in-it-for-
developers/
http://www.mckay.pub/2016-04-17-addons-old/

There have also been a number of discussions on this topic on the
dev-addons mailing list (which is probably a good place for follow-ups if
you want to discuss this further).

Although we're not planning to do everything that was proposed for
native.js, we do have webextensions experiments:
https://webextensions-experiments.readthedocs.io/en/latest/
Briefly, an experiment is an extension that exists just to implement a
webextensions API to be used by regular webextensions.  We're still
relatively early with this project, but the basic idea is that if you want
to write an extension that requires access to something that isn't
currently exposed via a webextensions API, you create an experiment to
expose the thing you need in a way that is consistent with the
webextensions goals of safety, maintainability, etc.  The experiment runs
with chrome privileges so it requires a thorough review, but the bulk of
your code can be written as a regular webextension, with all the benefits
that come along with that.  Then, if this new API is something that proves
to be popular, it can uplifted into the browser.

I'm happy to discuss this all further but like I mentioned above, the
dev-addons mailing list would probably be more appropriate than
dev-platform.  Or you can come find is on IRC in #webextensions.

-Andrew


On Sat, Jan 28, 2017 at 4:55 PM, Sergey Rozhenko  wrote:

> So far I haven't been able to find any piece of rationale behind
> https://bugzilla.mozilla.org/show_bug.cgi?id=1199718 getting WONTFIXed.
> And that's weird, because there has to be an enormous reason to justify its
> scrapping.
> WebExtensions made perfect sense to me until this happened:
> - Most extensions won't use it, would be easy to sign and won't break with
> FF updates.
> - Small percentage of extensions will make use of it to do the special
> things.
>
> Ability of addons to modify browser UI code is the defining feature of
> FireFox. Considering that Mozilla evidently lags far behind Chrome in
> manpower and resources, there's very little FF can do to compete if this
> feature is lost.
> It will lose most of "must-have" addons that power users of FF can't live
> without and that make people use FF rather than Chrome, like those made by
> Quicksaver: https://blog.mozilla.org/addons/2016/11/23/add-ons-in-2017/
>
> So, again, this is a "life and death" kind of issue for FireFox and there
> must be a "life and death" reason for scrapping native.js. What is it?
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to remove: support for installing multiple xpis simultaneously

[Andrew Swan]

tl;dr: We have two existing features (multipackage xpis and the
InstallTrigger api capability for installing multiple xpis in a single
call) that are not widely used.  I would like to remove them to reduce
complexity in the add-ons manager.

Background: The XPI file format is used for several types of add-ons
including extensions (both webextensions and the older xul and bootstrap
ones), themes, and language packs.  One of the more obscure features of the
format is "multi-package" xpis which are pretty much what you might guess
from the name: a collection of other xpis all bundled into a single file.
And then we have the InstallTrigger api, which provides a way to install
xpis from content (guarded by permissions prompts of course).  This is the
api that is is invoked when you press the "Add to Firefox" button on an
addons.mozilla.org page but it is also documented for use by others.  This
api is an ancient one that we inherited from Netscape (!!) though it has
never been standardized or implemented in other browsers.  Among other
things, InstallTrigger provides a way to install multiple xpis with a
single api call.

Unfortunately we don't have any telemetry available about how frequently
these two features are used but empirically they appear to be very
uncommon.  However, they are responsible for a good deal of complexity in
the add-ons manager and, more urgently, they complicate the UX design for
current efforts to display detailed permissions prompts to users when they
install a webextension.

Rather than deal with the UX design and corresponding implementation
complexity of install operations that include multiple webextensions that
need to be individually approved by the user, I'm proposing that we drop
support for multi-package xpis and restrict the InstallTrigger api to only
allow installing a single xpi at a time.  I would like to do this in
Firefox 53.

-Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform