Re: Changing .idl files

2017-08-08 Thread 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

Re: Changing .idl files

2017-08-07 Thread 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

Re: Changing .idl files

2017-08-07 Thread 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

Re: Changing .idl files

2017-08-07 Thread 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.

Re: Changing .idl files

2017-08-07 Thread 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

Re: Changing .idl files

2017-08-07 Thread 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

Re: Changing .idl files

2017-08-07 Thread 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

Re: Changing .idl files

2017-08-07 Thread 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

Re: Changing .idl files

2017-08-07 Thread 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

Re: Changing .idl files

2017-08-07 Thread 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

Re: Changing .idl files

2017-08-07 Thread 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

Re: Changing .idl files

2017-08-07 Thread 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

Re: Changing .idl files

2017-08-07 Thread 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

Re: Changing .idl files

2017-08-07 Thread 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

Re: Changing .idl files

2017-06-20 Thread 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,

Re: Changing .idl files

2017-06-14 Thread 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 >

Re: Changing .idl files

2017-06-14 Thread 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

Re: Changing .idl files

2017-06-14 Thread 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

Re: Changing .idl files

2017-06-14 Thread 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

Re: Changing .idl files

2017-06-14 Thread 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

Re: Changing .idl files

2017-06-14 Thread 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

Re: Changing .idl files

2017-06-14 Thread 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

Re: Changing .idl files

2017-06-14 Thread 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

Re: Changing .idl files

2017-06-14 Thread 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

Re: Changing .idl files

2017-06-14 Thread 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,

Re: Changing .idl files

2017-06-14 Thread 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

Re: Changing .idl files

2017-06-14 Thread Ehsan Akhgari
On 06/14/2017 09:02 AM, Benjamin Smedberg wrote: On Tue, Jun 13, 2017 at 8:40 PM, Nicholas Nethercote

Re: Changing .idl files

2017-06-14 Thread 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

Changing .idl files

2017-06-13 Thread 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