Re: Adopting the black Python code style

On Mon, Oct 12, 2020 at 10:05 AM Ricky Stewart wrote: > Hello everyone, > > If you don't write Python code in mozilla-central, you can stop reading > now. > > On October 19, 2020 we will be officially adopting the black Python style > for all our Python code in mozilla-central. > > black

Re: A new testing policy for code landing in mozilla-central

On Wed, Sep 16, 2020 at 5:10 AM Eric Rescorla wrote: > I certainly have some sympathy for this, but I'm not sure that it needs to > be > addressed via tools. What I would generally expect in cases like this is > that the reviewer says "why isn't there a test for X" and the author says > "for

Re: A new testing policy for code landing in mozilla-central

On Tue, Sep 15, 2020 at 8:03 AM Brian Grinstead wrote: > (This is a crosspost from firefox-dev) > > Hi all, > > We’re rolling out a change to the review process to put more focus on > automated testing. This will affect you if you review code that lands in > mozilla-central. > > ## TLDR > >

You can delete ipc/ipdl/ipdl/ipdl_lextab.py and ipdl_yacctab.py

In case like me you've had these files staring back at you whenever you do git status or whatever the equivalent is in hg, according to discussion in bug 1630362, as of about May 7th you can delete these files and they won't come back. Andrew ___

Re: Deprecation notice - change to Treeherder's jobdetail API

On Thu, Apr 9, 2020 at 6:51 PM Sarah Clements wrote: > Hello, > > As part of maintenance work and performance improvements to Treeherder, > we're making changes to some of the data that's stored in our database. On > *April > 30th*, we will no longer be retrieving uploaded artifacts for jobs

Removing support for non-nsISupports XPIDL interfaces

In times of old, you could declare an XPIDL interface that didn't inherit from nsISupports, as long as it only had constants in it. I'm not sure why it was really such a burden to make it inherit from nsISupports. Anyways, it appears that our de-COM efforts have proceeded far enough that this

Re: Finding windows and docshells leaked until shutdown

On Wed, Oct 2, 2019 at 2:35 PM Geoff Lankow wrote: > Hi all, I need some advice. > > I'm trying to enable Mochitest on debug builds of Thunderbird. It works > fine, except for the leak check, which finds a number of leaked windows > and docshells. Obviously we don't want to leak these things,

Re: Documentation for IPDL needs some edit

On Sat, Aug 10, 2019 at 7:15 AM wrote: > I have started to learn about IPDL and am reading IPDL Tutorial ( > https://developer.mozilla.org/en-US/docs/Mozilla/IPDL/Tutorial). It looks > like the document is old and needs some edits, but this is an area I'm > still learning so I want to make sure:

Re: Crash reports with Fission enabled are now indicated by DOMFissionEnabled = 1

On Fri, Jul 5, 2019 at 7:50 PM Masatoshi Kimura wrote: > On 2019/07/06 6:54, Andrew McCreight wrote: > >> Here's an example of a crash report with DOMFissionEnabled: > >> > https://crash-stats.mozilla.org/report/index/dac0a91a-ad57-4446-9a82-505a80190705#tab-metad

Re: Crash reports with Fission enabled are now indicated by DOMFissionEnabled = 1

On Fri, Jul 5, 2019 at 1:12 PM Andrew McCreight wrote: > I landed bug 1560977 a few days ago, so you can now see in a crash report > if Fission was enabled. If it was, the "meta data" tab will have a value of > 1 for DOMFissionEnabled. The behavior is modeled after

Crash reports with Fission enabled are now indicated by DOMFissionEnabled = 1

I landed bug 1560977 a few days ago, so you can now see in a crash report if Fission was enabled. If it was, the "meta data" tab will have a value of 1 for DOMFissionEnabled. The behavior is modeled after DOMIPCEnabled which indicates when e10s is enabled. There is no explicit indicator if Fission

XPIDL interfaces with [notxpcom] methods or attributes must declare [builtinclass]

I just landed bug 1550770 which makes it an error to have an XPIDL interface with a [notxpcom] method or attribute that is not [builtinclass]. Previously, we would just silently make it builtinclass. The new approach makes it easier to see if an interface is really builtinclass or not, but if you

Re: Improving our usage of Bugzilla

On Tue, Mar 12, 2019 at 3:55 AM Sylvestre Ledru wrote: > With this change, we are going to extend Bugzilla to add a new field with > three new values: > >- > >Defect - an issue in one of our products >- > >Enhancement - a new feature or an improvement >- > >Task - a

Re: What is future of editor mode-lines after the switch to clang-format?

On Fri, Nov 30, 2018 at 10:00 AM wrote: > Now that all of mozilla-central is been migrated to use clang-format > automated code formatting, the question of what should happen with editor > modelines at the top of files should be considered. > >

Re: The upcoming C/C++ coding style change

On Thu, Nov 29, 2018 at 8:44 AM Honza Bambas wrote: > OTOH, if the changes are only whitespace changes, maybe there is some > way `patch --ignore-whitespace --fuzz N` could apply the patches. Then > just re-format and your patches are OK. > The changes that clang-format makes include things

Re: assignment between related nsCOMPtrs<> now works

gt; On Tue, Oct 2, 2018 at 9:30 AM Andrew McCreight > wrote: > >> I've landed bug 1494765, which allows you to do assignments between >> nsCOMPtrs for classes that are related by subtyping. >> >> For instance: >> >> class A { ... ]; >> class

assignment between related nsCOMPtrs<> now works

I've landed bug 1494765, which allows you to do assignments between nsCOMPtrs for classes that are related by subtyping. For instance: class A { ... ]; class B : public A { ... }; nsCOMPtr b = ...; nsCOMPtr a = b; // this works now This is a step towards bug 1493226, which is going to

Re: Enabling (many) assertions in opt builds locally and eventually Nightly

On Wed, Sep 19, 2018 at 5:44 PM Kris Maglione wrote: > On Wed, Sep 19, 2018 at 05:37:46PM -0700, Bobby Holley wrote: > >So, I don't think we need to do anything fancy with forking - we'd just > >need to capture stacks and send them via telemetry rather than as a crash > >report. This was the

Re: Web Replay landed in Firefox nightly

On Sun, Jul 29, 2018 at 7:35 PM, Anthony Jones wrote: > I'm chuffed to announce that Web Replay has finally made its way into > nightly. It brings tardis like functionality (or perhaps rr like) to > Firefox Devtools, enabling recording and replaying of tab behavior, and > best of all, stepping

Re: Fission MemShrink Newsletter #1: What (it is) and Why (it matters to you)

* Eric Rahm added an AWSY test suite to track base content process memory >>(https://bugzil.la/1442361). Results: >> >> Resident unique: https://treeherder.mozilla.org >> /perf.html#/graphs?series=mozilla-central,1684862,1,4 >> =mozilla-central,1684846,1,4=mozil

Re: Fission MemShrink Newsletter #1: What (it is) and Why (it matters to you)

On Wed, Jul 11, 2018 at 5:42 AM, David Bruant wrote: > > > * Andrew McCreight created a tool for tracking JS memory usage, and >> figuring >> out which scripts and objects are responsible for how much of it >> (https://bugzil.la/1463569). >> > How ofte

Fwd: Bugs being resolved as INACTIVE

For people who aren't subscribed to dev-firefox, be aware that open bugs that haven't been modified in a year have been set to "inactive" without any bugmail being generated, in bug 1445054. It is probably better to that thread rather than creating a new parallel thread on this list... Andrew

Investigating leaks using DMD heap scan mode

A few years ago I came up with an approach for using a combination of cycle collector logs and DMD (which tracks all live blocks of heap allocated memory) to investigate leaks of refcounted objects. I've only had to use it about a half dozen times (most recently in bug 1451985), but it is very

Re: Using WebIDL objects in XPIDL

On Thu, Apr 19, 2018 at 12:53 PM, Gijs Kruitbosch wrote: > Dumb question because I don't do this very often - sorry! > > I am intending to async-ify a sync JS-implemented idl-defined API (which > currently returns an unsigned long), that has a few C++ consumers. I was >

XPT files shouldn't be added to package-manifest.in any more

I recently landed bug 1438688, which makes it so that we don't ship XPT files any more, so they don't need to be added to a package-manifest.in file. (Instead, the XPT information is compiled into the binary.) I think it'll give you an error if you add it anyways, but I haven't tested it. We still

Most definitions of Ci, Cr, Cc, and Cu have been removed from the tree

Following up on my previous post, I have just landed (in bug 1432992) the removal of most of the definitions of Ci, Cr, Cc, and Cu. This touched almost 2000 files, so it may affect your patches, but hopefully rebasing is easy. Thank you to Florian for reviewing a nearly-unreviewable patch and

Ci, Cr, Cc, and Cu are now automatically defined in all chrome scopes

Bug 767640 just merged to mozilla-central. This patch makes it so that Ci, Cr, Cc, and Cu are automatically defined in any chrome scope that has a Components object. Rejoice, because you no longer need to add "var Ci = Components.interfaces" into every file. I have a followup bug, bug 1432992,

Re: Announcing the next Extended Support Release of Firefox - ESR60 with policy engine

On Wed, Jan 10, 2018 at 6:22 AM, Romain Testard wrote: > Some enterprises may indeed find that enabling site isolation is worth the > trade-offs (memory usage seems to be the main one on Chrome's > implemenation). > Just to be clear here, we do not support the same kind of

Re: Next year in web-platform-tests

On Fri, Dec 15, 2017 at 9:38 AM, James Graham wrote: > Following the summary of what we achieved in wpt in the last year, I'd > like to solicit input from the gecko community to inform the > priorities of various pieces of wpt work for the next year. > > In order to

new helper class to avoid leaks when using DOM promises in non-window-related data structures

I just landed a patch for bug 1409115 that fixes a leak where a global data structure (some per-process service worker queue) holds alive a DOM promise, which ends up leaking the window forever. Fundamentally, holding alive a DOM promise, which holds alive its window, from a data structure that is

Re: Better triage for intermittent leaks in tests?

I half-heartedly keep an eye on intermittent leaks, so I can more active in looking at them. We'll need more logging for them to be actionable, but I guess the high frequency ones are easier to catch. Andrew On Thu, Oct 26, 2017 at 10:20 AM, Geoffrey Brown wrote: > Some of

Re: Intent to require `mach try` for submitting to Try

On Tue, Sep 19, 2017 at 8:49 AM, Eric Rescorla wrote: > Generally no, but this is an unfortunate consequence of Mozilla's decision > a while ago to pick a VCS which has not turned out to be the dominant > choice (not placing blame here, but I think it's clear that's how it's >

Re: Canonical cinnabar repository

On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta wrote: > I've tried using cinnabar a couple of times now and the last time I > tried, this was the dealbreaker for me. My worfklow often involves > moving a branch from one machine to another and the extra hassle that > results

Re: Incoming JS module (JSM) / component loader changes

: setting a property that has > only a getter", and "ReferenceError: assignment to undeclared variable", > and if you see any, file bugs blocking bug 1394556. > > 2) Andrew McCreight has been working on changing the component loader to > load most modules and components

Re: Coding style question: Meaningless argument names in declarations

On Thu, Sep 7, 2017 at 5:07 AM, Emilio Cobos Álvarez wrote: > Hi, > > I have a coding style question which I don't see addressed in the coding > style page. > > Given there have been a few threads lately on coding style, I guess I > should just ask. > > We have a lot of

NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION_INHERITED is gone

Just use NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION instead. These have been identical for years, so I just removed the _INHERITED variant in an attempt to make the CC macros a little simpler to deal with, in bug 1391005. Andrew ___ dev-platform mailing

Re: Improving visibility of compiler warnings

On Thu, May 25, 2017 at 4:03 PM, wrote: > On Friday, May 26, 2017 at 6:03:02 AM UTC+12, Chris Peterson wrote: > > On 2017-05-25 5:31 AM, Ehsan Akhgari wrote: > > > On 05/19/2017 02:44 PM, Gregory Szorc wrote: > > >> `mach build` attempts to parse compiler warnings to a

Re: Is it OK to make allocations that intentionally aren't freed?

On Mon, May 22, 2017 at 4:45 PM, Karl Tomlinson <mozn...@karlt.net> wrote: > Andrew McCreight writes: > > > On Fri, May 19, 2017 at 7:38 PM, Nicholas Nethercote < > n.netherc...@gmail.com > >> wrote: > > > >> There's also a pre-processor constant th

Re: Is it OK to make allocations that intentionally aren't freed? (was: Re: Is Big5 form submission fast enough?)

On Fri, May 19, 2017 at 7:38 PM, Nicholas Nethercote wrote: > There's also a pre-processor constant that we define in Valgrind/ASAN/etc. > builds that you can check in order to free more stuff than you otherwise > would. But I can't for the life of me remember what it's

Re: Have you run 'mach bootstrap' lately?

On Fri, May 12, 2017 at 11:34 AM, Ted Mielczarek wrote: > On Fri, May 12, 2017, at 10:45 AM, Sylvestre Ledru wrote: > > Would it be possible to add a check like: > > "You haven't updated your local configuration since XX days, please > > consider running > > mach bootstrap

Fwd: Changes to code review tools and processes

This was posted on mozilla.tools yesterday but doesn't seem to have made it to dev.platform. It is likely to be of interest to many people on this list. Note the comment "If you have questions or concerns beyond those addressed below, please use the mozilla.tools group and/or #phabricator on IRC

Watch out for a rogue nsILayoutHistoryState.h

I updated my tree this morning and did a build, and I ended up with a new untracked nsILayoutHistoryState.h file. Be sure to not accidentally commit it. I deleted the file, and then had to do a clobber build to fix everything. I filed bug 1351461 for the clobber issue or whatever it is.

IPDL error/ unit tests now require a failure reason

Note: this only affects you if you write tests in the ipc/ipdl/test/ipdl/error/ directory. In bug 1319620, I added checking of expected failures for IPDL error unit tests. This will ensure that changes like renaming IPDL keywords won't make the error tests silently start failing for the wrong

Re: e10s-multi update and tests

On Wed, Mar 22, 2017 at 6:00 PM, Nicholas Nethercote wrote: > Do we have a clear definition of "content process"? I.e. does/will it > include: > > - GMP processes (no?) > - GPU process (probably not?) > - file:// URL processes (probably should?) > - Web Extensions

FYI: git-cinnabar and a "Intermittent IndexError: tuple index out of range" error

If you are seeing this error when you try to do |git mozreview push|, update your version-control-tools. Then you'll see a different error. Work related to that is being looked at in https://bugzilla.mozilla.org/show_bug.cgi?id=1338530 Andrew ___

Re: Please write good commit messages before asking for code review

On Thu, Mar 9, 2017 at 1:55 PM, Nicholas Alexander wrote: > On Thu, Mar 9, 2017 at 1:48 PM, Boris Zbarsky wrote: > > > On 3/9/17 4:35 PM, Eric Rescorla wrote: > > > >> I'm in favor of good commit messages, but I would note that current m-c > >>

Re: All the processes

On Mon, Mar 6, 2017 at 4:45 PM, Eric Rahm wrote: > I'd suggest looking at the memory overhead of Chrome's individual processes > as compared to ours, it's pretty impressive. My blog posts on our own e10s > memory usage [1] and comparison to other browsers [2] have further

Re: All the processes

On Fri, Mar 3, 2017 at 4:15 PM, Nicholas Nethercote wrote: > Hi, > > I want to understand all the different processes that we can and will have > in Firefox. Here's a list I constructed off the top of my head. > > - main process > > - content process(es): 1 on release for

IPDL support for spawns, opens, and bridges being removed

In bug 1316755, I'm working on removing support for the IPDL keywords spawns, opens and bridges. These have been superseded by endpoints, a more general mechanism for starting up IPDL actors. The only drawback is that endpoints don't allow for static analysis of the relationships between

Re: Runnable labeling for Quantum DOM

On Thu, Dec 1, 2016 at 8:21 PM, Boris Zbarsky wrote: > If you want to get started before that, please make sure to >> file a bug on what you're doing before you start. That should avoid >> duplicating work. >> > > Is there an overall tracking bug people could check to see which

removing about:bloat

In bug 1308652, I'm planning on removing about:bloat. It disables XPCOM leak tracking while it is running, so running it can cause false negative leaks (bug 1271182). I don't think anybody uses it much any more, so I'm going to remove it. Andrew ___

Re: Would "Core :: Debugging: gdb" be a good bugzilla component?

You could also just file things like that in the corresponding component, and maybe create some kind of meta bug for gdb hooks. So debugging for nsTArray would be filed in XPCOM, etc. I think that's the way it works for Javascript engine related debugging hooks. Failing that, having the nested gdb

Re: Reorganization of Firefox-UI tests in mozilla-central

On Fri, Sep 2, 2016 at 12:11 PM, Ryan VanderMeulen <rya...@gmail.com> wrote: > On 9/2/2016 2:56 PM, Andrew McCreight wrote: > >> In DOM triage, we've just set up our list to not include bugs with the >> keyword intermittent failure. Ideally, we'd see intermittent failures

Re: PSA: mozilla/unused.h renamed to mozilla/Unused.h

On Fri, Aug 26, 2016 at 8:16 PM, Gregory Szorc wrote: > What I'm trying to say is thank you for reminding me to implement the > hook. And congratulations on likely being the last person to perform a case > only rename on the repo. > Sarcastic commentary on an innocent

Re: Alternative to Bonsai?

Searchfox works pretty well for blame including the CVS history, including large files that github won't show you. On Thu, Aug 25, 2016 at 12:09 PM, Philip Chee wrote: > On 16/09/2015 01:01, smaug wrote: > > On 09/15/2015 06:53 PM, Boris Zbarsky wrote: > >> On 9/15/15

Re: Heads up: valgrind/memcheck issues

We regularly run AddressSanitizer and Valgrind on mozilla-central, so it seems likely this is Thunderbird specific. Please file security bugs in bugzilla with any reports you have found. Andrew On Thu, Aug 25, 2016 at 10:59 AM, ISHIKAWA,chiaki wrote: > Hi, > > I

Re: mach and ccache failure?

I'm not sure of the particulars, but I believe ccache doesn't share the results between two object directories unless you set it up explicitly to use relative paths. Or something like that. https://ccache.samba.org/manual.html#_compiling_in_different_directories On Fri, Aug 19, 2016 at 3:45 PM,

Re: Checkin-needed requests - Please include complete information in the commit message :)

On Sun, Jul 10, 2016 at 7:29 PM, Martin Thomson wrote: > Is now the right time to start talking about retiring checkin-needed, > or is it still heavily used? > It is useful for anybody who doesn't use MozReview. FWIW I see 14 bugs with it set right now. > > On Sat, Jul

Re: Gecko shutdown (London session)

On Thu, Jun 30, 2016 at 8:41 AM, Aaron Klotz wrote: > Did the now-defunct exit(0) project ever come up in this discussion? > > See bugs 662444 and 826143. This was a perf team project back in the > Snappy days where the objective was to write important data to disk ASAP, >

Re: Notes about implementing DOM APIs in Rust

On Wed, Jun 22, 2016 at 1:05 PM, Henri Sivonen wrote: > Now that I'm looking at the hand-written notes that I made in the > meeting, I notice that the above paragraph fails to say how the > AddRef, Release and associated cycle collection-related calls are > routed from C++

Top crash list is odd right now

blassey landed a patch to suggest that users submit unsubmitted crash reports. This is going to make various kinds of crashes, like shutdown crashes, grossly overrepresented in the crash-stats "Top Crashers" list. You probably want to use "By build date" instead of the default "By report date" for

Re: All about crashes

On Fri, Jun 3, 2016 at 6:57 AM, Ted Mielczarek wrote: > BugHunter[1] attempts to reproduce crashes from crash-stats by loading > the URLs from the crash reports, which is sometimes successful. > Of note, BugHunter also uses both debug and AddressSanitizer builds, which

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

On Tue, May 31, 2016 at 7:14 PM, Nicholas Nethercote wrote: > If you use your favourite source code search tool to look for > "Shutdown too long", you'll find that this crash is occurring in > toolkit/components/terminator/nsTerminator.cpp. For example, here's a > DXR

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

On Mon, May 30, 2016 at 11:22 PM, Nicholas Nethercote < n.netherc...@gmail.com> wrote: > 6 MOZ_RELEASE_ASSERT(pi->mInternalRefs < pi->mRefCount) (Cycle > collector found more references to an object than its refcount)509 > 0.04 % > That's bug 1266882. 15 MOZ_RELEASE_ASSERT(aRefCount !=

Re: pushPrefEnv/popPrefEnv/flushPrefEnv now return Promises

On Thu, May 19, 2016 at 4:09 PM, Matthew N. wrote: > As a reminder, the nice thing about pushPrefEnv is that the pref changes > are reverted at the end of the test file which avoids them leaking into > other tests unintentionally. > Another good thing about it is that

Re: IPCStream landed in mozilla-central

On Thu, May 19, 2016 at 8:04 AM, Ben Kelly wrote: > 3) Supports async pipe streams using a new PSendStream actor from > *child-to-parent*. I have plans to add support for parent-to-child, but I > don't have a consumer yet and we need to figure out some issues with >

Re: Updating 32-bit Windows users to 64-bit Windows builds?

On Fri, May 13, 2016 at 1:02 PM, wrote: > Why do you developers keep insisting breathlessly that 64-bit builds are > memory hogs? I'm a power user who has 3 windows and 1,565 tabs open. I have > a 4 GB laptop and a 16 GB desktop replaced a 6 GB desktop. I like to think

Re: Ignoring viewpoints of non-Mozilla-employees can't be the way to go for a OSS project!

Thank you for opening a discussion thread rather than posting more in the bug. On Mon, May 9, 2016 at 11:23 AM, Tobias B. Besemer < tobias.bese...@googlemail.com> wrote: > Hi! > > Ignoring viewpoints of non-Mozilla-employees can't be the way to go for a > OSS Project! > The same mistake made

Re: Triage Plan for Firefox Components

Emma can correct me if I'm wrong, but I think she is using "Firefox" in the non-jargony sense of the entire thing we're shipping in Firefox, including Gecko. We've been using this system for a month or so in DOM. I think it has been going well. Anybody who is interested can ask Andrew Overholt or

Re: Triage Plan for Firefox Components

g actively worked on have a status that is just confusing to bug reporters, which discourages people from filing more bugs. Andrew > > — > - Milan > > > > > On Apr 1, 2016, at 11:16 , Andrew McCreight <amccrei...@mozilla.com> > wrote: > > > > On Thu, M

Re: Triage Plan for Firefox Components

On Thu, Mar 31, 2016 at 4:01 PM, Chris Peterson wrote: > Anthony's Media Playback team has been using a simple and effective triage > system without special tags. All open bugs in the Audio/Video Playback > component are in one of four states at all times: > > * Priority

Re: Intent to enable e10s by default when running tests locally

; refuse to accept --e10s when running mochitest-chrome to help avoid this > confusion? > > >> >> On Thu, Mar 24, 2016 at 3:05 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> >> wrote: >> >>> On 2016-03-24 1:25 PM, Andrew McCreight wrote: >>> > One poten

Re: Intent to enable e10s by default when running tests locally

On Thu, Mar 24, 2016 at 9:15 AM, Andrew Halberstadt < ahalberst...@mozilla.com> wrote: > Bug 1243083 tracks enabling e10s by default when running tests locally. > I intend to do this for as many harnesses as possible unless someone > says otherwise. Great! [some text deleted] One potential

Re: Split Gecko in standalone fuzzing-friendly programs.

On Wed, Mar 9, 2016 at 12:17 PM, Boris Zbarsky wrote: > Just to satisfy my curiosity, what is AFL? > AFL is American Fuzzy Lop, a fuzzer that uses a combination of compiled-in code coverage and genetic algorithms. http://lcamtuf.coredump.cx/afl/ It has found a ton of errors in

Re: Status: ASan builds on Windows

I'd also note that Google at least used to ship a similar kind of thing to their Canary users a few times a week, called SyzygyASAN: http://blog.chromium.org/2013/05/testing-chromium-syzyasan-lightweight.html I haven't found a ton of detail about whether they still do it but that blog post does

Re: git-bz-moz and Bugzilla 2 factor authentication

, Andrew McCreight <amccrei...@mozilla.com> wrote: > I've updated my repository for my git-bz REST API branch: > https://github.com/amccreight/git-bz-moz/tree/RestAPI > > I think everything is fixed now, so please try it out and let me know if > you encounter problems or something

Re: About static analyzers on some various projects

On Thu, Sep 24, 2015 at 4:23 PM, Nicholas Nethercote wrote: > On Thu, Sep 24, 2015 at 2:29 PM, Ehsan Akhgari > wrote: > > On 2015-09-24 1:41 PM, Sylvestre Ledru wrote: > >> > >> * Coverity, a proprietary tool with a great (but slow) web

Re: git-bz-moz and Bugzilla 2 factor authentication

/forum/#!topic/mozilla.dev.version-control/z9z9N7_vWiY Andrew On Tue, Sep 15, 2015 at 2:37 PM, Andrew McCreight <amccrei...@mozilla.com> wrote: > Apparently Bugzilla 2fa breaks the weird cookie authentication method that > git-bz-moz and bzexport use. I think I've read that this is a

Re: git-bz-moz and Bugzilla 2 factor authentication

On Thu, Sep 17, 2015 at 6:50 AM, Ehsan Akhgari wrote: > git bz edit and git bz push don't work, but the rest should, so please file >> issues at https://github.com/mozilla/git-bz-moz or email me if you notice >> them. (Oh, I think setting reviewer flags for Firefox

Re: easily getting allocation stacks for leaking objects

On Thu, Sep 17, 2015 at 5:31 AM, Gerald Squelart wrote: > Good stuff! > > I hope you'll consider tracking AddRef's and Release's as well. > > I recently experimented with that for a troubled RefCounted class [1], and > it was very useful to find which AddRef didn't have its

Re: easily getting allocation stacks for leaking objects

On Thu, Sep 17, 2015 at 7:42 AM, Andrew McCreight <amccrei...@mozilla.com> wrote: > > > On Thu, Sep 17, 2015 at 5:31 AM, Gerald Squelart <squel...@gmail.com> > wrote: > >> Good stuff! >> >> I hope you'll consider tracking AddRef's and Rel

Re: git-bz-moz and Bugzilla 2 factor authentication

Sorry, the command is actually |git bz apply 12345| as you probably figured out. Andrew On Tue, Sep 15, 2015 at 2:40 PM, Andrew McCreight <amccrei...@mozilla.com> wrote: > Oh, and another thing I meant to mention that seems underused: if you are > using git-bz-moz, the |git ap

Re: git-bz-moz and Bugzilla 2 factor authentication

, Sep 15, 2015 at 2:37 PM, Andrew McCreight <amccrei...@mozilla.com> wrote: > Apparently Bugzilla 2fa breaks the weird cookie authentication method that > git-bz-moz and bzexport use. I think I've read that this is a bugzilla bug, > but in the meanwhile I've been working on making

git-bz-moz and Bugzilla 2 factor authentication

Apparently Bugzilla 2fa breaks the weird cookie authentication method that git-bz-moz and bzexport use. I think I've read that this is a bugzilla bug, but in the meanwhile I've been working on making git-bz-moz use the Bugzilla backend of bexport, which is less hacky and supports using API keys

Re: Fingerprinting of battery status?

On Tue, Aug 4, 2015 at 9:33 AM, Jonas Sicking jo...@sicking.cc wrote: Fingerprinting doesn't seem useful if the fingerprint changes every few minutes as the battery level changes. I do agree that there are concerns that if the user has private-browsing pages and non-private-browsing pages

Re: Linux builds now default to building with Gtk+3

Just so people know, ASan builds with GTK3 crash immediately on startup, so you'll want to keep the gtk2 version as described below. Andrew On Wed, Jul 22, 2015 at 6:38 PM, Mike Hommey m...@glandium.org wrote: Hi, If you've followed the recent discussion in the GTK3 linux builds thread,

Re: New requirement for tier 1 platforms: working assertion stacks

Are we going to have tests for this? Does working include being properly symbolicated? But yes, it is extremely annoying to have failures without stacks. (See bug 1165469, which was only figured out once somebody reproduced the test locally, because there was no stack.) On Fri, Jul 10, 2015 at

Re: Announcing the Content Performance program

On Sun, Jun 28, 2015 at 7:55 PM, Vladan D vdje...@mozilla.com wrote: I asked Avi to work on pausing GC/CC during scrolling in Q3 Q4 2014. I still think it's relevant but process-per-tab will give some of the same benefits Olli is working on creating some kind of unified scheduler for the

Re: Revisiting modelines in source files

On Fri, Jun 19, 2015 at 8:27 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: Sat, Jun 20, 2015 at 2:16 AM, Gregory Szorc g...@mozilla.com wrote: We can mass rewrite the tree. But unless the tools to keep things consistent are easy and painless to use, this will add chaos.

Re: Revisiting modelines in source files

On Wed, Jun 17, 2015 at 3:53 AM, Mike Hommey m...@glandium.org wrote: What we currently have in the tree is essentially modelines for vim and emacs. But: - most vim installations have modelines disabled by default because of the security implications: https://lwn.net/Articles/20249/. -

Re: The War on Warnings

On Thu, Jun 4, 2015 at 2:49 AM, Jonas Sicking jo...@sicking.cc wrote: FWIW, I suspect it'll be hard to put a dent in the number of warnings that we emit unless we either change all instances of NS_ENSURE_SUCCESS(rv, rv) to use some other macro which doesn't warn, or unless we change

reminder: C++ mode lines

I just landed a 1.2MB patch to fix C++ mode lines in dom/ As a reminder, the mode lines that should be used (in C++ files that are properly 2-space indented) are: /* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */ /* vim: set ts=8 sts=2 et sw=2 tw=80: */ See more

Re: changing the default platform and operating-system on bugzilla.mozilla.org to all / all

On Tue, Apr 14, 2015 at 8:40 AM, Dave Townsend dtowns...@mozilla.com wrote: Are the platform fields actually useful? Most bugs apply to all platforms and in the cases that don't it is normally clear from the bug conversation that it is platform specific. It seems like we rarely go an update

Re: Proposal to ban the usage of refcounted objects inside C++ lambdas in Gecko

On Fri, Apr 10, 2015 at 10:37 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-04-10 12:33 PM, Andrew McCreight wrote: On Fri, Apr 10, 2015 at 8:46 AM, Ehsan Akhgari ehsan.akhg...@gmail.com mailto:ehsan.akhg...@gmail.com wrote: I would like to propose that we should ban

Re: Help needed: define Bugzilla components in moz.build files

I hacked up a crude script to collate the results from Gregory's spreadsheet that collates the results across a subdirectory into sort of useful results: https://github.com/amccreight/gecko-components From the spreadsheet, do download as and then comma separate values to get the input format.

Re: Help needed: define Bugzilla components in moz.build files

Is there any kind of existing code around that would look at the bugs for the commits for the files in a directory and create some kind of count of the components they were filed in? dom/ has something like 90 subdirectories, and it would be nice to be able to quickly get some kind of census like

Re: gecko-dev and Git replication will be broken for a little while

On Fri, Jan 30, 2015 at 2:08 AM, Tim Guan-tin Chien timdr...@mozilla.com wrote: Any support for Level 1 people for creating a patch-to-commit for attaching on Bugzilla? I tried :jlebar's moz-git-tools once but the exported patch was broken for hg. The easiest way to attach a git patch to

Re: e10s is now enabled by default for Nightly!

- Original Message - Thinking ahead: e10s is a big enough change that I suspect we'll see high levels of instability when it gets uplifted to Aurora and (especially) Beta. Not sure how to avoid that... but will there be an easy way to disable it? I think there should be a pref in the

Re: Git - Hg workflows?

Generally speaking, I use git for everything except pushing to inbound and try, and I use moz-git-tools to intermediate my interaction with hg. a) Landing code to inbound, fx-team, aurora, etc For this, I keep around hg repos for the repos I care about, which is m-c and inbound right now,

Re: PSA: ./mach build subdirectory doesn't work reliably any longer

- Original Message - FWIW, I've often made changes like this when touching files like nsCOMPtr.h or nsINode.h -- or switching nsresult from a typedef to an enum class! -- and I find just doing ./mach build binaries works fine. It reports errors randomly from all over the tree, but that

  1   2   >