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

[Andrew McKay]

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.

There needs to be an exit strategy for these add-ons from the current
siutation, but as you can see there's more to this about how these
things are developed. The fact that teams are opting choose to use
different tools again brings up the same conversation that devtools
had.

At this point, now we are post 57, we are starting to work with those
teams to find a solution.

On 15 November 2017 at 08:31, Kris Maglione  wrote:
> On Wed, Nov 15, 2017 at 04:12:06PM +0200, Henri Sivonen wrote:
>>
>> On Wed, Nov 15, 2017 at 3:16 PM, Andrea Marchesini
>>>
>>> This is why we had this issue. It should not be impossible for a
>>> 'standard'
>>> webextension to generate such mess.
>>
>>
>> How many Mozilla-signed special extensions are there? Does an analog
>> of https://dxr.mozilla.org/addons/ exist for searching their code? Is
>> there a CI system testing that the continue to work?
>
>
> The situation is pretty bad at this point. Ideally, all XPCOM add-ons that
> we support should run tests in treeherder on checkin, both for add-on
> changes and m-c changes. But as of now, most system add-ons, Test Pilot
> add-ons, and SHIELD studies are hosted on Github and do their own ad-hoc
> testing, mostly using Node-ish testing frameworks.
>
> There's also no standard place to host or index all of this add-on code, or
> even to get a list of what such add-ons exist. At one point, I asked for all
> SHIELD add-ons to at least be hosted in the same Github organization. The
> same should probably go for all other Mozilla-signed add-ons. That would at
> least give us a single place to find any XPCOM add-on code that we still
> support.
>
> In the mean time, though, as far as I'm concerned, the maintainers of those
> add-ons are responsible for dealing with breakage that results from not
> having in-tree tests and a standard place to search that code. If you're
> removing legacy XPCOM functionality, all you should need to care about is
> whether treeherder is green.
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: verifying unpacked signed add-ons

[Andrew McKay]

> 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 telemetry on the packed state of an extension, so we
don't know how widespread the use of unpacked extensions is. We might
want to collect first if there's a plan to disable that.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

W3C and WebExtensions

[Andrew McKay]

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 specification allows developers to write extensions and
know that the core of the extension will work across browsers, and
also understand where browsers may diverge from the specification.

We believe that extensions can do more than they do today, and will
continue to expand the API set Firefox supports as we move forward. As
we extend the APIs available to developers, we'll be marking the API
appropriately on MDN [3] so developers know what to expect. It is our
hope that other browsers will do the same, and that we'll collectively
grow the extension API.

This is documented on the wiki [4] and for more information on this or
particular APIs, please join dev-addons [5] or #webextensions on IRC.

[1]  https://www.w3.org/community/browserext/
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1392434
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1408494
[4] https://wiki.mozilla.org/WebExtensions/Spec
[5] https://mail.mozilla.org/listinfo/dev-addons
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrew McKay]

Just to close the loop on this thread, in 57 this will no longer
disable multi-e10s.

https://bugzilla.mozilla.org/show_bug.cgi?id=1404098

Thanks for the heads up Ben.

On 27 September 2017 at 10:53, Ben Kelly <bke...@mozilla.com> wrote:
> It disables multi-e10s.  Forced to one content 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> wrote:
>> On Mon, Sep 25, 2017 at 9:28 AM, Ben Kelly <bke...@mozilla.com> wrote:
>>
>>> Thanks Jonathan.
>>>
>>> Also, it seems the link to the web extension version of the container
>>> addon is broken above.  This one works for me:
>>>
>>> https://github.com/mozilla/multi-account-containers/releases/latest
>>>
>>
>> Sorry, I guess this isn't a web extension yet.  Its a legacy addon and
>> therefore disables multi-e10s.
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrew McKay]

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 web extension version of the container
>> addon is broken above.  This one works for me:
>>
>> https://github.com/mozilla/multi-account-containers/releases/latest
>>
>
> Sorry, I guess this isn't a web extension yet.  Its a legacy addon and
> therefore disables multi-e10s.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrew McKay]

Cool, thanks.

On 6 September 2017 at 16:32, Emma Humphries <e...@mozilla.com> wrote:
> Andy
>
> To start:
>
> https://bugzilla.mozilla.org/buglist.cgi?product=Core=Firefox=Firefox%20for%20Android=Firefox%20for%20iOS=Toolkit_format=advanced=---_whiteboard=test%20disabled%2Ctest-disabled%2Ctestdisabled_whiteboard_type=anywordssubstr=bug_id=0
>
> Add-ons, Web Extensions, and Plugins related:
>
> https://bugzilla.mozilla.org/buglist.cgi?resolution=---_whiteboard_type=anywordssubstr_format=advanced_whiteboard=test%20disabled%2Ctest-disabled%2Ctestdisabled=Add-on%20Manager=Add-ons%20Manager=Plug-ins=WebExtensions%3A%20Android=WebExtensions%3A%20Compatibility=WebExtensions%3A%20Developer%20Tools=WebExtensions%3A%20Experiments=WebExtensions%3A%20Frontend=WebExtensions%3A%20General=WebExtensions%3A%20Request%20Handling=WebExtensions%3A%20Untriaged=Core=Firefox=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?
>>
>> On 6 September 2017 at 14:10,  <jma...@mozilla.com> wrote:
>> > Over the last 9 months a few of us have really watched intermittent test
>> > failures almost daily and done a lot to pester people as well as fix many.
>> > While there are over 420 bugs that have been fixed since the beginning of
>> > the year, there are half that many (211+) which have been disabled in some
>> > form (including turning off the jobs).
>> >
>> > We don't like to disable and have been pretty relaxed in recommending
>> > disabling a test.  Overall we have tried to adhere to a policy of:
>> > * >=30 failures/week- ask for owner to look at failure and fix it, if
>> > this persists for a few weeks with no real traction we would go ahead [and
>> > recommend] disabling it.
>> > * >= 75 failures/week- ask for people to fix this in a shorter time
>> > frame and recommend disabling the test in a week or so
>> > * >= 150 failures/week- often just disable the test
>> >
>> > This is confusing and hard to manage.  Since then we have started
>> > adjusting triage queries and some teams are doing their own triage and we
>> > are ignoring those bugs (while they are getting prioritized properly).
>> >
>> > What we are looking to start doing this month is adopting a simpler
>> > policy:
>> > * any bug that has >=200 instances in the last 30 days will be disabled
>> > ** this will be a manual process, so it will happen a couple times/week
>> >
>> > We expect the outcome of this to be a similar amount of disabling, just
>> > an easier method for doing so.  It is very possible we might recommend
>> > disabling a test before it hits the threshold- keep in mind a disabled test
>> > is easy to re-enable (so feel free to disable for that one platform until
>> > you have time to look at fixing it)
>> >
>> > To be clear we (and some component owners) will continue triaging bugs
>> > and trying to get fixes in place as often as possible and prefer a fix, not
>> > a disabled test!
>> >
>> > Please raise any concerns, otherwise we will move forward with this in
>> > the coming weeks.
>> > ___
>> > dev-platform mailing list
>> > dev-platform@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-platform
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrew McKay]

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 a lot to pester people as well as fix many.  
> While there are over 420 bugs that have been fixed since the beginning of the 
> year, there are half that many (211+) which have been disabled in some form 
> (including turning off the jobs).
>
> We don't like to disable and have been pretty relaxed in recommending 
> disabling a test.  Overall we have tried to adhere to a policy of:
> * >=30 failures/week- ask for owner to look at failure and fix it, if this 
> persists for a few weeks with no real traction we would go ahead [and 
> recommend] disabling it.
> * >= 75 failures/week- ask for people to fix this in a shorter time frame and 
> recommend disabling the test in a week or so
> * >= 150 failures/week- often just disable the test
>
> This is confusing and hard to manage.  Since then we have started adjusting 
> triage queries and some teams are doing their own triage and we are ignoring 
> those bugs (while they are getting prioritized properly).
>
> What we are looking to start doing this month is adopting a simpler policy:
> * any bug that has >=200 instances in the last 30 days will be disabled
> ** this will be a manual process, so it will happen a couple times/week
>
> We expect the outcome of this to be a similar amount of disabling, just an 
> easier method for doing so.  It is very possible we might recommend disabling 
> a test before it hits the threshold- keep in mind a disabled test is easy to 
> re-enable (so feel free to disable for that one platform until you have time 
> to look at fixing it)
>
> To be clear we (and some component owners) will continue triaging bugs and 
> trying to get fixes in place as often as possible and prefer a fix, not a 
> disabled test!
>
> Please raise any concerns, otherwise we will move forward with this in the 
> coming weeks.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Retaining Nightly users after disabling of legacy extensions

[Andrew McKay]

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 WebExtensions will be
featured on AMO (as opposed to extensions that expect to upgrade). The
recommendation tool on AMO is being populated with add-ons any
suggestions welcome as per the thread here:
https://discourse.mozilla-community.org/t/favorite-webextensions/17087.

We are specifically and consciously focusing on release here and
giving the extension developers time to upgrade their extensions.

On 14 August 2017 at 13:16, Honza Bambas  wrote:
> On 8/13/17 6:42 PM, Ed Morley wrote:
>>
>> For the short term, Nightly users therefore have the following options:
>> a) Use latest nightly with legacy extensions disabled, and make do without
>> their extensions.
>
>
> There is also a2): find webext based alternatives "by hand" (what I have
> done and intend to help those addon developers to improve before 57 goes to
> release).  Note that in both cases (only two addons I really need to work -
> the rest is RIP now) are coming from *different* developers than the
> original xpcom-addons authors are.
>
> And here is my question: do we have a story for how to automatically updated
> addons of RELEASE channel users going from 56 to 57?  Given how we are gonna
> market 57, it would be sad that people after updating loose all their
> addons.  It will be just frustrating and ruin the main goal of 57 effort.
>
> 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.
>
> -hb-
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Switching to per-channel profiles

[Andrew McKay]

+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 2017 at 15:43, Dave Townsend  wrote:
> TL;DR: We should make each Firefox channel use its own profile data allowing
> you to run multiple channels at the same time.
>
> Running multiple channels of Firefox is currently harder than it needs to
> be. You can't start more than one channel at a time and either you use the
> same profile data for each channel running the risk of hitting bugs with
> downgrades or you have to create custom shortcuts to use different profiles
> for each channel. The exception to this is the developer edition which uses
> its own profile data by default. This turned out to be what most developers
> wanted and matches Chrome's behaviour. So we should do the same thing for
> the other channels.
>
> The technical details of how to do this are a little challenging so here is
> a proposal that hopes to limit the impact of the change:
>
> * Release will continue to work as it does today. The default profile listed
> in profiles.ini will be loaded and used as normal.
> * When Nightly and Beta first start they will look for a profile to use:
> ** First choice will be determined by a new flag in profiles.ini for each
> channel.
> ** Second choice will be a profile with a specific name which will be
> different for each channel. We do this because if the user runs an older
> build of Firefox it will blow away the new flags we use above.
> ** Finally if no profile has been found a new profile will be created with
> the appropriate name.
> * Throughout, if the command line includes --profile or -P to choose a
> specific profile then we respect that.
>
> The developer edition already does effectively the above just without the
> custom flag which allows you to rename your profile
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1098986). As part of this we
> would upgrade developer edition to support this too.
>
> How we populate the new profile we create for Nightly and Beta channels is
> an open question. We could simply clone the existing Release profile or use
> Firefox Refresh to copy across the basic data. In either case we can notify
> the user to let them know what has happened.
>
> If users still want to share profiles between channels then they will have
> that option going forwards by simply going to about:profiles and choosing a
> different default profile for the channel they are running.
>
> The main issue with this proposal is what happens if users downgrade Nightly
> or Beta to a version before we make these changes. They will revert back to
> the existing profile selection mechanism, effectively sharing profiles with
> the release channel again. Upgrading again will take them back to their new
> default profile unless they have renamed it away from the custom name we
> choose in which case a new default will be created again.
>
> Does anyone think we shouldn't do this or have comments on my proposal for
> implementing it?
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: Add-on SDK and others

[Andrew McKay]

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 discussion. The three main areas are:

* Removing the Add-on SDK. By Firefox 57 there should be no add-ons
(from within Mozilla or external) using the SDK on release.
https://bugzilla.mozilla.org/show_bug.cgi?id=1371065

* Removing support for un-supported configurations from Add-ons
Manager. https://bugzilla.mozilla.org/show_bug.cgi?id=1371064

* Removing some XPCOM support. There is no requirement from add-ons
team to keep XPCOM support around for experiments.
https://bugzilla.mozilla.org/show_bug.cgi?id=1347507

There will probably be more, but these are the three main areas. If
you have any questions or concerns, please comment on the bugs or
reach our to the team: https://wiki.mozilla.org/Add-ons#Who
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[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 proposes
pushing out an experiment to release, the usual release process for
that team will take place.

There is no need to think about interface compatibility in the future
with external clients.



On 14 June 2017 at 10:07, 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 reviewing
>>> changes that might affect them but of course changing IDL bindings is only
>>> one of a number of ways that a change to central could break an existing
>>> experiment.  This is one of the drawbacks of having out-of-tree code, I
>>> think its up to us (the webextensions maintainers) to either deal with
>>> this
>>> or get experiments worked into automation if this becomes a real problem
>>> in
>>> practice.
>>
>> Whoa. Experiments aren't tested in automation?
>
> Whoa.  We're going to still have to think about interface compat with
> external clients in a post-57 world?  This is the first I've heard of
> this.
>
>> Can they be, please? At least snapshotted versions.
>
> +1  Almost anything automation-related would be better than "hope
> peers think hard about this".
>
> -Nathan
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrew McKay]

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 Banner  wrote:
> On 22/09/2016 08:44, ISHIKAWA,chiaki wrote:
>>
>> 3:07:56 INFO -  1474488476446addons.xpi-utilsWARN
>> addMetadata: Add-on specialpow...@mozilla.org is invalid: Error: Invalid
>> addon ID: expected addon ID specialpow...@mozilla.org, found
>> special-pow...@mozilla.org in manifest  ...
>>
>>
>> I am not sure if this comes from the intended test.
>> Rather it looks a configuration error.
>> The error line seems to appear at beginning of the selected run of each
>> test directory.
>>
> ...
>>
>> cf. 3 results from the comm-central tree:
>> mozilla/testing/specialpowers/Makefile.in
>> ♢7 XPI_PKGNAME = specialpow...@mozilla.org
>
>
> Looks like this is different from what is specified in
> testing/specialpowers/install.rdf - which is the dashed version, and was
> introduced when it was rewritten last year.
>
> The simplest thing is probably to change the install.rdf to remove the dash
> as then it wouldn't be changing the file name on disk - and also update the
> other couple of instances in the tree. Probably worth a running through a
> few tests on try just to make sure as well.
>
> The test infrastructure has probably got away with it due to the next
> warning of "Could not uninstall invalid item from locked install location",
> so it kept on using it.
>
> Mark
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What if you could reinvent Firefox theming?

[Andrew McKay]

> 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 interesting contrast, although developers might
have been thinking about different things.

On 8 September 2016 at 15:41, Justin Dolske  wrote:
>
>
> On Thu, Sep 8, 2016 at 8:41 AM, Jared Wein  wrote:
>>
>> [...]
>
>
> Thanks for posting the results. A couple of observations...
>
>>
>> Why do you install themes?
>> [...] At 12% of responses was closer integration with the operating system
>
>
> Do the raw responses have further detail on what OSes are involved, and what
> kind of closer integration?
>
> I'm guessing this is mostly Linux (due to the gazillion different desktop
> environments and OS themes), though I also see the 28th-most-used theme on
> AMO is for making Firefox look like IE8.
>
>>
>> What capabilities would you like themes to have?
>> [...] Also at 3% of responses were requests from users who require larger
>> icons and improved readability of the browser's user interface for improved
>> accessibility. Not far behind, and ironically next in the order of
>> responses, were requests for a smaller browser UI (2%). These users
>> generally want to maximize the amount of screen space that web pages can
>> use.
>
>
> I'm a little surprised "make things smaller" came in so low!
>
> "Make things bigger" is somewhat curious... On Windows this is typically
> done by adjusting the display scaling factor in the OS settings. I wonder if
> people don't know about that, or are looking to make Firefox -- specifically
> -- larger than normal. I'm unclear on what Linux offers these days, and
> while I think OS X supports this internally it's not exposed in any UI.
> (Apple's preferred route seems to be screen zooming. Which is neat, I use it
> all the time and have normal vision.) So I'd be curious to understand this
> use-case better.
>
> Separately from themes, I think it would be a good idea to consider adding
> preferences UI for the default zoom-level of page content in Firefox. I
> think it's technically easy to do the same thing with chrome, but that would
> seem pretty strange to expose.
>
> Justin
>
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to bugzilla "plugins" product

[Andrew McKay]

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 this FFx::Add Ons Compatablity so that it's clear it's not plugins.
>
>
> Extensions and plugins are both types of add-ons so renaming makes it less
> clear as it then includes plugins and themes.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to bugzilla "plugins" product

[Andrew McKay]

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  wrote:
> Pasting what I mentioned in #fx-team
>
>
> Regarding FFx::Extension Compatibility componen
> t.
> 702 bugs total, 282 of which are not marked against a particular version
> . There are
> 11 in FFx 44, 10 in FFx 45, 9 in FFx 46, 7 in FFx 47, 3 in FFx 48
> ,
> 1 tracking FFx 47
> ,
> and only 44 bugs since the first of the year
>
> I'd like to get those into the right component, and make a decision
> on disposing
> of
> the rest?
>
> --
> Emma
>
>
>
> On Mon, May 2, 2016 at 1:37 PM, Emma Humphries  wrote:
>>
>> Let me take a look at those.
>>
>> On Mon, May 2, 2016 at 1:01 PM, Justin Dolske  wrote:
>>>
>>> Will Firefox :: Extension Compatibility also be rolled into this new ::
>>> Other component?
>>>
>>> (There are ~700 open bugs there still, most of which look pretty stale.)
>>>
>>> Justin
>>>
>>> On Mon, May 2, 2016 at 11:53 AM, Benjamin Smedberg
>>>  wrote:

 There used to be a bugzilla.mozilla.org product called "Plugins". This
 product has been renamed "External Software Affecting Firefox" and its
 component structure has been greatly simplified.

 It is usually not helpful to track defects in 3rd-party software in the
 Mozilla bug tracker. The only time we want to track those defects is when 
 we
 want to make explicit outreach efforts because those defects affect Firefox
 users.

 There were previously almost a hundred different "components" for fine
 classification of these bugs. This was not producing good results and 
 caused
 confusion for many people filing bugs. So I've asked for most of these
 components to be retired, and now there will be just three components:

 "Flash (Adobe)" - for bugs in Adobe Flash. I am triaging this list and
 working with Adobe when necessary.
 "OpenH264" - I believe Maire Reavy's team triages this component for
 bugs that affect our deployment of OpenH264 with Cisco.
 "Other" - For defects in basically all other 3rd-party software,
 including other NPAPI and GMP plugins, Firefox extensions, and other
 software such as antivirus tools, that may affect Firefox. I am triaging
 these bugs as necessary.

 --BDS

 ___
 firefox-dev mailing list
 firefox-...@mozilla.org
 https://mail.mozilla.org/listinfo/firefox-dev

>>>
>>>
>>> ___
>>> firefox-dev mailing list
>>> firefox-...@mozilla.org
>>> https://mail.mozilla.org/listinfo/firefox-dev
>>>
>>
>
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform