Re: Still-supported cases of out-of-tree XPCOM code?

To confirm, yes we have a list of all the add-ons that are bootstrapped. To get access to that special ability the teams agree that testing and maintenance is their responsibility. I agree that removing legacy XPCOM functionality is the priority and the focus should be keeping tree herder green.

Re: verifying unpacked signed add-ons

> WebExtensions are never meant to be installed unpacked except during > development. It's currently possible for some side-load methods to install > them unpacked in production, but that's not supported. System add-ons are > never installed unpacked in production builds. We don't have any

W3C and WebExtensions

We've been working on getting WebExtensions ready for Firefox 57, and wanted to follow up with our status regarding the W3C Community Group [1]. At this time Firefox implements a large part of the specification. Deviations from the spec are being tracked in bug 1392434 [2]. Following the

Re: Containers graduation from Test Pilot - we still care about 57+

t process. > > On Sep 27, 2017 12:58 PM, "Andrew McKay" <amc...@mozilla.com> wrote: > > Sorry, it disables e10s even though it has > true in the > install.rdf? That shouldn't be the case. > > On 27 September 2017 at 07:14, Ben Kelly <bke...@mozilla.com> wr

Re: Containers graduation from Test Pilot - we still care about 57+

Sorry, it disables e10s even though it has true in the install.rdf? That shouldn't be the case. On 27 September 2017 at 07:14, Ben Kelly wrote: > On Mon, Sep 25, 2017 at 9:28 AM, Ben Kelly wrote: > >> Thanks Jonathan. >> >> Also, it seems the link to the

Re: Intermittent oranges and when to disable the related test case - a simplified policy

x=Firefox%20for%20Android=Firefox%20for%20iOS=Toolkit > > On Wed, Sep 6, 2017 at 3:46 PM, Andrew McKay <amc...@mozilla.com> wrote: >> >> Is there an easy way for me to track what tests have been disabled as >> result of intermittent issues we haven't been able to fix?

Re: Intermittent oranges and when to disable the related test case - a simplified policy

Is there an easy way for me to track what tests have been disabled as result of intermittent issues we haven't been able to fix? On 6 September 2017 at 14:10, wrote: > Over the last 9 months a few of us have really watched intermittent test > failures almost daily and done

Re: Retaining Nightly users after disabling of legacy extensions

If an extension updates to a WebExtension, users will automatically get that update. If the author or another author creates an alternative then a user will have to find that. The recommendations are being populated and other changes are being made. For example, on September 1st only

Re: Switching to per-channel profiles

+1 I think it will be great benefit if someone could run Nightly for first time, whilst Firefox is running and not get the dreaded "Profile in Use" dialog. We should do whatever we can to minimize the appearance of that dialog, while still allowing -p to be passed in the command line. On 23 June

Intent to unship: Add-on SDK and others

With Firefox 57 only running WebExtensions, we are hoping to spend some time *after* Firefox 57 doing some cleaning and removing un-needed code. The plans are still being formed, but we are aiming to land some of these in the Firefox 58 or Firefox 59 trains. The timetable is currently under

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

Re: Strange error message on try-comm-central: Error: Invalid addon ID: expected addon ID specialpow...@mozilla.org, found special-pow...@mozilla.org in manifest

Just a note that https://bugzilla.mozilla.org/show_bug.cgi?id=1303418 is about to land and this will prevent an add-on upgrade changing the ID of the add-on. That's not happening in this case (the code hasn't landed), but just a heads up on a similar front. On 22 September 2016 at 01:33, Mark

Re: What if you could reinvent Firefox theming?

> The largest amount of responses (29.8%) said that it is a real pain to keep > these themes up-to-date and working > An overwhelming majority of the respondents insist that we don't need to > change a thing and that other apps don't offer grand alternatives at 36.5% I found these two an

Re: Changes to bugzilla "plugins" product

I agree, let's just leave its name as it is for now. On Mon, May 2, 2016 at 3:54 PM, Matthew N. wrote: > On Mon, May 2, 2016 at 3:43 PM, Emma Humphries wrote: >> >> Andrew, can you do a pass over the bugs since Jan 1st and, and let's >> rename

Re: Changes to bugzilla "plugins" product

Looks like that would fall on me. After a quick look at some of the bugs, its seems like its a holding pen for bugs that need to be passed on to other areas or back to the add-on developer themselves (which often means closing them). On Mon, May 2, 2016 at 2:01 PM, Emma Humphries