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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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,
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
>
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
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
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
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
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
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
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
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
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,
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
On 06/14/2017 09:02 AM, Benjamin Smedberg wrote:
On Tue, Jun 13, 2017 at 8:40 PM, Nicholas Nethercote
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
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
29 matches
Mail list logo