Re: Generating Visual Studio project files by default

This is great! Just few questions: Can we debug firefox in the IDE during mochitest? i.e.: ./mach mochitest --debugger=devenv Does it supports nmake as well? Thanks. Wei-Cheng Pan On 5/25/16 7:00 AM, Gregory Szorc wrote: > Coming soon to your local builds, Visual Studio project files will be

How do we measure active users on a given architecture?

I've seen statements such as "0.04% Firefox users don't have SSE"*. What I'd like to know is if when we make these measurements we also ascertain whether or not those users are on the most recent release. There's often pushback, which I think is certainly reasonable, related to abandoning users or

Documentation on how to read crash reports

Hi, Do we have documentation on how to read crash reports? The only thing I have found is this page: https://support.mozilla.org/en-US/kb/helping-crashes which is not bad, but is lacking some details. I suspect there is quite a bit of crash report interpretation wisdom that is in various people'

Re: All about crashes

Thanks for putting this together! It would be nice to see some consolidated details on how to investigate crashes, ie loading minidumps in Visual Studio, interpreting results, figuring out when VS is lying to you and what disassembly to look at. I think there's some great institutional knowledge h

Re: Generating Visual Studio project files by default

> On May 24, 2016, at 19:29, Jeff Gilbert wrote: > > What's the build-time impact of this? It should be marginal compared to all the other stuff that happens during a build, even a light build. Local and automation builds print the timing numbers and I've been doing a lot of work lately to s

Re: All about crashes

On 5/25/16 12:05 AM, Tobias B. Besemer wrote: Why are there so many crashes on Windows and so less on Linux ??? Mostly because there are so many more people running Firefox on Windows than on Linux... -Boris ___ dev-platform mailing list dev-platfo

Re: Generating Visual Studio project files by default

On Tue, May 24, 2016 at 7:29 PM, Jeff Gilbert wrote: > What's the build-time impact of this? The implicit question being, if this impact is non-zero, can I turn it off? Also, does it make any sense to do this on try machines? ___ dev-platform mailing l

Re: Generating Visual Studio project files by default

What's the build-time impact of this? On Tue, May 24, 2016 at 4:00 PM, Gregory Szorc wrote: > Coming soon to your local builds, Visual Studio project files will be > generated automatically when building on Windows because we want to > encourage more people to use them because fully-featured IDEs

Re: Intent to deprecate: MacOS 10.6-10.8 support

On Wed, May 25, 2016 at 2:19 AM, Lawrence Mandel wrote: > On Tue, May 24, 2016 at 12:11 PM, Henrik Skupin wrote: > > > Mike Hommey wrote on 05/11/2016 05:06 AM: > > >> The post states "Mozilla will end support for Firefox on OS X 10.6, > > 10.7, > > >> and 10.8 in August, 2016." This means that

Generating Visual Studio project files by default

Coming soon to your local builds, Visual Studio project files will be generated automatically when building on Windows because we want to encourage more people to use them because fully-featured IDEs can be productivity wins. The Visual Studio projects now automatically target the Visual Studio ve

Re: Two Factor Authentication and Github

Thanks all. I got me a new cellphone, as dumb as I could find, actually dumber than my former one (e.g. only 1 number per contact, and only 1 game, one I don't fancy) though with better-looking displays and I think finer pixel resolution. Cost me 25€ with earphones and charger but no SIM card (Sams

Re: All about crashes

Hi Nick, Wasn't sure how you wanted feedback. Here's some in email form. "Crashes are caused by defects" Reading this I think it implies defects in Firefox. This is not always the case. Crashes are also the result of interactions with third party software. Both that that we designed for (like NP

Re: Intent to implement and ship: spec changes to the .form property and "form" attribute on elements

On 5/24/16 7:16 AM, Florin Mezei wrote: Is there any chance for this to break web compatibility? Yes, there is, but seems pretty low. The Chrome intent to implement at https://groups.google.com/a/chromium.org/d/msg/blink-dev/QWyCpJjgfY8/TOxG9n-OAQAJ has some data. Quoting: ---

Re: Readable Bug Statuses in Bugzilla

Indeed, see tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1150541 Mark On 2016-05-24 1:03 PM, Emma Humphries wrote: > Yes, the plan is that the 'Modal' view will become the default, and the bmo > team is working on that. > > Meanwhile, you can beat the rush and switch over to the v

Re: Readable Bug Statuses in Bugzilla

I also recommend reading through the tests in the GitHub repo because that documents the behavior of the module. The demo code will also grab a stack of recent bugs and generate statuses for them. -- Emma On Tue, May 24, 2016 at 9:47 AM, Gijs Kruitbosch wrote: > On 24/05/2016 16:54, Ted Mielcz

Re: Readable Bug Statuses in Bugzilla

Also, if you see something, file something. Please report bugs and feature requests in the bugzilla.mozilla.com::User Interface:Modal component. I'll create tracking issues in the GitHub repo. If you have a pull request, I'll open a bugzilla ticket to pick up changes in bmo. On Tue, May 24, 2016

Re: Readable Bug Statuses in Bugzilla

Yes, the plan is that the 'Modal' view will become the default, and the bmo team is working on that. Meanwhile, you can beat the rush and switch over to the view in preferences. -- Emma On Tue, May 24, 2016 at 9:55 AM, J. Ryan Stinnett wrote: > On Tue, May 24, 2016 at 11:47 AM, Gijs Kruitbosch

Re: Readable Bug Statuses in Bugzilla

On Tue, May 24, 2016 at 11:47 AM, Gijs Kruitbosch wrote: > You can see this in bmo if you have the new/modal/experimental UI enabled ( > https://bugzillatips.wordpress.com/2015/08/07/new-modal-ui-for-show_bug-on-bmo/ > ) . Kind of a side note, but do we intend to make the "experimental" UI the si

Re: Readable Bug Statuses in Bugzilla

On 24/05/2016 16:54, Ted Mielczarek wrote: On Tue, May 24, 2016, at 11:45 AM, Emma Humphries wrote: Last week the bugzilla.mozilla.org team had a work week in the San Francisco office. They were finishing the work on the modal edit view in Bugzilla, and joined them to land another new feature: R

Re: Two Factor Authentication and Github

Rok Garbas 2016 May 24 at 01:50 you can also setup github's 2fa using GAuth[1] firefox app Or use Firekey in any web browser: https://firekey.org/ -myk ___ dev-platform mailing list dev-platform@lists.mozilla.org https://l

Re: Intent to deprecate: MacOS 10.6-10.8 support

On Tue, May 24, 2016 at 12:11 PM, Henrik Skupin wrote: > Mike Hommey wrote on 05/11/2016 05:06 AM: > >> The post states "Mozilla will end support for Firefox on OS X 10.6, > 10.7, > >> and 10.8 in August, 2016." This means that we will end support with the > >> Firefox 48 release. i.e. Firefox 48

Re: Intent to deprecate: MacOS 10.6-10.8 support

Mike Hommey wrote on 05/11/2016 05:06 AM: >> The post states "Mozilla will end support for Firefox on OS X 10.6, 10.7, >> and 10.8 in August, 2016." This means that we will end support with the >> Firefox 48 release. i.e. Firefox 48 will not support OS X 10.6-10.8. > > That's why the post should h

Re: Readable Bug Statuses in Bugzilla

On Tue, May 24, 2016, at 11:45 AM, Emma Humphries wrote: > Last week the bugzilla.mozilla.org team had a work week in the San > Francisco office. They were finishing the work on the modal edit view in > Bugzilla, and joined them to land another new feature: Readable Statuses. > > Bugs in bugzilla.

Readable Bug Statuses in Bugzilla

Last week the bugzilla.mozilla.org team had a work week in the San Francisco office. They were finishing the work on the modal edit view in Bugzilla, and joined them to land another new feature: Readable Statuses. Bugs in bugzilla.mozilla.org have a lot of metadata, and it's often not immediately

[Firefox Desktop] Issues found: May 16th to May 20th

Hi everyone, Here's the list of new issues found and filed by the Desktop Release QA Team last week, *May 16 - May 20* (week 20). Additional details on the team's priorities last week, as well as the plans for the current week are available at: https://public.etherpad-mozilla.org/p/Deskt

RE: Intent to implement and ship: spec changes to the .form property and "form" attribute on elements

Is there any chance for this to break web compatibility? Sounds like it shouldn't. Regards, Florin. -Original Message- From: dev-platform [mailto:dev-platform-bounces+florin.mezei=softvisioninc...@lists.mozilla.org ] On Behalf Of Boris Zbarsky Sent: Monday, May 23, 2016 10:17 PM To: dev-p

Re: Two Factor Authentication and Github

you can also setup github's 2fa using GAuth[1] firefox app [1] https://marketplace.firefox.com/app/gauth On Tue, May 24, 2016 at 5:59 AM, Tony Mechelynck wrote: > Well, apparently my home phone does not receive SMS messages. Maybe > they are blocked by the phone company. I'll see what is the dum

Re: Return-value-optimization when return type is RefPtr

jww...@mozilla.com writes: > For > > RefPtr GetFoo() { > RefPtr foo; > // ... > } > > should we: > > 1. return foo and expect RVO to kick in to eliminate additional AddRef/Release > 2. return foo.forget() > 3. return Move(foo) > > Which one is preferred? > > ps: I find gcc is able to apply RVO

Return-value-optimization when return type is RefPtr

For RefPtr GetFoo() { RefPtr foo; // ... } should we: 1. return foo and expect RVO to kick in to eliminate additional AddRef/Release 2. return foo.forget() 3. return Move(foo) Which one is preferred? ps: I find gcc is able to apply RVO even with "-O0". Not sure if it is also true for othe