I've just made version 2.0.20 of the CCK2 available. It contains the following changes:

• Multiple CCK2s can now coexist
• Rework of how Hidden UI works, including hiding UI on chrome pages (about:addons)
• Can completely disable Firefox Health Report
• Add the ability to disable the extension compatibility check at startup
• Add support for adding security devices
• Add the ability to disable search plugin installs from web pages and the search menu
• Add a tooltip to the menu that shows the ID and version of a config
• Disable the Firefox Refresh button on webpages
• Bug Fix: Hiding help menu items didn't remove them from the help popup in the Firefox menu
• Bug Fix: Autoconfig only, sometimes extensions wouldn't install
• Bug Fix: Sometimes telemetry prefs didn't migrate correctly from old CCK
• Bug Fix: Default browser error on Mac OS X Yosemite
• Bug Fix: CCK2 Wizard didn't work on Firefox menu
• Bug Fix: Adding Extensions with international characters in their install.rdf didn't work

If you find bugs, please report them at cck2.freshdesk.com.

Priority support is given to folks with support subscriptions. If the CCK2 is important to your company, please consider purchasing one.

http://mike.kaply.com/2015/02/13/cck2-2-0-20-available/

This week I’ve been:

Mozilla

• Collaborating with community members to nail down the learning objectives for the next Webmaker curriculum activity around Open Practices.
• Running a Webmaker Club with Chris Wilde. It was an awkward time to run it (after school, last week before half-term) but a few came along. We did the Kraken the Code activity and a bit of remixing with the X-Ray Goggles.
• Building-out more of the Wikipedia page for Web Literacy, which I started last week. We’re co-ordinating efforts in this GitHub issue.
• Writing blog posts:
  • A visual history of the first two years of Mozilla’s Web Literacy Map
  • Help us redefine the skills underpinning three Web Literacy Map competencies!
  • Wednesday Wisdom #25: Distraction
• Drafting a new section of the upcoming Learning Pathways whitepaper. I’ve also been responding to helpful comments by colleagues.
• Creating questionnaires for the Open Practices activity to be filled in before and after the sessions by learners and mentors.
• Re-reading and making notes on the Pathways working doc that Chloe Varelidi, Lucas Blair, and Grainne Hamilton put together last year for the Mozilla Discover project.
• Filing issues, commenting on them, and organising them in various GitHub repositories.
• Sorting out my travel and accommodation for FutureFest.
• Testing Eisenhower, a prototype productivity tool started by William Duyck (aka FuzzyFox) during his gap year on our team at Mozilla, and continued during his final year at university. He’s looking for feedback.
• Creating an epic spreadsheet of all of the skills for the upcoming Web Literacy Map v1.5.
• Hosting this week’s Web Literacy Map community call.
• Meeting with representatives of a couple of organisations around partnerships.

Dynamic Skillset

• Working on pricing for on-demand, one-off, and ongoing consultancy.
• Dealing with enquiries from various people/organisations.

Other

• Joining Ian O’Byrne and Bryan Mathers for a video podcast entitled Digitally Literacy 006 – A Picture of Literacy.
• Suffering from getting out of routine. I stayed up until just after midnight on Monday night getting something (technical) sorted out for a family member. This had a knock-on effect all week.
• Rescoping one of my planned e-books as The Essential Elements of Digital Literacies: worked examples after revisiting some of James Paul Gee‘s work.
• Exercising
  • Swimming (Monday, Thursday)
  • Gym (Wednesday, Friday)
  • Walk (Tuesday)

I’m going to be away on holiday from Monday 16th to Monday 23rd (inclusive) with my family in Dubai. I can’t tell you how much I’m looking forward to that!

Image CC BY-SA Alan Levine

http://dougbelshaw.com/blog/2015/02/13/weeknote-07-2015/

Today I have released a major release of mozci which includes the following:

• trigger_range(buildername, repo_name, start_revision, end_revision, times, dry_run=False)
• It allows you to trigger a buildername between two revisions as many times as you indicate.
• This is handy if you want to backfill jobs
• It fixes a major issue when trying to relate scheduling information with job execution data
• We needed to use UTC instead of localtime
• We needed to use the completion time of a job instead of the claiming time
• Added pushlog support
• Added buildbot job status interpretation 
• Found in mozci.sources.buildapi.query_job_status()

PyPi:       https://pypi.python.org/pypi/mozci
Source:   https://github.com/armenzg/mozilla_ci_tools

---

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

http://feedproxy.google.com/~r/armenzg_mozilla/~3/Wbf-0qWsGIY/mozilla-ci-tools-021-released-trigger.html

Here's January 2015's monthly analysis of the pushes to our Mozilla development trees. You can load the data as an HTML page or as a json file.

Trends
We're back to regular volume after the holidays. Also, it's really cold outside in some parts of the of the Mozilla world.  Maybe committing code > going outside.


Highlights
10798 pushes
348 pushes/day (average)
Highest number of pushes/day: 562 pushes on Jan 28, 2015
18.65 pushes/hour (highest)

General Remarks
Try had around around 42% of all the pushes
The three integration repositories (fx-team, mozilla-inbound and b2g-inbound) account around 24% of all of the pushes

Records
August 2014 was the month with most pushes (13,090  pushes)
August 2014 has the highest pushes/day average with 422 pushes/day
July 2014 has the highest average of "pushes-per-hour" with 23.51 pushes/hour
October 8, 2014 had the highest number of pushes in one day with 715 pushes 

http://relengofthenerds.blogspot.com/2015/02/mozilla-pushes-january-2015.html

This story started in 2011. A group of passionate Mozillians created the Reps program, their goal was to empower Mozilla volunteers all around the world to support the Mozilla mission. They provided visibility to the work of volunteers, created process to have access to resources and a better way to communicate within the community and with staff. It was the Reps themselves, especially the Council and the mentors who shaped this program. Now, counting 457 Reps, the program has evolved to be a powerful platform for community building where leaders from all around the world can emerge.

The Reps program proved to be very successful in building healthy local and regional communities. It also provided a structured connection to Mozilla functional activities when the work is inherently regional, for example with the Firefox OS launches. But as Mozilla grew and became more professional it was harder for volunteers to participate in the global nature of the project: volunteers could run local and regional activities much more easily, but participating in projects aimed at global impact became increasingly difficult.

Now fast Forward to 2015: We have a new participation plan that aims to bring back the balance and revive the participatory nature of Mozilla. Mark Surman’s blog post is a great read: we don’t only want to enable more participation but we want this participation to have value both for Mozilla and for the individual volunteers. And that means that we will empower many more volunteers to take the lead and participate much more deeply in Mozilla to have both local and global impact.

And here is where Reps come in. Our challenge is to make Mozilla much more participatory again, to partner with functional areas and take the lead. To make this successful in the long run we will work on new participation and leadership pathways connecting with functional teams. And we will work on the things that matter the most and make a difference. These pathways will of course provide more opportunities for personal and collective development as well as new leadership opportunities for Mozillians and Reps.

How will this be different from the past? We used to have “Special Interest Groups”, loose groups with an interest in a functional area, but not too many concrete projects or learning opportunities. We want to build on what was working there but shift to “Impact teams”: teams of staff and volunteers who will work hand in hand and where volunteers will be able to get real value out of their participation and will have a clear leadership pathway.

This new approach brings of course a whole new set of challenges: we’ll need to rethink the way we organize the Reps program, the way we empower Reps, mentors and Council and the way we do things in general. Education will be a fundamental part of this. We will need to work all together, Council, Mentors and Reps, to make this happen. And although it will be a lot of hard work I couldn’t be more excited for the changes coming: we’ll be investing so much energy and resources in empowering volunteers and offering new avenues for personal development while having a tangible impact bringing the Mozilla mission forward. I think 2015 will be a great year for Mozilla and the Reps program, join us in shaping this third era of Mozilla and writing the next chapter of the Mozilla Reps history.

https://blog.mozilla.org/mozillareps/2015/02/13/expanding-the-scope-of-the-mozilla-reps-program/

This story started in 2011. A group of passionate Mozillians created the Reps program, their goal was to empower Mozilla volunteers all around the world to support the Mozilla mission. They provided visibility to the work of volunteers, created process to have access to resources and a better way to communicate within the community and with staff. It was the Reps themselves, especially the Council and the mentors who shaped this program. Now, counting 457 Reps, the program has evolved to be a powerful platform for community building where leaders from all around the world can emerge.

The Reps program proved to be very successful in building healthy local and regional communities. It also provided a structured connection to Mozilla functional activities when the work is inherently regional, for example with the Firefox OS launches. But as Mozilla grew and became more professional it was harder for volunteers to participate in the global nature of the project: volunteers could run local and regional activities much more easily, but participating in projects aimed at global impact became increasingly difficult.

Now fast Forward to 2015: We have a new participation plan that aims to bring back the balance and revive the participatory nature of Mozilla. Mark Surman’s blog post is a great read: we don’t only want to enable more participation but we want this participation to have value both for Mozilla and for the individual volunteers. And that means that we will empower many more volunteers to take the lead and participate much more deeply in Mozilla to have both local and global impact.

And here is where Reps come in. Our challenge is to make Mozilla much more participatory again, to partner with functional areas and take the lead. To make this successful in the long run we will work on new participation and leadership pathways connecting with functional teams. And we will work on the things that matter the most and make a difference. These pathways will of course provide more opportunities for personal and collective development as well as new leadership opportunities for Mozillians and Reps.

How will this be different from the past? We used to have “Special Interest Groups”, loose groups with an interest in a functional area, but not too many concrete projects or learning opportunities. We want to build on what was working there but shift to “Impact teams”: teams of staff and volunteers who will work hand in hand and where volunteers will be able to get real value out of their participation and will have a clear leadership pathway.

This new approach brings of course a whole new set of challenges: we’ll need to rethink the way we organize the Reps program, the way we empower Reps, mentors and Council and the way we do things in general. Education will be a fundamental part of this. We will need to work all together, Council, Mentors and Reps, to make this happen. And although it will be a lot of hard work I couldn’t be more excited for the changes coming: we’ll be investing so much energy and resources in empowering volunteers and offering new avenues for personal development while having a tangible impact bringing the Mozilla mission forward. I think 2015 will be a great year for Mozilla and the Reps program, join us in shaping this third era of Mozilla and writing the next chapter of the Mozilla Reps history.

http://ombrosa.co/2015/02/13/expanding-the-scope-of-the-mozilla-reps-program/

Hi sweets,

Today you turn 5, which makes this the tenth one of these letters I’ve written (A letter, 6 months, 1 year old, 18 months, 2 years old, Two and a Half, 3 years old, Three and a Half, Four, Four and a Half). Every time I write a new one, I read all the other ones and then I fall down the rabbit hole of looking at old pictures of you, and I land in a big pile of feels. That happened again this morning, and I’m sitting in the Mozilla office sniffling like a goober.

You’re the coolest little kid, Lil. You’re big into Monopoly Junior right now, and you cackle a little when something good happens, but when you’re winning by too much, you give everyone else some of your money, “so that we all have a nice time.” You’ve got friends on the street and go over to hang out with them, which is totally normal and great, but also a hard thing to get used to. You’re developing all these mannerisms that are so big kid that it hurts, even though it’s awesome. There’s a lot of that in parenthood – heart-swelling-to-painful awesomeness. When you need my help to undo a button at the back of your dress, you gather up all your hair in your hands and tip your neck forward and I’d swear you were 17.

You’re working through having two homes, just like I did when I was your age. Which is expected and normal and still heart-achy. So far you’re just curious and trying to puzzle it out. For our part, as we muddle through it, we talk to other “bonus moms” who have been at it longer than we have, and try to pay it forward by talking to friends who are becoming step parents for the first time, to share what little we’ve learned. Take it from me, kid, there’s no quick road to the other side of this one – you’ll spend a lot of time thinking about it, well into adulthood. But I’ll always be here, if you want to talk about it.

You refuse to go to sleep. You sleep like a cat, you’re out for 9-10 hours a night at least, but getting you to close your eyes is a daily, ridiculous struggle. A few months ago I taught you the word, “stalling”, but naming it hasn’t eliminated it. You want another story. You want to pee. You want to cuddle. Your newest trick is to ask wide open questions about the world. Smart, thoughtful questions and they are my achilles heel, because of course I will talk to you about stars and planets and plants and animals and dinosaurs. Last week’s 9pm gambit was, “Daddy, how does light work?”

I pretend to get annoyed, and tell you to go to sleep, but I’m not really annoyed at all. I love our conversations. They’re the best part of my day. I love watching you experience the world, and watching you grow. It hurts sometimes, but in the best way.

I love you, Lil. Happy birthday.

http://blog.johnath.com/2015/02/13/five/

Last Thursday we had our weekly call about the Reps program, where we talk about what’s going on in the program and what Reps have been doing during the last week.

Summary

• Word of Mouth Marketing Program
• Southeast Asian meeting.
• Paris Reps Leadership meetup.
• Impact teams.
• Education.
• Mozilla Romania & Mozilla Balkans update.

Detailed notes

AirMozilla video

Don’t forget to comment about this call on Discourse and we hope to see you next week!

https://blog.mozilla.org/mozillareps/2015/02/13/reps-weekly-call-february-12th-2015/

A while back I wrote how I sometimes use Valgrind to print a stack trace every time a particular program point is reached. I just learned how to do likewise with GDB. Here’s an example session that illustrates what to do.

(gdb) break je_chunk_alloc_mmap     # set a breakpoint
Breakpoint 1 at 0x1aa32c0
(gdb) commands                      # enter breakpoint command sequence
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
>bt                                 # print stack trace
>c                                  # continue execution
>end                                # end command sequence
(gdb) set pagination off            # don't pause when the screen fills up
(gdb) set logging on                # copy output to a file
Copying output to gdb.txt.

This is better than the Valgrind technique because (a) it doesn’t require modifying the source code, and (b) programs tend to run faster under GDB than they do under Valgrind.

Thanks to Mike Hommey for helping with this.

https://blog.mozilla.org/nnethercote/2015/02/13/using-gdb-to-get-stack-traces-at-particular-program-points/

http://dbaron.org/log/20150213-feedback

I was writing a post about why you must work in the open to get more volunteers and I ended up writing this post about why I don’t work in the open.

The Good

So I think there are some very valid reasons for not working in the open:

• Personal. Not all projects are open source projects, especially personal ones. Where I’m going for Valentine’s Day or how to get my son to do better in school are not “open” projects. They could be, but they’re not.
• Not mine to share. There’s a lot of things I think should be shared with the world but they aren’t my stories or plans to share. I’d be violating someone else’s sense of privacy in order to share. I think your 2015 project goals are good enough to share with the world – and more people would join if you did – but you may not feel the same way.
• It’s not an open source project. Lots of projects in this world are not run in an open source way. If you are not looking to build a community, and you are not an open source software project nor a nonprofit nor a public entity, I think this is a totally valid way of working.

The Bad

And then I think there are some reasonable reasons (maybe right, maybe not) for not working in the open:

• Partners. At Mozilla, we often cite partners as a reason why we can’t share plans. I think partners just make it much harder. You either have to figure out how to do it in a way that doesn’t expose their identity or you have to convince them. It’s a valid reason but one that could often be different if you worked on it.
• Buy in. It takes time to figure out how to accurately describe an idea, what you mean and why you want to do it. It helps to get feedback from a few people to help make your initial communication clearer. Simon Phipps opines that if there’s a strong majority in a project, discussing an idea first with a few is a way to get something enough backing to push it forward.
• Getting clear. Sometimes you have to float your idea by a few people to get clear about what you really need to do.
• Not enough  time. Some times we don’t do things in the open when we are out of time. For me, this is especially true when it’s not my project but I really think it could benefit from being open. Like a fundraising project at school. If they created a web page and a mini social media campaign, I’m sure they could be tons more successful. But I don’t always have time to help them figure out how to do this. I think this crosses into “The Ugly” when it is your own project. If it should be in the open, and you want a community to help you out, you have to take the time to grow that project. You’ll recoup your time later.

The Ugly

And then I think there are some not so great reasons for not working in the open:

• Not enough  time. I hear this one a lot. We have to get this out next week or next month. There’s not enough time to articulate it clearly enough to open it, to answer everyone’s questions, to mentor, to accept contributions. This might be ok once in a while but I hear it more and more.
• Not distracting people. I feel this one a lot at Mozilla. Mozilla is a huge community now and we all want to keep up with everything. So every time you float a new idea and a million people weigh in, you feel like you are distracting them from everything else. But I think it’s ultimately their decision whether or not to be distracted.
• Not announcing other people’s plans. I put this in the ugly category because I often feel like my hands are tied in sharing until someone else shares their plans. Especially in technical documentation and evangelism, you are supposed to talk about other people’s work but not until they are ready. And you want to plan projects, outreach or events around their news.
• Not committing to something. Especially for your organization. It takes great skill to “float an idea” in the open. To not commit to it while still considering it. To be able to say, we are considering this and then to be clear if you decide not to go forward. The fear is that it makes you look indecisive. It makes people waste their time. It causes inappropriate press cycles. But if you can’t float ideas in the open, if you only talk about things that are already committed to and planned, you miss a huge opportunity to include people in the creative cycles and to make them feel like it really is their project.
• Not having company commitment. Especially when you are getting paid to work on an open source software project, it’s hard to float random ideas before you have your company’s or your boss’ commitment.
• Not making inappropriate news waves. There’s a lot of stuff I’d really love to talk about in the open and I don’t because I don’t want to read about them in the press. Right after I started at Mozilla we had a couple of these incidents. People’s personal blog posts turning into major news cycles. It wasn’t fun for them. I don’t want it to happen to me. (Unless it’s something I want in the news!)

When you choose not to work in the open, what are your reasons? Are they Good, Bad or Ugly? What are your suggestions for how those of us who want to work more in the open can all do better?

http://feedproxy.google.com/~r/StormysCornerMozilla/~3/c2EfoGUjNvQ/the-good-the-bad-and-the-ugly-of-why-i-dont-always-work-in-the-open.html

Weekly Mozilla Reps call

https://air.mozilla.org/reps-weekly-20150212/

Call me crazy, but I’m at it again. First a little resume from our previous episodes in this exciting saga:

Chapter 1: I closed the 10+ year old bug that made the Firefox download manager not detect failed downloads, simply because Firefox didn’t care if the HTTP 1.1 Content-Length was larger than what was actually saved – after the connection potentially was cut off for example. There were additional details, but that was the bigger part.

Chapter 2: After having been included all the way to public release, we got a whole slew of bug reports immediately when Firefox 33 shipped and we had to revert parts of the fix I did.

Chapter 3.

Will it land before it turns 11 years old? The bug was originally submitted 2004-03-16.

Since chapter two of this drama brought back the original bugs again we still have to do something about them. I fully understand if not that many readers of this can even keep up of all this back and forth and juggling of HTTP protocol details, but this time we’re putting back the stricter frame checks with a few extra conditions to allow a few violations to remain but detect and react on others!

Here’s how I addressed this issue. I wanted to make the checks stricter but still allow some common protocol violations.

In particular I needed to allow two particular flaws that have proven to be somewhat common in the wild and were the reasons for the previous fix being backed out again:

A – HTTP chunk-encoded responses that lack the final 0-sized chunk.

B – HTTP gzipped responses where the Content-Length is not the same as the actual contents.

So, in order to allow A + B and yet be able to detect prematurely cut off transfers I decided to:

1. Detect incomplete chunks then the transfer has ended. So, if a chunk-encoded transfer ends on exactly a chunk boundary we consider that fine. Good: This will allow case (A) to be considered fine. Bad: It will make us not detect a certain amount of cut-offs.
2. When receiving a gzipped response, we consider a gzip stream that doesn’t end fine according to the gzip decompressing state machine to be a partial transfer. IOW: if a gzipped transfer ends fine according to the decompressor, we do not check for size misalignment. This allows case (B) as long as the content could be decoded.
3. When receiving HTTP that isn’t content-encoded/compressed (like in case 2) and not chunked (like in case 1), perform the size comparison between Content-Length: and the actual size received and consider a mismatch to mean a NS_ERROR_NET_PARTIAL_TRANSFER error.

Prefs

When my first fix was backed out, it was actually not removed but was just put behind a config string (pref as we call it) named “network.http.enforce-framing.http1“. If you set that to true, Firefox will behave as it did with my original fix applied. It makes the HTTP1.1 framing fairly strict and standard compliant. In order to not mess with that setting that now has been around for a while (and I’ve also had it set to true for a while in my browser and I have not seen any problems with doing it this way), I decided to introduce my new changes pref’ed behind a separate variable.

“network.http.enforce-framing.soft” is the new pref that is set to true by default with my patch. It will make Firefox do the detections outlined in 1 – 3 and setting it to false will disable those checks again.

Now I only hope there won’t ever be any chapter 4 in this story… If things go well, this will appear in Firefox 38.

Chromium

But how do they solve these problems in the Chromium project? They have slightly different heuristics (with the small disclaimer that I haven’t read their code for this in a while so details may have changed). First of all, they do not allow a missing final 0-chunk. Then, they basically allow any sort of misaligned size when the content is gzipped.

http://daniel.haxx.se/blog/2015/02/12/tightening-firefoxs-http-framing-again/

I’m posting the steps I took to create the FirefoxOS dev environment for the Flame device. We use the Flame as our reference device on the Platform Rendering team. I had to re-do this recently on a new computer and I figure this might help others in the same boat. These steps assume you can already build the desktop version of Firefox on your computer.

1. Get ADB
2. Turn on ADB debugging on your device.
3. Download the latest base image (v18D_nightly.zip at the time of this writing.)
4. Unzip the base image archive and run the flash.sh script to update your phone to the latest base image. You’ll need to re-enable ADB debugging after this step.
5. Clone the B2G repository and follow the prerequisite steps for local builds.
   Note: the device we target for the config.sh step is flame-kk (not the older flame device.)
6. Get a coffee and wait for the long source download.
7. Run ./build.sh in the B2G source directory to build.
8. Run ./flash.sh in the B2G source directory to put your new build on to your phone.

http://junglecode.net/firefoxos-dev-quick-start/

I’ve had this post swirling around in my head for a while.  A post on my experiences and preference to lead, participate and negotiate conflict in online communities through kindness.

I might  be writing it as a proposal to others, but also it might be a bit of therapy to review this strategy for myself.

Kindness is the tone you set for yourself

When we consider approaching community conversation with kindness and patience; when we squash that immediate need to react we’re setting a tone of kindness .  It is not, as you might assume, solely for the benefit of others.  I believe much more that kindness is a selfish act,  siding with optimism for the community conversations  guides  outcomes far more meaningful than ‘being right’, or getting the most of what you came for.

Regret is harder to overcome, than leading with kindness will ever be.

Measure Twice, Respond Once

If  a conversation topic or introduction starts off in a way that makes you feel defensive.  Stop.  Read it again.  I know it’s hard, but looking past negative words  – to find the truth in a conversation often makes the difference to everyone involved.  Negativity could be as a result of events of the past, misconception and defensiveness.  It might have nothing to do with you at all, and so digging out the root of the conversation and focusing there, can bring sunshine.  I actually skim negative, and unprovoked comments altogether as a kindness to myself.

Every personality exists in community.  With the invitation of ‘open’  –  the simple act of getting shit done can come laced with barbs of protest, and  challenge.  Even when it’s clear that intentions may not be positive, reaching out with a benefit of the doubt can often turn that around.  I have found new allies this way.

Sometimes people just want to know they’re being heard.

Have a Point

If you are reaching out with a concern, complaint or comment  have a clear point.  A discombobulation of emotion mixed in with accusations and assumptions  will get you nowhere near the solution you’re seeking.  Instead of writing long posts/emails/forums with an assumption you’ll get push-back – dare to assume  people will respond with a desire to help!  Narrow your point into an ‘ask’, that welcomes feedback.

Make sure your point isn’t simply to ‘be proven correct’, or to expose what little someone else knows. There are better things to do in the world.

You could be wrong.  Learning is often a humbling experience (if you’ve ever watched a babys first steps), but learning and growing is a gift.  Don’t close the door to being wrong.

Check your Ego

If being right is a goal for your communication – then that’s a debate, and those can be good fun when both people sign-up.

However spending time providing the community with your credentials as a way to influence opinion, does far less than the act of listening, acknowledging the points of others, and specifically calling out feedback that helps you. Learn about others, there are some very brilliant, experienced yet quiet people lurking in our community – you may not realize the depth of someone else’s knowledge without making room for it.

Consider entering discussions with the goal of having your mind changed!

Ending with Kindness

 

 

http://tiptoes.ca/kindness-in-community/

One of the things I’ve been doing these past few months is running Mochitests on Valgrind on a semi-regular basis — roughly weekly — and trying to drive the resultant error count down to zero. I did this some years back, in the approach to Firefox 4, but the situation has drifted since then.

Anyway, I am pleased to say that Mochitests on 64-bit Linux is once again Valgrind/Memcheck clean. That is, free from invalid memory accesses and uses of undefined values. This involved fixing around 25 bugs, mostly to do with uninitialised values. They fall into three categories:

• Forgetting to initialise a field in a constructor. Pretty simple once you figure out which constructor is involved.

• Forgetting to write values to an out-parameter — an ever-popular failure mode. Typically a called function intends to return a value through a pointer to a caller-supplied buffer, and also returns an success/failure indication. But there’s some path through it which returns “success” without writing to the buffer.

• More complex sequencing errors, in which an object is allocated, and only partly initialised, in the expectation that other fields will be set up later, but before use, using an Init() method or some such. But the sequencing doesn’t quite work out, and Init() is called only after those fields are read.

The majority of the bugs are not to do with memory accesses in invalid places. I suspect most invalid accesses have already been picked up by our ASan runs.

The severity of the bugs varies. Any bug picked up by Valgrind might have serious consequences, as a result of making the computation depend on unknown values, either undefined ones, or ones taken from unknown places in memory. Some of the bugs seem fairly harmless.  Others looked like they could cause user visible weirdness, for example decisions along the lines of “is the download rate sufficient to support this video resolution, or should we request a lower resolution?” At least one would have been an obvious crash had the uninitialised value pulled out of memory been suitably unfavourable.

So, is it truly clean? Well, not entirely, for various reasons.  For one thing this is dynamic testing, of course, so it only covers scenarios that the test set exercises.

Secondly, the high level of C++ churn in the tree means there’s a constant, if low, influx of new memory errors, so we can only really get to “approaching zero” detectable errors. Doing this on the Aurora or Beta branches might help, but that doesn’t fit with our “mozilla-central first” development model.

Thirdly, this tests core Gecko code and the Linux specifics. It unfortunately doesn’t cover Mac specifics, Windows specifics or FirefoxOS specifics, although the latter is in progress.

One noticeable thing, if you play the run-Valgrind-and-fix-what-you-see game long enough, is that we can drive the observable memory errors in our code down to zero. That is, in anything that we build from source. But we can’t do anything about the various proprietary binary blobs we have to live with. Eventually we arrive at a situation where — at least so it seems — our code is cleaner than some of the other libraries it relies on.

Valgrinding Mochitests is quicker than it used to be. Back in the Firefox 4 days, it took about 14 CPU hours. Now it completes in about 5 hours. This is due to a combination of faster hardware (Intel Haswell), Valgrind generally being faster and scaling better for large processes, and having advanced to the point where it’s feasible to test “gcc -O2'' compiled code with a near-zero false error rate. It may also be that Gecko is simply faster, giving less work for Valgrind to do.

I’m beginning to run Valgrind tests of FirefoxOS startup on phones, in particular on the Flame. Given how resource-hungry Valgrind is, doing so is something of a challenge, requiring dodging timeouts, memory limits, sandboxes and proprietary driver blobs. But it is just about doable, and various bits of FirefoxOS-specific badness are in the process of getting cleaned up.

From a personal standpoint, this is very satisfying. Memcheck was originally conceived as a tool for finding bugs you didn’t yet know you had, rather than as a post-crash diagnostic tool. So it’s great to see it being used to remove a whole class of bugs from our tree.

We also have toolery (TSan, Helgrind) to find low level data races.  Nathan Froyd and Christian Holler have made good progress in using them to detect races and in getting folks to fix those races, as tracked by metabug 929478. I look forward to the day when we can say that Mochitests is also free from detectable data races.

https://blog.mozilla.org/jseward/2015/02/11/mochitests-are-now-valgrind-clean/

Since I joined Mozilla I’ve been looking for ways to increase the opportunities for new people to get started working on the Firefox user interface.

I’m now ready to try something that I’ve been thinking about doing for a little while.

I’m looking for four people that I will mentor and help along as they fix bugs across the Firefox user interface. The first bug will be an easy one to get started with the codebase and comfortable building the browser, and they will increase in difficulty from there. At the end of the program you will be able to say that you’ve made some large contributions to Firefox. We will use JavaScript, CSS, and XUL (similar to HTML).

The project will be about six weeks long, starting February 16th and ending March 31st. During this time, I will be available to meet through video chat, IRC (text-based chat), and email.

If you are interested in working with me and have at least two to three years of classroom experience in Computer Science (or equivalent open source experience), please send an email to jaws+goodfirstmentee@mozilla.com along with:

• Your name
• A short 1-2 sentences about any open source experience you have
• And a rough estimate of how many hours per week you think you could dedicate towards the program.

I’ll let you know if you’ve been accepted by February 13th. Thanks!

Tagged: firefox, mozilla, planet-mozilla

https://msujaws.wordpress.com/2015/02/11/firefox-ui-mentorship-program/

Weekly coordination meeting for Firefox Desktop & Android product planning between Marketing/PR, Engineering, Release Scheduling, and Support.

https://air.mozilla.org/product-coordination-meeting-20150211/

Watch mconley livehack on Firefox Desktop bugs!

https://air.mozilla.org/the-joy-of-coding-mconley-livehacks-on-firefox-episode-1/

I recently upgraded to Plasma 5.2 based upon this glowing review. While the transition was smooth for the most part (apart from minor KWin issues), Vidyo started to segfault. The Plasma system tray no longer supports older system tray protocols. I'm not aware of the details, but VidyoDesktop would complain about not being able to set a system tray icon and segfault. The fix is to install the sni-qt package from the extra repository.

http://blog.nikhilism.com/2015/02/getting-vidyo-running-on-archlinux.html