As you may have heard, there are a lot of changes coming up for add-on development. In the next 12-18 months, we will transition to WebExtensions as the standard for creating add-ons. Over the same period of time, existing methods for add-on development such as XUL/XPCOM will be deprecated. Multi-process Firefox (aka Electrolysis, or e10s) is also rolling out, which means some developers will have to update their add-on more than once. All this on the heels of add-on signing.

In the past few weeks, we’ve been gathering all the information and resources we could to help developers navigate the upcoming changes. We’re also lining up new content so we can continue to keep everyone informed and supported during this adjustment period.

Everything we’ve collected so far is here. A few notable pieces of information you’ll find:

• The emails we created based on the developer profiles that were identified with the help of the add-on reviewer are going out shortly.
• A survey is available for you to tell us which WebExtension APIs you need, so we can better prioritize them.
• A timeline of changes is available that includes dates to the best of our knowledge. This is a working doc and will be updated as we learn of new information.
• If you haven’t already, add the Developer Calendar to see upcoming meetings, blog posts, and office hours. We will also be adding release milestones to the calendar in the coming weeks.
• Resources and documentation related to the transitions are added here as they’re created. We have more content queued up, and as you can see we could use even more. If you’re interested in writing about your experience creating a WebExtension add-on, or becoming e10s compatible, or anything else that others might find relevant, please sign up here.

We’ll keep releasing information over the coming months as they become available. If you have ideas or would like to pitch in, please reach out to us. We’re here to help.

https://blog.mozilla.org/addons/2016/03/10/developer-support-for-changes-in-add-on-development/

With recent changes, addons.mozilla.org (AMO) now more strictly enforces our rule requiring version numbers for add-ons to be unique.

Previously, the website allowed some edge cases where if a version was deleted or disabled before we reviewed it, a new version with the same version number could be uploaded.  This caused issues with our CDN where the old xpi was cached. The hash (used for verification) could be wrong so the install would fail, and any users who installed the old xpi would fail to get the update to the ‘real’ version.

Now, once a version has been uploaded to AMO with a version number, you will be unable to use it again. Deleting or disabling the version won’t release the version number for re-use.  This restriction applies to add-ons that are uploaded for signing and external listing as well as ones listed on AMO.

We’re aware this will cause some irritation to developers when they try to upload again, and that perfect version “10.0.0.0” may be lost due to a hasty upload, but we believe the user benefits in this case outweigh the extra restriction on developers.

https://blog.mozilla.org/addons/2016/03/09/amo-updates-on-version-number-re-use/

I post these updates every 3 weeks to inform add-on developers about the status of the review queues, add-on compatibility, and other happenings in the add-ons world.

The Review Queues

In the past 3 weeks, 1065 add-ons were reviewed:

• 1007 (95%) were reviewed in less than 5 days.
• 26 (2%) were reviewed between 5 and 10 days.
• 32 (3%) were reviewed after more than 10 days.

There are 102 listed add-ons awaiting review.

You can read about the recent improvements in the review queues here.

If you’re an add-on developer and are looking for contribution opportunities, please consider joining us. Add-on reviewers get invited to Mozilla events and earn cool gear with their work. Visit our wiki page for more information.

Firefox Accounts

Firefox Accounts is now live on AMO. Next time you log in, you’ll be prompted to migrate your account. If you have any problems with this process, please post in the forum thread.

Firefox 45 Compatibility

This compatibility blog post is up. The bulk compatibility validation was run last week.

Firefox 46 Compatibility

The compatibility blog post is up. We expect to run the bulk validation in a couple of weeks.

As always, we recommend that you test your add-ons on Beta and Firefox Developer Edition to make sure that they continue to work correctly. End users can install the Add-on Compatibility Reporter to identify and report any add-ons that aren’t working anymore.

Extension Signing

The wiki page on Extension Signing has information about the timeline, as well as responses to some frequently asked questions. The current plan is to remove the signing override preference in Firefox 46 (updated from the previous deadline of Firefox 44).

Electrolysis

Electrolysis, also known as e10s, is the next major compatibility change coming to Firefox. Firefox will run on multiple processes now, running content code in a different process than browser code.

This is the time to test your add-ons and make sure they continue working in Firefox. We’re holding regular office hours to help you work on your add-ons, so please drop in on Tuesdays and chat with us!

WebExtensions

We’re working on the new WebExtensions API, and we recommend that you start looking into it for your add-ons. You can track progress of its development in http://www.arewewebextensionsyet.com/.

https://blog.mozilla.org/addons/2016/03/09/add-ons-update-78/

This is the sumo weekly call We meet as a community every Wednesday 17:00 - 17:30 UTC

https://air.mozilla.org/sumo-community-call/

I am currently a compiler engineer at Mozilla corporation, the company making the Firefox browser among else. Our JavaScript virtual machine, Spidermonkey, is split in several tiers, including an highly optimizing Just-In-Time (JIT) compiler able to compile JavaScript to assembly at runtime. My previous work has involved efficiently compiling Float32 arithmetic to hardware instructions and implement a new SIMD API for the Web.

About Float32 optimizations

The full blog post is there. It has been written in November 2013.

The main idea is that if you have float32 inputs to an operation; and you cast them to doubles; and you apply an arithmetic operation to these inputs; and you cast the result back to a float32, then you'd have the same result as if you did the entire computation with float32 values and operations.

So we've introduced an operation in JavaScript that converts a Number to its closest float32 IEEE754 representation: Math.fround. Said differently, the above equivalence says that:

function f(x, y) {
    return x + y;
}

function g(x, y) {
    var xf = Math.fround(x);
    var yf = Math.fround(y);
    return Math.fround(xf + yf);
}

// For all x, y that can be represented exactly as float32:
assert(f(x, y) === g(x, y));

Yes, ===. The same === you've been told not to use for floating-point Numbers. But here, we have bitwise equality, so we can use strict equality*.

Processors have special instructions for carrying out float32 arithmetic, which have higher throughput than the equivalent double ones. With this result in mind, we could add a pass that would spot opportunities where the computations are equivalent (thanks to Math.fround hints) and emit float32 instructions instead of double instructions. This sped up a some numerical applications and games engines by a few points.

* a careful reader would object that this is wrong for x = y = NaN, which I've put away for the sake of simplicity.

About SIMD.js

The full blog post is there. It has been written in March 2015.

Nowadays, processors have instructions sets that allow them to execute several simple arithmetic operations at once. For instance, let's say you have two arrays of integers and you want to add each element to the corresponding one in the other array. If both arrays have size N, this means you'll have to carry out N scalar additions. But processors can actually group these into bundles of several additions, with SIMD; for the case of 32-bits wide integers, on most modern processors, you need at most Math.ceil(N / 4) instructions. The blog post details what SIMD.js is and what bottlenecks we hit during implementation.

Conclusion

This was a small reminder about previously written blog posts. If you're into JavaScript, compilers or low-level optimization, I can only recommend you to go read the Mozilla's JavaScript blog.

https://blog.benj.me/2016/03/09/previous-writing-about-mozilla-work/

Over the past several weeks, Mozilla has been running an educational campaign about encryption. We believe it’s essential for everyday Internet users to better understand the technology that helps keep the Web a more secure platform.

So far, we’ve explored encryption’s role in helping protect users’ personal, intimate information. We’ve created an animated short that uses plain language to explain how encryption works. And we’ve expressed our support for Apple in its ongoing case against the FBI.

Today, we’re spotlighting how encryption can support not only our personal security, but also how it can play a role in promoting values like free expression that most of us hold dear.

Recently, Mozilla spoke with Trevor Timm, Executive Director of Freedom of the Press Foundation, a nonprofit organization that supports and defends journalism dedicated to transparency and accountability. “Increasingly, encryption is playing a huge role in upholding free expression rights,” Trevor says. You can learn more by watching our interview below:

I hope you’ll take a moment, hear Trevor, and share this video with friends and family. Broadening public understanding of encryption is the first step toward protecting it. We’ve learned that an informed public is one of the open Internet movement’s most powerful tools.

Mozilla is also supporting encryption by placing a technologist, in collaboration with the Ford Foundation, at the Freedom Of The Press Foundation. It’s part of our Open Web Fellows program — if you are interested in this program, apply by March 20.

Thanks for being involved and for joining the discussion about encryption. It’s an important moment for all of us to be talking about these issues.

https://blog.mozilla.org/blog/2016/03/09/encryption-journalism-and-free-expression/

A quick tip. If you're running karma tests via Firefox on Travis CI by default the Firefox version used is quite old (31 at time of writing).

To always use the latest (current) version you can add this snippet to your .travis.yml.

addons:  
  firefox: latest

This will keep your firefox up-to-date as new versions are released. Two other special release aliases are available:

• latest-esr - The latest extended support release.
• latest-beta - The latest beta version.

You can of course specify a specific version like so:

addons:  
  firefox: "44.0"

For for info see the Travis docs on setting firefox versions here.

https://muffinresearch.co.uk/using-the-latest-version-of-firefox-in-travis-ci/

Since last time I wrote about WebExtensions, a lot has been going on: for instance, I used to link a Mozilla Wiki article, and as you can see now I'm linking a full featured MDN entry :)

In the meanwhile, I've been among other things hacking the WebExtensions code itself to make it suitable for eventually porting my own extensions, NoScript and FlashGot, and all those which share similar requirements.

The key WebExtensions API needed by adblockers (one of the most popular browser extensions category), by anti-trackers like Ghostery and, of course, by security add-ons like NoScript, is WebRequest. Its first implementation as a JavaScript module (still the foundation of the current one, which is a thin wrapper over it) even predates WebExtensions themselves: genius e10s hacker Bill McCloskey started it as a brave experiment to see how realistic could have been migrating Adblock/Ghostery/NoScript to the still just rumored "next thing" in add-on development.

Unfortunately, the way this API was originally implemented imposed harsh limitations, both in Chrome compatibility and, more annoyingly, in suitability for the very kind of add-ons it was meant to support. But we've got good news: I've recently landed a couple of patches (after a long time spent away from Mozilla's code repositories), paving the way to the removal of the remaining Chrome incompatibilities and for the addition of new divergent features required by NoScript & Co. which by the way, if ever borrowed in Chromium, could even finally make a NoScript porting on Google's browsers and derivatives possible.

More specifically, Firefox 47 adds:

• The requestId property in every WebRequest event, allowing listeners to track individual requests across their entire lifecycle (yes, it's incredible we had not implement it yet, and it was the main blocker for Ghostery as a WebExtension).
• Reliable HTTP headers manipulation - they can be examined, deleted, added or modified both in requests (by onBeforeSendHeaders listeners) and responses (onHeadersReceived) as plain JavaScript arrays of name-value pairs.
• HTTP response status code and raw status line reporting - without this, it was almost impossible telling the type of a redirection or even whether a request succeeded or failed and how.

Coming very soon:

• The onErrorOccurred event (patch ready, will surely land in 48), also needed by Ghostery.
• The requestBody property, which allows onBeforeRequest listeners to analyze the payload of POST and PUT requests and is required by NoScript's XSS filter.
• An "origin" property, which is required not just by many features of NoScript's but also by other add-ons such as RequestPolicy.

I'm very satisfied with the work done so far, and as soon as the 3 features above are completed, I'm ready to take on other areas where the Chrome extensions API (hence, for obvious reasons, WebExtensions in their present state) are severely lacking, such as script execution control and fine-tuned content blocking, which still prevent NoScript from migrating.

During the past weeks I've grown intimate with the WebExtensions API source code and familiar enough with the "modern" Firefox development workflow. I'm sure this incoming spring will be a most interesting time, and I'm confident that summer will come with a brand new NoScript, reborn as a WebExtension :)

https://hackademix.net/2016/03/09/webrequest-where-were-where-were-going/

Our PL reading group read the paper “

https://www.msully.net/blog/2015/02/26/microkanren-%ce%bckanren-in-haskell/

I sent this to dev-planning, dev-platform, sheriffs and tools-taskcluster today. I added a little more context for a non-Mozilla audience.

The time has come! We are planning to switch to Tier-1 on Treeherder for TaskCluster Linux 64 Debug build jobs on March 14. At the same time, we will hide the Buildbot build jobs, but continue running them. This means that these jobs will become what Sheriffs use to determine the health of patches and our trees.

On March 21, we plan to switch the Linux 64 Debug tests to Tier-1 and hide the related Buildbot test jobs.

After about 30 days, we plan to disable and remove all Buildbot jobs related to Linux Debug.

Background:

We’ve been running Linux 64 Debug builds and tests using TaskCluster side-by-side with Buildbot jobs since February 18th. Some of the project work that was done to green up the tests is documented here.

The new tests are running in Docker-ized environments, and the Docker images we use are defined in-tree and publicly accessible.

This work was the culmination of many months of effort, with Joel Maher, Dustin Mitchell and Armen Zambrano primarily focused on test migration this quarter. Thank you to everyone who responded to NEEDINFOs, emails and pings on IRC to help with untangling busted test runs.

On performance, we’re taking a 14% hit across all the new test jobs vs. the old jobs in Buildbot. We ran two large-scale tests to help determine where slowness might still be lurking, and were able to find and fix many issues. There are a handful of jobs remaining that seem significantly slower, while others are significantly faster. We decided that it was more important to deprecate the old jobs and start exclusively maintaining the new jobs now, rather than wait to resolve the remaining performance issues. Over time we hope to address issues with the owners of the affected test suites.

http://www.chesnok.com/daily/2016/03/08/tier-1-status-for-linux-64-debug-build-jobs-on-march-14-2016/

Hace algunos minutos Mozilla lanz'o una nueva versi'on de Firefox y ya podemos gozar de nuevas e interesantes funcionalidades en nuestro navegador favorito. Si no lo sab'ias, las versiones del panda rojo ya no ser'an liberadas cada 6 semanas y de ahora en adelante tendr'an un ritmo variado que oscila entre 6 y 8 semanas.

La API Web Speech

Si alguna vez so~naste con hablarle a una p'agina web y que esta ejecutase acciones al igual que haces en iOS o en Android, desde Firefox ya lo puedes hacer. Web Speech permite incorporar datos en nuestras p'aginas y aplicaciones web, permitiendo que determinadas funciones como la autenticaci'on puedan ser controladas por la voz.

Web Speech comprende dos componentes fundamentales: el reconocimiento (como su nombre lo indica, se encarga de reconocer la voz desde un dispositivos de entrada) y la s'intesis (texto a voz). Para m'as detalles de c'omo emplear esta API puedes leer el art'iculo publicado en MDN. En GitHub tambi'en podr'as encontrar algunos ejemplos que ilustran el reconocimiento y s'intesis de voz.

Pesta~nas sincronizadas a la vista

Desde la inclusi'on de Sync en el navegador puedes compartir tu informaci'on y preferencias (como marcadores, contrase~nas, pesta~nas abiertas, lista de lectura y complementos instalados) con todos tus dispositivos para mantenerte actualizado y no perderte nada.

Con este lanzamiento, ver las pesta~nas abiertas en otros dispositivos ser'a mucho m'as f'acil e intuitivo pues al sincronizar inmediatamente se mostrar'a el bot'on  en la barra de herramientas, el cual te permite acceder mediante un panel a estas p'aginas en tu equipo con tan solo un clic. Tambi'en, mientras busques en la barra de direcciones, las pesta~nas ser'an mostradas en la lista desplegable.

Panel que muestra las pesta~nas abiertas en otros dispositivos

Si nunca has configurado Sync y deseas hacerlo, puedes leer este art'iculo en la Ayuda de Mozilla. !Es muy f'acil y r'apido!

Firefox habla guaran'i

Gracias a la colaboraci'on de las comunidades Mozilla de Paraguay y Bolivia, y de la Universidad Nacional de Asunci'on (UNA) ha sido posible traducir Firefox al guaran'i, lengua originaria de Latinoam'erica y muy empleada en Paraguay junto al espa~nol, tambi'en es hablada en algunas regiones del sur de Brasil y el norte de Argentina, as'i como en una zona de Bolivia.

Dicho proyecto, bautizado con el nombre de Aguaratata (zorro de fuego) tuvo una duraci'on de aproximadamente 2 a~nos y se tradujeron m'as de 45 000 palabras. De esta forma, el guaran'i pasar'a a ser una de las 91 localizaciones o traducciones en las que se puede obtener Firefox.

Adi'os a los grupos de pesta~nas

Panorama, la funcionalidad que nos permit'ia gestionar grupos y organizar nuestras pesta~nas finalmente ser'a eliminada de Firefox. Desde hace alg'un tiempo esta noticia ven'ia dando rumbos, ya que Panorama era usada solamente por menos del 1% de los usuarios y por parte de los desarrolladores, su mantenimiento era complicado frente a los cambios que est'an sucediendo actualmente en el coraz'on de Firefox.

Si eres de los que usaba esta caracter'istica, cuando actualices a la versi'on 45 de Firefox, te aparecer'a una pesta~na especial explic'andote lo que ha pasado. Todos tus grupos de pesta~nas se convertir'an en marcadores autom'aticamente y se guardar'an en la carpeta de marcadores. Podr'as acceder a ellos haciendo clic en el bot'on de marcadores en la barra de herramientas.

Si quieres un reemplazo directo, prueba el complemento Tab Groups. El cual se ha creado directamente a partir del c'odigo de Firefox y funciona justo como la antigua funci'on. Si lo instalas antes de actualizar a la versi'on 45 de Firefox:

• Los grupos de pesta~nas de Firefox se migrar'an autom'aticamente al complemento.
• Firefox no convertir'a tus grupos en marcadores, como se describe m'as arriba.

Al utilizar Tab Groups ser'a como si no la funci'on no hubiera desaparecido de Firefox y no notar'as el cambio al actualizar.

Para Android

• Adicionada una opci'on para deshabilitar el uso compartido de la c'amara y el micr'ofono en la interfaz de administraci'on para la navegaci'on familiar.
• La opci'on clic para ver im'agenes en el men'u de configuraci'on avanzado permite a los usuarios elegir las im'agenes a descargar y conservar el uso de datos.
• Reemplazadas las notificaciones con snackbar.
• Optimizada o re-organizada “Configuraci'on” bajo el “Men'u”.
• Deshabilitada la inclusi'on de la URL cuando se comparte el texto seleccionado de una p'agina web.
• Simplificada la interfaz de administraci'on de navegaci'on familiar en tabletas durante el perfil restringido.

Otras novedades para desarrolladores

• Clases en JavaScript.
• Soporte a Push API, parte de las Aplicaciones Web Progresivas.
• Posibilidad de filtrar la salida de la captura en la herramienta de Memoria.
• Capacidad de ajustar las animaciones al cambiar la velocidad de reproducci'on en la l'inea de tiempo del Inspector de animaciones.
• Los eventos DOMContentLoaded y load son mostrados en la l'inea de tiempo del Monitor de red.
• Adicionado el filtrado negativo de direcciones para el Monitor de red.
• A~nadido el soporte para diferenciar las capturas en la herramienta de Memoria.
• La b'usqueda del Inspector Web ahora machea el resultado desde todo el contenido de la p'agina web, incluyendo los subframes.
• La lista de propiedades animadas y keyframes son mostradas cuando se da clic sobre alguna animaci'on en la l'inea de tiempo del Inspector de animaciones.

Si prefieres ver la lista completa de novedades, puedes llegarte hasta las notas de lanzamiento (en ingl'es).

A'un no contamos con la versi'on para m'oviles pero cuando las tengamos les avisamos.

Puedes obtener esta versi'on desde nuestra zona de Descargas en espa~nol e ingl'es para Linux, Mac y Windows. Si te ha gustado, por favor comparte con tus amigos esta noticia en las redes sociales. No dudes en dejarnos un comentario.

http://firefoxmania.uci.cu/firefox-estrena-web-speech-api-localizacion-en-guarani-y-nuevas-herramientas-para-desarrolladores/

Following up from my last post, I’ve had some time to research and assess the current state of embedding Gecko. This post will serve as a (likely incomplete) assessment of where we are today, and what I think the sensible path forward would be. Please note that these are my personal opinions and not those of Mozilla. Mozilla are gracious enough to employ me, but I don’t yet get to decide on our direction

http://chrislord.net/index.php/2016/03/08/state-of-embedding-in-gecko/

Firefox Hello Beta is a communication tool that lets you share tabs you’re browsing in Firefox with others and chat over video or text, free and without needing an account or login. Firefox Hello Beta in Windows, Mac and Linux helps you discuss and make decisions about anything online by sharing the website you’re browsing in your conversation. This makes it easier and faster to do things like to shop online together with friends, plan a vacation with the family or collaborate on work with a colleague.

When you click the Firefox Hello icon in Firefox and invite someone to your conversation, Hello will instantly share the tab you’re viewing with them when they join.

Firefox Hello on Windows, Mac and Linux is developed with our partner Telef'onica and we’re always working on adding features, including the ability to pause sharing and more.

We hope you enjoy using the updated Firefox Hello Beta and we look forward to sharing more updates about new features we’re testing on our Future Releases Blog.

More information:

• Download Firefox for Windows, Mac, Linux
• Release Notes for Firefox for Windows, Mac, Linux
• Download Firefox for Android
• Release Notes for Firefox for Android

https://blog.mozilla.org/blog/2016/03/08/updates-to-firefox-hello-beta/

the following changes have been pushed to bugzilla.mozilla.org:

• [1252628] 404 on https://www.mozilla.org/en-US/quality/bug-writing-guidelines.html
• [1253032] Recent change to JSON::XS breaks some APIs
• [1252735] test_email_preferences.t selenium test is intermittently failing
• [1252862] Remove calls to delete_token() in several places where it is unnecessary
• [1252084] Warning when entering row into user_request_log when running commandline script
• [1253691] issue-api-key.pl needs to take an app_id as well
• [1251442] Update VP list in Recruiting Product
• [1252445] Tracking flags configuration is vulnerable to CSRF and causes persistent XSS
• [1252554] Avoid possibility of XSS in release tracking report

discuss these changes on mozilla.tools.bmo.

https://dlawrence.wordpress.com/2016/03/08/happy-bmo-push-day-7/

One little-known way to be a SUMO hero participant in SUMO this week is tweeting, posting on facebook and answering a support forum question. Come to the support forum for SUMO questions day. For the Release of Firefox 45 on Desktop and Mobile.

In the world of Social, Madalina is leading the first ever Social day for SUMO Support.  With the Army of Awesome and a new fancy tool called Sprinkler, Facebook and Twitter will not know what hit them if you decide to tune in and make a post. Before you know it you will be getting Facebook’s new emoticons. When you are tweeting, remember you can sign up to be part of the Awesome here.

I like that post!

See the etherpad to find out more about how you can tweet, like, and express empathy for Firefox users looking for support. It will take place all day on Tuesday March 8, 2016, the planned date for the new Firefox 45 release.

And two days later, if you missed Tuesday or cannot get enough (and think “my participation activity list must have some support forum question threads answers”), the forum SUMO day is happening in the support forum for 24 hours on March 10, 2016. Do not worry, expect a reminder. If you do not have an account yet, there are instructions on how to get one on our Get Started page.  When the questions come in, we will see you at the starting line in the forums.

This etherpad has instructions on everything you need to know regarding participation.

“If you are passionate about something, then you should pick up your flag and run with it” –Bette Midler, (singer, comedian b. 1945)

I hereby give you the license to participate and can’t wait to see you online this week under the banner of our mighty Firefox 45.

https://blog.mozilla.org/sumo/2016/03/08/firefox-45-launch-social-day-and-sumo-day-march-8-2016/

Stockholm City, as photographed by Michael Caven

In July 2015, 40-something HTTP implementers and experts of the world gathered in the city of M"unster, Germany, to discuss nitty gritty details about the HTTP protocol during four intense days. Representatives for major browsers, other well used HTTP tools and the most popular HTTP servers were present. We discussed topics like how HTTP/2 had done so far, what we thought we should fix going forward and even some early blue sky talk about what people could potentially see being subjects to address in a future HTTP/3 protocol.

You can relive the 2015 version somewhat from my daily blog entries from then that include a bunch of details of what we discussed: day one, two, three and four.

The HTTP Workshop was much appreciated by the attendees and it is now about to be repeated. In the summer of 2016, the HTTP Workshop is again taking place in Europe, but this time as a three-day event slightly further up north: in the capital of Sweden and my home town: Stockholm. During 25-27 July 2016, we intend to again dig in deep.

If you feel this is something for you, then please head over to the workshop site and submit your proposal and show your willingness to attend. This year, I’m also joining the Program Committee and I’ve signed up for arranging some of the local stuff required for this to work out logistically.

The HTTP Workshop 2015 was one of my favorite events of last year. I’m now eagerly looking forward to this year’s version. It’ll be great to meet you here!

The city of Stockholm in summer sunshine

https://daniel.haxx.se/blog/2016/03/08/summers-are-for-http/

Hi everyone!

Last Friday, March 4th, we held Firefox 46.0 Aurora Testday.  It was a successful event (please see the results section below) so a big Thank You goes to everyone involved.

First of all, many thanks to our active contributors: chaithanya, Iryna Thompson, Chandrakant Dhutadmal, gaby2300, Chandana, kenkon, Md Shahbaz Alam, Hossain Al Ikram, Rezaul Huque Nayeem, Azmina Akter Papeya, Md. Rahimul Islam, Sajedul Islam, Kazi Nuzhat Tasnem, Shaily Roy, Raihan Ali, Saddam Hossain, Samad Talukdar, Jobayer Ahmed Mickey, Md.Tarikul Islam Oashi, Mohammad Maruf Islam, MD. NAZMUS SHAKIB (ROBIN), Khalid Syfullah Zaman, Nazir Ahmed Sabbir, Mohammad Mosfiqur Rahman, Saheda Reza Antora, Sayed Ibn Masud, Fazle Rabbi, Tanvir Rahman, Maruf Rahman, Mamun Md. Toufiqul Haque, Kazi Sakib Ahmad, Forhad Hossain, Zubayer Alam Shuvo, sourov debnath, Md. Ehsanul Hassan, Mohammed Jawad Ibne Ishaque, Md. Almas Hossain, Asif Mahmud Shuvo, Wahiduzzaman Hridoy.

Secondly, a big thank you to all our active moderators.

Results:

• several testcases executed for the APZ and e10s plugins features
• 1 new bug filed: 1253694
• 7 bugs were verified: 1243125, 1248128, 1047395, 1207168, 1044365, 1043586, 1245654

We hope to see you all in our next events, all the details will be posted on QMO!

https://quality.mozilla.org/2016/03/firefox-46-0-aurora-testday-results/

It seems like I’m only managing one blog post a month at the moment. I’m doing loads of things, but don’t seem to have time to blog about them! Currently, the major components of my work are:

• Helping Thunderbird get to a good and sustainable place (status update)
• Running MOSS (applications always open!)
• Copyright work for the public policy team

On that last point, we just submitted a filing to a US Copyright Office consultation on the famous section 1201 of the DMCA, which is the one which regulates the every three years exemption process for bypassing DRM. See our blog post here, which links to our filing. While this process is not really fixable in its current form, I hope we can help to make it a little better.

http://feedproxy.google.com/~r/HackingForChrist/~3/h7Bl_zdxSjI/

The TaskCluster Platform team is in Portland this week, hacking on the taskcluster-worker.

Today, we all sync’d up on the current state of our worker, and what we’re going to hack on this week. We started with the current docs.

The reason why we’re investing so much time in the worker is two fold:

• The worker code previously lived in two code bases – docker-worker and generic-worker. We need to unify these code bases so that multiple engineers can work on it, and to help us maintain feature parity.
• We need to get a worker that supports Windows into production. For now, we’re using the generic-worker, but we’d like to switch over to taskcluster-worker in late Q2 or early Q3. This timeline lines up with when we expect the Windows migration from Buildbot to happen.

One of the things I asked this team to do was come up with some demos of the new worker. The first demo today was to simply output a log and upload it from Greg Arndt.

The rest of the team is getting their Go environments set up to run tests and get hacking on crucial plugins, like our environment variable handling and additional artifact uploading logic we need for our production workers.

We’re also taking the opportunity to sync up with our Windows environment guru. Our goal for Buildbot to TaskCluster migration this quarter is focused on Linux builds and tests. Next quarter, we’ll be finishing Linux and, I hope, landing Windows builds in TaskCluster. To do that, we have a lot of details to sort out with how we’ll build Windows AMIs and deploy them. It’s a very different model because we don’t have the same options with Docker as we have on Linux.

http://www.chesnok.com/daily/2016/03/07/portland-taskcluster-worker-hello-world/

I remember a time, not so very long ago, when Gecko powered 4 or 5 non-Mozilla browsers, some of them on exotic platforms, as well as GPS devices, wysiwyg editors, geographic platforms, email clients, image editors, eBook readers, documentation browsers, the UX of virus scanners, etc, as well as a host of innovative and exotic add-ons. In these days, Gecko was considered, among other things, one of the best cross-platform development toolkits available.

The year is now 2016 and, if you look around, you’ll be hard-pressed to find Gecko used outside of Firefoxen (alright, and Thunderbird and Bluegriffon). Did Google or Apple or Microsoft do that? Not at all. I don’t know how many in the Mozilla community remember this, but this was part of a Mozilla strategy. In this post, I’d like to discuss this strategy, its rationale, and the lessons that we may draw from it.

Building a Gecko monoculture

For the first few years of Firefox, enthusiasm for the technology behind the browser was enormous. After years of implementing Gecko from scratch, Mozilla had a kick-ass cross-platform toolkit that covered almost everything from system interaction to network, cryptography, user interface, internationalization, even an add-on mechanism, a scripting language and a rendering engine. For simplicity, let’s call this toolkit XUL. Certainly, XUL had a number of drawbacks, but in many ways, this toolkit was years ahead of everything that other toolkits had to offer at the time. And many started to use XUL for things that had never been planned. Dozens of public projects and certainly countless more behind corporate doors. Attempts were made to extend XUL towards Python, .Net, Java and possibly more. These were the days of the “XUL Planet”. All of this was great – for one, that is how I joined the Mozilla community, embedding Gecko in exotic places and getting it to work nicely with exotic network protocols.

But this success was also hurting Mozilla’s mission in two ways. The first way was the obvious cost. The XUL platform had a huge API, in JavaScript, in C, in C++, in IDL, in declarative UI (XUL and XBL), not to mention its configuration files and exotic query language (hello, RDF, I admit that I don’t really miss you that much), and I’m certain I miss a few. Oh, that’s not including the already huge web-facing API that can never abandon backwards compatibility with any feature, of course. Since third-party developers could hit any point of this not-really-internal API, any change made to the code of Gecko had the potential of breaking applications in subtle and unexpected ways – applications that we often couldn’t test ourselves. This meant that any change needed to be weighed carefully as it could put third-party developers out of business. That’s hardly ideal when you attempt to move quickly. To make things worse, this API was never designed for such a scenario, many bits were extremely fragile and often put together in haste with the idea of taking them down once a better API was available. Unfortunately, in many cases, fixing or replacing components often proved impossible, for the sake of compatibility. And to make things even worse, the XUL platform was targeting an insane number of Operating Systems, including Solaris, RiscOS, OS/2, even the Amiga Workbench if I recall correctly. Any change had to be kept synchronized between all these platforms, or, once again, we could end up putting third-party developers out of business by accident.

So this couldn’t last forever.

Another way this success was hurting Mozilla is that XUL was not the web. Recall that Mozilla’s objectives were not to create yet another cross-platform toolkit, no matter how good, but to Take Back the Web from proprietary and secret protocols. When the WhatWG and HTML5 started rising, it became clear that the web was not only taken back, but that we were witnessing the dawn of a new era of applications, which could run on all operating systems, which were based on open protocols and at least at some level on open-source. The Web Applications were the future – an ideal future, by some criteria – and the future was there. In this context, non-standard, native cross-platform toolkits were a thing of the past, something that Mozilla was fighting, not something that Mozilla should be promoting. It made entire sense to stop putting resources in XUL and concentrate more tightly on the web.

So XUL as a cross-platform toolkit couldn’t last forever.

I’m not sure exactly who took the decision but at some point around 2009, Mozilla’s strategy changed. We started deprecating the use cases of Gecko that were not the Web Platform. This wasn’t a single decision or a single fell swoop, and this didn’t go in one single unambiguous direction, but this happened. We got rid of the impedimenta.

We reinvented Gecko as a Firefox monoculture.

Living in a monoculture

We have now been living in a Gecko monoculture long enough to be able to draw lessons from our choices. So let’s look at the costs and benefits.

API and platform cost

Now that third-party developers using Gecko and hitting every single internal API are gone, it is much easier to refactor. Some APIs are clearly internal and I can change them without referring to anyone. Some are still accessible by add-ons, and I need to look for add-ons that use them and get in touch with their developers, but this is still infinitely simpler than it used to be. Already, dozens of refactorings that were critically needed but that had been blocked at some point in the past by backwards internal compatibility have been made possible. Soon, Jetpack WebExtensions will become the sole entry point for writing most add-ons, and Gecko developers will finally be free to refactor their code at will as long as it doesn’t break public APIs, much like developers of every single other platform on the planet.

Similarly, dropping support for exotic platforms made it possible to drop plenty of legacy code that was hurting refactoring, and in many cases, made it possible to write richer APIs without being bound by the absolute need to implement everything on every single platform.

In other words, by the criteria of reducing costs and increasing agility, yes, the Gecko monoculture has been a clear success.

Web Applications

Our second objective was to promote web applications. And if we look around, these days, web applications are everywhere – except on mobile. Actually, that’s not entirely true. On mobile, a considerable number of applications are built using PhoneGap/Cordova. In other word, these are web applications, wrapped in native applications, with most of the benefits of both worlds. Indeed, one could argue that PhoneGap/Cordova applications are more or less applications which could have been developed with XUL, and are instead developed with a closer-to-standards approach. As a side-note, it is a little-known fact is that one of the many (discarded) designs of FirefoxOS was as a runtime somewhat comparable to PhoneGap/Cordova, and which would have replaced the XUL platform.

Despite the huge success of web applications and even the success of hybrid web/native applications, the brand new world in which everything would be a web application hasn’t arrived yet, and it is not sure that it ever will. The main reason is that mobile has taken over the world. Mobile applications need to integrate with a rather different ecosystem, with push notifications, working disconnected, transactions and microtransactions, etc. not to mention a host of new device-specific features that were not initially web-friendly. Despite the efforts of most browser vendors, browser still haven’t caught up this moving target. New mobile device have gained voice recognition and in the meantime, the WhatWG is still struggling to design a secure, cross-platform API for accessing local files.

In other words, by the criteria of pushing web applications, I would say that the Gecko monoculture has had a positive influence, but not quite enough to be called a success.

The Hackerbase

Now that we have seen the benefits of this Gecko monoculture, perhaps it is time to look at the costs.

By turning Gecko into a Firefox monoculture, we have lost dozens of products. We have almost entirely lost the innovations that were not on the roadmap of the WhatWG, as well as the innovators themselves. Some of them have turned to web applications, which is what we wanted, or hybrid applications, which is close enough to what we wanted. In the meantime, somewhere else in the world, the ease of embedding first WebKit and now Chromium (including Atom/Electron) have made it much easier to experiment and innovate with these platforms, and to do everything that has ever been possible with XUL, and more. Speaking only for myself, if I were to enter the field today with the same kind of technological needs I had 15 years ago, I would head towards Chromium without a second thought. I find it a bit sad that my present self is somehow working against my past self, while they could be working together.

By turning our back on our Hackerbase, we have lost many things. In the first place, we have lost smart people, who may have contributed ideas or code or just dynamism. In the second place, we have lost plenty of opportunities for our code and our APIs to be tested for safety, security, or just good design. That’s already pretty bad.

Just as importantly, we have lost opportunities to be part of important projects. Chris Lord has more to say on this topic, so I’ll invite you to read his post if you are interested.

Also, somewhere along the way, we have largely lost any good reason to provide clean and robust APIs, to separate concerns between our libraries. I would argue that the effects of this can be witnessed in our current codebase. Perhaps not in the web-facing APIs, that are still challenged by their (mis)usage in terms of convenience, safety and robustness, but in all our internal+addons APIs, many of which are sadly under-documented, under-tested, and designed to break in new and exciting ways whenever they are confronted with unexpected inputs. One could argue that the picture I am painting is too bleak, and that some of our fragile APIs are, in fact, due to backwards compatibility with add-ons or, at some point, third-party applications.

Regardless, by the criteria of our Hackerbase, I would count the Gecko monoculture as a bloody waste.

Bottom line

So the monoculture has succeeded at making us faster, has somewhat helped propagate Web Applications, and has hurt us by severing our hackerbase.

Before starting to write this blogpost, I felt that turning Gecko into a Firefox monoculture was a mistake. Now, I realize that this was probably a necessary phase. The Gecko from 2006 was impossible to fix, impossible to refactor, impossible to improve. The Firefox from 2006 would have needed a nearly-full reimplementation to support e10s or Rust-based code (ok, I’m excluding Rust-over-XPConnect, which would be a complete waste). Today’s Gecko is much fitter to fight against WebKit and Chromium. I believe that tomorrow’s Gecko – not Firefox, just Gecko – with full support for WebExtensions and progressive addition of new, experimental WebExtensions, would be a much better technological base for implementing, say, a cross-platform e-mail client, or an e-Book reader, or even a novel browser.

As all phases, though, this monoculture needs to end sooner or later, and I certainly hope that it ends soon, because we keep paying the cost of this transformation through our community.

Surviving the monoculture

An exit strategy from the Gecko monoculture

It is my belief that we now need to consider an exit strategy from the Gecko monoculture. No matter which strategy is picked, it will have a cost. But I believe that the potential benefits in terms of community and innovation will outweigh these costs.

First, we need to avoid repeating past mistakes. While WebExtensions may not cover all the use cases for which we need an extension API for Gecko, they promise a set of clean and high-level APIs, and this is a good base. We need to make sure that whatever we offer as part of WebExtensions or in addition to them remains a set high-level, well-insulated APIs, rather than the panic-inducing entanglement that is our set of internal APIs.

Second, we need to be able to extend our set of extension APIs in directions we not planned by any single governing body, including Mozilla. When WebExtensions were first announced, the developers in charge of the project introduced a uservoice survey to determine the features that the community expected. This was a good start, but this will not be sufficient in the long run. Around that time, Giorgio Maone drafted an API for developing and testing experimental WebExtensions features. This was also a good start, because experimenting is critical for innovation. Now, we need a bridge to progressively turn experimental extension APIs into core APIs. For this purpose, I believe that the best mechanism is a RFC forum and a RFC process for WebExtensions, inspired from the success of RFCs in the Rust (or Python) community.

Finally, we need a technological brick to get applications other than Firefox to run Gecko. We have experience doing this, from XULRunner to Prism. A few years ago, Mike De Boer introduced “Chromeless 2”, which was roughly in the Gecko world what Electron is nowadays in the Chromium world. Clearly, this project was misunderstood by the Mozilla community – I know that it was misunderstood by me, and that it took Electron to make me realize that Mike was on the right track. This project was stopped, but it could be resumed or rebooted. To make it easier for the community, using the same API as Electron, would be a possibility.

Keeping projects multicultural

Similarly, I believe that we need to consider strategies that will let us avoid similar monocultures in our other projects. This includes (and is not limited to) B2G OS (formerly known as Firefox OS), Rust, Servo and Connected Devices.

So far, Rust has proved very open to innovation. For one thing, Rust has its RFC process and it works very well. Additionally, while Rust was originally designed for Servo, it has already escaped this orbit and the temptation of a Servo monoculture. Rust is now used for cryptocurrencies, operating systems, web servers, connected devices… So far, so good.

Similarly, Servo has proved quite open, albeit in very different directions. For one thing, Servo is developed separately from any web browser that may embed it, whether Servo Shell or Browser.html. Also, Servo is itself based on dozens of libraries developed, tested and released individually, by community members. Similarly, many of the developments undertaken for Servo are released themselves as independent libraries that can independently be maintained or integrated in yet other projects… I have hopes that Servo, or at least large subsets, will eventually find its way into projects unrelated to Mozilla, possibly unrelated to web browsers. My only reservation is that I have not checked how much effort the Servo team has made into checking that the private APIs of Servo remain private. If this is the case, so far, so good.

The case of Firefox OS/B2G OS is quite different. B2G OS was designed from scratch as a Gecko application and was entirely dependent on Gecko and some non-standard extensions. Since the announcement that Firefox OS would be retired – and hopefully continue to live as B2G OS – it has been clear that B2G-specific Gecko support would be progressively phased out. The B2G OS community is currently actively reworking the OS to make sure that it can live in a much more standard environment. Similarly, the Marketplace, which was introduced largely to appease carriers, will disappear, leaving B2G OS to live as a web OS, as it was initially designed. While the existence of the project is at risk, I believe that these two changes, together, have the potential to also set it free from a Gecko + Marketplace + Telephone monoculture. If B2G is still alive in one or two years, it may have become a cross-platform, cross-rendering engine operating system designed for a set of devices that may be entirely different from the Firefox Phones. So, I’m somewhat optimistic.

As for Connected Devices, well, these projects are too young to be able to judge. It is our responsibility to make sure that we do not paint ourselves into monocultural corners.

edit Added a link to Chris Lord’s post on the topic of missed opportunities.

https://dutherenverseauborddelatable.wordpress.com/2016/03/07/the-gecko-monoculture/