Mozilla Nederland LogoDe Nederlandse

Abonneren op feed Mozilla planet
Planet Mozilla -
Bijgewerkt: 1 maand 3 weken geleden

Andy McKay: Manual review of add-ons

di, 11/07/2017 - 09:00

As we start to expand WebExtension APIs beyond parity with Chrome, a common theme is appearing in bug comments when proposing new APIs. That theme is something like "we'll have to give add-ons using that API a special manual review".

Put simply, that's not happening. Either we feel comfortable with an API and everyone can use it, or we don't implement it. There won't be any special manual review process for WebExtensions for specific APIs.

Manual review has quite a few problems but bluntly, it costs Mozillians resources and time and upsets developers.

On the cost side, we've had to put an awful lot of developer and reviewer (both paid and volunteer) time into reviewing extensions. There's tools and sites supported by Mozilla to support the review process.

But more than that, loud and clear developers have told us they dislike the review process and complain about it. It causes delays and developers get upset when people (many of whom are volunteer) aren't able to turn around reviews within reasonable time scales.

Further, this makes it harder for developers because it forces developers to upload unobfuscated sources. Something that its getting harder and harder as webpack, browserify and other tools gain in popularity.

And finally manual review isn't perfect. It's hard to review code, look for all the possible security and policy problems and ensure that questionable API didn't do something we felt uncomfortable with.

Manual review has its place in Mozilla, but one thing we shouldn't be do is placing more burdens on the process. We should be aiming to streamline review and ease the burden on reviewers and developers.

The result is we've got to either say no to the API or find a way to make everyone comfortable with the API.

Categorieën: Mozilla-nl planet

Andy McKay: Mail filters

di, 11/07/2017 - 09:00

Wil posted on his blog some mail filters he uses to cope with all the incoming mail. Here's a few of mine:

Highlight mentions on mentored bugs:

Matches: "X-Bugzilla-Mentors" Do this: Skip Inbox, Apply label "Bugzilla/Mentored"

Filter out intermittents:

Matches: "X-Bugzilla-Keywords: intermittent-failure" Do this: Skip Inbox, Apply label "Bugzilla/Intermittents"

Filter down by a specific product and component:

Matches: "X-Bugzilla-Product: Firefox" "X-Bugzilla-Component: Extension Compatibility" Do this: Skip Inbox, Apply label "Bugzilla/Extension Compat"
Categorieën: Mozilla-nl planet

This Week In Rust: This Week in Rust 190

di, 11/07/2017 - 06:00

Hello and welcome to another issue of This Week in Rust! Rust is a systems language pursuing the trifecta: safety, concurrency, and speed. This is a weekly summary of its progress and community. Want something mentioned? Tweet us at @ThisWeekInRust or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR.

Updates from Rust Community News & Blog Posts Friends of the Forest

Our community likes to recognize people who have made outstanding contributions to the Rust Project, its ecosystem, and its community. These people are 'friends of the forest'.

Our this week's friend of the forest is Guillaume Gomez, whose influence is evident everywhere you look in Rust.

Crate of the Week

Sadly, no crate was nominated this week.

Submit your suggestions and votes for next week!

Call for Participation

Always wanted to contribute to open-source projects but didn't know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

If you are a Rust project owner and are looking for contributors, please submit tasks here.

Updates from Rust Core

113 pull requests were merged in the last week

New Contributors
  • boreeas
  • Kornel
  • oyvindln
Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

Final Comment Period

Every week the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. This week's FCPs are:

New RFCs Style RFCs

Style RFCs are part of the process for deciding on style guidelines for the Rust community and defaults for Rustfmt. The process is similar to the RFC process, but we try to reach rough consensus on issues (including a final comment period) before progressing to PRs. Just like the RFC process, all users are welcome to comment and submit RFCs. If you want to help decide what Rust code should look like, come get involved!

The RFC style is now the default style in Rustfmt - try it out and let us know what you think!

An interesting issue:

Good first issues:

We're happy to mentor these, please reach out to us in #rust-style if you'd like to get involved

Upcoming Events

If you are running a Rust event please add it to the calendar to get it mentioned here. Email the Rust Community Team for access.

Rust Jobs

Tweet us at @ThisWeekInRust to get your job offers listed here!

Quote of the Week

Unsafe is your friend! It's maybe not a friend like you would invite to your sister's wedding, or the christening of her first-born child. But it's sort of the friend who lives in the country and has a pick-up truck and 37 guns. And so you might not want to hang out with them all the time, but if you need something blown up he is there for you.

Simon Heath on game development in Rust (at 38:35 in video).

Thanks to G2P and David Tolnay for the suggestion.

Submit your quotes for next week!

This Week in Rust is edited by: nasa42, llogiq, and brson.

Categorieën: Mozilla-nl planet

Niko Matsakis: Non-lexical lifetimes: draft RFC and prototype available

di, 11/07/2017 - 06:00

I’ve been hard at work the last month or so on trying to complete the non-lexical lifetimes RFC. I’m pretty excited about how it’s shaping up. I wanted to write a kind of “meta” blog post talking about the current state of the proposal – almost there! – and how you could get involved with helping to push it over the finish line.


What can I say, I’m loquacious! In case you don’t want to read the full post, here are the highlights:

  • The NLL proposal is looking good. As far as I know, the proposal covers all major intraprocedural shortcomings of the existing borrow checker. The appendix at the end of this post talks about the problems that we don’t address (yet).
  • The draft RFC is available in a GitHub repository:
    • Read it over! Open issues! Open PRs!
    • In particular, if there is some pattern you think may not be covered, please let me know about it by opening an issue.
  • There is a working prototype as well:
    • The prototype includes region inference as well as the borrow checker.
    • I hope to expand it to become the normative prototype of how the borrow checker works, allowing us to easily experiment with extensions and modifications – analogous to Chalk.
Background: what the proposal aims to fix

The goal of this proposal is to fix the intra-procedural shortcomings of the existing borrow checker. That is, to fix those cases where, without looking at any other functions or knowing anything about what they do, we can see that some function is safe. The core of the proposal is the idea of defining reference lifetimes in terms of the control-flow graph, as I discussed (over a year ago!) in my introductory blog post; but that alone isn’t enough to address some common annoyances, so I’ve grown the proposal somewhat. In addition to defining how to infer and define non-lexical lifetimes themselves, it now includes an improved definition of the Rust borrow checker – that is, how to decide which loans are in scope at any particular point and which actions are illegal as a result.

When combined with RFC 2025, this means that we will accept two more classes of programs. First, what I call “nested method calls”:

impl Foo { fn add(&mut self, value: Point) { ... } fn compute(&self) -> Point { ... } fn process(&mut self) { self.add(self.compute()); // Error today! But not with RFC 2025. } }

Second, what I call “reference overwrites”. Currently, the borrow checker forbids you from writing code that updates an &mut variable whose referent is borrowed. This most commonly shows up when iterating down a slice in place (try it on play):

fn search(mut data: &mut [Data]) -> bool { loop { if let Some((first, tail)) = data.split_first_mut() { if is_match(first) { return true; } data = tail; // Error today! But not with the NLL proposal. } else { return false; } } }

The problem here is that the current borrow checker sees that data.split_first_mut() borrows *data (which has type [Data]). Normally, when you borrow some path, then all prefixes of the path become immutable, and hence borrowing *data means that, later on, modifying data in data = tail is illegal. This rule makes sense for “interior” data like fields: if you’ve borrowed the field of a struct, then overwriting the struct itself will also overwrite the field. But the rule is too strong for references and indirection: if you overwrite an &mut, you don’t affect the data it refers to. You can workaround this problem by forcing a move of data (e.g., by writing {data}.split_first_mut()), but you shouldn’t have to. (This issue has been filed for some time as #10520, which also lists some other workarounds.)

Draft RFC

The Draft RFC is almost complete. I’ve created a GitHub repository containing the text. I’ve also opened issues with some of the things I wanted to get done before posting it, though the descriptions are vague and it’s not clear that all of them are necessary. If you’re interested in helping out – please, read it over! Open issues on things that you find confusing, or open PRs with suggestions, typos, whatever. I’d like to make this RFC into a group effort.

The prototype

The other thing that I’m pretty excited about is that I have a working prototype of these ideas. The prototype takes as input individual .nll files, each of which contains a few struct definitions as well as the control-flow graph of a single function. The tests are aimed at demonstrating some particular scenario. For example, the borrowck-walk-linked-list.nll test covers the “reference overwrites” that I was talking about earlier. I’ll go over it in some detail to give you the idea.

The test begins with struct declarations. These are written in a very concise form because I was too lazy to make it more user-friendly:

struct List<+> { value: 0, successor: Box<List<0>> } // Equivalent to: // struct List<T> { // value: T, // successor: Box<List<T>> // }

As you can see, the type parameters are not named. Instead, we specify the variance (+ here means “covariant”). Within the function body, we reference type parameters via a number, counting backwards from the end of the list. Since there is only one parameter (T, in the Rust example), then 0 refers to T.

(In real life, this struct would use Option<Box<List<T>>>, but the prototype doesn’t model enums yet, so this is using a simplified form that is “close enough” from the point-of-view of the checker itself. We also don’t model raw pointers yet. PRs welcome!)

After the struct definitions, there are some let declarations, declaring the global variables:

let list: &'list mut List<()>; let value: &'value mut ();

Perhaps surprisingly, the named lifetimes like 'list and 'value correspond to inference variables. That is, they are not like named lifetimes in a Rust function – which are the one major thing I’ve yet to implement – but rather correspond to inference variables. Giving them names allows for us to add “assertions” (we’ll see one later) that test what results got inferred. You can also use '_ to have the parser generate a unique name for you if you don’t feel like giving an explicit one.

After the local variables, comes the control-flow graph declarations, as a series of basic-block declarations:

block START { list = use(); goto LOOP; }

Here, list = use() means “initialize list and use the (empty) list of arguments”. I’d like to improve this to support named function prototypes, but for now the prototype just has the idea of an ‘opaque use’. Basic blocks can optionally have successors, specified using goto.

One thing the prototype understands pretty well are borrows:

block LOOP { value = &'b1 mut (*list).value; list = &'b2 mut (*list); use(value); goto LOOP EXIT; }

An expression like &'b1 mut (*list).value borrows (*list).value mutably for the lifetime 'b1 – note that the lifetime of the borrow itself is independent from the lifetime where the reference ends up. Perhaps surprisingly, the reference can have a bigger lifetime than the borrow itself: in particular, a single reference variable may be assigned from multiple borrows in disjoint parts of the graph.

Finally, the tests support two kinds of assertions. First, you can mark a given line of code as being “in error” by adding a //! comment. There isn’t one in this example, but you can see them in other tests; these identify errors that the borrow checker would report. We can also have assertions of various kinds. These check the output from lifetime inference. This test has a single assertion:

assert LOOP/0 in 'b2;

This assertion specifies that the point LOOP/0 (that is, the start of the loop) is contained within the lifetime 'b2 – that is, we realize that the reference produced by (*list) may still be in use at LOOP/0. But note that this does not prevent us from reassigning list (nor borrowing (*list) This is because the new borrow checker is smart enough to understand that list has been reassigned in the meantime, and hence that the borrows from different loop iterations do not overlap.

Conclusion and how you can help

I think the NLL proposal itself is close to being ready to submit – I want to add a section on named lifetimes first, and add them to the prototype – but there is still lots of interesting work to be done. Naturally, reading and improving the RFC would be useful. However, I’d also like to improve the prototype. I would like to see it evolve into a more complete – but simplified – model of the borrow checker, that could serve as a good basis for analyzing the Rust type system and investigating extensions. Ideally, we would merge it with chalk, as the two complement one another: put together, they form a fairly complete model of the Rust type system (the missing piece is the initial round of type checking and coercion, which I would eventually like to model in chalk anyhow). If this vision interests you, please reach out! I have open issues on both projects, though I’ve not had time to write in tons of details – leave a comment if something sparks your interest, and I’d be happy to give more details and mentor it to completion as well.

Questions or comments?

Take it to internals!

Appendix: What the proposal won’t fix

I also want to mention a few kinds of borrow check errors that the current RFC will not eliminate – and is not intended to. These are generally errors that cross procedural boundaries in some form or another. For each case, I’ll give a short example, and give some pointers to the current thinking in how we might address it.

Closure desugaring. The first kind of error has to do with the closure desugaring. Right now, closures always capture local variables, even if the closure only uses some sub-path of the variable internally:

let get_len = || self.vec.len(); // borrows `self`, not `self.vec` self.vec2.push(...); // error: self is borrowed

This was discussed on an internals thread; as I commented there, I’d like to fix this by making the closure desugaring smarter, and I’d love to mentor someone through such an RFC! However, it is out of scope for this one, since it does not concern the borrow check itself, but rather the details of the closure transformation.

Disjoint fields across functions. Another kind of error is when you have one method that only uses a field a and another that only uses some field b; right now, you can’t express that, and hence these two methods cannot be used “in parallel” with one another:

impl Foo { fn get_a(&self) -> &A { &self.a } fn inc_b(&mut self) { self.b.value += 1; } fn bar(&mut self) { let a = self.get_a(); self.inc_b(); // Error: self is already borrowed use(a); } }

The fix for this is to refactor so as to expose the fact that the methods operate on disjoint data. For example, one can factor out the methods into methods on the fields themselves:

fn bar(&mut self) { let a = self.a.get();; use(a); }

This way, when looking at bar() alone, we see borrows of self.a and self.b, rather than two borrows of self. Another technique is to introduce “free functions” (e.g., get(&self.a) and inc(&mut self.b)) that expose more clearly which fields are operated upon, or to inline the method bodies. I’d like to fix this, but there are a lot of considerations at play: see this comment on an internals thread for my current thoughts. (A similar problem sometimes arises around Box<T> and other smart pointer types; the desugaring leads to rustc being more conservative than you might expect.)

Self-referential structs. The final limitation we are not fixing yet is the inability to have “self-referential structs”. That is, you cannot have a struct that stores, within itself, an arena and pointers into that arena, and then move that struct around. This comes up in a number of settings. There are various workarounds: sometimes you can use a vector with indices, for example, or the owning_ref crate. The latter, when combined with associated type constructors, might be an adequate solution for some uses cases, actually (it’s basically a way of modeling “existential lifetimes” in library code). For the case of futures especially, the ?Move RFC proposes another lightweight and interesting approach.

Categorieën: Mozilla-nl planet

Mozilla Marketing Engineering & Ops Blog: MozMEAO SRE Status Report - July 11, 2017

di, 11/07/2017 - 02:00

Here’s what happened on the MozMEAO SRE team from July 5th - July 11th.

This weeks report is brief as the team is returning from the Mozilla San Francisco All Hands and vacation.

Current work Static site hosting Kubernetes
  • Our main applications are being moved to our new Frankfurt Kubernetes cluster.
Categorieën: Mozilla-nl planet

J.C. Jones: Cutting over Let's Encrypt's Statistics to Map/Reduce

ma, 10/07/2017 - 22:54

We're changing the methodology used to calculate the Let's Encrypt Statistics page, primarily to better cope with the growth of Let's Encrypt. Over the past several months it's become clear that the existing methodology is less accurate than we had expected, over-counting the number of websites using Let's Encrypt, and the number of active certificates. The new methodology is more easily spot-checked, and thus, we believe, is more accurate.

We're planning to soon cut-over all data in the Let's Encrypt statistics dataset used for the graphs, and use the new and more accurate data from 3 July 2017 onward. Because of this the data and graphs will show that between 2 and 3 July the count of Active Certificates will fall ~14%, and the count of Registered Domains and Fully-Qualified Domain Names each also fall by ~7%.

Growth Discontinuity

You can preview the new graphs at, as well as look at the old and new datasets, and a diff.

Shifting Methodology

These days I volunteer to process the Certificate Transparency logs for Let's Encrypt's statistics.

Previously, I used a tool to process Certificate Transparency logs and insert metadata into a SQL database, and then made queries against that SQL database to derive all of the statistics we display and use for Let's Encrypt's growth. As the database size has gotten larger, it has been increasingly expensive to maintain. The SQL methodology wasn't intended for long-term statistics, but as with most established infrastructure, it was difficult to carve out the time needed to revamp it.

The revamp is finally ready, using a Map/Reduce approach that can scale much further than a SQL database.

Why did the old way overcount?

Some of the domain overcounting appears to have been due to domains issued SAN-certificates sometimes not being purged when those certificates expire without being renewed. This only happens in cases where the domains are part of a SAN cert, and then the SAN cert is re-issued with a somewhat different set of domains. Those removed, while expired, were still counted. It appears that this seeming-edge case happened quite a lot for some hosting providers.

The active certificate overcounting is in-part due to timing of new certificates being added during nightly maintenance being essentially double-counted. Jacob pointed out that if Let's Encrypt had average issuance, for every hour maintenance takes, the active certificate count would inflate by ~5%. Maintenance with the SQL code took between 1 and 4 hours to complete each night, so this could easily account for the discrepancy in the active certificate count.

There are likely other more subtle counting errors, too.

How do we know it's better now?

The nature of the new Map/Reduce effort produces discrete lists of domains for each issuance day, which are more easily inspected for debugging, so I feel more confident in it. These domain lists are also available as (huge) datasets (which I should move to S3 for performance reasons) at Line counts in the "FQDN" and "RegDom" lists should match the figures for the most recent day's entry. At least, so far they have...

Reprocessing historical logs?

It's technically possible to re-process the historical data in Certificate Transparency for Let's Encrypt to ensure more accuracy, but I've not yet decided whether I will do this. All the data and software is public, so others could perform this effort, if desired.

Technical Details

The SQL effort moved around through 2016 from various hosting providers to get the best deal on RAM to keep the growing database in check, ultimately moving to Amazon's RDS last winter. A single db.r3.large RDS instance is handling the size well, but is quite expensive for this use case.

The new Map/Reduce effort is currently on a single Amazon m4.xlarge EC2 instance with 150 GB of disk space to hold the 90 days of raw CT log information, the daily summary files, and the 90-day summaries that populate the statistics. This EC2 instance only needs to run about 2 hours a day to catch-up on Certificate Transparency, and then produce the resulting data set. When it needs to scale upward again, I'll likely move to an Apache Spark cluster.

We'll see how fast Let's Encrypt needs it. :)

(Also posted at

Categorieën: Mozilla-nl planet

Air Mozilla: Mozilla Weekly Project Meeting, 10 Jul 2017

ma, 10/07/2017 - 20:00

Mozilla Weekly Project Meeting The Monday Project Meeting

Categorieën: Mozilla-nl planet

Mozilla Reps Community: Reps Mobilizer Experiment

ma, 10/07/2017 - 15:25

During the second quarter of 2017, and in order to understand how to better identify, recruit and support mobilizers, we decided to run a small experiment with a reduced set of existing “best in class” mobilizers and walk with them during their work supporting technical communities.


Reps program is a program for core mobilizers, who create, grow, sustain and engage communities around Mozilla projects. There are still improvement areas in order to become  a state of the art mobilizer program, so we wanted to identify which are these areas and which are the changes we can implement.


Bob Chao (Taiwan) – WebVR

Long time contributors, Bob has been empowering and growing different Mozilla related communities in Taiwan, more recently Rust and WebVR.

Full Report


Srushtika Neelakantam (India) – WebVR

Deeply involved with the WebVR community since its formation, Srushtika has been empowering the local community in India for a few years now. She has even wrote a book about WebVR.

Full Report


Daniele Scasciafratte (Italy) – WebExtensions

Extremely involved contributors, Daniele has been supporting the community in Italy for many years. He has been key to develop the first Addons activity for the MozActivate campaign.

Full Report

Vigneshwer Dhinakaran (India) – Rust

He has been key for the formation and growth of the Rust community in India, he is author of a book about the technology.

Full Report


Process Overview

We decided to use a human centered design approach to test this hypothesis. Each project started with a research phase followed by multiple iterations of potential solutions. Each iteration involved testing, reflecting on the learnings and iterating on the approach.

Overall main learnings
  1. A certain degree of understanding of the technology is needed for the mobilizer to be truly effective and understand the communities.
  2. It’s key to devote enough time to do research and understand the local environment and the potential contributors needs
    1. After a solid research, we can start thinking on which are and implement the best channels for communications between the community (sync and async) as well as information distribution (announces, materials…)
  3. There are two important areas when working with technical communities:
    1. Getting people excited about the tech and the community
    2. Keeping people engaged after the main activities take place. The top priority should be designing for the follow-up instead of the activity.
  4. Establishing a direct conversation between mobilizers and the functional area staff is key for having a correct direction and impactful outputs.
    1. Teams that work with more closed tools (slack) presented a bigger challenge

As a result of these learnings we will evaluate a set of recommendations to improve the Reps program and we will share with some early ideas soon on the Reps discourse.

Thank you Vigneshwer, Daniele, Srushtika and Bob, your work is an inspiration to all Reps and to the rest of Mozilla, you have demostrated strong leadership and an impact-oriented strategy thinking that will help others to follow your steps.

Categorieën: Mozilla-nl planet

Mozilla Open Design Blog: Zilla Slab: A common language through a shared font

ma, 10/07/2017 - 13:00

How do the rules change when you design in the open? That is a question I asked myself many times as I prepared to join the Mozilla brand team back in November 2016. Having never worked in an open source company, I knew that I would need to prepare myself for a mental shift.

Brand design systems are often managed tightly by internal creative teams, with strict guidelines. The guidelines,  are shared like canons, with outside agencies. At Mozilla, we pride ourselves on our relationship to a passionate community of volunteers who outnumber our employees 10 to 1. With this community, strict control doesn’t work, but we still need to provide a design system that includes their views and results in better designs. Here’s a conversation discussing the process with Yuliya Gorlovetsky, Mozilla’s Associate Creative Director and font expert Peter Biľak of Typotheque who helped with the font design.

Tools not rules

Logo refinement from Johnson Banks and Fontsmith.

Yuliya: When I joined the Mozilla brand team, the new identity was close to completion. The concept relied heavily on typography, and Johnson Banks had chosen a slab serif for the logo. Slab serifs are the less common and less well known serifs. They are often bold, sharper, and have strong personality. We saw an opportunity for Mozilla to build on this by creating a custom font to support the new identity system – a distinct typeface for the identity refresh that we planned to open source for all to use.

Jordan Gushwa, a Creative Lead at Mozilla Foundation, and I both agreed that adding an elegant yet flexible slab serif would help us refine the brand. It would allow us to design experiences that lead with typography and written messages, akin to experiences that you might find in lifestyle magazines or design publications when the opportunity presented itself. Mozilla is investing in content creation, as it becomes more important today to tell the stories about how we stay safe and connected on the web.

To develop the Zilla Slab, we worked with Peter Biľak and Nikola Djurek from Typotheque. We respected their work and valued their expertise in multi-language support. I remember that Peter was surprised during our first call when I said we were interested in Slab Serifs that would be at home in top notch magazines or web publications. He happily added those options to our font explorations.

Peter: Slab serif typefaces, sometimes called Egyptians, are usually angular and robust in construction. They hint at a technological underpinning, with aesthetics that are characteristic of the early 19th century Industrial Revolution.

When Yuliya called us at Typotheque, the decision had already been made to use a Slab serif typeface. I wanted to understand the rationale and possibly consider alternatives. Quickly I came to understand that this was a well-informed decision, looking for less explored areas of typeface categorisation.

Yuliya: Peter pulled together multiple options of baseline slab serifs from his catalog and showed us how they could evolve to support our logo design needs. Looking for a font that could flex from display to body copy, we quickly settled on Tesla as our base font. Tesla had a good balance of original details but also the evenness that would support a variety of subject matter.


Getting into the details

At the start, the main focus was was on the logotype. Peter kept us accountable by illustrating the impact that the decisions we made for the logotype letters would have on the full font family. When showing different logo options, he would extract the letters from the logo and show how the different design decisions would show up in other letters in a typeface.

This way we could consider side by side, not only the logo, but the full typeface we would have. It was a hard line to walk. You want to just focus on the logo, because that is the combination of letters that will appear time and time again, but since we wanted the logo to connect to the font, we had to find a place of compromise. We needed to make decisions that equally supported both, the logo and the font. Most of the exploration played out in the three main letters: m, z, and a. It’s amazing how many people will ask if they can stop coming to meetings when you talk through 10 different ‘a’ options.

Peter: We looked at various Slab Serif models. Earlier models proposed by Johnson Banks, which were typical heavy geometric Slabs, and then we looked at Sans serif typefaces and considered turning them into Slabs. From our collection we looked at Irma Text Slab, Charlie, Lumin, Zico, before settling on Tesla Slab as a starting point. Perhaps too much detailed information here? Yuliya was intrigued by models  that exhibited unusual traits —  shifted axes of contrast of thick and thin strokes, based on cursive writing rather than geometric construction, or even an asymmetric serif structure. The lowercase ‘a’ is a more complex letter that provides clues to how other letters may look in a full exploration of the logotype. We wanted to bring an angled stroke to the top of the ‘a’, mimicking the slashes of the internet protocol. The other letters would then need to follow the same construction principles.

Yuliya: We were able to narrow it down to two design directions:

  1. A dressed down simplified slab font with a more geometric “a”. Geometric fonts are created from basic shapes, such as straight, monolinear lines and circular shapes. They lack ornamentation, and rarely appear with serifs. This “a”, that we considered, was more round, upright, and had no serif on the end.
  2. A more serifed font that had a more humanist “a” with a very pronounced serif. Humanist serifs are the very first kind of Roman typeface. The letters were originally drawn with a pen held at a consistent angle, creating a consistent visual rhythm. This “a”, that we considered, had a very pronounced two-level serif, that was tilted at a slight angle to respond to the “/”  that came before it.


Peter: Most of the Slab typefaces are static and geometric in construction. “Static” refers here to the axis of contrast. When the axis is 0 degree, typefaces are usually described as static. When there is an angle, they became ‘dynamic’. We experimented with injecting more humanistic values into the traditional Slab model, with the help of more calligraphic stroke terminations, which not only improve legibility but create a more flowing rhythm of letter shapes.

Yuliya: After much debate and 35 rounds of review, we had narrowed the directions down to 2 top choices. We then guerilla tested on folks, we showed the 2 directions to some folks within Mozilla, and some colleagues and friends outside of Mozilla and asked which one they gravitated towards and why. We also asked folks what emotions the different directions inspired in them. These conversation gave us the insight to proceed with the more humanist version, but to simplify the serif on the “a”. The result was an overall simplification of the font, which we lovingly call Zilla Slab. We think that Zilla Slab is a casual and contemporary slab serif that still has a good amount of quirk.

We launched the logo in the middle of January, and applied it to just a few assets; web headers, signage around the office and some print applications. After the launch, Peter and his team continued to work with us through the details of the full font family. Peter regularly shared the progress, which we in turn shared with many designers and fellow type enthusiasts across Mozilla. Turns out a lot of folks across Mozilla self identify as type nerds!

Sophisticated italics

Italics came next, and they are graceful and sharp. As a humanist slab, the Zilla Slab italics are closer to a true italics and add a softness to the overall typography system. There are moments when I’m reviewing work and I have to pause and stare at the curved slant detail in the v, w, x, and y of the italics letters.

Peter: Italics are generally not used for longer texts.  The function of italics is to emphasise short passages, so they offer more space for expression. Since we aimed to make Zilla Slab a more affable typeface with humanistic elements, the Italics offered an opportunity to go fully in that direction. We based the Italic not on a slanted Roman, but on a cursive broad-nib writing style. Diagonals in italic often break the rhythm of writing, so we introduced curved diagonals that work well with cursive italic by maintaining a smoother flow.


Building in the highlight effect

Yuliya: Johnson Banks originally modeled the highlight effect for the identity system on the functional act of highlighting a piece of type with your mouse on a screen or within software, or code inspector.

From the original guideline from Johnson Banks. The red rectangle is the size of the colon rectangle in the logo.


We continued to expand and ask people for feedback on the identity system internally. As we put it to use we quickly discovered that typing out the words and manually drawing out the highlight box to contain those letters not only took a lot of effort, but also created visual inconsistencies. Sizing the letters and the highlight box separately and having them come together in the same way time and time again, requires a lot of math and visual tuning. Following our idea of focusing on tools that enable people rather than rules that restrict, we asked Typotheque to create a true highlight version of Zilla Slab. The highlight weight would show the counter shapes between letters rather than the letterforms themselves. These additional weights of Zilla Slab make it easy for anyone to contribute to the brand identity and not to be limited by design software or design knowledge. Building the logic and rules into the font makes it a seamless part of the system.

Peter: Crafting a wordmark or a logo is usually a different process from developing a functional typeface. as Wordmarks can create more context specific design and brand solutions, which may not work well in a font. With Zilla Slab, we worked on a wordmark and the typeface at the same time, and had to anticipate how the wordmark features could be translated to other glyphs not present in the original wordmark. This extended possibly to other writing scripts.

Typing “Mozilla” in Zilla Slab Highlight Bold


Yuliya: The final touch on making the font a completely functional tool for the brand started by asking Peter if it would be possible to automate Zilla Slab so that it would be possible to type out the Mozilla logo using the bold highlight weight of the Zilla Slab. This would allow browsers and native applications to  turn “Mozilla” automatically into “moz://a” in specific cases. This would free people from needing to place and attach a static image version of the file, and frees us from managing those files. A logo for an open source company, typed out in its open source font.

Peter: Since the Zilla font is used to create the new Mozilla logo, we included the OpenType substitution feature triggered by the Ligature function that replaces the ‘ill’ letters by ‘://”. This should only replace the “ill” when intended —  not in a word ‘illustration’, but always in mozilla or ‘Mozilla’, for example.


Looking Ahead

Design work from the design team. Special attribution to Patrick Crawford.


Over five months of development, as Peter’s team worked through the font details, our design team worked in parallel to test Zilla Slab in a broad range of design applications. It has proven to be as unique and flexible as we had hoped it would be. Zilla Slab has taken its place as the unifying component of our design system. After all, it’s through typography that we see language, and at Mozilla we all have a lot to say.

The roll out of Zilla Slab has also helped to unite our different design teams and give all of our Mozilla contributors a shared visual voice. We are launching Zilla Slab with support for 70 European Latin based languages, and we can’t wait to continue our work with Typotheque and localize it to additional alphabets.

This is one of our first shared tools within our identity system. We will keep adding more tools, writing about them, and designing these tools in the open with you.

Download Zilla Slab on Github or Google Fonts.

The post Zilla Slab: A common language through a shared font appeared first on Mozilla Open Design.

Categorieën: Mozilla-nl planet

Mozilla VR Blog: Easily customized environments using the Aframe-Environment-Component

ma, 10/07/2017 - 12:23
Easily customized environments using the Aframe-Environment-Component

Get a fresh and new environment for your A-Frame demos and experiments with the aframe-environment component!

Just include the aframe-environment-component.min.js component in your html file, add an <a-entity environment></a-entity> to your <a-scene>, and voila!

Easily customized environments using the Aframe-Environment-Component

<html> <head> <script src="path/to/aframe.js"></script> <script src="path/to/aframe-environment-component.js"></script> </head> <body> <a-scene> <a-entity environment><a-entity> </a-scene> </body> </html>

The component generates a new environment with presets for lights and geometry. These presets can be easily customized by using the inspector (ctrl + alt + i) and tweaking the individual values until you find the look you like. Presets are a combination of property values that define a particular style, they are a starting point that you can later customize:

<a-entity environment="preset: goldmine; sunPosition: 1 5 -2; groundColor: #742"><a-entity>

You can view and try all the presets from the aframe-environment-component example page.

And of course, the component is fully customizable without a preset:

<a-entity environment="skyType: gradient; skyColor: #1d7444; horizonColor: #7ae0e0; groundTexture: checkerboard; groundColor: #523c60; groundColor2: #544264; dressing: cubes; dressingAmount: 15; dressingColor: #7c5c45"></a-entity>

TIP: If you are using the inspector and are happy with the look of your environment, open your browser's dev tools (F12) and copy the latest parameters from the console.

Customizing your environment

The environment component defines four different aspects of the scene: lighting, sky, ground terrain and dressing objects.

Lighting and mood

The lighting in your scene is easily adjusted by changing the sunPosition property. Scene objects will subtly receive a bounce light from the ground, and the color of the fog will also change to match the sky color at the horizon.

Easily customized environments using the Aframe-Environment-Component

To fully control the lighting of the scene, you can disable the environment lights with lighting: none, and you can set lighting: point if you want a point light instead of a distant light for the sun.

Add realism to your scene by adding shadows toggling on the shadow parameter and adding the shadow component on objects that should cast shadows onto the ground. Learn more about A-Frame shadows.

Sky and atmosphere

The 200m radius sky dome can have a basic color, a top-down gradient, or a realistic looking atmospheric look by using skyType: atmosphere sky type. Lowering the sun near or below the horizon will give you a starry night sky.

Ground terrain

The ground is a flat subdivided plane that can be deformed to various different terrain patterns like hills, canyons, or spikes. The appearance can also be customized by its texture and colors.

The center play area where the player is initially positioned is always flat, so nobody will get buried ;)

The grid property will add a grid texture to the ground and can be adjusted to different colors and patterns.

Dressing objects

A sky and ground with nothing more could be a little too simple sometimes. The environment component includes many families of objects that can be used to spice up your scene, including cubes, pyramids, towers, mushrooms and more. Among other parameters, you can adjust their variation using dressingVariance, or the ratio of objects that will be inside or outside the play area with dressingOnPlayArea.

All dressing objects share the same material and are all merged in one single geometry for better performance.

Easily customized environments using the Aframe-Environment-Component

Further customization

To see the full list of parameters of the component, check out GitHub's aframe-environment-component repository.

Help make this component better

We could use your help!

  • File github issues
  • Create a new preset
  • Share your presets! So anyone can copy/paste and even try live
  • Create new dressing geometries
  • Create new procedural textures
  • Create new ground types
  • Create new grid styles

Feel free to send a pull request to the repository!

Performance considerations

The main idea of this component is to have a complete and visually interesting environment by including a single Javascript file, with no extra includes or dependencies. This requires that assets have to be included into the Javascript or (in most cases) generated procedurally . Despite of the computing time and increased file size, both options are normally faster than requesting and waiting for additional textures or model files.

Apart from the parameter dressingAmount, there is not much difference among different parameters in terms of performance.

Categorieën: Mozilla-nl planet

Christian Heilmann: Debugging JavaScript – console.loggerheads?

za, 08/07/2017 - 19:35

The last two days I ran a poll on Twitter asking people what they use to debug JavaScript.

  • console.log() which means you debug in your editor and add and remove debugging steps there
  • watches which means you instruct the (browser) developer tools to log automatically when changes happen
  • debugger; which means you debug in your editor but jump into the (browser) developer tools
  • breakpoints which means you debug in your (browser) developer tools

The reason was that having worked with editors and developer tools in browsers, I was curious how much either are used. I also wanted to challenge my own impression of being a terrible developer for not using the great tools we have to the fullest. Frankly, I feel overwhelmed with the offerings and choices we have and I felt that I am pretty much set in my ways of developing.

Developer tools for the web have been going leaps and bounds in the last years and a lot of effort of browser makers goes into them. They are seen as a sign of how important the browser is. The overall impression is that when you get the inner circle of technically savvy people excited about your product, the others will follow. Furthermore, making it easier to build for your browser and giving developers insights as to what is going on should lead to better products running in your browser.

I love the offerings we have in browser developer tools these days, but I don’t quite find myself using all the functionality. Turns out, I am not alone:

The results of 3970 votes in my survey where overwhelmingly in favour of console.log() as a debugging mechanism.

Twitter pollPoll results: 67% console, 2% watches, 15% debugger and 16% breakpoints.

Both the Twitter poll and its correlating Facebook post had some interesting reactions.

  • As with any too simple poll about programming, a lot of them argued with the questioning and rightfully pointed out that people use a combination of all of them.
  • There was also a lot of questioning why alert() wasn’t an option as this is even easier than console().
  • There was quite some confusion about debugger; – seems it isn’t that common
  • There was only a small amount of trolling – thanks.
  • There was also quite a few mentions of how tests and test driven development makes debugging unimportant.

There is no doubt that TDD and tests make for less surprises and are good development practice, but this wasn’t quite the question here. I also happily discard the numerous mentions of “I don’t make mistakes”. I was pretty happy to have had only one mention of document.write() although you do still see it a lot in JavaScript introduction courses.

What this shows me is a few things I’ve encountered myself doing:

  • Developers who’ve been developing in a browser world have largely been conditioned to use simple editors, not IDEs. We’ve been conditioned to use a simple alert() or console.log() in our code to find out that something went wrong. In a lot of cases, this is “good enough”
  • With browser developer tools becoming more sophisticated, we use breakpoints and step-by-step debugging when there are more baffling things to figure out. After all, console.log() doesn’t scale when you need to track various changes. It is, however, not our first go-to. This is still adding something in our code, rather than moving away from the editor to the debugger
  • I sincerely hope that most of the demands for alert() were in a joking fashion. Alert had its merits, as it halted the execution of JavaScript in a browser. But all it gives you is a string and a display of [object object] is not the most helpful.
Why aren’t we using breakpoint debugging?

There should not be any question that breakpoint debugging in vastly superior to simply writing values into the console from our code:

  • You get proper inspection of the whole state and environment instead of one value
  • You get all the other insights proper debuggers give you like memory consumption, performance and so on
  • It is a cleaner way of development. All that goes in your code is what is needed for execution. You don’t mix debugging and functionality. A stray console.log() can give out information that could be used as an attack vector. A forgotten alert() is a terrible experience for our end users. A forgotten “debugger;” or breakpoint is a lot less likely to happen as it does pause execution of our code. I also remember that in the past, console.log() in loops had quite a performance impact of our code.

Developers who are used to an IDE to create their work are much more likely to know their way around breakpoint debugging and use it instead of extra code. I’ve been encountering a lot of people in my job that would never touch a console.log() or an alert() since I started working in Microsoft. As one response of the poll rightfully pointed out it is simpler:

It's even longer to write console.log than to put a breakpoint...

— Chen Eshchar (@cheneshchar) July 6, 2017

So, why do we then keep using console logging in our code rather than the much more superior way of debugging code that our browser tooling gives us?

I think it boils down to a few things:

  • Convenience and conditioning – we’ve been doing this for years, and it is easy. We don’t need to change and we feel familiar with this kind of back and forth between editor and browser
  • Staying in one context – we write our code in our editors, and we spent a lot of time customising and understanding that one. We don’t want to spend the same amount of work on learning debuggers when logging is good enough
  • Inconvenience of differences in implementation – whilst most debuggers work the same there are differences in their interfaces. It feels taxing to start finding your way around these.
  • Simplicity and low barrier of entry – the web became the big success it is by being independent of platform and development environment. It is simple to show a person how to use a text editor and debug by putting console.log() statements in your JavaScript. We don’t want to overwhelm new developers by overloading them with debugger information or tell them that they need a certain debugging environment to start developing for the web.

The latter is the big one that stops people embracing the concept of more sophisticated debugging workflows. Developers who are used to start with IDEs are much more used to breakpoint debugging. The reason is that it is built into their development tools rather than requiring a switch of context. The downsides of IDEs is that they have a high barrier to entry. They are much more complex tools than text editors, many are expensive and above all they are huge. It is not fun to download a few Gigabyte for each update and frankly for some developers it is not even possible.

How I started embracing breakpoint debugging

One thing that made it much easier for me to embrace breakpoint debugging is switching to Visual Studio Code as my main editor. It is still a light-weight editor and not a full IDE (Visual Studio, Android Studio and XCode are also on my machine, but I dread using them as my main development tool) but it has in-built breakpoint debugging. That way I have the convenience of staying in my editor and I get the insights right where I code.

For a node.js environment, you can see this in action in this video:

Are hackable editors, linters and headless browsers the answer?

I get the feeling that this is the future and it is great that we have tools like Electron that allow us to write light-weight, hackable and extensible editors in TypeScript or just plain JavaScript. Whilst in the past the editor you use was black arts for web developers we can now actively take part in adding features to them.

I’m even more a fan of linters in editors. I like that Word tells me I wrote terrible grammar by showing me squiggly green or red underlines. I like that an editor flags up problems with your code whilst you code it. It seems a better way to teach than having people make mistakes, load the results in a browser and then see what went wrong in the browser tools. It is true that it is a good way to get accustomed to using those and – let’s be honest – our work is much more debugging than coding. But by teaching new developers about environments that tell them things are wrong before they even save them we might turn this ratio around.

I’m looking forward to more movement in the editor space and I love that we are able to run code in a browser and get results back without having to switch the user context to that browser. There’s a lot of good things happening and I want to embrace them more.

We build more complex products these days – for good or for worse. It may be time to reconsider our development practices and – more importantly – how we condition newcomers when we tell them to work like we learned it.

Categorieën: Mozilla-nl planet

Mozilla Localization (L10N): New L10n Report: July Edition

za, 08/07/2017 - 02:08

Please note some of the information provided in this report may be subject to change as we are sometimes sharing information about projects that are still in early stages and are not final yet.


New localizers:

Are you a locale leader and want us to include new members in our upcoming reports? Contact us!

New community and locales added
  • azz (Sierra Puebla Nahuatl): it was onboarded in recent months and already made a lot of progress.
  • be (Belarusian): when we sadly had to drop Belarusian from our desktop and mobile builds due to inactivity, new contributors immediately contacted us to revive localization work. A big shout-out to this newly formed community!
  • Tg (Tajik): successfully localized their first project, Thimble!
New content and projects What’s new or coming up in Firefox desktop

Big changes are coming to Firefox 57, with some of them sneaking up even in 56 (the version currently localized in Nightly, until August 7). The new feature with more significant impact for localization is the new Onboarding experience: it consists of both an Onboarding overlay (a tour displayed by clicking the fox icon in the New tab), and Onboarding notifications, displayed at the bottom of New tab.

If you haven’t seen them yet (we always make sure to tweet the link), we strongly suggest to read the latest news about Photon in the Photon Engineering Newsletter (here’s the latest #8).

On a side note, you should be using Nightly for your daily browsing, it’s exciting (changes every day!) and fundamental to ensure the quality of your localization.

There is a bug on file to stop localizing about:networking, given how small the target is (users debugging network issues) and how obscure some of these strings are.

A final reminder: The deadline to update Firefox Beta is July 25. Remember that Firefox Beta should mainly be used to fix small issues, since new translations added directly to Beta need to be manually added to the Nightly project in your localization tools.

What’s new or coming up in Test Pilot

The new set of experiments, originally planned for July 5, has been moved to July 25. Make also sure to read this mail on dev-l10n if you have issues testing the website on the dev server.

What’s new or coming up in mobile
  • Mobile (both Android and iOS projects) is going to align with the visual changes coming up on desktop by getting a revamped UI thanks to Photon. Check it out!
    • Firefox for Android Photon meta-bug.
    • Please note that due to the current focus on desktop with Firefox 57, Firefox for Android work is slower than usual. Expect to see more and more Photon updates on Nightly builds though as time passes by.
  • We recently launched Focus for Android v1 with 52 languages! Have you tried it out yet? Reviews speak for themselves. Expect a new release soon, and with that, more locales (and of course, more features and improvements to the app)!
  • Mobile experiments are on the rise. The success of Focus is paving the way to many other great mobile projects. Stay tuned on our mailing list because there just may be cool stuff arriving very soon!
What’s new or coming up in on web projects
  • With the new look and feel, a new set of Firefox pages and unified footer were released for l10n. Make sure to localize firefox/shared.lang before localizing the new pages. Try to complete these new pages before deadline or the pages will redirect to English on August 15
  • Monthly snippets have expanded to more locales. Last month, we launched the first set in RTL locales: ar, fa, he, and ur. The team is considering creating regional specific snippets.
  • A set of Internet Health pages were launched. Some recent updates were made to fit the new look and layout. Many communities have participated in localizing some or all pages.
  • The newly updated Community Participation Guideline is now localized in six languages: de, es, fr, hi-IN, pt-BR, and zh-TW. Thanks to the impacted communities for reviewing the document before publishing.
  • Expect more updates of existing pages in the coming months so the look and feel are consistent between pages.
What’s new or coming up in Foundation projects
  • Thimble, the educational code editor, got a makeover and new useful features, that all got localized in more than 20 locales.
  • The fundraising campaign will start ramping up earlier than November this year, so it’s a great idea to make sure the project is up-to-date for your locale, if it isn’t already.
  • The EU Copyright campaign is in slow mode over the summer while MEPs are on holiday, but we will rock again full speed in September before committees are voting
  • We will launch an Internet of Things survey over the summer to get a better understanding of what people know about IoT.
Newly published localizer facing documentation Events
  • Next l10n workshop will be in Asuncion, Paraguay (August)
  • Berlin l10n workshop is coming up in September!
  • Want to showcase an event coming up that your community is participating in? Reach out to any l10n-driver and we’ll include that (see links to emails at the bottom of this report)
Opportunities Accomplishments Some numbers Friends of the Lion

Image by Elio Qoshi

  • Shout-out to all Mozilla RTL communities who have been doing a great job at filing and fixing bugs on mobile – as well as providing much needed feedback and insights during these past few months! Tomer, Reza, ItielMaN, Umer, Amir, Manel, Yaron, Abdelrahman, Yaseen – just to name a few. Thank you!
  • Thanks to Jean-Bernard and Adam for jumping in to translate the new Firefox pages in French.
  • Thanks to Nihad of Bosnian community for leading the effort in localizing the site that is now on production.
  • A big thank you to Duy Thanh for his effort in rebuilding the Vietnamese community and his ongoing localization contribution.
  • kab (Kabyle) community started a while back, their engagement is impressive in all products and projects.

Know someone in your l10n community who’s been doing a great job and should appear here? Contact on of the l10n-drivers and we’ll make sure they get a shout-out (see list at the bottom)!

Useful Links Questions? Want to get involved?

Did you enjoy reading this report? Let us know how we can improve by reaching out to any one of the l10n-drivers listed above.

Image by Slip Premier, Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0)

Categorieën: Mozilla-nl planet

Smokey Ardisson: iOSify Bookmarklets and adding bookmarklets on iOS

za, 08/07/2017 - 01:14

I don’t do much web browsing on iOS (I just can’t handle the small screen), but I do visit a number of sites regularly, some of which do stupid things that make them annoying or hard to use, especially in Mobile Safari. On the desktop, it’s usually easy to “fix” these annoyances with a bit of JavaScript or CSS or a quick trip to the Document Inspector, but none of these are readily available on iOS. Fortunately, however, bookmarklets still work in Mobile Safari.

Unfortunately, though, adding bookmarklets to Mobile Safari is cumbersome at best. Unless you sync all of your bookmarks from the desktop, it’s almost impossible to add a bookmarklet to Mobile Safari unless the bookmarklet’s author has done some work for you. On the desktop, you’d typically just drag the in-page bookmarklet link to your bookmarks toolbar and be done, or control-/right-click on the in-page bookmarklet link and make a new bookmark using the context menu. One step, so simple a two-year-old could do it. The general process of adding a bookmarklet to Mobile Safari goes like this:

  1. Bookmark a page, any page, in order to add a bookmark
  2. Manually edit the aforementioned bookmark’s URL to make it a bookmarklet, i.e. by pasting the bookmarklet’s code
  3. Fun! :P

To make things slightly easier, Digital Inspiration has a collection of common bookmarklets that you can bookmark directly and then edit back into functioning bookmarklets.1 It’s still two steps, but step 2 becomes much simpler (probably a five-year-old could do it). This is great if Digital Inspiration has the bookmarklet you want (or if the bookmarklet’s author has included an “iOS-friendly” link on the page), but what if you want to add Alisdair McDiarmid’s Kill Sticky Headers bookmarklet?

To solve that problem, I wrote “iOSify Bookmarklets”—a quick-and-dirty sort-of “meta-bookmarklet” to turn any standard in-page bookmarklet link into a Mobile Safari-friendly bookmarkable link.

Once you add iOSify Bookmarklets to Mobile Safari (more on that below), you tap it in your bookmarks to covert the in-page bookmarklet link into a tapable link, tap the link to “load” it, bookmark the resulting page, and then edit the URL of the new bookmark to “unlock” the bookmarklet.

Say you’re visiting and it has a bookmarklet, bar, that you want to add to Mobile Safari.

  1. Open your Mobile Safari bookmarks and tap iOSify Bookmarklets. (The page appears unchanged afterwards, but iOSify Bookmarklets did some work for you.)
  2. Tap the in-page link to the bookmarklet (bar) you want to add to Mobile Safari. N.B. It may appear again that nothing happens, but if you tap the location bar and finger-scrub, you should see the page’s URL has been changed to include the code for the “bar” bookmarklet after a ?bookmarklet# string.
  3. Tap the Share icon in Mobile Safari’s bottom bar and add the current page as a bookmark; you can’t edit the URL at this point, so just choose Done.
  4. Tap the Bookmarks icon, then Edit, then the bookmark you just added. Edit the URL and delete everything before the javascript: in the bookmark’s URL. (Tap Done when finished, and Done again to exit editing mode.)

The “bar” bookmarklet is now ready for use on any page on the web.

Here’s an iOS-friendly bookmarkable version of iOSify Bookmarklets (tap this link, then start at step 3 above to add this to Mobile Safari): iOSify Bookmarklets

The code, for those who like that sort of thing:

I hope this is helpful to someone out there :-)


1 For the curious, Digital Inspiration uses query strings and fragments in the URL in order to include the bookmarklet code in the page URL you bookmark, and iOSify Bookmarklets borrows this method. ↩︎

Categorieën: Mozilla-nl planet

Mozilla VR Blog: Link Traversal and Portals in A-Frame

vr, 07/07/2017 - 01:28
Link Traversal and Portals in A-Frame

Demo for the impatients (It requires controllers: Oculus, HTC Vive, Daydream or GearVR)

A-Frame 0.6.0 and Firefox Nightly now support navigating across pages while in VR mode. WebVR has finally earn the Web badge. The Web gets its name from the structure of interconnected content that uses the link as the glue. Until now, The VR Web was fragmented and had to be consumed in bite size pieces since the VR session was not preserved on page navigation. In the first iteration of the WebVR API we focused on displaying pixels and meet the performance requirements on a single page. Thanks to the efforts of Doshheng Mu and Kip, Firefox Nightly now also ships the mechanism that enables a seamless transition between VR sites.

Link Traversal and Portals in A-Frame

Link traversal in VR relies on the onvrdisplayactivate event. It is fired on the window object on page load if the precedent site was presenting content in the headset.

To enter VR mode for the first time, the user is expected to explicitly trigger VR mode with an action like mouse click or a keyboard shortcut to prevent sites to take control of the headset inadvertently. Once VR is engaged subsequent page transitions can present content in the headset without further user intervention. A page can be granted permissions to enter VR automatically by simply attaching an event handler:

window.addEventListener('vrdisplayactivate' function (evt) { /* A page can now start presenting in the headset */ vrDisplay.requestPresent([{ source: myCanvas }]).then(function () { ... }); } Links in A-Frame

A-frame 0.6.0 ships with a link component and a-link primitive. The link component can be configured in several ways:

<a-entity link="href: index.html; title:My Home; image: #homeThumb"></a-entity> PropertyDescription hrefURL where the link points to titleText displayed on the link. href is used if not defined onevent that triggers link traversal image360 panorama used as scene preview in the portal colorBackground color of the portal highlightedtrue if the link is highlighted highlightedColorcolor used to highlight the link visualAspectEnabledenable/disable the visual aspect if you want to implement your own

The a-link primitive provides a compact interface that feels like the traditional <a> tag that we are all used to.

<a-link href="index.html" image="#thumbHome" title="my home"></a-link>

The image property points to the <img> element that will be used as a background of the portal and the title is the text displayed on the link.

The UX of VR links

Using the wonderful art of arturitu, both the A-Frame component and primitive come with a first interpretation on how links could be visually represented in VR. It is a starting point for an exciting conversation that will develop in the next years.

Our first approach addresses several problems we identified:

Links visual aspect should be consistent.

So users can quickly identify the interconnected experiences at a glance. Thanks to kip's shader wisdom we chose a portal representation that gives each link a distinct look representative of the referenced content. A-Frame provides a built in screenshot component to easily generate the 360 panoramas necessary for the portal preview.

Link Traversal and Portals in A-Frame

Links should be useful at any distance.

Portals help discriminate between links in the proximity but the information becomes less useful in the distance. From far away, portals alone can be difficult to spot because they might blend with the scene background or become hard to see at wide angles. To solve the problem, we made links fade into a solid fuchsia circle with a white border that grows in thickness with the distance so all the links have a consistent look (colors are configurable). Portals will also face the camera to avoid wide angles that reduce the visible surface.

Link Traversal and Portals in A-Frame

Link Traversal and Portals in A-Frame

Links should provide information about the referenced experience.

One can use the surrounding space to contextualize and give a hint where the link will point to. In addition, links themselves display either the title or the url that they refer to. This provides additional information to the user about the linked content.

Link Traversal and Portals in A-Frame

There should be a convenient way to explore the visible links.

While portals are a good way to preview an experience it can be hard to explore the available options if the user has to move around the scene to inspect the links one by one. We developed a peek feature that allows the user to point to any link and quickly zoom into the preview without having to move.

Link Traversal and Portals in A-Frame

Next steps

One of the limitations of the current API is that a Web Developer needs to manually point to the thumbnails that the links use to render the portals. We want to explore a way, via meta tags, web manifest or other conventions for a site to provide the thumbnail for 3rd party links to consume. This way a Web Developer has more control on how her website will be represented in other pages.

Another rough edge is what happens when after navigation a page takes a lot time to load or ends up in an error. There's no way at the moment to inform the user of those scenarios while keeping the VR headset on. We want to explore ways for the browser itself to intervene in VR mode and keep the user properly informed at each step when leaving, loading and finally navigating to a new piece of VR content.


With in-VR page navigation we're now one step closer to materialize the Open Metaverse on top the existing Web infrastructure. We hope you find our link proposal inspiring and sparks a good conversation. We don't really know how links will look like in the future: doors, inter-dimensional portals or exit burritos... We cannot wait to see what you come up with. All the code and demos are already available as part of the 0.6.0 version of A-Frame. Happy hacking!

Link Traversal and Portals in A-Frame

Categorieën: Mozilla-nl planet

Air Mozilla: Reps Weekly Meeting Jul. 06, 2017

do, 06/07/2017 - 18:00

Reps Weekly Meeting Jul. 06, 2017 This is a weekly call with some of the Reps to discuss all matters about/affecting Reps and invite Reps to share their work with everyone.

Categorieën: Mozilla-nl planet

The Mozilla Blog: New Research: Is an Ad-Supported Internet Feasible in Emerging Markets?

do, 06/07/2017 - 16:56
Fresh research conducted by Caribou Digital and funded by Mozilla explores digital advertising models in the Global South — whether they can succeed, and what that means for users, businesses, and the health of the Internet

Since the Internet’s earliest days, advertising has been the linchpin of the digital economy, supporting businesses from online journalism to social networking. Indeed, two of the five largest companies in the world — Facebook and Google — earn almost all of their revenue through digital advertising.

As the Internet reaches new users in India, Kenya, and elsewhere across the Global South, this model is following close behind. But is the digital advertising model that has evolved in developed economies sustainable in emerging economies? And if it’s not: What does it mean for the billions of users who are counting on the Internet to unlock new pathways to education, economic growth, and innovation?

Publishers see drastically less revenue per user in these regions, partly because low-income populations are less valuable to advertisers, and partly because constraints on the user experience — low-quality hardware, unreliable network coverage, and a dearth of local content — fundamentally limit how people engage with digital content and services.

As a result, users in emerging markets will have fewer choices, as local content providers and digital businesses will struggle to earn enough from their home markets to compete with the global platforms.

Today, we’re publishing “Paying Attention to the Poor: Digital Advertising in Emerging Markets.”

It’s fresh research conducted by Caribou Digital and funded by Mozilla that explores the barriers traditional digital advertising models face in emerging economies; the consequent impact on users, businesses, and the health of the Internet; and what new models are emerging.  

In summary:

Ad revenue-wise, there is an order-of-magnitude difference between users in developed economies and users in the Global South.

Facebook earns a quarterly ARPU (average revenue per user) of $1.41 in Africa and Latin America, and $2.07 in Asia-Pacific — an order of magnitude less than  the $19.81 it earns in the U.S. and Canada

As a result, just over half of Facebook’s total global revenue comes from only 12% of its users

The high cost of data in emerging markets is one driver of ad blocking

Due to prohibitive data costs and slower network speeds, many Internet users in emerging markets use proxy browsers, such as UC Browser or Opera Mini, which reduce data consumption and also block ads

One report by PageFair claims over 309 million users around the world used mobile ad blockers in 2016 — with 89 million hailing from India and 28 million hailing from Indonesia

A dearth of user data — or, the “personal data gap” — presents another challenge to advertisers.

In developed economies, data profiling and ad targeting has been a boon to advertisers. But in the Global South, people have much smaller digital footprints

Limited online shopping, a glut of open-source Android devices, and a tendency toward multiple, fragmented social media accounts dilutes the value of personal data to advertisers

Limited advertising revenue in emerging markets challenges local innovation and competition.

Publishers and developers follow the money. As a result, content is targeted to, and localized for, developed markets like the U.S. or Japan — even producers in emerging markets will ignore their domestic market in favor of more lucrative ones

Large companies like Facebook have the resources to subsidize forays into unprofitable markets; smaller companies do not. As a result, the reigning giants become further entrenched

A lack of local content can have deeply negative implications.

Availability of local content is a key demand-side driver for increasing Internet access for marginalized populations, and localized media can foster inclusion and support democratic institutions

But without viable economic models for supporting this content, opportunity is squandered. Presently, the majority of digital content — including user-generated content such as Wikipedia — is in English

The outlook for digital advertising-supported businesses in emerging markets is bleak.

Low monetization rates will continue to limit the types of Internet businesses that can flourish in the Global South

To succeed, businesses in the Global South have to build more strategically, working toward profitability (and not user growth) from the very beginning

These constraints demand new business model innovations for an Internet ecosystem that is evolving differently in the Global South

“Sponsored data” or “incentivized action” models which offer free data in return for engagement with an advertiser’s content are one approach to mitigating the access and affordability constraint

Transactional revenue models, such as those seen in digital financial services, will play an increasingly important role as payments infrastructure matures

You can read the full report here.

In the coming weeks and months, Mozilla and Caribou Digital will share our findings with allies across the Internet health space — the network of NGOs, institutions, and individuals who are working toward a more healthy web. We hope our learnings will help unlock innovative solutions that balance commercial success with openness and freedom online.

The post New Research: Is an Ad-Supported Internet Feasible in Emerging Markets? appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Robert O'Callahan: Bay Area Progress Report

do, 06/07/2017 - 08:15

I'm in the middle of a three-week work trip to the USA.

Monday last week I met with a couple of the people behind the Julia programming language, who have been using and contributing to rr. We had good discussions and it's good to put faces to names.

Monday night through to Friday night I was honoured to be a guest at Mozilla's all-hands meeting in San Francisco. I had a really great time catching up with a lot of old friends. I was pleased to find more Mozilla developers using rr than I had known about or expected; they're mostly very happy with the tool and some of them have been using esoteric features like chaos mode with success. We had a talk about rr and I demoed some of the new stuff Kyle and I have been working on, and talked about which directions might be most useful to Mozilla.

Saturday through Monday I went camping in Yosemite National Park with some friends. We camped in the valley on Saturday night, then on Sunday hiked down from Tioga Road (near the Lukens Lake trailhead) along Yosemite Creek to north of Yosemite Falls and camped there overnight. The next day we went up Eagle Peak for a great view over Yosemite Valley, then hiked down past the Falls back to the valley. It's a beautiful place and rather unlike any New Zealand tramping I've done — hot, dry, various sorts of unusual animals, and ever-present reminders about bears. There were a huge number of people in the valley for the holiday weekend!

Tuesday was a bit more relaxed. Being the 4th of July, I spent the afternoon with friends playing games — Bang and Lords of Waterdeep, two of my favourites.

Today I visited Brendan and his team at Brave to talk about rr. On Friday I'll give a talk at Stanford. On Monday I'll be up in Seattle giving a talk at the University of Washington, then on Tuesday I'll be visiting Amazon to talk about the prospects for rr in the cloud. Then on Wednesday through Friday I'll be attending Usenix ATC in Santa Clara and giving yet another rr talk! On Saturday I'll finally go home.

I really enjoy talking to people about my work, and learning more about people's debugging needs, and I really really enjoy spending time with my American friends, but I do miss my family a lot.

Categorieën: Mozilla-nl planet

Nicholas Nethercote: How we made compiler warnings fatal in Firefox

do, 06/07/2017 - 02:11

Compiler warnings are mostly good: they identify real problems, and when false positives do occur they are usually easy to work around. However, if they’re not fatal, they tend to be ignored and build up. (See bug 187528 for an idea!)

One way to prevent the build-up is to make them fatal, so they become errors. But won’t that cause problems? Not if you’re careful. Here’s how we did it for Firefox.

  • Choose with some care which warnings end up fatal. Don’t be afraid to modify your choices as time goes on.
  • Introduce a mechanism for enabling fatal warnings on a per-directory basis. Mozilla’s custom build system used to have a directive called FAIL_ON_WARNINGS for this purpose.
  • Set things up so that fatal warnings are off by default, but enabled on continuous integration (CI). This means the primary coverage is via CI. You don’t want fatal warnings on by default because it causes problems for developers who use non-standard compilers (e.g. pre-release versions with new warning classes). Developers using the same compilers as CI can turn it on locally if they want without problem.
  • Allow per-file exceptions for particular kinds of warnings, because there are occasionally warnings you just want to ignore.
  • Fix warnings one directory at a time, and turn on fatal warnings for that directory as soon as it’s warning-free.
  • Invert the sense of the per-directory mechanism once you’ve converted more than half of the directories. For Mozilla code we now have the ALLOW_COMPILER_WARNINGS directive. It’s almost exclusively used for directories containing third-party code which is not under our control.
  • Gradually expand the coverage of which compilers you have fatal warnings for. Mozilla code now does this for GCC, clang, and MSVC.
  • Congratulations! You now have fatal warnings on everywhere that is practical.

With a setup like this, it’s possible for a patch to compile on a developer’s machine but fail to compile on CI. But that’s just one of many ways in which full CI runs may fail when local runs don’t. So it’s not as bad as it seems.

Also, before upgrading the compilers on CI you need to address any new warnings, by fixing them or suppressing them or filing a compiler bug report. But this isn’t a bad thing.

It took a long time for Firefox to reach this stage, but I think it was worth the effort. Thank you to Chris Peterson and all the others who helped with this.

Categorieën: Mozilla-nl planet

Mozilla Marketing Engineering & Ops Blog: Kuma Report, June 2017

do, 06/07/2017 - 02:00

Here’s what happened in June in Kuma, the engine of MDN Web Docs:

  • Shipped the New Design to Beta Testers
  • Added KumaScript macro tests
  • Continued MDN data projects
  • Shipped tweaks and fixes

Here’s the plan for July:

  • Continue the redesign
  • Experiment with on-site interactive examples
  • Update localization of macros
  • Ship the sample database
Done in June Shipped the new design to beta testers

This month, we revealed some long-planned changes. First, MDN is focusing on web docs, which includes changing our identity from “Mozilla Developer Network” to “MDN Web Docs”. Second, we’re shipping a new design to beta users, to reflect Mozilla’s new brand identity as well as the MDN Web Docs brand.

Stephanie Hobson did a tremendous amount of work over 26 Kuma PRs and 2 KumaScript PRs to launch a beta of the updated design on wiki pages. A lot of dead code has been removed, and non-beta users continue to get the current design. Schalk Neethling reviewed the PRs as fast as they were created, including checking the rendering in supported browsers. Our beta users have provided a lot of feedback and found some bugs, which Stephanie has been triaging, tracking, and fixing.

This work continues in July, with an update to the homepage and other pages. When we’ve completed the redesign, we’ll ship the update to all users. If you want to see it early, opt-in as a beta tester.

Added KumaScript Macro Tests

Macros used to be tested manually, in production. After moving the macros to GitHub, they were still tested manually, but in the development environment. In June, Ryan Johnson added an automated testing framework, and tests for five macros, in PR 204. This allows us to mock the Kuma APIs needed for rendering, and to test macros in different locales and situations. This will help us refine and refactor macros in the future.

Continued MDN Data Projects

The MDN data projects were very busy in June, with 48 browser-compat-data PRs and 10 data PRs merged. MDN “writers” Florian Scholz, wbamberg, and Eric Shepherd have been converting MDN browser compatibility tables to JSON data, refining the schema and writing documentation. This is already becoming a community project, with almost half of the PRs coming from contributors such as Andy McKay (1 PR). Dominik Moritz (2 PRs), Roman Dvornov (6 PRs), Ng Yik Phang (2 PRs), and Sebastian Noack (16 PRs!).

The tools and processes are updating as well, to keep up with the activity. browser-compat-data gained a linter in PR 240. mdn-browser-compat-data’s npm package was bumped to version 0.0.2, and then 0.0.3. mdn-data was released as 1.0.0. We’re loading the browser-compat-data from the NPM package in production, and hope to start loading the data NPM package soon.

We’re happy with the progress on the data projects. There’s a lot of work remaining to convert the data on MDN, and also a lot of work to automate the process so that changes are reflected in production as quickly as possible.

Shipped Tweaks and Fixes

Here’s some other highlights from the 44 merged Kuma PRs in June:

Here’s some other highlights from the 31 merged KumaScript PRs in June:

Planned for July Continue the Redesign

Some of the styling for the article pages is shared across other pages, but there is more work to do to complete the redesign. Up next is the homepage, which will change to reflect our new focus on documenting the open web. Other pages will need further work to make the site consistent. When we and the beta testers are mostly happy, we’ll ship the design to all MDN visitors, and then remove the old design code.

Experiment with On-site Interactive Examples

We’re preparing some interactive examples, so that MDN readers can learn by adjusting the code without leaving the site. We’re still working out the details of serving these examples at production scale, so we’re limiting the July release to beta users. You can follow the work at mdn/interactive-examples.

Update Localization of Macros

Currently, KumaScript macros use in-macro localization strings and utility functions like getLocalString to localize output for three to five languages. Meanwhile, user interface strings in Kuma are translated in Pontoon into 57 languages. We’d like to use a similar workflow for strings in macros, and will get started on this process in July.

Ship the Sample Database

The Sample Database has been promised every month since October 2016, and has slipped every month. We almost had to break the tradition, but we can say again it will ship next month. PR 4248, adding the scrape_document command, shipped in June. The final code, PR 4076, is in review, and should be merged in July.

Categorieën: Mozilla-nl planet

Karl Dubost: Some random thoughts in San Francisco

do, 06/07/2017 - 01:09

We had a working business week for Mozilla All Hands. The big bi-annual meeting of the full company to work, discuss, cooperate and make wonderful things.

These are random notes not work related about thoughts accumulated during San Francisco week. What we notice in spaces and people are primary ourselves. It's often the start of a self-introspection more than anything else.

Meeting with my thoughts
  • crossing the border went smoothly. I was feeling good. No mobile device. Blank laptop.
  • Mission street areas from the bus. A bus of wealthy geeks watching the poor, the abandonned, the drifter from up there behind a window. It takes a blaze and spirit to start a revolution. The spirit is drowned inside the body.
  • This insecure feeling of the touristic areas when you never know if and when a driver will plow into the crowd or someone will draw a gun.
  • Chinatown is peaceful and calming environment for me. Something familiar, something I relate to.
  • The charm of the hills of San Francisco is a beautiful pain to my legs. The effort and the view are a gift.
  • Brands using pseudo-political messages to sell more stuff. Nauseous.
  • Exhausted.
  • Sleeping.
  • Plastic surgery is a thing.
  • Cable cars packed with tourists. Do locals still take the cable cars? Private buses to go to Silicon Valley. Dedicated transportation for tourists… What a broken world.
  • Noisy reception, rooms full of people too loud.
  • The emptiness of ads.
  • Long discussion with a friend walking across the San Francisco streets about everything, about nothing, about simple things. On the road, we share.
  • From coit tower, foggy dark Golden Gate vaporized in the horizon.
  • Sirens of fire trucks are frequent
  • A black old man clapped my hand when crossing and wished me a good day. I replied "you too". I don't know if he heard me.
  • I hear the cable cars tongtong tongtong from the hotel window.
  • Things we hear in SF "Oh crap, can someone stash my kinder eggs?"
  • Industrial buildings and hipster shops. The world of rich people is leveled.
  • Freezing wind.
  • Wonderful broth of a Pho Bo
  • A woman shouting "bitch" multiple times at the window of a Carl's restaurant.
  • The feeling of meeting too many people.
  • The feeling of meeting too few people.
  • A perfume shop clerk, old and elegant woman talked to me English, then Japanese, then French. Smile for the day.
  • Missing the cafe latte barista from Whistler All Hands.
  • USA and too big hotel rooms. Ridiculous use of space in a time where everything should be counted and saved.
  • Written culture of street signs.
  • Walking from the hotel to the bye bye event, a moment for long life discussions.
  • American college kids doing bbq. A certain image of USA.
  • Long streets without any shops.
  • overheard: "Let's start the day with a bloody mary" (at the airport at 8am)


Categorieën: Mozilla-nl planet