Sergey, the short and informal answer is that the move to webextensions and
the deprecation of xul and sdk extensions are large pieces of an effort to
limit the ability for folks to run unreviewed and out-of-tree code with
full chrome privileges in Firefox. Here's a partial list of blog posts
that
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
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 p
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 af
On Wed, Jul 19, 2017 at 5:02 PM, R Kent James wrote:
> On 7/19/2017 4:06 PM, David Keeler wrote:
>
>> [dev-apps-thunderbird and dev-apps-seamonkey cc'd, but please discuss on
>> dev-platform]
>>
> ...
>
>> Given all this, the question is do we still need this second API? Does
>> Thunderbird or Se
On Fri, Jul 21, 2017 at 12:32 AM, Jörg Knobloch wrote:
> Since you're saying that we're still using the old interface, in fact
> Andrew said: "old add-on install
> confirmation dialog, that dialog includes a note about the certificate",
> would you be able to give us some exact DXR references whi
I believe that Gabor's response to the original question nicely captures
the thinking and plans of everybody working on WebExtensions day-to-day.
The questions about formally defining a policy for what to expose to
extensions and about how to (or if we should) distinguish Firefox-specific
APIs from
On Wed, Jul 26, 2017 at 2:49 AM, Frank-Rainer Grahl wrote:
> I need to look at the notifications for SeaMonkey anyway but how could
> Thunderbird implement the standard doorhanger with no location bar? I think
> the dialog should be retained for projects which do not have a location bar
> and/or
On Wed, Jul 26, 2017 at 4:27 PM, Steve Fink wrote:
> This thread worries me greatly. Somebody tell me we have a plan and policy
> around this already. Please?
>
We might, but I'm not sure what "this" you're concerned about. Whether API
names should be prefixed? Or whether we should expose thin
Sorry for the slow reply, I was half-waiting to see if anybody else would
jump in but I guess product managers don't follow dev-platform :)
I think we're mostly in sync on most of the nuts and bolts and the
unresolved topics are generally pretty high-level concerns.
On Thu, Jul 27, 2017 at 10:02
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
After lots of recent discussion, it is finally happening. The patch to
flip the default setting to disallow legacy extensions is in autoland at
the moment and, barring some snafu, should be in tomorrow's Nightly
builds. This is a bit anti-climactic since a few other changes that have
already land
On Mon, Aug 14, 2017 at 6:16 AM, Honza Bambas wrote:
> Ed already mentioned that the addons manager doesn't automatically suggest
> or even update to webext alternatives. We really should have something
> like this SOON - the more automatic or fluent the better.
There is a "find a replacement"
On Thu, Aug 24, 2017 at 12:03 AM, Alessio Placitelli <
aplacite...@mozilla.com> wrote:
> 2017-08-24 0:00 GMT+02:00 Andrew McKay :
> > The recommendations are being populated and other changes are being
> > made. For example, on September 1st only WebExtensions will be
> > featured on AMO (as oppos
On Wed, Oct 18, 2017 at 3:22 PM, Justin Dolske wrote:
> On Wed, Oct 18, 2017 at 11:52 AM, Blake Kaplan wrote:
>
>>
>> One more thing to point out: with the removal of e10srollout, I also
>> removed the code that would disable e10s if we detected a
>> non-multiprocessComptaible extension. We are
On Wed, Nov 15, 2017 at 6:12 AM, Henri Sivonen wrote:
> How many Mozilla-signed special extensions are there? Does an analog
> of https://dxr.mozilla.org/addons/ exist for searching their code?
Unfortunately there is not an index of them. andym could provide a
complete list but off the top of
On Thu, Feb 1, 2018 at 4:32 PM, Xidorn Quan wrote:
> What do we show when we disable legacy addons? We can probably borrow
> whatever we did there.
>
There is no explicit notification for disabled legacy addons (you can see
them in about:addons but you have to know to go look there)
tl;dr: We have two existing features (multipackage xpis and the
InstallTrigger api capability for installing multiple xpis in a single
call) that are not widely used. I would like to remove them to reduce
complexity in the add-ons manager.
Background: The XPI file format is used for several types
Geoff,
First, I'm moving this over to dev-addons since it is about the internals
of the webextensions implementation and probably not of interest to many of
the people on dev-platform. Anybody from dev-platform who is interested,
feel free to follow us over to dev-addons.
The short answer is tha
19 matches
Mail list logo
