Mozilla Nederland LogoDe Nederlandse

Soledad Penades: Running a web server on the front-end

Mozilla planet - wo, 15/04/2015 - 13:51

The introduction of TCP sockets support in Firefox OS made it possible to run a web server from the front-end, and all is written in JavaScript. Think of having something similar to express.js… but running on a browser (because after all, Firefox OS is a superturbocharged browser).

Again, JS server superstar Justin d’Archangelo wrote an implementation of a web server that works on Firefox OS. It’s called fxos-web-server and it includes a few examples you can run.

None of the examples particularly fit my use case–I want to serve static content from a phone to other phones, but the examples were a bit more contrived. So I decided to build a simpler proof-of-concept example: catserver, a web server that served a simple page with full screen Animated GIFs of cats:


The first thing I wanted to do is to use Browserify “proper”, to write my app in a more modular way. For this I had to fork Justin’s original project and modify its package.json so it would let me require() the server instead of tucking its variable in the window globals :-) – sadly I yet have to send him a PR so you will need to be aware of this difference. The dependency in package.json points to my fork for now:

"fxos-web-server": "git+" Building (with gulp)

My example is composed of two “websites”. The first one is the web server app itself which is what is executed in the “server” device. The sources for this are in src.

The second website is what the server will transfer to devices that connect to it, so this actually gets executed in the client devies. This is where the cats are! Its contents are in the www folder.

Both websites are packaged in just one ZIP file and then installed onto the server device.

This build process also involves running Browserify first so I can get from node-style code that uses require() to a JavaScript bundle that runs on Firefox OS. So I’m using gulp to do all that. The tasks are in gulpfile.js.

Web server app

Thanks to Justin’s work, this is fairly simple. We create an HTTP server on port 80:

var HTTPServer = require('fxos-web-server');
var server = new HTTPServer(80);

And then we add a listener for when a request is made, so we can respond to it (and serve content to the connected client):

server.addEventListener('request', function(evt) {
      var request = evt.request;
      var response = evt.response;

      //... Decide what to send

The “decide what to send” part is a bit like writing nginx or express config files. In this case I wanted to:

  • serve an index.html file if we request a “directory” (i.e. a path that ends with “/”)
  • serve static content if we request a file (i.e. the path doesn’t end with “/”)

Before serving a file we need to tell the client what kind of content we’re sending to it. I’m using a very simple “extension to content type” function that determines MIME types based on the extension in the path. E.g. ‘html’ returns text/html.

Once we know the content type, we set it on the response headers:

response.headers['Content-Type'] = getContentType(fileToSend);

and use Justin’s shortcut function sendFile to send a file from our app to the client:


With the request handler set up, we can finally start the server!

server.start(); But… how does it even work?!

Welcome to the Hack of The Week!

When you say “sendFile” what the server app does is: it creates an XMLHttpRequest with type = arraybuffer to load the raw contents of the resource. When the XMLHttpRequest emits the load event, the server takes the loaded data and sends it to the client. That’s it!

Naive! Simple! It works! (for simple cases)

Ways that this could be improved – AKA “wanna make this better?! this is your chance!”

As I mentioned above, right now this is very naive and assumes that the files will exist. If they don’t, well, horrible things will happen. Or you will get a 404 error. I haven’t tried it myself. I’m not sure. I’d say there is no error handling (yet).

The extension to content type function could be made into a module, and probably extended to know about more file types. It probably exists already, somewhere in npmlandia.

Another idea I had is that instead of loading the entire resource in memory and then flush it down the pipe as sendFile does, we could use progress events on the XMLHttpRequest and feed it to the client as we load it–so that the server device won’t run out of memory. I don’t know how we could find the length of the resource first, perhaps a HEAD request could work!

And finally we could try to serve each request in a worker, so that the server doesn’t block when responding to a large request. Am I going too far? I don’t even know if the TCP sockets work with workers, or if there are issues with that, or who knows!? This is unexplored territory, welcome to Uncertainty Land! :-D

Even extremer ways to get very… “creative”

What if you wrote a PHP parser that runs in JavaScript and then parsed .php files instead of just returning their contents as text/html?

I’m only half kidding, but you could maybe execute JS templates on the server. Forget security! You trust the content, right? ;-)

Another thing you could do is take advantage of the fact that the server is also a browser. So you can do browsersy things such as using Canvas to generate images, instead of having to load libraries that simulate canvas in node. Or you could synthesise web audio stuff on demand–maybe you could use an OfflineAudioWorker for extra non-blocking goodness! Or, if you want to go towards a relatively more boring direction, you could do DOM / text handling on a server that can deal with that kind of stuff natively.

With all the new platforms in which we can run Firefox OS, there are so many things we can do! Phone servers might be limited by battery, but a Raspberry PI running Firefox OS and connected to a power source can be an interesting platform with which to experiment with this kind of easy-to-write web servers.

But I saw NFC mentioned in the video!

Indeed! But I will cover that in another post, so we keep this one focused on the HTTP server :-)

Happy www serving!

flattr this!

Categorieën: Mozilla-nl planet

Mozilla Release Management Team: Firefox mobile 37.0.1 to 37.0.2

Mozilla planet - wo, 15/04/2015 - 11:05

37.0.2 mobile fix a critical issue for our Japanese users.

A 37.0.2 Desktop release is planned to fix some issues (especially graphic). It should be published in the next few days.

  • 1 changesets
  • 4 files changed
  • 4 insertions
  • 5 deletions

ExtensionOccurrences txt2 sh1 in1

ModuleOccurrences mobile2 config1 browser1

List of changesets:

Mark FinkleBug 1151469 - Tweak the package manifest to avoid packaging the wrong file. r=rnewman, a=lmandel - c8866e34cbf3

Categorieën: Mozilla-nl planet

Mozilla veröffentlicht Firefox für Android 37.0.2 -

Nieuws verzameld via Google - wo, 15/04/2015 - 10:34

Mozilla veröffentlicht Firefox für Android 37.0.2
Mozilla hat das zweite außerplanmäßige Update für die Android-Version von Firefox veröffentlicht. Dieses behebt ein Problem mit dem Feature zum Anfordern der Desktop-Version einer Webseite. Mit Firefox für Android 37.0.2 behebt Mozilla ein Problem mit ...

Categorieën: Mozilla-nl planet

Mozilla Release Management Team: Firefox mobile 37.0.1 to 37.0.2

Mozilla planet - wo, 15/04/2015 - 09:12

37.0.2 mobile fix a critical issue for our Japanese users.

A 37.0.2 Desktop release is planned to fix some issues (especially graphic). It should be published in the next few days.

  • 1 changesets
  • 4 files changed
  • 4 insertions
  • 5 deletions

ExtensionOccurrences txt2 sh1 in1

ModuleOccurrences mobile2 config1 browser1

List of changesets:

Mark FinkleBug 1151469 - Tweak the package manifest to avoid packaging the wrong file. r=rnewman, a=lmandel - c8866e34cbf3

Categorieën: Mozilla-nl planet

Eitan Isaacson: (re)Introducing eSpeak.js

Mozilla planet - wo, 15/04/2015 - 04:44

Look! A flashy demo with buttons!


A long time ago, we were investigating a way to expose text-to-speech functionality on the web. This was long before the Web Speech API was drafted, and it wasn’t yet clear what this kind of feature would look like. Alon Zakai stepped up, and proposed porting eSpeak to Javascript with Emscripten. This was a provocative idea: was our platform powerful enough to support speech synthesis purely in JS? Alon got back a few days later with a working demo, the answer was “yes”.

While the speak.js port was very impressive, it didn’t answer many of our practical needs. For example, the latency was not good enough for making a responsive UI, you could wait more than a couple of seconds to hear a short phrase. In addition, the longer the text you wanted to synthesize, the longer you needed to wait.

It proved a concept, but there were missing pieces we didn’t have four years ago. Today, we live in the future of 2011, and things that were theoretical then, are possible now (in the future).


Today, Emscripten will compile C/C++ code into a subset of Javascript called asm.js. This subset is optimized on all current browsers, and allows performance to be about 2x native. That is really good. eSpeak is a pretty lightweight library already, the extra performance boost of asm.js makes speech instantaneous.

Transferable Objects

Passing data between a web worker and a parent process used to mean a lot of copying, since the worker doesn’t share memory with the parent process. But today, you can transfer ownership of ArrayBuffers with zero copying. When the web worker is ready to send audio data back to the calling process, it could do so while maintaining a single copy of the audio buffer.

Web Audio API

We have a slick, full featured Audio API today on the web. When speak.js came out in 2011, it used a prefixed method on an <audio> element to write PCM data to. Today, we have a proper API that enables us to take the audio data and send it through an elaborate pipeline of filters and mixers, or even send it into the ether with WebRTC.

Emscripten Got Fancy

This was my first time playing with it, so I am not sure what was available in 2011. But, if I have to guess, it was not as powerful and fun to work with. Emscripten’s new WebIDL support makes adding bindings extremely easy. You still get a chance to do some pointer arithmetic, but that’s supposed to be fun. Right?

So here is eSpeak.js!

I wanted to do a real API port, as opposed to simply porting a command line program that takes input and writes a WAV file. Why? two main reasons:

  1. eSpeak can progressively synthesize speech. If you provide a callback to espeak_Synth(), it will be called repeatedly with as many samples as you defined in the buffer size. It doesn’t matter how long the text is that you want synthesized, it will fill the buffer and return it to you immediately. This allows for a consistent low latency from the moment you call espeak_Synth(), until you could start playing audio.
  2. eSpeak supports events. If you use a callback, you get access to a list of events that provide a timestamp in the audio, and the type of event that occurs there, such as word or sentence boundaries.

And, of course, with all the recent-ish platform improvements above, I was really time for a fresh attempt.

Future Work
  • Break up the data files. Right now, eSpeak.js is over a 2MB download. That’s because I packaged all the eSpeak data files indiscriminately. There may be a few bits that are redundant. On the flip side you get all 99 voice/language combinations (that’s a good deal for 2MB, eh?). It would be cool to break it up to a few data files and allow the developer to choose which voices to bundle or, even better, just grab them on demand.
  • Make a demo of the speech events. It makes my head hurt to think about how to do something compelling. But it is a neat feature that should somehow be shown.
  • ScriptProcessorNode is apparently deprecated. This is going to need to be ported to an AudioWorker once that is widely implemented.

I’m done apologizing, here is the demo.

Categorieën: Mozilla-nl planet

Mike Hommey: Announcing git-cinnabar 0.2.1

Mozilla planet - wo, 15/04/2015 - 04:20

Git-cinnabar is a git remote helper to interact with mercurial repositories. It allows to clone, pull and push from/to mercurial remote repositories, using git.

Get it on github.

What’s new since 0.2.0?

Not much, but this felt important enough to warrant a release, even though the issue has been there since before 0.1.0:

Mercurial can be slower when cloning or pulling a list of “heads” that contain non-topological heads. On repositories like the mercurial repository, it’s not so much of a big deal, taking 7s instead of 4s. But on big repositories like mozilla-central, it’s taking 23 minutes instead of 2 minutes and 20s (on my machine). And that’s with 100% CPU use on the server side.

The problem is that mozilla-central recently merged some old closed heads, such that it now has branch heads that aren’t topological heads. Git-cinnabar, until this release, would request those branch heads, leading the server to use the slow path mentioned above. This release works around the issue.

It also fixes an issue pushing to a remote empty mercurial repository.

Categorieën: Mozilla-nl planet

Mike Hommey: Getting ready for GCC 5.1

Mozilla planet - wo, 15/04/2015 - 03:59

Confusingly, GCC has a new, weird, version scheme. The first release of GCC 5 will be 5.1. It is due soon (next week). For that reason, and because it’s better to find compiler bugs before it’s released, I started looking into building Firefox with it.

The first round of builds I did was with 5-20150405. That got me to find a small bunch of issues:

So that got me to do a second round with the first 5.1 RC, which had the fix for that ICE.

With all the above fixed, I could finally get builds out of try, and tests running, which revealed two more issues:

  • Another (quickly fixed) Internal Compiler Error on 32-bits PGO builds (but only for a nightly setup, with --enable-profiling, not for a release setup, which doesn’t have it).
  • JS engine assertions during some JIT tests on 64-bits builds (with or without PGO), which Dan Gohman kindly tracked down and reduced to a small test case allowing to file a GCC bug and bisect to pinpoint at the GCC upstream commit that broke it (yay git bisect run on a 36-CPU EC2 instance).

Preliminary results are promising, with benchmarks improving up to 16%, but the comparison wasn’t entirely fair, because they compared GCC 4.8 builds with frame pointers and JS engine diagnostics to GCC 5.1 builds without.

I’ll also give a spin to LTO, possibly finding more GCC bugs in the process.

Categorieën: Mozilla-nl planet

Anthony Hughes: Report on Recognition

Mozilla planet - di, 14/04/2015 - 22:47

Earlier this year I embarked on a journey to investigate how we could improve participation in the Mozilla QA community. I was growing concerned that we were failing in one key component of a vibrant community: recognition.

Before I could began, I needed to better understand Mozilla QA’s recognition story. To this end I published a survey to get anonymous feedback and today, I’d like to share some of that feedback.

Profile of Participants

The first question I asked was intended to profile the respondents in terms of how long they’d been involved with Mozilla and whether they were still contributing.

recognition-activityThis revealed that we have a larger proportion of contributors who’ve been involved for more than a couple of years. I think what this indicates we need to be doing a better job of developing long-term relationships with new contributors.

recognition-teamsWhen asked which projects contributors identified with, 100% of respondents identified as being volunteers with the Firefox QA team. The remaining teams breakdown fairly evenly between 11% and 33%. I think this indicates most people are contributing to more than one team, and that teams at the lower end of the scale have an excellent opportunity for growth.

Recognizing Recognition

The rest of the questions were focused more on evaluating the forms of recognition we’ve employed in the past.


When looking at how we’ve recognized contributors it’s good to see that everyone is being recognized in some form or another, in many cases receiving multiple forms of recognition. However I suspect the results are somewhat skewed (ie. people who haven’t been recognized are probably long gone and did not respond to the survey). In spite of that, it appears that seemingly simple things, like being thanked in a meeting, are well below what I’d expect to see.

recognition-likelihoodWhen looking at the impact of being recognized, it seems that more people found recognition to be nice but not necessarily a motivation for continuing to contribute. 44% found recognition to be either ineffective or very ineffective while 33% found it to be either effective or very effective. This could point to a couple of different factors, either our forms of recognition are not compelling or people are motivated by the work itself. I don’t have a good answer here so it’s probably worth following up.

What did we learn?

After all said and done, here is what I learned from doing this survey.

1. We need to be focused on building long-term relationships. Helping people through their first year and making sure people don’t get lost long-term.

2. Most people are contributing to multiple projects. We should have a framework in place that facilitates contribution (and recognition of contribution) across QA. Teams with less participation can then scale more quickly.

4. We need to be more proactive in our recognition, especially in its simplest form. There is literally no excuse for not thanking someone for work done.

5. People like to be thanked for their work but it isn’t necessarily a definitive motivator for participation. We need to learn more about what drives individuals and make sure we provide them whatever they need to stay motivated.

6. Recognition is not as well “baked-in” to QA as it is with other teams — we should work with these teams to improve recognition within QA and across Mozilla.

7. Contributors find testing to be difficult due to inadequate description of how to test. In some cases, people spend considerable amounts of time and energy figuring out what and how to test, presenting a huge hurdle to newcomers in particular. We should make sure contribution opportunities are clearly documented so that anyone can get involved.

8. We should be engaging with Mozilla Reps to build a better, more regional network of QA contributors, beginning with giving local leaders the opportunity to lead.

Next Steps

In closing, I’d like to thank everyone who took the time to share their feedback. The survey remains open if you missed the opportunity. I’m hoping this blog post will help kickstart a conversation about improving recognition of contributions to Mozilla QA. In particular, making progress toward solving some of the lessons learned.

As always, I welcome comments and questions. Feel free to leave a comment below.


Categorieën: Mozilla-nl planet

Yunier José Sosa Vázquez: Firefox impedirá que recopilen nuestra información

Mozilla planet - di, 14/04/2015 - 19:21

Si de protección a la privacidad se habla, tenemos que reconocer los esfuerzos que realiza Mozilla para mantenernos seguros en este mundo donde todos quieren espiarnos y robar nuestra información a cualquier costo. Por esa razón, Mozilla recibió el premio a la compañía más confiable en Internet.

Firefox ya incluye la funcionalidad No rastrear, que le indica a los sitios web que no monitorizen tu actividad web, las compañías no están obligadas a hacerle caso. Sin embargo, Mozilla no se detiene y en la próxima versión de Firefox introducirá un nuevo filtro de seguridad que ya podemos activar de forma manual.

Antes de seguir, es importante que conozcan ¿qué es el rastreo en línea u online? El rastreo online consiste en la recopilación de los datos de navegación de una persona a través de los diferentes sitios web; esta recopilación se hace, por lo general, solo con ver el contenido de un sitio web. Los dominios rastreadores solo intentan identificar a una persona a través del uso de cookies o mediante la utilización de otras tecnologías, como por ejemplo, la huella digital.

Pero ¿qué solución ofrece Mozilla? La protección de rastreo te permite tomar el control de tu privacidad. Aunque Firefox proporciona  La Protección de rastreo de Firefox te devuelve de nuevo el control de tu privacidad, bloqueando activamente los dominios y sitios web que son conocidos por rastrear a sus visitantes.

La lista negra inicial utilizada por la herramienta Protección de rastreo, está basada en la lista negra de Disconnect. Si deseas probar esta funcionalidad, debes instalar la versión Nightly que se encuentra en nuestra zona de Descargas para tu sistema, ¿Cómo activar la Protección de rastreo?
  1. En la barra de direcciones, escribe about:config y pulsa IntroRetorno.
    • El aviso de about:config “¡Zona hostil para manazas!” o “¡Esto puede cancelar su garantía!” puede aparecer. Haz clic en ¡Tendré cuidado, lo prometo! o ¡Seré cuidadoso, lo prometo!, para continuar.
  2. Busca privacy.trackingprotection.enabled.
  3. Haz doble clic en privacy.trackingprotection.enabled para cambiar su valor a true.

Esto activará la Protección de rastreo. Si más tarde quieres desactivarla, repite los pasos anteriores para cambiar el valor a false.

Cómo usar la Protección de rastreo

Una vez activada la Protección de rastreo, verás un escudo en la barra de direcciones cuando Firefox esté bloqueando el rastreo desde ese dominio o desde contenido mixto.


Para desactivar la Protección de rastreo en un sitio web en particular, simplemente haz clic en el icono del escudo y selecciona “Desactivar protección para este sitio”. Una vez que la Protección de rastreo se desactiva en un sitio web, podrás ver un escudo con una cruz roja. Puedes volver a activar la Protección de rastreo en ese sitio web volviendo a hacer clic en el escudo y seleccionando “Activar protección”.


Para ver qué recursos están siendo bloqueados, abre la consola web y busca en los mensajes que están en la pestaña Seguridad.

Si deseas probar esta funcionalidad, debes instalar la versión Nightly que se encuentra en nuestra zona de Descargas para tu sistema,

Fuente: Ayuda de Firefox

Categorieën: Mozilla-nl planet

Mozilla wants to drop HTTP support in Firefox -

Nieuws verzameld via Google - di, 14/04/2015 - 18:33


Mozilla wants to drop HTTP support in Firefox
On Mozilla's developer discussion groups most agree, but also potential issues are discussed. An issue could be with intranet sites that are mainly all HTTP based and older devices which don't always support the safe HTTPS implementation. Some sites ...
​Want fancy Firefox features? Secure your websiteCNET

alle 4 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Will Kahn-Greene: Input: 2015q1 quarter in review

Mozilla planet - di, 14/04/2015 - 18:00

We got a lot of stuff done in 2015q1--it was a busy quarter.

Things to know:

  • Input is Mozilla's product feedback site.
  • Fjord is the code that runs Input.
  • We maintain project details and plans at
  • I am Will Kahn-Greene and I'm the tech lead, architect, QA and primary developer on Input.
Bugzilla and git stats Quarter 2015q1 (2015-01-01 -> 2015-03-31) ========================================= Bugzilla ======== Bugs created: 73 Creators: 7 Will Kahn-Greene [:willkg] : 67 Gregg Lind (User Advocacy - He : 1 Shashishekhar H M : 1 Matt Grimes [:Matt_G] : 1 Mark Banner (:standard8) : 1 deshrajdry : 1 L. Guruprasad : 1 Bugs resolved: 97 WONTFIX : 13 FIXED : 82 DUPLICATE : 1 INCOMPLETE : 1 Tracebacks : 4 Research : 2 Tracker : 6 Research bugs: 2 1124412: [research] evaluate SUMO search APIs for best results given a piece of feedback Tracker bugs: 6 907871: [tracker] add analytics infrastructure and reports to Input 967037: [tracker] add classifier page to Firefox OS feedback form 968230: [tracker] capture carrier in Firefox OS form 1092280: [tracker] heartbeat v2 (Input-specific changes) 1104932: [tracker] about:support support tracker 1130599: [tracker] Alerts phase 1 Resolvers: 6 Will Kahn-Greene [:willkg] : 65 L. Guruprasad : 16 Ricky Rosario [:rrosario, :r1c : 7 aokoye : 5 mgrimes : 2 deshrajdry : 2 Commenters: 22 willkg : 579 rrosario : 25 deshrajdry : 10 mcooper : 10 lgp171188 : 10 mgrimes : 9 cww : 8 glind : 8 adnan.ayon : 6 aokoye : 4 robb : 4 brnet00 : 3 mozaakash : 2 John99-bugs : 2 chofmann : 2 bwalker : 1 laura : 1 standard8 : 1 shashishekharhm : 1 christian : 1 fwenzel : 1 dlucian93 : 1 git === Total commits: 276 Will Kahn-Greene : 189 (+9707, -3904, files 558) L. Guruprasad : 38 (+916, -402, files 160) Ricky Rosario : 36 (+1756, -10764, files 314) Adam Okoye : 6 (+210, -12, files 12) deshraj : 3 (+19, -19, files 5) Michael Kelly : 2 (+2, -2, files 4) Adrian Gaudebert : 2 (+20, -6, files 4) Total lines added: 12630 Total lines deleted: 15109 Total files changed: 1057 Everyone ======== Adam Okoye adnan.ayon Adrian Gaudebert brnet00 bwalker chofmann christian cww deshrajdry dlucian93 fwenzel Gregg Lind (User Advocacy - Heartbeat - Test Pilot) John99-bugs L. Guruprasad laura Mark Banner (:standard8) Matt Grimes [:Matt_G] mcooper Michael Kelly mozaakash Ricky Rosario robb Shashishekhar H M standard8 Will Kahn-Greene

Code line counts:

2014q1: April 1st, 2014: 15195 total 6953 Python 2014q2: July 1st, 2014: 20456 total 9247 Python 2014q3: October 7th. 2014: 23466 total 11614 Python 2014q4: December 31st, 2014: 30158 total 13615 Python 2015q1: April 1st, 2015: 28977 total 12623 Python

Input finally shrunk, though this is probably due to switching from the South migration system to the Django 1.7 migration system and in the process of doing that ditching most of our old migration code.

Contributor stats

L Guruprasad worked through 16 bugs this quarter--that's awesome!

Adam worked on the Thank You page overhaul. It's not quite done, but it's in a good place--I'll be finishing up that work in 2015q2.

Ricky finisedh up the Django 1.7 update just in time for Django 1.8 to be released. In doing that work, we cleaned up a lot of code, shed a bunch of dependencies and are in a much better place in regards to technical debt. Yay!

Thank you to everyone who contributed!


Django 1.7 upgrade: We upgraded to Django 1.7. That's a big deal since Django 1.8 was just released so Django 1.6 isn't supported anymore. Django 1.7 has a new migration system, so there was a lot of work required to upgrade Input.

Heartbeat v2: We did most of Heartbeat v2 in 2014q4, however it didn't really launch until 2015q1. We did a bunch of work to tweak things for the release.

Alerts v1: We added an Alerts API. Input collects a variety of feedback-type data. After several discussions, we decided that it was a better idea to have alert systems live outside of Input, but push alert events to Input. This allows us to develope alert emitting systems faster because they're outside of the Input development process. Further, it relaxes implementation details. The Alerts API has GET and POST abilities and lets us capture and report on arbitrary alert events.

Alerts API.

Remote troubleshooting data capture: We finished this work in 2015q1. It's now rolled out for specific products and in all locales.

Remote troubleshooting data capture project plan.

12 Factor App: At some point, we're going to move Input to AWS. In the process of doing that, we're going to change how Input is configured and deployed and switch to a 12-factor-app-friendly model. I spent a good portion this quarter cleaning things up and redoing configuration so it's more 12-factor-app-compliant.

There's still some work to do, but it'll be easier to do as we're in the process of switching to AWS and know more about how the infrastructure is going to be structured.

12 Factor App.

Snow removal: I live next town over from Lowell, MA, USA. We got 118 inches of snow this winter the bulk of which came in a 6-week period where it pretty much snowed every three days. It was exhausting.

I did a lot of shoveling, but never really solved the problem. However, it did subside after a while and now it's gone.

Snow removal.


2015q1 went by really fast and we got a lot of stuff done and we worked through a lot of technical debt, too. It was a good quarter.

Categorieën: Mozilla-nl planet

Air Mozilla: Martes mozilleros

Mozilla planet - di, 14/04/2015 - 17:00

Martes mozilleros Reunión bi-semanal para hablar sobre el estado de Mozilla, la comunidad y sus proyectos. Bi-weekly meeting to talk (in Spanish) about Mozilla status, community and...

Categorieën: Mozilla-nl planet

Mozilla Release Management Team: Firefox 38 beta3 to beta4

Mozilla planet - di, 14/04/2015 - 16:52

This beta release is going back to normal level in term of number of patches and size.

We took some important fixes for graphics and also uplifted some polish patches for the new features which will ship with 38 or 38.1 (Reading list, in-tab preferences, etc).

  • 33 changesets
  • 68 files changed
  • 1204 insertions
  • 986 deletions

ExtensionOccurrences cpp21 js14 html6 ini5 h5 xml4 jsm4 java2 css2 webidl1 py1 list1 inc1 idl1

ModuleOccurrences browser19 dom8 layout7 toolkit6 mobile6 widget5 testing4 gfx4 editor3 media2 js2 xpcom1 ipc1

List of changesets:

Ryan VanderMeulenBug 1153060 - Bump the in-tree mozharness revision. a=test-only - 7f7236a5b6dd Patrick BrossetBug 1139925 - Make the BoxModelHighlighter highlight all quads and draw guides around the outer-most rect. r=miker, a=sledru - e2f81a3ca1e5 Brian HackettBug 1151401 - Watch for non-object unboxes while optimizing object-or-null operations. r=jandem, a=sledru - d2bade84e15e Gijs KruitboschBug 1147337 - Stop checking article URL as AboutReader.jsm gets created separately every time anyway. r=margaret, a=sledru - 948241aa9d1a Gijs KruitboschBug 1152104 - Use command event and delegate clicks to it. r=jaws, a=sledru - f5f2adb88968 Matt WoodrowBug 1116812 - Blacklist two intel GPUs that are trigger driver crashes frequently. r=jrmuizel, a=sledru - 6d9fdd280e65 Jean-Yves AvenardBug 1133633: Part2. Enable async decoding on mac. r=mattmoodrow, a=sledru - 10f75583d21a Jean-Yves AvenardBug 1153469: Ensure IOSurface isn't released before being composited. r=mattwoodrow, a=sledru - 7efd806788be Kannan VijayanBug 1134515 - Ensure SPSBaselineOSRMarker checks pseudostack size properly. r=shu, a=sledru - 10c3198eb453 Aryeh GregorBug 1134545 - Insufficient null check. r=ehsan, a=sledru - 5f042fe29707 Chris PearceBug 1148286 - Ensure we don't nullpointer deref if the CDM crashes in MediaKeys and Reader::SetCDMProxy implementations. r=edwin, a=sledru - 999636e73165 Jean-Yves AvenardBug 1147744 - Part 1: Round down display size. r=k17e, a=sledru - 8f8ebd186863 Jean-Yves AvenardBug 1147744 - Part 2: Properly calculate cropping value. r=k17e, a=sledru - c4a01c159cb6 Margaret LeibovicBug 1150695 - Use isProbablyReaderable function from Readability.js. r=Gijs, a=sledru - ab0337907115 Drew WillcoxonBug 1151077 - Make the desktop reading list sync module batch its POST /batch requests. r=markh, a=sledru - 1b6ba1cb52f6 John SchoenickBug 1139560 - Reject non-standard parses of integers in srcset descriptors. r=jst, a=sledru - dffb5c867f47 John SchoenickBug 1139560 - Fix srcset parser 'After descriptor' state mishandling spaces. r=jst, a=sledru - 07666fc071be John SchoenickBug 1139560 - <img>.currentSrc should be not be nullable. r=jst, a=sledru - 7285a02cd883 Mike TaylorBug 1139560 - Update srcset web-platform expectations. r=jst, a=sledru - cd5b5709b2e4 Ben TurnerBug 1135344 - Don't let IPDL use names that are reserved for compilers. r=froydnj, a=sledru - 8340415e7b27 Jared WeinBug 1149230 - In-content preferences: missing padding between labels and learn more links in Advanced -> Data Choices panel. rs=Gijs, a=sledru - 002faed66e96 Mark HammondBug 1152703 - Prevent desktop reading list sync errors from preventing sync from starting again. r=adw, a=sledru - 8191b45753c7 Blake WintonBug 1149136 - Specify a min-width and min-height to avoid flex making things too small. ui-r=mmaslaney, r=florian, a=sledru - 0a9b3f3e962d Michael ComellaBug 1153193 - Add EXTRA_DEVICES_ONLY flag to share intents. r=rnewman, a=sledru - 7081bbd2b331 Margaret LeibovicBug 1153262 - Remove length comparison from testReadingListCache. r=gijs, a=sledru - 2ffc047abd90 Michael ComellaBug 1150430 - Set quickshare !visible and !enabled by default. r=mfinkle, a=sledru - b54c44cfa07e Jared WeinBug 1043612 - Persist the size of resizable in-content subdialogs. r=gijs, a=sledru - 9740c1d817f1 Michael ComellaBug 1152489 - Prevent getMostRecentHomePanel() from being called on null selectedTab. r=mfinkle, a=sledru - afe57494b44d Mats PalmgrenBug 1143299 - Make frame insertion methods deal with aPrevFrame being on an overflow list. r=roc, a=sledru - 2659ba26dcf2 Gijs KruitboschBug 1152022 - Update Readability to github tip. r=gijs, r=margaret, a=sledru - 333017ad43a9 Andrew McCreightBug 1144649 - Make CCGraph::AddNodeToMap fallible again. r=smaug, a=sledru - 7717f3aa4cf6 L. David BaronBug 1148829 - Backport a safer version of part of Bug 1061364 to make transitions stop running the refresh driver after they've finished. r=bbirtles, a=sledru - 4359c16b7f44 Jeff MuizelaarBug 1153381 - Add a D3D11 ANGLE blacklist. r=mstange, ba=sledru - 05508ccf3ae8

Categorieën: Mozilla-nl planet

Verschlüsselung: Auch Mozilla will HTTPS zum Standard machen -

Nieuws verzameld via Google - di, 14/04/2015 - 15:32

Verschlüsselung: Auch Mozilla will HTTPS zum Standard machen
Der Mozilla-Vorschlag ist bislang nur ein Entwurf, der jetzt öffentlich diskutiert wird. Er folgt jedoch einem Trend: Eine ganze Reihe von Akteuren hat zuletzt erklärt, dass verschlüsselte Webseiten der neue Standard im Netz werden sollten. Google hat ...

Categorieën: Mozilla-nl planet

Mozilla-ontwikkelaar wil ondersteuning voor http-verkeer uitfaseren - Tweakers

Nieuws verzameld via Google - di, 14/04/2015 - 10:14

Mozilla-ontwikkelaar wil ondersteuning voor http-verkeer uitfaseren
Richard Barnes, security engineer bij Mozilla, heeft voorgesteld om de ondersteuning voor onversleuteld http-verkeer stapsgewijs af te bouwen. Volgens de softwareontwikkelaar is http te gemakkelijk af te tappen en te misbruiken voor bijvoorbeeld het ...

Categorieën: Mozilla-nl planet

Planet Mozilla Interns: Willie Cheong: Academics Complete

Mozilla planet - di, 14/04/2015 - 08:47

I’ve written many last exams before. But today I finish writing my last, last exam; graduation awaits. Life is pretty exciting right now. School has been an amazing experience, but being done feels much better.

Goodbye Waterloo; Hello World!

Categorieën: Mozilla-nl planet

Byron Jones: happy bmo push day!

Mozilla planet - di, 14/04/2015 - 08:41

the following changes have been pushed to

  • [1152160] “take” button doesn’t update the ui, so it looks like nothing happened
  • [1152163] passing an invalid bug id to the multiple bug format triggers: Can’t call method “name” on an undefined value
  • [1152167] “powered by” logo requests fails: it sets the assignee to dboswell
  • [1150448] Replace the newline with ” – ” when the bug’s id and summary are copied
  • [1152368] BUGZILLA_VERSION in Bugzill::Constants causes error when installing Perl deps for new BMO installation
  • [1090493] Allow ComponentWatching extension to work on either bmo/4.2 or upstream 5.0+
  • [1152662] user story text should wrap
  • [1152818] changing an assignee to or any .bugs address should automatically reset the status from ASSIGNED to NEW
  • [1149406] “project flags” label is visible even if there aren’t any project flags
  • [1031035] xmlrpc can be DoS’d with billion laughs attack
  • [1152118] Shortcut for editing gets triggered even when “ctrl” and “e” are not pressed at the same time
  • [1152360] Add parameter to that generates a cpanfile usable by utilities such as cpanm for installing Perl dependencies
  • [1148490] Custom Budget Request form for FSA program
  • [1154098] Unable to add mentors to bugs
  • [1146767] update relative dates without refreshing the page
  • [1153103] add hooks for legal product disclaimer

discuss these changes on

Filed under: bmo, mozilla
Categorieën: Mozilla-nl planet

Air Mozilla: Elasticsearch Meetup

Mozilla planet - di, 14/04/2015 - 03:00

Elasticsearch Meetup Join us as Mozilla hosts an ElasticSearch meetup, featuring a duo inviting you along on a whirlwind dive of the ElasticSearch .NET client

Categorieën: Mozilla-nl planet

Jet Villegas: Gaia Tips and Tricks for Gecko Hackers

Mozilla planet - di, 14/04/2015 - 02:28

I’m often assigned Firefox Rendering bugs in bugzilla. By the time a bug gets assigned to me, the reporter had usually exhausted other options and assumed (correctly) that I’m ultimately responsible for fixing Firefox rendering bugs. Of course, I often have to reassign most bugs to more capable individuals.

Some of the hardest bugs to assign are the ones reported by our own Gaia team: the team responsible for building the user experience in Firefox OS. The Gaia engineers take CSS and JavaScript and build powerful mobile apps like the phone dialer and SMS client. When they report bugs, it’s often found within lots of CSS and JS code. I wanted to learn how to effectively reduce the time it takes to resolve rendering issues reported by the Gaia team. It takes a long time to go from a Gaia bug like “scrolling in the gallery app is slow” to find the underlying Gecko bug, for example “rounding issue creates an invalidation rectangle that is too large.”

To do that, I became a Gaia developer for a few days at our Paris office. I reasoned that if I could learn how they work, then I can help my team boil down issues faster and become more responsive to their needs. We already recognize the value of having expert web application developers on staff, but we could do a better job with a better understanding of how they work. With that in mind, I spent the week without any C++ code to look at, and dived into the world of mobile web app development.

I wrote down the steps I took to set up a FirefoxOS build and test environment in an earlier post This time, I’ll list a few of the tips and tricks I learned while I was working with the Gaia developers.

The first and most important tip: You will brick the phone when working on the OS. In fact, you’re probably not trying hard enough if you don’t brick it :) Fastboot lets you connect ADB to the phone when it becomes unresponsive to flash the device with a known good system (like the base image.) Learn how to manually force fastboot on your phone.

Julien showed me how to maintain a Gaia developer profile on your desktop development environment. This set of commands will configure your B2G build to produce the desktop B2G runtime that’s a bit easier to debug than a device build:

# change value of the FIREFOX to point to the full path to the B2G desktop build export FIREFOX=/Volumes/firefoxos/B2G/build/dist/ export PROFILE_FOLDER=gaia-profile DEBUG=1 DESKTOP=0 make

With a Gaia developer profile, you can switch between B2G desktop and a regular Firefox browser build for testing:

export FIREFOX=/full/path/to/desktop/browser $FIREFOX -profile gaia-profile --no-remote app://

The Gaia profile lets you use URL’s like app:// to run the Gaia apps on the desktop browser. This trick alone was a huge time saver! Try it with other URL’s like app://

For a first Gaia development project, I picked up the implementation of new card view for gaia that is based on an asynchronous panning and zooming (APZC.) Etienne did the initial proof-of-concept and my goal is to rebase/finish/polish it and add some CSS Scroll Snapping features. My initial tests for this feature are very promising. CSS Scroll Snapping is much more responsive than the previous JavaScript-based implementation. I’m still working out some bugs but hope to land my first Gaia pull request soon.

I’ve already been able to apply what I’ve learned to triage bugs like this one. The bug started out described as a problem with how we launch GMail on B2G in Arabic language. Based on the testing tricks I learned from Gaia team, I was able to distill it to a root cause with scrollbar rendering on right-to-left (RTL) languages. I added a simplified test case to the bug that should greatly reduce debugging time, and assigned it to one of our RTL experts. That’s quite a bit better than assigning tough bugs to random developers with the entire OS as the test case!

Thanks to Julien and Ettiene for helping me get up to speed. I highly recommend that any Gecko engineer spend a few days as a Gaia hacker. I’m humbled by the ingenuity these developers have for building the entire OS user experience with only the capabilities offered by the Web. We could all learn a lot in the trenches with these hackers!

Categorieën: Mozilla-nl planet

John O'Duinn: “why work doesnt happen at work” by Jason Fried on TEDx

Mozilla planet - di, 14/04/2015 - 02:20

While reading “Remote”, I accidentally found this TEDx talk by one of the authors, Jason Fried. Somehow I’d missed this when it first came out in 2010, so stopped to watch it. I’ve now watched this a few times in a row, found it just as relevant today as it was 4-5 years ago, so am writing this blogpost.

The main highlights for me were:

1) work, like sleep, needs solid uninterrupted time. However, most offices are designed to enable interrupts. Open plan layouts. Phones. Casual walk-by interrupts from managers asking for status. Unneeded meetings. They are not designed for uninterrupted focus time. No-one would intentionally plan to have frequently-interrupted-sleep every night and consider it “good”, so why set up our work environments like this?

2) Many people go into the office for the day, attempting to get a few hours uninterrupted work done, only to spend time reacting to interrupts all day, and then lament at the end of the day that “they didn’t get anything done”! Been there, lived through that. As a manager, he extols people to try things like “no-talking-Thursdays”, just to see if people can actually be more productive.

3) The “where do you go when you really want to get work done” part of his presentation nailed it for me. He’s been asking people this question for years, and the answers tend to fall into three categories:

  • place: “the kitchen”, “the spare room”, “the coffee shop”, …
  • moving object: plane, train, car… the commute
  • time: “somewhere really early or really late at night or on the weekend”

… and he noted that no-one said “the office during office hours”!! The common theme is that people use locations where they can focus, knowing they will not get interrupted. When I need to focus, I know this is true for me also.

All of which leads to his premise that organizing how people work together, with most communication done in a less interruptive way is really important for productivity. Anyone who has been at one of my remoties sessions knows I strongly believe this is true – especially for remoties! He also asked why businesses spend so much money on these counter-productive offices.

Aside: I found his “Facebook and twitter are the modern day smoke breaks” comment quite funny! Maybe thats just my sense of humor. Overall, its a short 15min talk, so instead of your next “facebook/twitter/smokebreak”, grab a coffee and watch this. You’ll be glad you did.

Categorieën: Mozilla-nl planet