Mozilla Nederland LogoDe Nederlandse

Alex Gibson: How to help find a regression range in Firefox Nightly

Mozilla planet - do, 15/01/2015 - 01:00

I recently spotted a visual glitch in a CSS animation that was only happening in Firefox Nightly. I was pretty confident the animation played fine just a couple of weeks ago, so after some debugging and ruling out any obvious wrong-doing in the code, I was pretty confident that a recent change in Firefox must have somehow caused a regression. Not knowing quite what else to do, I decided to file a bug to see if anyone else could figure out what was going wrong.

After some initial discussion it turned out the animation was only broken in Firefox on OSX, so definitely a bug! It could have been caused by any number of code changes in the previous few weeks and could not be reproduced on other platforms. So how could I go about helping to find the cause of the regression?

It was then someone pointed me to a tool I hadn't heard of before, called mozregression. It's an interactive regression range finder for Mozilla nightly and inbound builds. Once installed, all you need to do is pass in a last known "good date" together with a known "bad date" and a URL to test. The tool then automates downloading and running different nightly builds against the affected URL.

mozregression --good=2014-10-01 --bad=2014-10-02 -a ""

After each run, mozregression asks you if the build is "good" or "bad" and then continues to narrow down the regression range until it finds when the bug was introduced. The process takes a while to run, but in the end it then spits out a pushlog like this.

This helped to narrow down the cause of the regression considerably, and together with a reduced test case we we're then able to work out which commit was the cause.

The resulting patch also turned out to fix another bug that was effecting Leaflet.js maps in Firefox. Result!

Categorieën: Mozilla-nl planet

Mozilla veröffentlicht Firefox 35 -

Nieuws verzameld via Google - wo, 14/01/2015 - 22:44


Mozilla veröffentlicht Firefox 35
Ebenfalls mit Firefox 34 eingeführt hat Mozilla eine neue Suchleiste plus neue Sucheinstellungen. Zumindest für Nutzer der US-Version von Firefox. Nutzer der deutschen Ausgabe müssen sich noch bis Firefox 36 gedulden oder können die neue Suche ...
Der neue Mozilla-Browser Firefox 35 im TestDIE WELT
Firefox 35 zum Download: Neuer Mozilla-Browser will chattenT-Online
Firefox 35 zum Download - neue Optik, neue FunktionenSTERN
Online PC -ComputerBase -FOCUS Online
alle 44 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Niko Matsakis: Little Orphan Impls

Mozilla planet - wo, 14/01/2015 - 20:03

We’ve recently been doing a lot of work on Rust’s orphan rules, which are an important part of our system for guaranteeing trait coherence. The idea of trait coherence is that, given a trait and some set of types for its type parameters, there should be exactly one impl that applies. So if we think of the trait Show, we want to guarantee that if we have a trait reference like MyType : Show, we can uniquely identify a particular impl. (The alternative to coherence is to have some way for users to identify which impls are in scope at any time. It has its own complications; if you’re curious for more background on why we use coherence, you might find this rust-dev thread from a while back to be interesting reading.)

The role of the orphan rules in particular is basically to prevent you from implementing external traits for external types. So continuing our simple example of Show, if you are defining your own library, you could not implement Show for Vec<T>, because both Show and Vec are defined in the standard library. But you can implement Show for MyType, because you defined MyType. However, if you define your own trait MyTrait, then you can implement MyTrait for any type you like, including external types like Vec<T>. To this end, the orphan rule intuitively says “either the trait must be local or the self-type must be local”.

More precisely, the orphan rules are targeting the case of two “cousin” crates. By cousins I mean that the crates share a common ancestor (i.e., they link to a common library crate). This would be libstd, if nothing else. That ancestor defines some trait. Both of the crates are implementing this common trait using their own local types (and possibly types from ancestor crates, which may or may not be in common). But neither crate is an ancestor of the other: if they were, the problem is much easier, because the descendant crate can see the impls from the ancestor crate.

When we extended the trait system to support multidispatch, I confess that I originally didn’t give the orphan rules much thought. It seemed like it would be straightforward to adapt them. Boy was I wrong! (And, I think, our original rules were kind of unsound to begin with.)

The purpose of this post is to lay out the current state of my thinking on these rules. It sketches out a number of variations and possible rules and tries to elaborate on the limitations of each one. It is intended to serve as the seed for a discussion in the Rust discusstion forums.

The first, totally wrong, attempt

The first attempt at the orphan rules was just to say that an impl is legal if a local type appears somewhere. So, for example, suppose that I define a type MyBigInt and I want to make it addable to integers:

1 2 impl Add<i32> for MyBigInt { ... } impl Add<MyBigInt> for i32 { ... }

Under these rules, these two impls are perfectly legal, because MyBigInt is local to the current crate. However, the rules also permit an impl like this one:

1 impl<T> Add<T> for MyBigInt { ... }

Now the problems arise because those same rules also permit an impl like this one (in another crate):

1 impl<T> Add<YourBigInt> for T { ... }

Now we have a problem because both impls are applicable to Add<YourBigInt> for MyBigInt.

In fact, we don’t need multidispatch to have this problem. The same situation can arise with Show and tuples:

1 2 impl<T> Show for (T, MyBigInt) { ... } // Crate A impl<T> Show for (YourBigInt, T) { ... } // Crate B

(In fact, multidispatch is really nothing than a compiler-supported version of implementing a trait for a tuple.)

The root of the problem here lies in our definition of “local”, which completely ignored type parameters. Because type parameters can be instantiated to arbitrary types, they are obviously special, and must be considered carefully.

The ordered rule

This problem was first brought to our attention by arielb1, who filed Issue 19470. To resolve it, he proposed a rule that I will call the ordered rule. The ordered rule goes like this:

  1. Write out all the type parameters to the trait, starting with Self.
  2. The name of some local struct or enum must appear on that line before the first type parameter.
    • More formally: When visiting the types in pre-order, a local type must be visited before any type parameter.

In terms of the examples I gave above, this rule permits the following impls:

1 2 3 impl Add<i32> for MyBigInt { ... } impl Add<MyBigInt> for i32 { ... } impl<T> Add<T> for MyBigInt { ... }

However, it avoids the quandry we saw before because it rejects this impl:

1 impl<T> Add<YourBigInt> for T { ... }

This is because, if we wrote out the type parameters in a list, we would get:

1 T, YourBigInt

and, as you can see, T comes first.

This rule is actually pretty good. It meets most of the requirements I’m going to unearth. But it has some problems. The first is that it feels strange; it feels like you should be able to reorder the type parameters on a trait without breaking everything (we will see that this is not, in fact, obviously true, but it was certainly my first reaction).

Another problem is that the rule is kind of fragile. It can easily reject impls that don’t seem particularly different from impls that it accepts. For example, consider the case of the Modifier trait that is used in hyper and iron. As you can see in this issue, iron wants to be able to define a Modifier impl like the following:

1 2 3 struct Response; ... impl Modifier<Response> for Vec<u8> { .. }

This impl is accepted by the ordered rule (thre are no type parameters at all, in fact). However, the following impl, which seems very similar and equally likely (in the abstract), would not be accepted:

1 2 3 struct Response; ... impl<T> Modifier<Response> for Vec<T> { .. }

This is because the type parameter T appears before the local type (Response). Hmm. It doesn’t really matter if T appears in the local type, either; the following would also be rejected:

1 2 3 struct MyHeader<T> { .. } ... impl<T> Modifier<MyHeader<T>> for Vec<T> { .. }

Another trait that couldn’t be handled properly is the BorrowFrom trait in the standard library. There a number of impls like this one:

1 impl<T> BorrowFrom<Rc<T>> for T

This impl fails the ordered check because T comes first. We can make it pass by switching the order of the parameters, so that the BorrowFrom trait becomes Borrow.

A final “near-miss” occurred in the standard library with the Cow type. Here is an impl from libcollections of FromIterator for a copy-on-write vector:

1 impl<'a, T> FromIterator<T> for Cow<'a, Vec<T>, [T]>

Note that Vec is a local type here. This impl obeys the ordered rule, but somewhat by accident. If the type parameters of the Cow trait were in a different order, it would not, because then [T] would precede Vec<T>.

The covered rule

In response to these shortcomings, I proposed an alternative rule that I’ll call the covered rule. The idea of the covered rule was to say that (1) the impl must have a local type somewhere and (2) a type parameter can only appear in the impl if the type parameter is covered by a local type. Covered means that it appears “inside” the type: so T is covered by MyVec in the type MyVec<T> or MyBox<Box<T>>, but not in (T, MyVec<int>). This rule has the advantage of having nothing to do with ordering and it has a certain intution to it; any type parameters that appear in your impls have to be tied to something local.

This rule [turns out to give us the required orphan rule guarantees][proof]. To see why, consider this example:

1 2 impl<T> Foo<T> for A<T> // Crate A impl<U> Foo<B<U>> for U // Crate B

If you tried to make these two impls apply to the same type, you wind up with infinite types. After all, T = B<U>, but U=A<T>, and hence you get T = B<A<T>>.

Unlike the previous rule, this rule happily accepts the BorrowFrom trait impls:

1 impl<T> BorrowFrom<Rc<T>> for T

The reason is that the type parameter T here is covered by the (local) type Rc.

However, after implementing this rule, we found out that it actually prohibits a lot of other useful patterns. The most important of them is the so-called auxiliary pattern, in which a trait takes a type parameter that is a kind of “configuration” and is basically orthogonal to the types that the trait is implemented for. An example is the Hash trait:

1 impl<H> Hash<H> for MyStruct

The type H here represents the hashing function that is being used. As you can imagine, for most types, they will work with any hashing function. Sadly, this impl is rejected, because H is not covered by any local type. You could make it work by adding a parameter H to MyStruct:

1 impl<H> Hash<H> for MyStruct<H>

But that is very weird, because now when we create our struct we are also deciding which hash functions can be used with it. You can also make it work by moving the hash function parameter H to the hash method itself, but then that is limiting. It makes the Hash trait not object safe, for one thing, and it also prohibits us from writing types that are specialized to particular hash functions.

Another similar example is indexing. Many people want to make types indexable by any integer-like thing, for example:

1 2 3 impl<I:Int, T> Index<I> for Vec<T> { type Output = T; }

Here the type parameter I is also uncovered.

Ordered vs Covered

By now I’ve probably lost you in the ins and outs, so let’s see a summary. Here’s a table of all the examples I’ve covered so far. I’ve tweaked the names so that, in all cases, any type that begins with My is considered local to the current crate:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +----------------------------------------------------------+---+---+ | Impl Header | O | C | +----------------------------------------------------------+---+---+ | impl Add<i32> for MyBigInt | X | X | | impl Add<MyBigInt> for i32 | X | X | | impl<T> Add<T> for MyBigInt | X | | | impl<U> Add<MyBigInt> for U | | | | impl<T> Modifier<MyType> for Vec<u8> | X | X | | impl<T> Modifier<MyType> for Vec<T> | | | | impl<'a, T> FromIterator<T> for Cow<'a, MyVec<T>, [T]> | X | X | | impl<'a, T> FromIterator<T> for Cow<'a, [T], MyVec<T>> | | X | | impl<T> BorrowFrom<Rc<T>> for T | | X | | impl<T> Borrow<T> for Rc<T> | X | X | | impl<H> Hash<H> for MyStruct | X | | | impl<I:Int,T> Index<I> for MyVec<T> | X | | +----------------------------------------------------------+---+---+

As you can see, both of these have their advantages. However, the ordered rule comes out somewhat ahead. In particular, the places where it fails can often be worked around by reordering parameters, but there is no answer that permits the covered rule to handle the Hash example (and there are a number of other traits that fit that pattern in the standard library).

Hybrid approach #1: Covered self

You might be wondering – if neither rule is perfect, is there a way to combine them? In fact, the rule that is current implemented is such a hybrid. It imposes the covered rules, but only on the Self parameter. That means that there must be a local type somewhere in Self, and any type parameters appearing in Self must be covered by a local type. Let’s call this hybrid CS, for “covered apply to Self”.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 +----------------------------------------------------------+---+---+---+ | Impl Header | O | C | S | +----------------------------------------------------------+---+---+---| | impl Add<i32> for MyBigInt | X | X | X | | impl Add<MyBigInt> for i32 | X | X | | | impl<T> Add<T> for MyBigInt | X | | X | | impl<U> Add<MyBigInt> for U | | | | | impl<T> Modifier<MyType> for Vec<u8> | X | X | | | impl<T> Modifier<MyType> for Vec<T> | | | | | impl<'a, T> FromIterator<T> for Cow<'a, MyVec<T>, [T]> | X | X | X | | impl<'a, T> FromIterator<T> for Cow<'a, [T], MyVec<T>> | | X | X | | impl<T> BorrowFrom<Rc<T>> for T | | X | | | impl<T> Borrow<T> for Rc<T> | X | X | X | | impl<H> Hash<H> for MyStruct | X | | X | | impl<I:Int,T> Index<I> for MyVec<T> | X | | X | +----------------------------------------------------------+---+---+---+ O - Ordered / C - Covered / S - Covered Self

As you can see, the CS hybrid turns out to miss some important cases that the pure ordered full achieves. Notably, it prohibits:

  • impl Add<MyBigInt> for i32
  • impl Modifier<MyType> for Vec<u8>

This is not really good enough.

Hybrid approach #2: Covered First

We can improve the covered self approach by saying that some type parameter of the trait must meet the rules (some local type; impl type params covered by a local type), but not necessarily Self. Any type parameters which precede this covered parameter must consist exclusively of remote types (no impl type parameters, in particular).

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 +----------------------------------------------------------+---+---+---+---+ | Impl Header | O | C | S | F | +----------------------------------------------------------+---+---+---|---| | impl Add<i32> for MyBigInt | X | X | X | X | | impl Add<MyBigInt> for i32 | X | X | | X | | impl<T> Add<T> for MyBigInt | X | | X | X | | impl<U> Add<MyBigInt> for U | | | | | | impl<T> Modifier<MyType> for Vec<u8> | X | X | | X | | impl<T> Modifier<MyType> for Vec<T> | | | | | | impl<'a, T> FromIterator<T> for Cow<'a, MyVec<T>, [T]> | X | X | X | X | | impl<'a, T> FromIterator<T> for Cow<'a, [T], MyVec<T>> | | X | X | X | | impl<T> BorrowFrom<Rc<T>> for T | | X | | | | impl<T> Borrow<T> for Rc<T> | X | X | X | X | | impl<H> Hash<H> for MyStruct | X | | X | X | | impl<I:Int,T> Index<I> for MyVec<T> | X | | X | X | +----------------------------------------------------------+---+---+---+---+ O - Ordered / C - Covered / S - Covered Self / F - Covered First

As you can see, this is a strict improvement over the other appraoches. The only thing it can’t handle that the other rules can is the BorrowFrom rule.

An alternative approach: distinguishing “self-like” vs “auxiliary” parameters

One disappointment about the hybrid rules I presented thus far is that they are inherently ordered. It runs somewhat against my intuition, which is that the order of the trait type parameters shouldn’t matter that much. In particular it feels that, for a commutative trait like Add, the role of the left-hand-side type (Self) and right-hand-side type should be interchangable (below, I will argue that in fact some kind of order may well be essential to the notion of coherence as a whole, but for now let’s assume we want Add to treat the left- and right-hand-side as equivalent).

However, there are definitely other traits where the parameters are not equivalent. Consider the Hash trait example we saw before. In the case of Hash, the type parameter H refers to the hashing algorithm and thus is inherently not going to be covered by the type of the value being hashed. It is in some sense completely orthogonal to the Self type. For this reason, we’d like to define impls that apply to any hasher, like this one:

1 impl<H> Hash<H> for MyType { ... }

The problem is, if we permit this impl, then we can’t allow another crate to define an impl with the same parameters, but in a different order:

1 impl<H> Hash<MyType> for H { ... }

One way to permit the first impl and not the second without invoking ordering is to classify type parameters as self-like and auxiliary.

The orphan rule would require that at least one self-like parameter references a local type and that all impl type parameters appearing in self-like types would be covered. The Self type is always self-like, but other types would be auxiliary unless declared to be self-like (or perhaps the default would be the opposite).

Here is a table showing how this new “explicit” rule would work, presuming that the type parameters on Add and Modifier were declared as self-like. The Hash and Index parameters would be declared as auxiliary.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 +----------------------------------------------------------+---+---+---+---+---+ | Impl Header | O | C | S | F | E | +----------------------------------------------------------+---+---+---|---|---+ | impl Add<i32> for MyBigInt | X | X | X | X | X | | impl Add<MyBigInt> for i32 | X | X | | X | X | | impl<T> Add<T> for MyBigInt | X | | X | X | | | impl<U> Add<MyBigInt> for U | | | | | | | impl<T> Modifier<MyType> for Vec<u8> | X | X | | X | X | | impl<T> Modifier<MyType> for Vec<T> | | | | | | | impl<'a, T> FromIterator<T> for Cow<'a, MyVec<T>, [T]> | X | X | X | X | X | | impl<'a, T> FromIterator<T> for Cow<'a, [T], MyVec<T>> | | X | X | X | X | | impl<T> BorrowFrom<Rc<T>> for T | | X | | | X | | impl<T> Borrow<T> for Rc<T> | X | X | X | X | X | | impl<H> Hash<H> for MyStruct | X | | X | X | X | | impl<I:Int,T> Index<I> for MyVec<T> | X | | X | X | X | +----------------------------------------------------------+---+---+---+---+---+ O - Ordered / C - Covered / S - Covered Self / F - Covered First E - Explicit Declarations

You can see that it’s quite expressive, though it is very restrictive about generic impls for Add. However, it would push quite a bit of complexity onto the users, because now when you create a trait, you must classify its type parameter as self.

In defense of ordering

Whereas at first I felt that having the rules take ordering into account was unnatural, I have come to feel that ordering is, to some extent, inherent in coherence. To see what I mean, let’s consider an example of a new vector type, MyVec<T>. It might be reasonable to permit MyVec<T> to be addable to anything can converted into an iterator over T elements. Naturally, since we’re overloading +, we’d prefer for it to be commutative:

1 2 3 4 5 6 7 8 impl<T,I> Add<I> for MyVec<T> where I : IntoIterator<Output=T> { type Output = MyVec<T>; ... } impl<T,I> Add<MyVec<T>> for I where I : IntoIterator<Output=T> { type Output = MyVec<T>; ... }

Now, given that MyVec<T> is a vector, it should be iterable as well:

1 2 3 4 impl<T> IntoIterator for MyVec<T> { type Output = T; ... }

The problem is that these three impls are inherently overlapping. After all, if I try to add two MyVec instances, which impl do I get?

Now, this isn’t a problem for any of the rules I proposed in this thread, because all of them reject that pair of impls. In fact, both the “Covered” and “Explicit Declarations” rules go farther: they reject both impls. This is because the type parameter I is uncovered; since the rules don’t consider ordering, they can’t allow an uncovered iterator I on either the left- or the right-hand-side.

The other variations (“Ordered”, “Covered Self”, and “Covered First”), on the other hand, allow only one of those impls: the one where MyVec<T> appears on the left. This seems pretty reasonable. After all, if we allow you to define an overloaded + that applies to an open-ended set of types (those that are iterable), there is the possibility that others will do the same. And if I try to add a MyVec<int> and a YourVec<int>, both of which are iterable, who wins? The ordered rules give a clear answer: the left-hand-side wins.

There are other blanket cases that also get prohibited which might on their face seem to be reasonable. For example, if I have a BigInt type, the ordered rules allow me to write impls that permit BigInt to be added to any concrete int type, no matter which side that concrete type appears on:

1 2 3 4 5 impl Add<BigInt> for i8 { type Output = BigInt; ... } impl Add<i8> for BigInt { type Output = BigInt; ... } ... impl Add<BigInt> for i64 { type Output = BigInt; ... } impl Add<i64> for BigInt { type Output = BigInt; ... }

It might be nice, if I could just write the following two impls:

1 2 impl<R:Int> Add<BigInt> for R { type Output = BigInt; ... } impl<L:Int> Add<L> for BigInt { type Output = BigInt; ... }

Now, this makes some measure of sense because Int is a trait that is only intended to be implemented for the primitive integers. In principle all bigints could use these same rules without conflict, so long as none of them implement Int. But in fact, nothing prevents them from implementing Int. Moreover, it’s not hard to imagine other crates creating comparable impls that would overlap with the ones above:

1 2 3 4 struct PrintedInt(i32); impl Int for PrintedInt; impl<R:Show> Add<PrintedInt> for R { type Output = BigInt; ... } impl<L:Show> Add<L> for PrintedInt { type Output = BigInt; ... }

Assuming that BigInt implements Show, we now have a problem!

In the future, it may be interesting to provide a way to use traits to create “strata” so that we can say things like “it’s ok to use an Int-bounded type parameter on the LHS so long as the RHS is bounded by Foo, which is incompatible with Int”, but it’s a subtle and tricky issue (as the Show example demonstrates).

So ordering basically means that when you define your traits, you should put the “principal” type as Self, and then order the other type parameters such that those which define the more “principal” behavior come afterwards in order.

The problem with ordering

Currently I lean towards the “Covered First” rule, but it bothers me that it allows something like

1 impl Modifier<MyType> for Vec<u8>

but not

1 impl<T> Modifier<MyType> for Vec<T>

However, this limitation seems to be pretty inherent to any rules that do not explicitly identify “auxiliary” type parameters. The reason is that the ordering variations all use the first occurrence of a local type as a “signal” that auxiliary type parameters should be permitted afterwards. This implies that another crate will be able to do something like:

1 impl<U> Modifier<U> for Vec<YourType>

In that case, both impls apply to Modifier<MyType> for Vec<YourType>.


This is a long post, and it covers a lot of ground. As I wrote in the introduction, the orphan rules turn out to be hiding quite a lot of complexity. Much more than I imagined at first. My goal here is mostly to lay out all the things that aturon and I have been talking about in a comprehensive way.

I feel like this all comes down to a key question: how do we identify the “auxiliary” input type parameters? Ordering-based rules identify this for each impl based on where the first “local” type appears. Coverage-based rules seem to require some sort of explicit declaration on the trait.

I am deeply concerned about asking people to understand this “auxiliary” vs “self-like” distinction when declaring a trait. On the other hand, there is no silver bullet: under ordering-based rules, they will be required to sometimes reorder their type parameters just to pacify the seemingly random ordering rule. (But I have the feeling that people intuitively put the most “primary” type first, as Self, and the auxiliary type parameters later.)

Categorieën: Mozilla-nl planet

Marco Zehe: Quickly check your website for common accessibility problems with

Mozilla planet - wo, 14/01/2015 - 19:12 is a new tool to test web sites against some of the Web Content Accessibility Guidelines criteria. While this does not guarantee the usability of a web site, it gives you an idea of where you may have some problems. Due to its API, it can be integrated into workflows for test automation and other building steps for web projects.

However, sometimes you’ll just quickly want to check your web site and get an overview if something you did has the desired effect.

The Tenon team released a first version of a Chrome extension in December. But because there was no equivalent for Firefox, my ambition was peaked, and I set out to build my first ever Firefox extension.

And guess what? It does even a bit more than the Chrome one! In addition to a tool bar button, it gives Firefox users a context menu item for every page type so keyboard users and those using screen readers have equal access to the functionality. The extension grabs the URL of the currently open tab and submits that to Tenon. It opens a new tab where the Tenon page will display the results.

For the technically interested: I used the Node.js implementation of the Firefox Add-On SDK, called JPM, to build the extension. I was heavily inspired by this blog post published in December about building Firefox extensions the painless way. As I moved along, I wanted to try out io.js, but ran into issues in two modules, so while working on the extension, I contributed bug reports to both JPM and jszip. Did I ever mention that I love working in open source? ;)

So without further due: Here’s the Firefox extension! And if you like it, a positive review is certainly appreciated!

Have fun!

Categorieën: Mozilla-nl planet

Doug Belshaw: How we're building v1.5 of Mozilla's Web Literacy Map in Q1 2015

Mozilla planet - wo, 14/01/2015 - 17:24

The Web Literacy Map constitutes the skills and competencies required to read, write and participate on the web. It currently stands at version 1.1 and you can see a more graphical overview of the competency layer in the Webmaker resources section.

Minecraft building

In Q1 2015 (January-March) we’ll be working with the community to update the Web Literacy Map to version 1.5. This is the result of a consultation process that initially aimed at a v2.0 but was re-scoped following community input. Find out more about the interviews, survey and calls that were part of that arc on the Mozilla wiki or in this tumblr post.

Some of what we’ll be discussing and working on has already been scoped out, while some will be emergent. We’ll definitely be focusing the following:

  • Reviewing the existing skills and competencies (i.e. names/descriptors)
  • Linking to the Mozilla manifesto (where appropriate)
  • Decide whether we want to include ‘levels’ in the map (e.g. Beginner / Intermediate / Advanced)
  • Explore ways to iterate on the visual design of the competency layer

After asking the community when the best time for a call would be, the first one is scheduled for tomorrow (Thursday 15th January 2015, 4pm UTC). Join us! Details of the other calls can be found here.

In addition to these calls, we’ll almost certainly have 'half-hour hack’ sessions where we get stuff done. This might include re-writing skills/competencies and work on other things that need doing - rather than discussing. These will likely be Mondays at the same time.

Questions? Comments? Tweet me or email me

Categorieën: Mozilla-nl planet

Soledad Penades: Introduction to Web Components

Mozilla planet - wo, 14/01/2015 - 17:13

I had the pleasure and honour to be the opening speaker for the first ever London Web Components meetup! Yay!

There was no video recording, but I remembered to record a screencast! It’s a bit messy and noisy, but if you couldn’t attend, this is better than nothing.

It also includes all the Q&A!

Some of the things people are worried about, which I think are interesting if you’re working on Web Components in any way:

  • How can I use them in production reliably?
  • What’s the best way to get started i.e. where do I start? do you migrate the whole thing with a new framework? or do you start little by little?
  • How would them affect SEO and accessibility? the best option is probably to extend existing elements where possible using the is="" idiom so you can add to the existing functionality
  • How do Web Components interact with other libraries? e.g. jQuery or React. Why would one use Web Components instead of Angular directives for example?
  • And if we use jQuery with components aren’t we back to “square one”?
  • What are examples of web components in production we can look at? e.g. the famous GitHub time element custom element.
  • Putting the whole app in just one tag yes/no: verging towards the NO, makes people uneasy
  • How does the hyphen thing work? It’s for preventing people registering existing elements, and also casual namespacing. It’s not perfect and won’t avoid clashes, some idea is to allow a way to delay the registration until the name of the element is provided so you can register it in the same way that you can require() something in node and don’t care what the internal name of such module is.

Only one person in the audience was using Web Components in production (that would be Wilson with Firefox OS, tee hee!) and about 10 or so were using them to play around and experiment, and consistently using Polymer… except Firefox OS, which uses just vanilla JS.

Slides are here and here’s the source code.

I’m really glad that I convinced my awesome colleague Wilson Page to join us too, as he has loads of experience implementing Web Components in Firefox OS and so he could provide lots of interesting commentary. Hopefully he will speak at a future event!

Join the meet-up so you can be informed when there’s a new one happening!

flattr this!

Categorieën: Mozilla-nl planet

Pete Moore: Weekly review 2015-01-14

Mozilla planet - wo, 14/01/2015 - 16:30

I am still alive.

Or, as the great Mark Twain once said: "The reports of my death have been greatly exaggerated."

Highlights from this week

This week I have been learning Go! And it has been a joy. Mostly.

My code doodles:

This article got me curious about Erlang:

Other than that I have been playing with docker, installed on my Mac, and have set up a VMware environment and acquired Windows Server 2008 x64 for running Go on Windows.

Plans for next week

Start work on porting the taskcluster-client library to Go. See:

Other matters

  • VCS Sync issues this week for l10n gecko
  • Found an interesting Go conference to attend this year
Categorieën: Mozilla-nl planet

Download of the day: Mozilla Thunderbird - TechRadar

Nieuws verzameld via Google - wo, 14/01/2015 - 16:12


Download of the day: Mozilla Thunderbird
There are plenty of webmail options out there, but if you want a desktop client, there are few better than Mozilla Thunderbird. Coming under the trusted Mozilla brand, Thunderbird comes with everything you'd want from an email client – robust message ...

en meer »
Categorieën: Mozilla-nl planet

Download of the day: Mozilla Thunderbird - TechRadar

Nieuws verzameld via Google - wo, 14/01/2015 - 16:10

Download of the day: Mozilla Thunderbird
There are plenty of webmail options out there, but if you want a desktop client, there are few better than Mozilla Thunderbird. Coming under the trusted Mozilla brand, Thunderbird comes with everything you'd want from an email client – robust message ...

en meer »
Categorieën: Mozilla-nl planet

Daniel Stenberg: My talks at FOSDEM 2015

Mozilla planet - wo, 14/01/2015 - 15:48


Saturday 13:30, embedded room (Lameere)

Tile: Internet all the things – using curl in your device

Embedded devices are very often network connected these days. Network connected embedded devices often need to transfer data to and from them as clients, using one or more of the popular internet protocols.

libcurl is the world’s most used and most popular internet transfer library, already used in every imaginable sort of embedded device out there. How did this happen and how do you use libcurl to transfer data to or from your device?

Sunday, 09:00 Mozilla room (UD2.218A)

Title: HTTP/2 right now

HTTP/2 is the new version of the web’s most important and used protocol. Version 2 is due to be out very soon after FOSDEM and I want to inform the audience about what’s going on with the protocol, why it matters to most web developers and users and not the last what its status is at the time of FOSDEM.

Categorieën: Mozilla-nl planet

Henrik Skupin: Firefox Automation report – week 47/48 2014

Mozilla planet - wo, 14/01/2015 - 14:57

In this post you can find an overview about the work happened in the Firefox Automation team during week 47 and 48.


Most of the work during those two weeks made by myself were related to get [Jenkins]( upgraded on our Mozmill CI systems to the most recent LTS version 1.580.1. This was a somewhat critical task given the huge number of issue as mentioned in my last Firefox Automation report. On November 17th we were finally able to get all the code changes landed on our production machine after testing it for a couple of days on staging.

The upgrade was not that easy given that lots of code had to be touched, and the new LTS release still showed some weird behavior when connecting slave nodes via JLNP. As result we had to stop using this connection method in favor of the plain java command. This change was actually not that bad because it’s better to automate and doesn’t bring up the connection warning dialog.

Surprisingly the huge HTTP session usage as reported by the Monitoring plugin was a problem introduced by this plugin itself. So a simple upgrade to the latest plugin version solved this problem, and we will no longer get an additional HTTP connection whenever a slave node connects and which never was released. Once we had a total freeze of the machine because of that.

Another helpful improvement in Jenkins was the fix for a JUnit plugin bug, which caused concurrent builds to hang, until the former build in the queue has been finished. This added a large pile of waiting time to our Mozmill test jobs, which was very annoying for QA’s release testing work – especially for the update tests. Since this upgrade the problem is gone and we can process builds a lot faster.

Beside the upgrade work, I also noticed that one of the Jenkins plugins in use, it’s actually the XShell plugin, failed to correctly kill the running application on the slave machine in case of an job is getting aborted. The result of that is that following tests will fail on that machine until the not killed job has been finished. I filed a Jenkins bug and did a temporary backout of the offending change in that plugin.

Individual Updates

For more granular updates of each individual team member please visit our weekly team etherpad for week 47 and week 48.

Meeting Details

If you are interested in further details and discussions you might also want to have a look at the meeting agenda, the video recording, and notes from the Firefox Automation meetings of week 47 and week 48.

Categorieën: Mozilla-nl planet

Mozilla Firefox 35 stable release now available for free download: What's new - International Business Times UK

Nieuws verzameld via Google - wo, 14/01/2015 - 12:49

Mozilla Firefox 35 stable release now available for free download: What's new
International Business Times UK
Users of the Mozilla Firefox 35 Android application should now be able to use the Android Download Manager to keep track of downloaded files. Also, the Android app, post updating, claims to boost Mozilla's geolocation service by sharing users' wi-fi ...

Categorieën: Mozilla-nl planet

Navegador Mozilla Firefox permite chamadas de voz e vídeo gratuitas - Info Online

Nieuws verzameld via Google - wo, 14/01/2015 - 11:53

Navegador Mozilla Firefox permite chamadas de voz e vídeo gratuitas
Info Online
O navegador Mozilla Firefox ganhou suporte para chamadas de voz e vídeo. O Firefox Hello, que a fundação define como o "primeiro comunicador global desenvolvido diretamente dentro do navegador", permite que os internautas realizem ligações e ...
Mozilla quer transformar Firefox em ferramenta de
Nova versão de navegador da Mozilla disponibiliza o Firefox Hello, para realizar ...Portal Maxpress
Firefox 35 chega com várias novidades e traz Hello para chamadas in-appCanaltech
Boa Informação -Pplware
alle 16 nieuwsartikelen »Google Nieuws
Categorieën: Mozilla-nl planet

Firefox 35: Neuer Mozilla-Browser steht zum Download bereit - STERN

Nieuws verzameld via Google - wo, 14/01/2015 - 11:21


Firefox 35: Neuer Mozilla-Browser steht zum Download bereit
Ebenfalls neu: Firefox 35 lädt dynamisch gestaltete Webseiten nun schneller und große Bilder werden zügiger skaliert, verspricht Mozilla. Mac-Nutzer profitieren von neuen Schnittstellen (APIs) und einer eingebauten H.264-Unterstützung ohne zusätzliche ...
Firefox 35 jetzt zum Download: neuen Mozilla-Browser runterladenT-Online
Mozilla Firefox 35 steht zum Download
Mozilla: Videotelefonate ohne Plugins in FirefoxNeue Zürcher Zeitung -PC Games
alle 25 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Matjaž Horvat: Pontoon report 2014: Make your translations better

Mozilla planet - wo, 14/01/2015 - 11:03

This post is part of a series of blog posts outlining Pontoon development in 2014. I’ll mostly focus on new features targeting translators. If you’re more interested in developer oriented updates, please have a look at the release notes.

Part 1. User interface
Part 2. Backend
Part 3. Meet our top contributors
Part 4. Make your translations betteryou are here
Part 5. Demo project

Some new features have been added to Pontoon, some older tools have been improved, all helping translators be more efficient and make translations more consistent, more accurate and simply better.

History tab displays previously suggested translations, including submissions from other users. Privileged translators can pick approved translation or delete the ones they find inappropriate.

The next tab provides automated suggestions from several sources: Pontoon translation memory, Transvision (Mozilla), amagama (open source projects), Microsoft Terminology and machine translation by Bing Translator. Using machinery will make your translations more consistent.

Quality checks
Pontoon reviews every submitted translation by running Translate Toolkit pofilter tests that check for several issues that can affect the quality of your translations. Those checks are locale specific and can be turned off by translator.

Some pieces of strings are not supposed to be translated. Think HTML markup or variables for example. Pontoon colorizes those pieces (called placeables) and allows you to easily insert them into your translation by clicking on them.

Get involved
Are you a developer, interested in Pontoon? Learn how to get your hands dirty.

Categorieën: Mozilla-nl planet

Mozilla patcht 10 beveiligingslekken in Firefox 35 -

Nieuws verzameld via Google - wo, 14/01/2015 - 10:41

Mozilla patcht 10 beveiligingslekken in Firefox 35
Mozilla heeft een nieuwe versie van Firefox uitgebracht waarin tien beveiligingslekken zijn verholpen, waarvan vier zo ernstig dat een aanvaller het onderliggende systeem in het ergste geval volledig kon overnemen als de gebruiker een kwaadaardige of ...

Categorieën: Mozilla-nl planet

Software-update: Mozilla Thunderbird 31.4.0 - Tweakers

Nieuws verzameld via Google - wo, 14/01/2015 - 10:35

Software-update: Mozilla Thunderbird 31.4.0
Mozilla Thunderbird logo (90 pix) De Mozilla Foundation heeft versie 31.4.0 van Thunderbird uitgebracht. Mozilla Thunderbird is een opensourceclient voor e-mail en nieuwsgroepen, met features als ondersteuning voor verschillende mail- en newsaccounts, ...

Categorieën: Mozilla-nl planet

Julian Seward: Valgrind support for MacOS X 10.10 (Yosemite)

Mozilla planet - wo, 14/01/2015 - 10:13

Valgrind support on Yosemite has improved significantly in the past few months. It is now feasible to run Firefox on Valgrind on Yosemite. Support for 10.9 (Mavericks) has also improved, but 64-bit Yosemite remains the primary focus of support work.

For various reasons, MacOS is a difficult target for Valgrind. So you’ll find it little slower, and possibly more flaky, than running on Linux. Occasionally, the MacOS kernel will panic, for unknown reasons.  But it does work.

Full details of running Firefox on Valgrind on Yosemite are at  For serious use, you need to read that page.  In the meantime, here is the minimal getting-started recipe.

First, build Valgrind. You’ll need to use the trunk, since Yosemite support didn’t make it in time for the current stable (3.10.x) line.

svn co svn:// valgrind-trunk cd valgrind-trunk ./ && ./configure --prefix=`pwd`/Inst make -j8 && make -j8 install

Make the headers available for building Firefox:

cd /usr/include sudo ln -s /path/to/valgrind-trunk/Inst/include/valgrind .

Now build your Firefox tree. I recommend a mozconfig containing

ac_add_options --disable-debug ac_add_options --enable-optimize="-g -O2" ac_add_options --disable-jemalloc ac_add_options --enable-valgrind

And run, being sure to run the real binary (firefox-bin):

/path/to/valgrind-trunk/Inst/bin/valgrind --smc-check=all-non-file \ --vex-iropt-register-updates=allregs-at-mem-access --dsymutil=yes \ ./objdir/dist/


Categorieën: Mozilla-nl planet

Mozilla startet Science Lab Fellowship Program - Pro-Linux

Nieuws verzameld via Google - wo, 14/01/2015 - 09:05

Mozilla startet Science Lab Fellowship Program
Vor 18 Monaten hatte Mozilla das Science Lab gegründet, dessen Aufgabe es sein sollte, Zusammenarbeit in der Forschung zu fördern. Mittel zur Zusammenarbeit sind Webanwendungen, was auch den Zusammenhang mit Mozilla herstellt. Das Science Lab ...

Google Nieuws
Categorieën: Mozilla-nl planet

Andy McKay: Mozilla uses what

Mozilla planet - wo, 14/01/2015 - 09:00

Today there was a blog post about Angular. One of the main things in there seems to be that:

Google has a good name in web technology, so if they push a JavaScript library it must be good ... right?

I've seen this happen multiple times, especially in an development agency staffed by non-technical managers. Managers ask developers to pick a framework and justify it. They can write a long list, but in the end they'll get to a bullet point like "Google uses it" or "Google built it".

The problem with that - any large organisation uses a large amounts of differing and competing technologies. Mozilla uses a huge number of open source projects and libraries. I'm not even going to list the things we use in just our web applications because it's ridiculously long. And that's just one very small part of Mozilla.

More than that, not only do we use a lot of projects - we write a lot of open source projects. Have a look at the Mozilla github repo and again, that's one very small part of Mozilla.

It's easy to assume that Google makes Angular and make associations with Gmail and so many other great things. But Google doesn't use Angular for everything. Just like Mozilla doesn't use node.js for everything.

Choose an open source technology for the right reasons, but avoid linking a technology to a brand and clouding your judgement.

Categorieën: Mozilla-nl planet