mozilla

The Go Faster initiative is important as it enables us to ship code faster, using special add-ons, without being strictly tied to the Firefox train schedule. As Georg Fritzsche pointed out in his article, we have two options for instrumenting these add-ons: having probe definitions ride the trains (waiting a few weeks!) or implementing and sending a new custom ping (doing some pipeline work!). Both solutions are not very appealing when shipping code faster....

Let me state this clearly, again: data latency sucks. This is especially true when working on Firefox: a nicely crafted piece of software that ships worldwide to many people. When something affects the experience of our users we need to know and react fast. The story so far… We started improving the latency of the data coming from Firefox, in the previous quarters, and got to the point where the majority of pings reach our servers within 1 hour, instead of days (latest Beta only): there’s an extremely satisfying plot by :chutten about that!...

The data our Firefox users share with us is the key to identify and fix performance issues that lead to a poor browsing experience. Collecting it is not enough if we don’t manage to receive the data in an acceptable time-frame. My esteemed colleague Chris already wrote about this a couple of times: data latency sucks. But we can fix that. Why is there latency, anyway? The bulk of measurements we collect (histograms, scalars, events, …) are sent through the main-ping....

By Alessio Placitelli, Ali Almossawi, and Rebecca Weiss Cross-posted from Medium We have just released the Firefox Hardware Report, a report of the hardware used by the Firefox release user base. You can read the announcement here. The Firefox team believes that this report will be very valuable to developers, particularly those who build for the web. Web developers need to know what platforms and hardware are being used to inform their decisions when they are building and upgrading applications....

Sadly, right now (and until bug 1169873 is fixed), it’s not possible to build Firefox for Android on Windows. That’s not nice, especially if you need to track down some Android-only failures triggered by your code 🙂 Until recently I was able to run my Android Virtual Device within my Ubuntu Virtual Machine (yeah, tricky). Then something broke in OracleVM (ticket 12941), preventing me from starting the Android emulator. Here comes the good news: there’s a way to spawn an Android emulator on Windows, build Firefox for Android on a VM and then run it....