Re: Changing .idl files

[Henri Sivonen]

On Tue, Aug 8, 2017 at 6:17 AM, Kris Maglione  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
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Kris Maglione]

On Mon, Aug 07, 2017 at 08:50:38PM -0700, Fabrice Desre wrote:

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.


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.

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

Re: Changing .idl files

[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

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

Re: Changing .idl files

[Kris Maglione]

On Mon, Aug 07, 2017 at 10:58:11PM -0400, Boris Zbarsky wrote:

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.


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.

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

Re: Changing .idl files

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Nicholas Nethercote]

On Tue, Aug 8, 2017 at 7:12 AM, Boris Zbarsky  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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[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

Boris Zbarsky wrote:

On 8/7/17 1:05 PM, Kris Maglione 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.


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

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

Re: Changing .idl files

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

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

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

Re: Changing .idl files

[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
___
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: Changing .idl files

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

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

Re: Changing .idl files

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[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.netherc...@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?)
>
> Is all that correct? Have I missed anything? Thanks.
>
> Nick
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Nathan Froyd]

On Wed, Jun 14, 2017 at 2:14 PM, Andrew Swan  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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Kris Maglione]

On Wed, Jun 14, 2017 at 01:49:28PM -0400, Boris Zbarsky 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?


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.

___
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  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

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Steve Fink]

On 06/14/2017 10:35 AM, Andrew Swan wrote:


On Wed, Jun 14, 2017 at 10:07 AM, Nathan Froyd > wrote:


On Wed, Jun 14, 2017 at 12:54 PM, Steve Fink > 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.)


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

Re: Changing .idl files

[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  wrote:

On Wed, Jun 14, 2017 at 12:54 PM, Steve Fink  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".

-Nathan
___
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: Changing .idl files

[Andrew Swan]

On Wed, Jun 14, 2017 at 10:07 AM, Nathan Froyd  wrote:

> On Wed, Jun 14, 2017 at 12:54 PM, Steve Fink  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 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.



On 14 June 2017 at 10:07, Nathan Froyd  wrote:
> On Wed, Jun 14, 2017 at 12:54 PM, Steve Fink  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".
>
> -Nathan
> ___
> 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: Changing .idl files

[Nathan Froyd]

On Wed, Jun 14, 2017 at 12:54 PM, Steve Fink  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".

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

Re: Changing .idl files

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

___
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: Changing .idl files

[Ehsan Akhgari]

On 06/14/2017 09:02 AM, Benjamin Smedberg wrote:

On Tue, Jun 13, 2017 at 8:40 PM, Nicholas Nethercote . 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.

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

Re: Changing .idl files

[Benjamin Smedberg]

On Tue, Jun 13, 2017 at 8:40 PM, Nicholas Nethercote  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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform