Re: Visual Studio 2017 coming soon

[Randell Jesup]

>2017-10-30 19:19 GMT+01:00 Kris Maglione :
>
>> Our static analysis tools are pretty good at catching a lot of lambda
>> capture bugs at this point, though. I'd be much less comfortable using them
>> if they weren't.
>>
>> It's probably worth considering whether we need to write static analysis
>> tools for a new feature before we turn it on, though...
>
>We can probably help with introducing more static analysis to avoid
>incorrect usages of C++{11,14,17} features.

Sure - but in most cases we've only realized that a static-analysis bit
was needed after hitting and solving a few (or a bunch of) crashes/sec bugs --
static-analysis tends to be reactive.

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Retiring Bugzilla Socorro Lens

[Kris Maglione]

Well, that's certainly a nifty bit of new UI... I never realized 
how much I needed it.


On Wed, Nov 01, 2017 at 07:50:22PM -0700, Anthony Hughes wrote:

This is now live. Much thanks to Dylan Hardison for getting it across the
line.

If you see any issues with it, or have feature requests, please report them
to https://github.com/ashughes1/bmo-bsl

Cheers!

On 31 October 2017 at 13:07, Anthony Hughes  wrote:


Due to an unrelated infrastructure issue the push has been delayed.
Apologies for the delay.

On 30 October 2017 at 13:27, Anthony Hughes  wrote:


This is a heads up that I am shutting down further development of my
Bugzilla Socorro Lens add-on. If you're currently using the add-on I
recommend that you uninstall it and please file issues at
https://github.com/ashughes1/bmo-bsl.

Over the past few weeks I've been working to integrate the functionality
it provides natively with bugzilla.mozilla.org. These changes should be
live as of Tuesday, October 31, 2017. You can read more about this at
https://ashughes.com/?p=453.

Thank you

--
Anthony Hughes
Senior Quality Engineer
Mozilla Corporation





--
Anthony Hughes
Senior Quality Engineer
Mozilla Corporation





--
Anthony Hughes
Senior Quality Engineer
Mozilla Corporation


--
Kris Maglione
Senior Firefox Add-ons Engineer
Mozilla Corporation

What is freedom of expression?  Without the freedom to offend, it
ceases to exist.
--Salman Rushdie

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

Re: PSA: Retiring Bugzilla Socorro Lens

[Anthony Hughes]

This is now live. Much thanks to Dylan Hardison for getting it across the
line.

If you see any issues with it, or have feature requests, please report them
to https://github.com/ashughes1/bmo-bsl

Cheers!

On 31 October 2017 at 13:07, Anthony Hughes  wrote:

> Due to an unrelated infrastructure issue the push has been delayed.
> Apologies for the delay.
>
> On 30 October 2017 at 13:27, Anthony Hughes  wrote:
>
>> This is a heads up that I am shutting down further development of my
>> Bugzilla Socorro Lens add-on. If you're currently using the add-on I
>> recommend that you uninstall it and please file issues at
>> https://github.com/ashughes1/bmo-bsl.
>>
>> Over the past few weeks I've been working to integrate the functionality
>> it provides natively with bugzilla.mozilla.org. These changes should be
>> live as of Tuesday, October 31, 2017. You can read more about this at
>> https://ashughes.com/?p=453.
>>
>> Thank you
>>
>> --
>> Anthony Hughes
>> Senior Quality Engineer
>> Mozilla Corporation
>>
>
>
>
> --
> Anthony Hughes
> Senior Quality Engineer
> Mozilla Corporation
>



-- 
Anthony Hughes
Senior Quality Engineer
Mozilla Corporation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal to remove some preferences override support

[Kris Maglione]

On Thu, Nov 02, 2017 at 01:06:09AM +0100, Jörg Knobloch wrote:

  On 02/11/2017 00:41, Nicholas Nethercote wrote:

1) Remove the defaults/preferences directory support for extensions. This
is a feature that was used by legacy extensions but is not used by
WebExtensions.

  Is that the facility that legacy extensions can have
  defaults/preferences/defaults.js to declare their preferences?

  In Thunderbird we're trying to keep legacy extensions working, currently
  by having |ac_add_options "MOZ_ALLOW_LEGACY_EXTENSIONS=1"| in the
  mozconfigs.

  So are the components legacy extensions rely on slowly dismantled? So some
  will keep working and some will stop working?


Yes. The components that non-bootstrapped add-ons rely on, 
anyway.



  If so, what is the replacement? Setting up the preference in JS on the fly
  in the add-on?


Yes.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal to remove some preferences override support

[Jörg Knobloch]

  
  
On 02/11/2017 00:41, Nicholas
  Nethercote wrote:


  1) Remove the defaults/preferences directory support for extensions. This
is a feature that was used by legacy extensions but is not used by
WebExtensions.

Is that the facility that legacy extensions can have defaults/preferences/defaults.js
to declare their preferences?
In Thunderbird we're trying to keep legacy extensions
working, currently by having |ac_add_options
"MOZ_ALLOW_LEGACY_EXTENSIONS=1"| in the mozconfigs.
So are the components legacy extensions rely on slowly
dismantled? So some will keep working and some will stop
working?
If so, what is the replacement? Setting up the preference in
JS on the fly in the add-on?
Jörg.

  

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

Proposal to remove some preferences override support

[Nicholas Nethercote]

Greetings,

In https://bugzilla.mozilla.org/show_bug.cgi?id=1413413 I am planning to
remove a couple of things relating to preferences.

1) Remove the defaults/preferences directory support for extensions. This
is a feature that was used by legacy extensions but is not used by
WebExtensions.

2) Remove the "preferences" override directory in the user profile.
This removes
support for profile preferences override files other than user.js.

The bug has a patch with r+. The specific things it removes include:
- The "load-extension-default" notification.
- The NS_EXT_PREFS_DEFAULTS_DIR_LIST/"ExtPrefDL" directory list, including
the entry from the toolkit directory service.

Does anybody foresee any problems with this change?

Thanks.

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: Data preference changes in Firefox 58

[Georg Fritzsche]

*This a shorter summary; if you need more details see this blog post
.*

As part of the Photon UI refresh, the Firefox data preferences were
streamlined. Previously we had two data controls for historic reasons, but
now:

   - There is just one control for data upload for Firefox, which is on by
   default.
   - Individual measurements are now collected from either all users or
   prerelease users.

So for Firefox we now just differentiate between “release data” and
“prerelease data”. *(For some specific features or studies there may still
be explicit opt-in notifications, but this covers all standard Firefox data
collection.)*

As detailed in another post
,
this doesn’t change anything about the type of data being collected while
it makes the data controls less confusing. However, it does have some
technical consequences for Telemetry that we landed in Firefox 58.
What does this mean for me?

While this has broader technical impact on Firefox data collection, the
changes we landed should make this work mostly seamless.

For *Firefox users*, there is no significant change; the data upload
setting users chose is respected as before. The opt-in for additional
Telemetry data went away; instead we always collect less data on Firefox
release.

For most *Firefox development*, nothing should change. Telemetry takes care
of doing the right thing for histograms, scalars & events internally.

Local builds from current mozilla-central should default to recording all
the prerelease data but not upload it, without any extra build flags.
*about:telemetry* allows you to confirm that.

For testing locally how release Telemetry behaves, there is a hidden pref:
*toolkit.telemetry.testing.overridePreRelease*

.

For *Fennec development*, nothing changed. Fennec still has the same
Telemetry behavior and preference handling as before.

For *writing Firefox tests*, *nsITelemetry.canRecordExtended* can be used
to check whether prerelease data is recorded. The pref
*toolkit.telemetry.testing.overridePreRelease* can be used for tests that
need to enable prerelease behavior.

For *QAing Firefox data collection*, you might need to override the
prerelease status using the pref
*toolkit.telemetry.testing.overridePreRelease*. The prerelease and sending
status can be checked in *about:telemetry*.

If you are *looking at Telemetry data*, there are some changes. In Firefox
58, we will not receive the “extended” data from release anymore. This
directly affects some parts of telemetry.mozilla.org that provided release
data from that small *“opt-in”* population:

   - the distribution and evolution dashboards will soon not show release
   data anymore.
   - telemetry.js
   
   and the aggregates service will not provide release data when 58 is
   released.

If you will be affected by these changes and need alternatives, please
reach out to us.
Reaching out

   - If you have any questions reach out
   to :gfritzsche, :chutten, :dexter, :frank or the team
   .
   - For any specific issues, please file a bug
   
.
   We are using bug 1406390
    for tracking.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsAutoConfig

[Mike Kaply]

I didn't write the test, so I honestly don't know. I'll try to make time to
take a look.

Mike

On Wed, Nov 1, 2017 at 12:04 PM,  wrote:

> Hey Mike,
> according to our code coverage report, nsAutoConfig is never executed
> during tests.
>
> As far as I can see, it is actually not tested, as the test you mentioned
> is not setting the autoadmin.global_config_url pref that would make
> nsReadConfig instantiate nsAutoConfig. Is that correct?
>
> I'd like to understand whether this is a problem in our coverage
> collection tools that are not picking up this file for some reason or if it
> actually is not tested. I've opened https://bugzilla.mozilla.org/
> show_bug.cgi?id=1413600.
>
> - Marco.
>
> On Tuesday, October 31, 2017 at 4:22:06 PM UTC+1, mka...@mozilla.com
> wrote:
> > On Tuesday, October 31, 2017 at 12:10:21 AM UTC-5, Nicholas Nethercote
> wrote:
> > > Hi,
> > >
> > > I was just looking at the extensions/pref/autoconfig/ directory and
> trying
> > > to understand what it does.
> > >
> > > As far as I can tell, the code is there to allow custom deployments
> with
> > > particular prefs set, as described at
> > > https://developer.mozilla.org/en-US/Firefox/Enterprise_
> deployment#Configuration
> > >
> > > It's initialized by modules/libpref/Preferences.cpp if a
> > > "general.config.filename" pref is found:
> > > http://searchfox.org/mozilla-central/rev/
> 1ebd2eff44617df3b82eea7d2f3ca1b60cc591a0/modules/libpref/
> Preferences.cpp#3907-3920
> > >
> > > There is also some MozHarness code relating to it here:
> > > http://searchfox.org/mozilla-central/source/testing/
> mozharness/mozharness/mozilla/firefox/autoconfig.py
> > >
> > > Just to check: is this still supported functionality?
> > >
> > > Thanks.
> > >
> > > Nick
> >
> > Yes, this is very much supported functionality. It is our primary means
> of enterprise customization right now.
> >
> > The reason there are very few tests is because when it was first
> developed, it wasn't possible to write tests that involved putting down
> files before startup. There are some tests now:
> >
> > http://searchfox.org/mozilla-central/source/extensions/
> pref/autoconfig/test/unit
> >
> > Mike Kaply
>
> ___
> 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: nsAutoConfig

[mcastelluccio]

Hey Mike,
according to our code coverage report, nsAutoConfig is never executed during 
tests.

As far as I can see, it is actually not tested, as the test you mentioned is 
not setting the autoadmin.global_config_url pref that would make nsReadConfig 
instantiate nsAutoConfig. Is that correct?

I'd like to understand whether this is a problem in our coverage collection 
tools that are not picking up this file for some reason or if it actually is 
not tested. I've opened https://bugzilla.mozilla.org/show_bug.cgi?id=1413600.

- Marco.

On Tuesday, October 31, 2017 at 4:22:06 PM UTC+1, mka...@mozilla.com wrote:
> On Tuesday, October 31, 2017 at 12:10:21 AM UTC-5, Nicholas Nethercote wrote:
> > Hi,
> > 
> > I was just looking at the extensions/pref/autoconfig/ directory and trying
> > to understand what it does.
> > 
> > As far as I can tell, the code is there to allow custom deployments with
> > particular prefs set, as described at
> > https://developer.mozilla.org/en-US/Firefox/Enterprise_deployment#Configuration
> > 
> > It's initialized by modules/libpref/Preferences.cpp if a
> > "general.config.filename" pref is found:
> > http://searchfox.org/mozilla-central/rev/1ebd2eff44617df3b82eea7d2f3ca1b60cc591a0/modules/libpref/Preferences.cpp#3907-3920
> > 
> > There is also some MozHarness code relating to it here:
> > http://searchfox.org/mozilla-central/source/testing/mozharness/mozharness/mozilla/firefox/autoconfig.py
> > 
> > Just to check: is this still supported functionality?
> > 
> > Thanks.
> > 
> > Nick
> 
> Yes, this is very much supported functionality. It is our primary means of 
> enterprise customization right now.
> 
> The reason there are very few tests is because when it was first developed, 
> it wasn't possible to write tests that involved putting down files before 
> startup. There are some tests now:
> 
> http://searchfox.org/mozilla-central/source/extensions/pref/autoconfig/test/unit
> 
> Mike Kaply

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

Re: Intent to ship: Retained Display Lists

[Ben Kelly]

On Tue, Oct 31, 2017 at 11:44 PM, Ben Kelly  wrote:

> Anecdotely this pref seems to make twitter much less janky on fennec on my
> Nexus 5x.
>

Actually, at least some retained display list code is disabled in non-e10s
because of a process type check.  Its unclear what flipping the pref does
or does not do on fennec at the moment.

I filed a bug for the process checks currently being used here:

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

Sorry for my confusion.

Ben
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform