Mozilla Nederland LogoDe Nederlandse
Mozilla gemeenschap

Abonneren op feed Mozilla planet
Planet Mozilla -
Bijgewerkt: 8 uur 28 min geleden

Daniel Stenberg: Coverity scan defect density: 0.00

do, 09/10/2014 - 09:14

A couple of days ago I decided to stop slacking and grab this long dangling item in my TODO list: run the coverity scan on a recent curl build again.

Among the static analyzers, coverity does in fact stand out as the very best one I can use. We run clang-analyzer against curl every night and it hasn’t report any problems at all in a while. This time I got almost 50 new issues reported by Coverity.

To put it shortly, a little less than half of them were issues done on purpose: for example we got several reports on ignored return codes we really don’t care about and there were several reports on dead code for code that are conditionally built on other platforms than the one I used to do this with.

But there were a whole range of legitimate issues. Nothing really major popped up but a range of tiny flaws that were good to polish away and smooth out. Clearly this is an exercise worth repeating every now and then.

End result

21 new curl commits that mention Coverity. Coverity now says “defect density: 0.00” for curl and libcurl since it doesn’t report any more flaws. (That’s the number of flaws found per thousand lines of source code.)

Want to see?

I can’t seem to make all the issues publicly accessible, but if you do want to check them out in person just click over to the curl project page at coverity and “request more access” and I’ll grant you view access, no questions asked.

Categorieën: Mozilla-nl planet

Eitan Isaacson

do, 09/10/2014 - 01:13

An understated feature in desktop Firefox is the option to suppress the text and background colors that content authors choose for us, and instead go with the plain old black on white with a smattering of blue and purple links. In other words, 1994.

Why is this feature great? Because it hands control back to the user and allows people with visual impairments to tweak things just enough to make the web readable.

Somebody once asked on the #accessibility IRC channel why they can’t turn off content colors in Firefox for Android. So it seemed like a good idea to re-introduce that option in the form of an extension. There are a few color related addons in AMO, but I just submitted another one, and you could get it here. This is what the toggle option looks like:

Remove colors option in tools menu

Remove colors option in tools menu

Since the color attribute was introduced, the web has evolved a lot. We really can’t go back to the, naive, monochrome days of the 90s. Many sites use background images and colors in novel ways, and use backgrounds to portray important information. Sometimes disabling page colors will really break things. So once you remove colors from AMO, you get:

AMO with colors removed

Okayish, eh?

As you can see, it isn’t perfect, but it does make the text more readable to some. Having a menu item that doesn’t take too much digging to find will hopfully help folks go back and forth between the two modes and gt the best out of both worlds.

Categorieën: Mozilla-nl planet

Peter Bengtsson: Premailer on Python 3

wo, 08/10/2014 - 23:00

Premailer is probably my most successful open source project in recent years. I base that on the fact that 25 different people have committed to it.

Today I merged a monster PR by Michael Jason Smith of

What it does is basically that it makes premailer work in Python 3, PyPy and Python 2.6. Check out the tox.ini file. Test coverage is still 100%.

If you look at the patch the core of the change is actually surprisingly little. The majority of the "secret sauce" is basically a bunch of import statements which are split by if sys.version_info >= (3, ): and some various minor changes around encoding UTF-8. The rest of the changes are basically test sit-ups.

A really interesting thing that hit us was that the code had assumptions about the order of things. Basically the tests assumed the the order of certain things in the resulting output was predictable even though it was done using a dict. dicts are famously unreliable in terms of the order you get things out and it's meant to be like that and it's a design choice. The reason it worked till now is not only luck but quite amazing.

Anyway, check it out. Now that we have a tox.ini file it should become much easier to run tests which I hope means patches will be better checked as they come in.

Categorieën: Mozilla-nl planet

Mozilla Open Policy & Advocacy Blog: Launching the Ford-Mozilla Open Web Fellows Program, a Global Initiative to Recruit the Heroes of the Open Internet

wo, 08/10/2014 - 19:21

{Re-posting from the Mozilla Blog on Sep 30, 2014}

By Mark Surman, Executive Director, Mozilla Foundation; and Darren Walker, President, Ford Foundation

We are at a critical point in the evolution of the Internet. Despite its emergence as an integral part of modern life, the Internet remains a contested space. Far too often, we see its core ethos – a medium where anyone can make anything and share it with anyone – undermined by forces that wish to make it less free and open. In a world in which the future health of the Internet is vital to democratic discourse and a free flow of ideas, we need a band of dedicated Mozilla Advocacyindividuals standing ready to protect it.

That’s why we are joining together today to launch the Ford-Mozilla Open Web Fellows program, a landmark initiative to create a worldwide community of leaders who will advance and protect the free and open Web.

Working in the Open on Core Issues with the World’s Most Innovative Organizations

Ford-Mozilla Fellows will be immersed in projects that create a better understanding of Internet policy issues among civil society, policy makers, and the broader public. Fellows will be technologists, hackers, and makers who work on a range of Internet policy issues, from privacy and security to surveillance and net neutrality. They will create an affirmative agenda and improve coordination across the sector, boosting the overall number of people throughout society (in nonprofit, government, philanthropy, academic and corporate sectors) that protect the Internet. At present, a whole new architecture is emerging at NGOs and in government where a technology lens is vital to achieving results, just as a focus on law and communications were important in building previous capacity. Fellows will be encouraged to work in the open so that they can share their experiences and learnings with others. Around the world, civil society organizations are working under difficult situations to advance social justice and create a thriving digital society where all voices have an opportunity to be heard.

Fellows will serve as technology advisors, mentors and ambassadors to host organizations, helping to better inform the policy discussion. We are thrilled to name the first cohort organizations that will host a Fellow in the first year of the program. They include:

A Call for Fellowship Applicants

Today also marks the official opening of the application window. Beginning immediately, people can apply to be a Ford-Mozilla Open Web Fellow by visiting The application deadline is December 31, 2014.

We are looking for emerging leaders who have a passion for influencing and informing the public policies that impact the Internet. Selected Fellows will have a track record of making and contributing to projects and an interest in working with Mozilla, the Ford Foundation, and our host organizations on specific initiatives to advance and protect the free and open Web.

Protecting the Internet

The Internet has the potential to be the greatest global resource in the history of the world, accessible to and shaped by all people. It has the promise to be the first medium in which anyone can make anything, and share it with anyone. In many ways, it already has helped bend the arc of history towards enlightenment and justice.

But continuing in that direction isn’t guaranteed without help. For all the good that can come from the Internet, in some areas it is already being used to weaken society and concentrate power in the hands of the few, and to shut down democratic discourse. The fight over preserving net neutrality in the U.S.; the debate over governments undermining the Internet to further surveillance efforts; the curtailing of speech and access to the Internet by authoritarian regimes — these are all threats to the Internet and to civil rights.

We need to take up the challenge to prevent this from happening. We must support the heroes – the developers, advocates and people who are fighting to protect and advance the free and open Internet. We must train the next generation of leaders in the promise and pitfalls of technology. We need to build alliances and infrastructure to bridge technology policy and social policy.

The Ford-Mozilla Open Web Fellows program is an effort to find and support the emerging leaders in the fight to protect the free and open Internet. Apply to become a Ford-Mozilla Fellow and tell us how you would stand up to protect and advance the Web to continue the effort to bend the arc toward justice.

Categorieën: Mozilla-nl planet

Jeff Walden: Holt v. Hobbs: Is a prisoner’s 1/2″ beard so dangerous that he can’t have it even if his religion requires it?

wo, 08/10/2014 - 18:17

Now the second, final argument this trip. (There are other arguments this week, some interesting enough to attend. But I ran out of time to prepare for them or attend them.) Holt v. Hobbs is much simpler than Heien v. North Carolina, because one side’s arguments are “almost preposterous”. So this post is (slightly) breezier.

This line was a bit different from the Heien line: more people attending for (this) argument, fewer people present simply for opening day. The line was possibly less talkative (and I still had briefs to read, although I never intended to read all twenty-one [!] of them), but there were still good discussions with local law students, the author of one of the amicus briefs (which I naturally read standing in line), and others. Good fun again.

49 for Holt v. Hobbs Another day, another line Gregory Holt and his would-be beard

Gregory Holt is a Muslim inmate in the Arkansas prison system. (He actually goes by Abdul Maalik Muhammad now; Gregory Holt is his birth [legal?] name. News stories and legal discussion refer to him as Holt, and in some sense I want this in that corpus, so I use Holt here.) Holt interprets Islamic law to require he have a beard.

Allah’s Messenger said, “Cut the moustaches short and leave the beard (as it is).”

The Translation of the Meanings of Sahih Al-Bukhari ¶ 5893 (Muhammad Muhsin Khan trans., Darussalam Pubs. 1997)

A small request. Reasonable? Quoting the ever-colorful Justice Scalia in oral argument, “Religious beliefs aren’t reasonable. I mean, religious beliefs are categorical. You know, it’s God tells you. It’s not a matter of being reasonable.” Reasonable or not, a beard isn’t an obviously dangerous request like, “My religion requires I carry a broadsword.” And as a conciliatory gesture Holt moderated his request to a half-inch beard.

Sunrise over the Court, with a camera crew and reporter in the foreground No matter how many arguments I go to (this makes ten), the sunrise over the Court will never get old Arkansas: no beards

Arkansas doesn’t permit prisoners to grow beards (except to the natural extent between twice-weekly shaves). There’s an exception for prisoners with medical conditions (typically burn victims), shaving only to 1/4″. But no religious exceptions.

Arkansas’s justifications are three. A beard could hide contraband. A bearded prisoner can shave to disguise himself, hindering rapid identification and perhaps aiding an escape (see The Fugitive). And it’s a hassle measuring half-inch beards on everyone.

The law’s requirements

Twenty-odd years ago, Holt would likely have been out of luck. Turner v. Safley permitted regulations “reasonably related to legitimate penological objectives”. And Justice Scalia’s Employment Division v. Smith says that as a constitutional matter, generally-applicable laws may burden religious exercise, with objectors having no recourse. It’d be an uphill slog getting past the no-beard rule.

But in the mid-1990s to 2000, Congress near-unanimously statutorily protected some exercises of religion, even against generally-applicable laws. (Lest it be thought this was protection specifically, or only, of Christian beliefs: the original motivating case was a Native American group that used a hallucinogen for sacramental purposes.) In particular Congress enacted the Religious Land Use and Institutionalized Persons Act (RLUIPA, usually “ruh-loo-pah”), stating:

No government shall impose a substantial burden on the religious exercise of [a prisoner], even if the burden results from a rule of general applicability, unless the government demonstrates that imposition of the burden on that person—

  1. is in furtherance of a compelling governmental interest; and
  2. is the least restrictive means of furthering that compelling governmental interest
42 U.S.C. § 2000cc-1(a)

And “religious exercise” is later defined as:

The term “religious exercise” includes any exercise of religion, whether or not compelled by, or central to, a system of religious belief.

42 U.S.C. § 2000cc-5(7)(A)

Now, prisons may regulate in pursuit of normal prison aims. But regulations can’t “substantial[ly] burden” a prisoner’s “religious exercise”, regardless how important the exercise is(n’t) in the prisoner’s belief system, even if the regulation is general and doesn’t target religion — unless the government demonstrates the regulation satisfies a “compelling interest” that can’t be addressed less restrictively. This phrasing comes from strict scrutiny: the strongest form of review American courts apply to laws. Unlike the Turner/Smith regime, these requirements have teeth.

19 Almost go-time to advance onto the plaza to receive line numbers Evaluating Arkansas’s no-beard rule applied to Holt

As a threshold matter, Holt must wish to engage in “religious exercise” that is “substantial[ly] burden[ed]“. Once Holt claims the belief, courts won’t second-guess it. They will consider whether the belief is sincere: no opportunistic exception requests for unwarranted benefits. But no one contests the sincerity of Holt’s beliefs. If Holt refuses to be shaved, he’ll suffer various disciplinary actions and bad consequences: “loss of privileges, punitive segregation, punitive work assignments, and loss of good-time credits”. Certainly a substantial burden.

Now Arkansas must demonstrate — with evidence, persuasively — both a compelling interest, and least restrictive means. Put another way, does Arkansas’s regulation pass strict scrutiny?

Arkansas’s claimed interests are “prison safety and security”. But a no-beards rule only marginally advances these goals, and “the government does not have a compelling interest in each marginal percentage point by which its goals are advanced.” Arkansas’s interest must be more specific: an interest specifically in no beards.

It’s hard to say Arkansas has a compelling interest when the rules in forty-odd prison systems nationwide, and various penal code recommendations, either impose no restrictions on beards among prisoners, or would allow Holt his 1/2″ beard. Arkansas is an outlier. And Arkansas’s medical exemption undermines the argument that no beards must apply universally (compelling interests often brook no exceptions). Similarly, Arkansas can’t use the least restrictive means when forty jurisdictions use even less restrictive means.

Arkansas might justify their policy through unique local experience. But Arkansas concedes “no example” of anyone hiding contraband in a beard. (With the “caveat” that “Just because we haven’t found the example doesn’t mean they aren’t there.” A strong argument!) Disguise arguments could be addressed by taking multiple pictures (as other systems do). And measuring the few inmates requesting religious exemptions wouldn’t be much harder than measuring medical-exception beards.

Arkansas could “demonstrate” strict scrutiny is satisfied by providing evidence of evaluation and reasoned rejection of other states’ policies. But Arkansas previously admitted it considered no other systems (eliciting an acerbic suggestion to try “the common practice of picking up the phone to call other prisons”).

Arkansas could argue that Arkansas’s system, that houses many prisoners in barracks and not separate cells, justifies no beards. But such systems exist elsewhere, and no beards applies in Arkansas’s non-barracks prisons.

In short, Arkansas has demonstrated neither a compelling interest, nor least restrictive means, and it has done so presenting no evidence. Ouch.

In lower courts

An obvious question: why must Holt fight this in court if he’s so obviously right? Basically, a few lower courts are giving far too much deference (a word found in legislative history but not in the statute) to the mere assertions of prison officials, without requiring them to “demonstrate” much of anything. The magistrate judge described officials’ claim that Holt might hide something in his half-inch beard as “almost preposterous” — just before deferring to those claims. Courts below the Supreme Court similarly gave too much deference to prison officials’ bare assertions unsupported by any data.

At the Supreme Court

One indicator of lopsidedness here is the brief count, and authors, on each side. Holt has seventeen other briefs on his side, representing a wide variety of interests: Jewish, Christian, Islamic, Hindu, Sikh, American Indian and Hawaiian, former prison wardens, former corrections officials, Americans United for Separation of Church and State (whose brief, incidentally, is interesting but quite surpassed by later events), sociologists, and the United States government (and others). The authors include a who’s-who of religious freedom organizations. Arkansas has one brief on its side: from eighteen states, who don’t defend Arkansas’s policy as much as try to preserve deference as an element to consider (presumably so those states’ prison systems can be run with a freer hand).

The Court accepted this case in unusual circumstances. Holt filed a hand-written petition requesting Supreme Court review, through a special system not requiring him to pay filing fees from non-existent income. Such petitions are almost never accepted. (Holt basically won the lottery. That said, when I read his brief after the case was accepted, the form was unusual, but the discussion and presentation seemed orthodox.) It’s pretty clear the Court accepted this case to lopsidedly, probably unanimously, overturn the Eighth Circuit. The Supreme Court doesn’t take cases to correct errors, but that’s what they’ll do here.

The #12 admission card Number 12 today: slipping back slightly, but as far as I’m concerned this means I had perfect timing Oral argument

The argument questions roughly ran in largely three veins: pondering deference, drawing a line, and almost mocking Arkansas’s arguments. Holt’s counsel faced difficult questions, but not skeptical questions.


First, what does deference (if it even matters — the term appears only in legislative history, not in the law as enacted) look like in the context of strict scrutiny? These are somewhat contradictions in terms. Yet the Court somehow must make sense of this.


Second, while beards are easy to decide, other issues (Sikh turbans that actually can conceal things, for example) will require different considerations. How can the Court provide general guidelines to address these situations? The Court doesn’t want to be in the business of reviewing every prison official’s (better-“demonstrated”) decisions. (Scalia bluntly put it this way: “Bear in mind I would not have enacted this statute, but there it is.” Recall he wrote Employment Division v. Smith, shutting off constitutional religious exemptions from generally-applicable laws. Something to remember any time Scalia’s stereotyped as reflexively pro-religion.) But Congress opened up that box, so courts have to live with it.

Almost mocking questions

Arkansas’s position is not easily defended. Not surprisingly, then, questions and comments almost made fun of Arkansas’s position. To the assertion that “Just because we haven’t found the example doesn’t mean they aren’t there”, Justice Breyer replied, “There are a lot of things we’ve never found that might be there and I’ll refrain from mentioning them. You see them on television, a lot of weird programs from time to time.” (Presumably referring to things like Sasquatch, the Loch Ness Monster, Ghost Hunters, and similar.) And later, Justice Alito proposed an alternative means of detecting beard contraband: “Why can’t the prison just…say comb your beard, and if there’s anything in there, if there’s a SIM card in there, or a revolver, or anything else you think ­­can be hidden in a half-inch beard…” (emphases added). Both lines made the audience erupt in laughter.

Post-Holt crowds on the Supreme Court plaza The post-argument crowds, framed by visitor lines Why Arkansas fights

It’s unclear to me why Arkansas is still arguing. They won in lower courts. But once the Court agreed to review the in forma pauperis petition, Arkansas should have folded. The law is too clearly against them, and this Court won’t give them a pass. Arkansans should be outraged that their state is wasting taxpayer money to defend this system. (And on the policy’s merits, outraged at the petty bureaucratic nonsense at best, and bigotry at worst, it represents.)

One plausible, potentially upsetting, explanation is provided by former prison wardens: “Political Considerations May Underlie Prison Officials’ Resistance to Accommodations of Religious Practices.” These wardens had been sued (and lost) in various cases cited in briefing, and they candidly admitted that their positions were partly attributable to “political realities”.


Arkansas will lose. The only remaining question is how. (And as before, if I’ve made any mistakes in this discussion, please point them out.)

Categorieën: Mozilla-nl planet

Doug Belshaw: Playtesting for MozFest

wo, 08/10/2014 - 18:02

Today I was down at Bishop Grosseteste University, giving a guest lecture and facilitating a workshop. The module was on digital literacies as part of a course for Early Years students. These are students who may go on to teacher training. Some of the work relating to my thesis and the work I’ve done with Mozilla is on their reading list.


From my point of view it was a useful opportunity to playtest some sessions I’ve got planned for the Mozilla Festival at the end of the month. I’ve travelled a lot less in the year since I moved to the Webmaker team, and so I welcomed this opportunity to refine some of my thinking. It’s also good to get input from as many places as possible about Web Literacy Map v2.0.

I made the lecture as participatory as the logic of the lecture theatre allowed. You can find my slides here. We had a backchannel in the form of a Google Doc which surfaced some interesting questions. On a meta level my aim was to highlight the importance of attention. I’m coming round to Howard Rheingold’s view that it’s key to everything we do, both online and offline. Interestingly, one of the questions was whether a single Web Literacy Map can be relevant to everyone.

For the workshop, I split the students into two groups and swapped over halfway. After an introduction to both workshops, half stayed with the course leaders, and the other half came with me. Those who came with me read a chapter of my book The Essential Elements of Digital Literacies followed by a discussion. Those who stayed behind completed a Web Literacy Map activity on their iPads.

Three things stand out in particular from the discussion I had with students:

  1. Confidence. One student had the insight about the reason she’s always shied away from using technology. She explained that she wasn’t exposed to it at a young age in the same way others had been. As a result, she’s always felt under-confident around anything digital and never wants to do more than she has to with it.

  2. Filtering. As I point out in my book, I’m against filtered internet connections. This presupposes the ability to have a rational conversation instead of just filtering. In Early Years (ages 3-5) this isn’t necessarily the case.

  3. Unintended consequences. We know that people devise workarounds to problems they have. Students talked about the ways in which school filters had prevented them accessing Facebook. As a result, they resorted to ‘dodgy’ websites that had evaded filters. These often featured inappropriate advertising and malware, but promised access to Facebook. User accounts were often hacked. By filtering, the school had driven students towards those things they were trying to prevent them doing or seeing.

I’m still waiting to see all the results of the Web Literacy Map activity I set, but the couple of examples I saw were promising. Students added, renamed and re-arranged the competencies of the Web Literacy Map v1.1. This led to some curious groupings. I wouldn’t necessarily thought of putting together ‘Credibility’ with ‘Security’ and ‘Privacy’, for example. It was also interesting that it wasn’t immediately obvious to them what ‘Infrastructure’ means.

For MozFest, I’m going to:

  • Refine the Web Literacy Map activity based on the results of the survey we’re launching this week.
  • Think about where skills and competencies related to ‘e-safety’ should sit.
  • Revisit Beetham & Sharpe’s (2009) taxonomy of access, skills, practices, and attributes.

All in all, it was definitely a worthwhile trip down to Lincoln for me. I hope it was for the students and course leaders, too! Many thanks to Ben Samuels for the invitation, and to Chris Bonfield, Mary-Louise Maynes and team for their warm welcome!

Categorieën: Mozilla-nl planet

Jen Fong-Adwent: End of a year, start of a new year

wo, 08/10/2014 - 17:00
A year ago I publicly announced Meatspace as an experiment in realtime chat with animated GIFs
Categorieën: Mozilla-nl planet

Gervase Markham: Rebel Alliance Ideas

wo, 08/10/2014 - 13:34

Chris Beard has been encouraging us to think like the rebels; what can we do that other people won’t do? How can we make an impact?

Here are some of my thoughts:

  • The internet, in global average, is getting less reliable, slower and more laggy. Finish Janus and persuade our mobile partners to deploy it and default to it. Your Firefox OS phone now accesses the net faster than an Android phone.
  • Make Firefox OS connect by default to access points, and encourage Firefox OS users to run them. There’s a virtuous circle here. More net in more places; a global movement of being generous with net access.
  • Finish Daala faster, by finding people other than the core team to do everything except design the codec and write the algorithms (e.g., testing, speed optimizations, fuzzing, writing Windows Media plugins). We need to get the word out that this project is critical.
  • Show the core free software community, who have great influence over tech choices and who should be our natural allies, that we care about them. Be the first organization ever to make a free-from-bottom-to-top mobile phone (running Firefox OS) and give some help to the Replicant team to port to it as well, just to prove we mean it and it’s real.
  • Make it possible to search for specifically open source software in the Marketplace, and show we believe it “promotes the development of the Internet as a public resource” by promoting apps which are open source.
  • Ship Collusion (which has been in the works for years), even if there’s not a perfect mapping between what it shows you and what’s actually bad. Make sites feel they have to justify all their 3rd party links.

What are your ideas?

Categorieën: Mozilla-nl planet

Lucas Rocha: Probing with Gradle

wo, 08/10/2014 - 01:12

Up until now, Probe relied on dynamic view proxies generated at runtime to intercept View calls. Although very convenient, this approach greatly affects the time to inflate your layouts—which limits the number of use cases for the library, especially in more complex apps.

This is all changing now with Probe’s brand new Gradle plugin which seamlessly generates build-time proxies for your app. This means virtually no overhead at runtime!

Using Probe’s Gradle plugin is very simple. First, add the Gradle plugin as a dependency in your build script.

buildscript { ... dependencies { ... classpath 'org.lucasr.probe:gradle-plugin:0.1.3' } }

Then apply the plugin to your app’s build.gradle.

apply plugin: 'org.lucasr.probe'

Probe’s proxy generation is disabled by default and needs to be explicitly enabled on specific build variants (build type + product flavour). For example, this is how you enable Probe proxies in debug builds.

probe { buildVariants { debug { enabled = true } } }

And that’s all! You should now be able to deploy interceptors on any part of your UI. Here’s how you could deploy an OvermeasureInterceptor in an activity.

public final class MainActivity extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { Probe.deploy(this, new OvermeasureInterceptor()); super.onCreate(savedInstanceState); setContentView(; } }

While working on this feature, I have changed DexMaker to be an optional dependency i.e. you have to explicitly add DexMaker as a build dependency in your app in order to use it.

This is my first Gradle plugin. There’s definitely a lot of room for improvement here. These features are available in the 0.1.3 release in Maven Central.

As usual, feedback, bug reports, and fixes are very welcome. Enjoy!

Categorieën: Mozilla-nl planet

Will Kahn-Greene: Input: 2014q3 post-mortem

di, 07/10/2014 - 20:00

This is the 2014q3 Input post-mortem. It was a better quarter than 2014q2--that one kind of sucked. Instead 2014q2 started out well and then got kind of busy and then I was pretty overwhelmed by the end.

Things to know:

  • Input is Mozilla's product feedback site.
  • Fjord is the code that runs Input.
  • I unilaterally decided to extend 2014q3 to October 6th.
  • I am Will Kahn-Greene and I'm the primary developer on Input.
Bug and git stats Bugzilla ======== Bugs created: 58 Bugs fixed: 54 git === Total commits: 168 Will Kahn-Greene : 144 (+195460, -188019, files 658) Ian Kronquist : 12 (+402, -106, files 21) L. Guruprasad : 6 (+16, -36, files 6) Adam Okoye : 4 (+34, -34, files 34) Ruben Vereecken : 2 (+69, -29, files 12) Total lines added: 195981 Total lines deleted: 188224 Total files changed: 731

We added a bunch of code this quarter:

  • October 7th. 2014: 23466 total, 11614 Python

Compare to previous quarters:

  • 2014q1: April 1st, 2014: 15195 total, 6953 Python
  • 2014q2: July 1st, 2014: 20456 total, 9247 Python

Nothing wildly interesting there other than noting that the codebase for Input continues to grow.

Contributor stats

Ian Kronquist was the Input intern for Summer 2014. He contributed several fixes to Input. Yay!

We spent a bunch of time making our docs and Vagrant provisioning script less buggy so as to reduce the problems new contributors have when working on Input. I talked with several people about things they're interested in working on. Plus several people did some really great work on Input.

Generally, I think Input is at a point where it's not too hard to get up and running, we've got several lists of bugs that are good ones to start with and the documentation is good-ish. I think the thing that's hampering us right now is that I'm not spending enough time and energy answering questions, managing the work and keeping things going.

Anyhow, welcome L. Guruprasad, Adam Okoye and Ruben Vereecken! Additionally, many special thanks to L. Guruprasad who fixed a lot of issues with the Vagrant provisioning scripts. That work is long and tedious, but it helps everyone.


Dashboards for everyone: We wrote an API and some compelling examples of dashboards you can build using the API. It's being used in a few places now. We'll grow it going forward as needs arise. I'm pretty psyched about this since it makes it possible for people with needs to help themselves and not have to wait for me to get around to their work. Dashboards for everyone project plan.

Vagrant: We took the work I did last quarter and improved upon it, rewrote the docs and have a decent Vagrant setup now. Reduce contributor pain project plan.

Abuse detection: Ian spent his internship working on an abuse classifier so that we can more proactively detect and prevent abusive feedback from littering Input. We gathered some interesting data and the next step is probably to change the approach we used and apply some more complex ML things to the problem. The key here is that we want to detect abuse with confidence and not accidentally catch swaths of non-abuse. Input feedback has some peculiar properties that make this difficult. Reduce the abuse project plan.

Loop support: Loop is now using Input for user sentiment feedback.

Heartbeat support: User Advocacy is working on a project to give us a better baseline for user sentiment. This project was titled Heartbeat, but I'm not sure whether that'll change or not. Regardless, we added support for the initial prototype. Heartbeat project plan.

Data retention policy: We've been talking about a data retention policy for some time. We decided on one, finalized it and codified it in code.

Shed the last vestiges of Playdoh and funfactory: We shed the last bits of Playdoh and funfactory. Input uses the same protections and security decisions those two projects enforced, but without being tied to some of the infrastructure decisions. This made it easier to switch to peep-based requirements management.

Switched to FactoryBoy and overhauled tests: Tests run pretty fast in Fjord now. We switched to FactoryBoy, so writing model-based tests is a lot easier than the stuff we had before.


Better than 2014q2 and we fixed some more technical debt further making it easier to develop for and maintain Input. Still, there's lots of work to do.

Categorieën: Mozilla-nl planet

Roberto A. Vitillo: Using ML to correlate add-ons to performance bottlenecks

di, 07/10/2014 - 16:50

I started looking into exploiting our Telemetry data to determine which add-ons are causing performance issues with Firefox. So far there are three metrics that I plan to correlate with add-ons:

  • startup time,
  • shutdown time,
  • background hangs.

In this post I am going over my findings for the first scenario, i.e. the relation between startup time and installed add-ons.

In an ideal world, all add-ons would have an uniform way to initialize themselves which could be instrumented. Unfortunately that’s not possible, many add-ons use asynchronous facilities and or rely on observer notifications for initialization. In other words, there is no good way to easily measure the initialization time for all add-ons without possibly touching their codebases individually.

This is the sort of problem that screams for a multi-way ANOVA but, after some thought and data exploration, it turns out that the interaction terms can be dropped between add-ons, i.e. the relation between add-ons and the startup time can be modeled as a pure additive one. Since a multi-way ANOVA is equivalent to a linear regression between a set of predictors and their interactions, the problem can be modeled with a generalized linear model where for each Telemetry submission the add-on map is represented as a boolean vector of dummy variables that can assume a value of 0 or 1 corresponding to “add-on installed” and “add-on not installed”, respectively.

Startup time depends on many other factors that are not taken into account in the model, like current system load and hard drive parameters. This means that it would be very surprising, to say the least, if one could predict the startup time without those variables. That doesn’t mean that we can’t explain part of the variance! In fact, after training the model on the data collected during the past month, it yielded a R^2 score of about 0.15, which in other words means that we can explain about 15% of the variance. Again, as we are not trying to predict the startup time accurately this is not necessarily a bad result. The F ratio, which relates the variance between add-ons to the variance within add-ons, is significant which remarks that having or not certain add-ons installed does influence the startup time.

Many of the p-values of the predictor’s coefficients are highly significant (<< 0.001); it’s just a matter of sorting the significant results by their effect size to determine the add-ons that cause a notable slowdown of Firefox during startup:

Rplot06The horizontal axis measures the startup time overhead with respect to the average startup time of Firefox. For instance, Yandex Elements seems to be slowing down startup by about 8 seconds on average. The error-bars represent the standard errors of the sampling distributions of the coefficients.

Note that the model is based on a very small fraction of our user-base, i.e. the subset that has Telemetry enabled, so there clearly is some implicit bias. The picture might be different for a truly random sample of our users, nevertheless it is an indication of where to start digging deeper.

The next step is to “dashboardify” the whole thing and contact the developers of the various add-ons. We are also considering notifying users, in a yet to be determined way, when the browser detects add-ons that are known to cause performance issues.

References: map-reduce job and model

Categorieën: Mozilla-nl planet

Adam Lofting: Mozilla Contributor Analysis Project (Joint MoCo & MoFo)

di, 07/10/2014 - 16:27

I’m  back at the screen after a week of paternity leave, and I’ll be working part-time for next two weeks while we settle in to the new family routine at home.

In the meantime, I wanted to mention a Mozilla contributor analysis project in case people would like to get involved.

We have a wiki page now, which means it’s a real thing. And here are some words my sleep-deprived brain prepared for you earlier today:

The goal and scope of the work:

Explore existing contribution datasets to look for possible insights and metrics that would be useful to monitor on an ongoing basis, before the co-incident workweek in Portland at the beginning of December.

We will:

  • Stress-test our current capacity to use existing contribution data
  • Look for actionable insights to support Mozilla-wide community building efforts
  • Run ad-hoc analysis before building any ‘tools’
  • If useful, prototype tools that can be re-used for ongoing insights into community health
  • Build processes so that contributors can get involved in this metrics work
  • Document gaps in our existing data / knowledge
  • Document ideas for future analysis and exploration

Find out more about the project here.

I’m very excited that three members of the community have already offered to support the project and we’ve barely even started.

In the end, these numbers we’re looking at are about the community, and for the benefit of the community, so the more community involvement there is in this process, the better.

If you’re interested in data analysis, or know someone who is, send them the link.

This project is one of my priorities over the following 4-8 weeks. On that note, this looks quite appealing right now.

So I’m going make more tea and eat more biscuits.

Categorieën: Mozilla-nl planet

Patrick Cloke: How I Got Involved in Mozilla

di, 07/10/2014 - 15:31

This is discussed very briefly on my about page, but I figured it could use a bit of a longer discussion. I generally consider myself to have joined the Mozilla community in ~2006. I know that I was using Mozilla Firefox, Mozilla Thunderbird, and Mozilla Sunbird way before that (probably since ~2004, which is when I built my own computer). But I was just an enthusiast then, running beta builds, then alpha and eventually nightly builds. (This was way back when we things were more dangerous to run: Minefield and Shredder.)

Anyway, back to 2006…I initially got involved in a more technical fashion by writing extensions (or maybe it was GreaseMonkey scripts). I don’t really have anyway to prove this though — I don’t seem to have any of that code. (This was before widespread distributed version control.) Anyway, let’s just assume this 2006 date is correct.

My first patch was in 2008 to move a function from the Provider for Google Calendar to the calendar core so that I could use it in Thundershows: a calendar provider for TV shows [1] [2]. (As far as I know, I’m one of a handful of people to actually implement a calendar provider.) I found the calendar project much easier to get involved in than other aspects of Mozilla since it was so much smaller. (I also toyed with adding an entire new protocol to Thunderbird, which R Kent James has now done successfully! [3] [4])

I then came across Instantbird in ~2008 (sometime in the Instantbird 0.1 era). I thought this was great — Mozilla was finally making an instant messaging client! Well, I was kind of right…Instantbird is not an official Mozilla project, but it was exactly what I wanted! The guys (mostly Florian Quèze) in the #instantbird IRC channel were awesome: kind, patient, helpful, and welcoming. They were the ones that really introduced me into the Mozilla way of doing things. I fixed my first bug for Instantbird in 2010 and haven’t stopped since! I’ve since added IRC support and am now one of the lead developers. I’ve mentored Google Summer of Code students twice (2013 and 2014), contribute to Thunderbird and am a peer of the chat code shared between Instantbird and Thunderbird. (I do also occassionally contribute to other projects. [5])

[1]This was my first project to really have other users, I had people filing bugs, asking for new features, etc. It was great! I even had someone (years later) tell me in #instantbird that they had loved Thundershows! [2]My second bug dealt with the same set of code and had tests committed (by me) over 5 years after the initial patch. Oops! [3]My work was based off of some experiments Joshua Cranmer did to add support for web forums to Thunderbird. After all this time, I still want that extension. [4]Oh, also rkent did EXACTLY what I wanted years later: which is add Twitter to Thunderbird. [5]But not Firefox. After seven years (and over 1800 commits), I’ve never fixed a bug in Firefox; although I have had code committed to mozilla-central.
Categorieën: Mozilla-nl planet

Ben Hearsum: Redo 1.3 is released – now with more natural syntax!

di, 07/10/2014 - 14:48

We’ve been using the functions packaged in Redo for a few years now at Mozilla. One of the things we’ve been striving for with it is the ability to write the most natural code possible. In it’s simplest form, retry, a callable that may raise, the exceptions to retry on, and the callable to run to cleanup before another attempt – are all passed in as arguments. As a result, we have a number of code blocks like this, which don’t feel very Pythonic:

retry(self.session.request, sleeptime=5, max_sleeptime=15, retry_exceptions=(requests.HTTPError, requests.ConnectionError), attempts=self.retries, kwargs=dict(method=method, url=url, data=data, config=self.config, timeout=self.timeout, auth=self.auth, params=params) )

It’s particularly unfortunate that you’re forced to let retry do your exception handling and cleanup – I find that it makes the code a lot less readable. It’s also not possible to do anything in a finally block, unless you wrap the retry in one.

Recently, Chris AtLee discovered a new method of doing retries that results in much cleaner and more readable code. With it, the above block can be rewritten as:

for attempt in retrier(attempts=self.retries): try: self.session.request(method=method, url=url, data=data, config=self.config, timeout=self.timeout, auth=self.auth, params=params) break except (requests.HTTPError, requests.ConnectionError), e: pass

retrier simply handles the the mechanics of tracking attempts and sleeping, leaving your code to do all of its own exception handling and cleanup – just as if you weren’t retrying at all. It’s important to note that the break at the end of the try block is important, otherwise self.session.request would run even if it succeeded.

I released Redo 1.3 with this new functionality this morning – enjoy!

Categorieën: Mozilla-nl planet

Alex Vincent: Competing with pen & paper

di, 07/10/2014 - 07:37

In tonight’s linear algebra class, I made the mistake of leaving my paper notebook home. Ok, I thought, I’ll just use Amaya and see how that goes.

Not so well, it turns out.

Twenty minutes of lecture equals a frantic “where is that thing?”, and nothing learned…
  • The template for a MathML subscript is in a different panel from the template for a MathML summation (“sigma”), and you have to switch between panels constantly.
  • If you want two subscripts (and in linear algebra, two subscripts for an element is common), you get a modal dialog.  (Really? How many subscripts does an element need?)
  • Where’s the special “M” symbol for matrix spaces? (I’d post it, but WordPress eats everything after that U+1D544 character!)  We can get the real number set with &#x211d;..
  • The UI for Amaya is hard-coded, so I can’t change it at all.
  • Amaya’s copy & paste support is terrible.
  • It takes about 2 seconds to write [Ai]1j with pen & paper. In Amaya that takes somewhere around ten seconds, plus the dialog I mentioned earlier.
  • Oh, and the instructor’s going on, keeping a pace for students using pen & paper… there’s no chance of me keeping up with him.

After twenty minutes of trying to quickly jot down what he’s saying, without comprehension, I end up with some symbolic gobbledygook that’s probably about 80% of a match to what the instructor is actually saying.  But what I was able to write down was complete nonsense.

I ended up switching to scratch paper and pen, where I was not only able to keep up, but ask some insightful questions.

(Incidentally, I glanced at LibreOffice tonight as well.  I saw immediately that I’d have fundamentally the same problems:  unfamiliar UI and lots of context switching.  Too much to really listen to what the instructor’s saying.)

How does a computer compete with pen & paper?

Later tonight, I realized, if it only takes five quick, essentially subconscious penstrokes to draw Ai, and a fair bit of training to teach someone the equivalent keystrokes in an editor… then maybe a keyboard and mouse are the wrong tools to give a student.  Maybe something closer to pen & paper is best for quickly jotting down something, and then translating it to markup later… which sounds like character recognition.

Hmm, isn’t that something digital tablets and styluses are somewhat good at?  Maybe not perfect, but easier for a human to work with than a memorized set of keystrokes.

Now, I am starting to understand why computer manufacturers (and Firefox OS developers) are putting so much effort into supporting touchscreens:  because they’re useful for taking notes, at least.  Once again, I’ve somewhat missed the boat.

How does this impact my editor project?

The good news is this is way too complicated for me to even attempt in my proof-of-concept editor that I’m trying to build.  (The proof of concept is about making each XML language an add-on to the core editor.)

The bad news is if I ever want students to regularly use computers in a mathematics classroom (which is the raison d’être I even started working with computers as a child), I’m going to need to support tablet computers and styluses.  That’s a whole can of worms I’m not even remotely prepared to look at.  This raises the bar extremely high.  I’m writing this blog post mainly for myself as a future reference, but it means I’ve just discovered a Very Hard Problem is really a Much, Much Harder Problem than I ever imagined.

Categorieën: Mozilla-nl planet