Re: Changing .idl files

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

Re: Changing .idl files

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

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.

Re: Changing .idl files

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

Re: Changing .idl files

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.

Re: Changing .idl files

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

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 bec

Re: Changing .idl files

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

Re: Changing .idl files

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 a

Re: Changing .idl files

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 f

Re: Changing .idl files

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

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

Re: Changing .idl files

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 alr

Re: Changing .idl files

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 g

Re: Changing .idl files

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

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

Re: Changing .idl files

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 th

Re: Changing .idl files

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 s

Re: Changing .idl files

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

Re: Changing .idl files

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 mailto:sf...@mozilla.com>> wrote: > Whoa. Experiments aren't tested in automation? Whoa. We're going to still

Re: Changing .idl files

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 th

Re: Changing .idl files

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

Re: Changing .idl files

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 pr

Re: Changing .idl files

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 chang

Re: Changing .idl files

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

Re: Changing .idl files

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 ca

Re: Changing .idl files

On 06/14/2017 09:02 AM, Benjamin Smedberg wrote: 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-

Re: Changing .idl files

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 risk

Changing .idl files

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