Changing .idl files

[Nicholas Nethercote]

Hi,

What must be considered when changing an XPIDL interface in a .idl file? As
far
as I know, it's the following.

(1) Update browser C++ code that uses the interface. This is easy because
the
compiler will tell you the parts that need changing.

(2) Update browser JS code that uses the interface. This is harder because
it
requires using grep or a similar tool to find all the occurrences. But it's
usually not too bad.

(3) Do extensions use it? If so, changing it probably isn't possible. This
can
be imperfectly determined by searching through addons/ in DXR.

(4) Does Thunderbird use it? This is no longer a hard constraint, but is
something to consider.

Once Firefox 57 disallows all extensions other than Web Extension, I think
(3) will
no longer be relevant. In which case, once 57 is under development (August
~7th)
it will be *much* easier to change XPIDL interfaces.

(Although, if DevTools are moved its their own repository, that repo will
have to be
checked as well?)

Is all that correct? Have I missed anything? Thanks.

Nick

[Benjamin Smedberg]

On Tue, Jun 13, 2017 at 8:40 PM, Nicholas Nethercote <n.neth...@gmail.com
> wrote:

>
> (3) Do extensions use it? If so, changing it probably isn't possible. This
> can
> be imperfectly determined by searching through addons/ in DXR.
>

There is no rule that we can't break old-style addons: it just makes the
change riskier and may require outreach or an addon validation step. So
it's a question of risk/reward tradeoff.

Given that old-style addons are going away for 57, if it's possible to
delay addon-breaking IDL changes by one release until 57 that's probably
the easiest way to deal with this. We're already causing the addon
community a lot of churn.

>
> (4) Does Thunderbird use it? This is no longer a hard constraint, but is
> something to consider.
>

In general our policy is that we should spend only minimal time worrying
about this. A courtesy note to tbird devs is nice.

> (Although, if DevTools are moved its their own repository, that repo will
> have to be
> checked as well?)
>

I've been trying to find out some technical details about the devtools
plan, but my initial understanding is that they are trying to target stable
web/webextensions/debugger API surfaces, and so they *shouldn't* be
affected by gecko internals changes. But I'd be a lot more comfortable if
that were in writing as part of the devtools plan.

--BDS

[Ehsan Akhgari]

On 06/14/2017 09:02 AM, Benjamin Smedberg wrote:
> On Tue, Jun 13, 2017 at 8:40 PM, Nicholas Nethercote <n.neth...@gmail.com
>> wrote:
>> (3) Do extensions use it? If so, changing it probably isn't possible. This
>> can
>> be imperfectly determined by searching through addons/ in DXR.
>>
> There is no rule that we can't break old-style addons: it just makes the
> change riskier and may require outreach or an addon validation step. So
> it's a question of risk/reward tradeoff.
>
> Given that old-style addons are going away for 57, if it's possible to
> delay addon-breaking IDL changes by one release until 57 that's probably
> the easiest way to deal with this. We're already causing the addon
> community a lot of churn.

Also note that not every kind of modification to IDL files has the same
kind of risk in terms of add-on (and also Thunderbird) breakage. For
example, adding a new method/attribute can very rarely break something
(unless for example code tests for existence of the currently
non-existing name and takes a different path based on that.) Similarly,
adding an optional argument at the end of the list of arguments to a
method can rarely break an add-on, except if the add-on implements the
method.

>
>> (Although, if DevTools are moved its their own repository, that repo will
>> have to be
>> checked as well?)
>>
> I've been trying to find out some technical details about the devtools
> plan, but my initial understanding is that they are trying to target stable
> web/webextensions/debugger API surfaces, and so they *shouldn't* be
> affected by gecko internals changes. But I'd be a lot more comfortable if
> that were in writing as part of the devtools plan.

(There's a google doc about the plans but I'm not sure if I'm allowed to
link to it here, someone from the devtools team can probably do so here
if that's OK...)

That sounds pretty hard to believe given how deeply tied devtools is
into Gecko. At least in a few areas that I'm familiar with, there are
no Web Extension APIs for what devtools needs, so it will most likely
need to depend on our XPCOM APIs at least in the immediate term.


Two items to add to njn's list:

[5] Pay attention to [builtinclass] interfaces (and make new ones where
possible!)
builtinclass means that JS code isn't allowed to implement an XPIDL
interface, which allows C++ code to assume things about the concrete
implementation behind an XPIDL interface which can sometimes be nice.
If you are modifying a [builtinclass] interface for example to add a new
argument to a method, you don't need to worry about add-ons implementing
that method, since that would be impossible. Where possible and
sensible, please try to make existing interfaces [builtinclass].

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

[Andrew Swan]

On Wed, Jun 14, 2017 at 7:09 AM, Ehsan Akhgari <ehsan....@gmail.com>
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

[Steve Fink]

On 06/14/2017 09:23 AM, Andrew Swan wrote:
>
> 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.
>

Whoa. Experiments aren't tested in automation?

Can they be, please? At least snapshotted versions.

[Nathan Froyd]

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

-Nathan

[Andrew McKay]

WebExtension Experiments are a way to write WebExtension APIs without
having to write an API in mozilla-central.

There are no WebExtension Experiments enabled on release.

They have been enabled on release in Firefox 55 for a restricted set
of users *only*. Basically, Test Pilot. When that team proposes
pushing out an experiment to release, the usual release process for
that team will take place.

There is no need to think about interface compatibility in the future
with external clients.

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[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

[Steve Fink]

Right. But in my mind, "not tested in automation" ~= "always broken".
And if I understand the whole addon picture correctly (unlikely), then
WebExtension Experiments is basically our only answer to the mountain of
legacy extensions that we're breaking. (Not that it fixes them, just
that it's the answer to "yeah, you can't do stuff like that anymore in
Firefox".)

I don't want to hold up an always broken solution as our defense against
the claim that we've completely nerfed our extension capabilities. If
it's the most realistic path forward for any addon that extends in
currently unsupported places, then it would behoove us to make it truly
realistic. (If, instead, we decided to tell people wanting additional
extension points that they need to land them directly in gecko, then
fine, but my understanding is that Experiments is there to provide a
gentler path.)

It's ok if they break, even, as long as we *know* what's broken and
aren't in a state where developers have no trust in Experiments actually
working. "Try it and see, but you'll probably have to fix it before you
can use it" is not where we want to be.

On 06/14/2017 10:25 AM, Andrew McKay wrote:
> WebExtension Experiments are a way to write WebExtension APIs without
> having to write an API in mozilla-central.
>
> There are no WebExtension Experiments enabled on release.
>
> They have been enabled on release in Firefox 55 for a restricted set
> of users *only*. Basically, Test Pilot. When that team proposes
> pushing out an experiment to release, the usual release process for
> that team will take place.
>
> There is no need to think about interface compatibility in the future
> with external clients.
>
>
>

> On 14 June 2017 at 10:07, 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".
>>

[Steve Fink]

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

> <mailto:nfr...@mozilla.com>> wrote:
>
> On Wed, Jun 14, 2017 at 12:54 PM, Steve Fink <sf...@mozilla.com
> <mailto:sf...@mozilla.com>> wrote:
> > 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.

Ok, fair enough. I just sort of assumed that Experiments were a more
actively used thing already, but didn't actually look at current usage.
Hopefully it'll grow into something more, and we'll have a good story
for ensuring that they don't continually break. Knowing the current
state, I guess that addresses my concern. (Well, not the concern that we
don't have a great story for deeper extensions yet, but at least I
understand now why CI testing isn't really where we are yet.)

[Boris Zbarsky]

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?

-Boris

[Andrew Swan]

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

[Kris Maglione]

Currently, we don't allow experiments on release builds. Or, to
be technically accurate, we allow them on release builds as of
55 if they're signed by AMO, but AMO does not currently support
signing them.

When we've talked about allowing them on release builds in the
past, the consensus has always been that they'd need to be
reviewed by appropriate Firefox or Platform peers before being
published, and we would have the appropriate ownership to update
them as necessary to maintain compatibility.

[Nathan Froyd]

On Wed, Jun 14, 2017 at 2:14 PM, Andrew Swan <as...@mozilla.com> wrote:
> 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... :)

Thank you for clarifying this!

-Nathan

[Nicholas Nethercote]

I just found https://bugzilla.mozilla.org/show_bug.cgi?id=1347507: "Stuff
we can remove when XPCOM extensions are no longer supported". A number of
the blocking bugs are for removing XPIDL interfaces. If you know of other
things that can be removed, please add them as blocking bugs.

Nick

On Wed, Jun 14, 2017 at 10:40 AM, Nicholas Nethercote <
n.neth...@gmail.com> wrote:

> Hi,
>
> What must be considered when changing an XPIDL interface in a .idl file?
> As far
> as I know, it's the following.
>
> (1) Update browser C++ code that uses the interface. This is easy because
> the
> compiler will tell you the parts that need changing.
>
> (2) Update browser JS code that uses the interface. This is harder because
> it
> requires using grep or a similar tool to find all the occurrences. But it's
> usually not too bad.
>

> (3) Do extensions use it? If so, changing it probably isn't possible. This
> can
> be imperfectly determined by searching through addons/ in DXR.
>

> (4) Does Thunderbird use it? This is no longer a hard constraint, but is
> something to consider.
>

> Once Firefox 57 disallows all extensions other than Web Extension, I think
> (3) will
> no longer be relevant. In which case, once 57 is under development (August
> ~7th)
> it will be *much* easier to change XPIDL interfaces.
>

> (Although, if DevTools are moved its their own repository, that repo will
> have to be
> checked as well?)
>

[Boris Zbarsky]

On 6/14/17 9:02 AM, Benjamin Smedberg wrote:
> Given that old-style addons are going away for 57, if it's possible to
> delay addon-breaking IDL changes by one release until 57 that's probably
> the easiest way to deal with this. We're already causing the addon
> community a lot of churn.

I'd like to get some clarity on what's going on here, actually.

57 tip right now still allows old-style addons, right? But people have
started landing interface changes that break those addons quite badly;
see https://bugzilla.mozilla.org/show_bug.cgi?id=1326520 for an example.

This is causing addon authors a bunch of pain as they struggle to keep
their addons working on nightly (where they are theoretically still
supported, per above) while also trying to port them to WebExtensions.
I can't find a link to the bug comments complaining about this right
now, but I recall it being connected to the nsIURI changes.

So what is the state of things at the moment? Should we just turn off
old-style addons on nightly? If not, then we should probably stop
breaking them until we _do_ turn them off.

-Boris

[Kris Maglione]

On Mon, Aug 07, 2017 at 12:31:30PM -0400, Boris Zbarsky wrote:
>On 6/14/17 9:02 AM, Benjamin Smedberg wrote:
>>Given that old-style addons are going away for 57, if it's possible to
>>delay addon-breaking IDL changes by one release until 57 that's probably
>>the easiest way to deal with this. We're already causing the addon
>>community a lot of churn.
>
>I'd like to get some clarity on what's going on here, actually.
>
>57 tip right now still allows old-style addons, right? But people
>have started landing interface changes that break those addons quite
>badly; see https://bugzilla.mozilla.org/show_bug.cgi?id=1326520 for an
>example.
>
>This is causing addon authors a bunch of pain as they struggle to keep
>their addons working on nightly (where they are theoretically still
>supported, per above) while also trying to port them to WebExtensions.
>I can't find a link to the bug comments complaining about this right
>now, but I recall it being connected to the nsIURI changes.

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.

>So what is the state of things at the moment? Should we just turn off
>old-style addons on nightly? If not, then we should probably stop
>breaking them until we _do_ turn them off.

I don't think so. Extension authors know the score here. There's
no official support for legacy add-ons in 57. If they want to
continue attempting to support them, they need to expect
frequent breakage.

[Andrew Swan]

On Mon, Aug 7, 2017 at 10:05 AM, Kris Maglione <kmag...@mozilla.com>
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

[Jonathan Kew]

On 07/08/2017 18:05, 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.

Will that pref still be available in 57 once it reaches Release (and
then for how much longer?), or will it be going away somewhere between
now and then?

(I'd been under the impression that legacy add-ons would be dead as of
FF57, but if they can be re-enabled by flipping a pref, then that's not
as clear-cut as I thought.)

Thanks,

JK

[Kris Maglione]

On Mon, Aug 07, 2017 at 07:03:52PM +0100, Jonathan Kew wrote:
>On 07/08/2017 18:05, 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.
>
>Will that pref still be available in 57 once it reaches Release (and
>then for how much longer?), or will it be going away somewhere between
>now and then?

It will be nightly-only. In release builds, legacy extensions
will be disabled by a compile-time constant.

[Boris Zbarsky]

On 8/7/17 1:05 PM, Kris Maglione wrote:
>> So what is the state of things at the moment? Should we just turn off
>> old-style addons on nightly? If not, then we should probably stop
>> breaking them until we _do_ turn them off.
>
> I don't think so. Extension authors know the score here.

OK, I thought about this some more, and here's the problem as I see it.
Extension authors may know the score (though see below), but nightly
users may not, and even if they do they may not realize that addons are
involved in breakage.

So if right now we land a patch that breaks addons, and a nightly user
updates, they get a broken browser and have to try to figure out whether
it's because we broken an addon (and this may not be the first thing
they think of) or because we introduced a bug that they should report.

So I strongly feel that to avoid wasting the time and effort of our
nightly users we should not start landing addon-breaking changes (or at
least ones that might cause exceptions in addons that break various
browser functionality) until after we have disabled addons.

Note that the issues addon authors are having are precisely the "we
don't want to make nightly users' lives hell, so we're trying to make
sure our addons keep working for the users who have them installed"
issue. As in, they're caring more about our nightly users a lot more
than some of our developers seem to be. :(

If people just want to clean up IDL, which is what I'm seeing, they
should start with the ton of noscript interfaces we have that need
cleanup and which are known to not break any addons ever since we remove
binary addon support.

-Boris

[Frank-Rainer Grahl]

Just for reference. With latest NoScript View Source is broken and it throws
an exception now and then. Still on Beta because of this one. I won't browse
the web without it.

For me Web Extensions do not cut it yet and Classic Extensions are unsupported
and go away. Bad timing even on a Nightly. You should have waited till ESR 59
for mass removals of interfaces and to stabilize this more.

FRG

[Nicholas Nethercote]

On Tue, Aug 8, 2017 at 7:12 AM, Boris Zbarsky <bzba...@mit.edu> wrote:

>
> So if right now we land a patch that breaks addons, and a nightly user
> updates, they get a broken browser and have to try to figure out whether
> it's because we broken an addon (and this may not be the first thing they
> think of) or because we introduced a bug that they should report.
>

I switched from Nightly to Release on my main work machine after
yesterday's Nightly update broke both Tree Style Tab and ChatZilla. I heard
that Tree Style Tab was fixed again shortly afterward.

I also heard that both of these may have been caused by disabling e10s
shims, or something like that, but I don't know if it's correct.

> So I strongly feel that to avoid wasting the time and effort of our
> nightly users we should not start landing addon-breaking changes (or at
> least ones that might cause exceptions in addons that break various browser
> functionality) until after we have disabled addons.
>

Is there going to be a clear point in time when legacy extensions stop
working in Nightly? I have the impression it'll be more of a slow
degradation.

Nick

[Boris Zbarsky]

On 8/7/17 6:17 PM, Nicholas Nethercote wrote:
> Is there going to be a clear point in time when legacy extensions stop
> working in Nightly?

I was under the impression that there is, and I strongly feel there
should be.

-Boris

[Kris Maglione]

There isn't. Not as such, anyway. By the end of the week, legacy
extensions that aren't specially signed will be disabled by
default. On nightlies and in unbranded builds, it will still be
possible to enable them by flipping a pref, but they will be
completely unsupported.

Yes, that means that some users and developers will continue to
use them, and continue to get upset when they break, but that's
what they're signing up for when they flip the preference. I
tend to compare this to the rooted Android ecosystem. People who
develop for that environment know that they have no official
support, and their apps are never going to reach a broad user
base.. People who setup that environment know that things are
going to be unstable, and apps are going to break. But for one
reason or another, it's worth it to them.

[Fabrice Desre]

On 08/07/2017 08:17 PM, Kris Maglione wrote:

> Yes, that means that some users and developers will continue to use
> them, and continue to get upset when they break, but that's what they're
> signing up for when they flip the preference. I tend to compare this to
> the rooted Android ecosystem. People who develop for that environment
> know that they have no official support, and their apps are never going
> to reach a broad user base.. People who setup that environment know that
> things are going to be unstable, and apps are going to break. But for
> one reason or another, it's worth it to them.

Slight difference is that rooted-Android users were always in this
situation, while things will degrade for Firefox Nightly users.

Fabrice

[Kris Maglione]

They'll degrade for Firefox nightly users one way or the other.
The ones who want to continue using legacy add-ons will need to
opt into continuing to use them as an unsupported feature. The
ones that don't opt in will simply lose those add-ons.

[Boris Zbarsky]

On 8/7/17 11:17 PM, Kris Maglione wrote:
> There isn't. Not as such, anyway. By the end of the week, legacy
> extensions that aren't specially signed will be disabled by default.

That fits what I want. That being a notification to nightly users that
says "These are now officially unsupported; if you force-enable them,
you will likely have issues and should not be surprised".

> Yes, that means that some users and developers will continue to use
> them, and continue to get upset when they break, but that's what they're
> signing up for when they flip the preference.

Right. I'm a lot more ok with this than stealth-breaking stuff without
people even realizing we might have broken it.

-Boris

[Henri Sivonen]

On Tue, Aug 8, 2017 at 6:17 AM, Kris Maglione <kmag...@mozilla.com> wrote:
> On nightlies and
> in unbranded builds, it will still be possible to enable them by flipping a
> pref, but they will be completely unsupported.
>

> Yes, that means that some users and developers will continue to use them,
> and continue to get upset when they break

Why is it worthwhile to keep a configuration that will continue to
make people upset? Does there exist a known set of legacy extensions
that 1) do something that WebExtensions can't yet do and that 2) are
limited to using interfaces that we don't want to remove or refactor
ASAP?

--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/