Mark BannerFirefox Hello Desktop: Behind the Scenes – Architecture

This is the second of some posts I’m writing about how we implement and work on the desktop and standalone parts of Firefox Hello. The first post was about our use of Flux and React, this second post is about the architecture.

In this post, I will give an overview of the Firefox browser software architecture for Hello, which includes the standalone UI.

User-visible parts of Hello

Although there’s many small parts to Hello, most of it is shaped by what is user visible:

Firefox Hello Desktop UI (aka Link-Generator)

Hello Standalone UI (aka Link-clicker)

Firefox Browser Architecture for Hello

The in-browser part of Hello is split into three main areas:

  • The panel which has the conversation and contact lists. This is a special about: page that is run in the content process with access to additional privileged APIs.
  • The conversation window where conversations are held. Within this window, similar to the panel, is another about: page that is also run in the content process.
  • The backend runs in the privileged space within gecko. This ties together the communication between the panels and conversation windows, and provides access to other gecko services and parts of the browser to which Hello integrates.
Outline of Hello's Desktop Architecture

Outline of Hello’s Desktop Architecture

MozLoopAPI is our way of exposing small bits of the privileged gecko (link) code to the about: pages running in content. We inject a navigator.mozLoop object into the content pages when they are loaded. This allows various functions and facilities to be exposed, e.g. access to a backend cache of the rooms list (which avoids multiple caches per window), and a similar backend store of contacts.

Standalone Architecture

The Standalone UI is simply a web page that’s shown in any browser when a user clicks a conversation link.

The conversation flow is in the standalone UI is very similar to that of the conversation window, so most of the stores and supporting files are shared. Most of the views for the Standalone UI are currently different to those from the desktop – there’s been a different layout, so we need to have different structures.

Outline of Hello's Standalone UI Architecture

Outline of Hello’s Standalone UI Architecture

File Architecture as applied to the code

The authoritative location for the code is mozilla-central it lives in the browser/components/loop directory. Within that we have:

  • content/ – This is all the code relating to the panel and conversation window that is shipped on in the Firefox browser
  • content/shared/ – This code is used on browser as well as on the standalone UI
  • modules/ – This is the backend code that runs in the browser
  • standalone/ – Files specific to the standalone UI

Future Work

There’s a couple of likely parts of the architecture that we’re going to rework soon.

Firstly, with the current push to electrolysis, we’re replacing the current exposed MozLoopAPI with a message-based RPC mechanism. This will then let us run the panel and conversation window in the separated content process.

Secondly, we’re currently reworking some of the UX and it is moving to be much more similar between desktop and standalone. As a result, we’re likely to be sharing more of the view code between the two.

Interested in learning more?

If you’re interested in learning more about Hello’s architecture, then feel free to dig into the code, or come and ask us questions in #loop on irc.

If you want to help out with Hello development, then take a look at our wiki pages, our mentored bugs or just come and talk to us.

About:CommunityFirefox 39 new contributors

With the release of Firefox 39, we are pleased to welcome the 64 developers who contributed their first code change to Firefox in this release, 55 of whom were brand new volunteers! Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions:

  • agrigas: 1135270
  • bmax1337: 967319
  • leo: 1134993
  • schtroumps31: 1130045
  • zmiller12: 1138873
  • George Duan: 1135293
  • Abhinav Koppula: 732688, 951695, 1127337
  • Alex Verstak: 1113431, 1144816
  • Alexandre Ratchov: 1144087
  • Andrew Overholt: 1127552
  • Anish: 1135091, 1135383
  • Anush: 418517, 1113761
  • Bhargav Chippada: 1112605, 1130372
  • Boris Kudryavtsev: 1135364, 1144613
  • Cesar Guirao: 1139132
  • Chirag Bhatia: 1133211
  • Danilo Cesar Lemes de Paula: 1146020
  • Daosheng Mu: 1133391
  • Deepak: 1039540
  • Felix Janda: 1130164, 1130175
  • Gareth Aye: 1145310
  • Geoffroy Planquart: 942475, 1042859
  • Gerald Squelart: 1121774, 1135541, 1137583
  • Greg Arndt: 1142779
  • Henry Addo: 1084663
  • Jason Gersztyn: 1132673
  • Jeff Griffiths: 1138545
  • Jeff Lu: 1098415, 1106779, 1140044
  • Johan K. Jensen: 1096294
  • Johannes Vogel: 1139594
  • John Giannakos: 1134568
  • John Kang: 1144782, 1146252
  • Jorg K: 756984
  • Kyle Thomas: 1137004
  • Léon McGregor: 1115925, 1130741, 1136708
  • Manraj Singh [:manrajsingh|Away till 21st June]: 1120408
  • Mantaroh Yoshinaga: 910634, 1106905, 1130614
  • Markus Jaritz: 1139174
  • Massimo Gervasini: 1137756, 1144695
  • Matt Hammerly: 1124271
  • Matt Spraggs: 1036454
  • Michael Weisz : 736572, 782623, 935434
  • Mitchell Field: 987902
  • Mohamed Waleed: 1106938
  • NiLuJe: 1143411
  • Perry Wagle: 1122941
  • Ponç Bover: 1126978
  • Quentin Pradet: 1092544
  • Ravi Shankar: 1109608
  • Rishi Baldawa: 1143196
  • Stéphane SCHMIDELY: 935259, 1144619
  • Sushrut Girdhari (sg345): 1137248
  • Thomas Baquet: 1132078
  • Titi_Alone : 1133063
  • Tyler St. Onge: 1134927
  • Vaibhav Bhosale: 1135009
  • Vidit23: 1121317
  • Wickie Lee: 1136253
  • Zimon Dai: 983469, 1135435
  • atlanto: 1137615
  • farhaan: 1073234
  • pinjiz: 1124943, 1142260, 1142268
  • qasim: 1123431
  • ronak khandelwal: 1122767
  • uelis: 1047529
  • Karl DubostWatch A Computing Engineer Live Coding

    Mike (Taylor) has been telling me about the live coding session of Mike Conley for a little while. So yesterday I decided to give it a try with the first episode of The Joy of Coding (mconley livehacks on Firefox). As mentionned in the description:

    Unscripted, unplanned, uncensored, and true to life, watch what a Firefox Desktop engineer does to close bugs and get the job done.

    And that is what is written on the jar. And sincerely this is good.

    Why Should You Watch Live Coding?

    I would recommend to watch this for:

    • Beginner devs: To understand that more experienced developers struggle and make mistakes too. To also learn a couple of good practices when coding.
    • Experienced devs: To see how someone is coding and learn a couple of new tricks and habits when coding. To encourage them to do the same kind of things than Mike is doing.
    • Managers: You are working as a manager in a Web agency, you are a project manager, watch this. You will not understand most of it, but focus exactly on what Mike is doing in terms of thoughts process and work organization. Even without a knowledge of programming, we discover the struggles, the trials and errors, and the success.

    There's a full series of them, currently 19.

    My Own (Raw) Notes When Watching The Video

    • Watching the first video of Live Coding
    • He started with 3 video scenes and switched to his main full screen
    • He's introducing himself
    • mconley: "Nothing is prepared"
    • He's introducing the bug and explained it in demonstrating it
    • mconley: "I like to take notes when working on bugs" (taken in evernote)
    • mconley: "dxr is better than mxr."
    • He's not necessary remembering everything. So he goes through other parts of the code to understand what others did.
    • Sometimes he just doesn't know, doesn't understand and he says it.
    • mconley: "What other people do?"
    • He's taking notes including some TODOs for the future to explore, understand, do.
    • He's showing his fails in compiling, in coding, etc.
    • (personal thoughts) It's hard to draw on a computer. Paper provides some interesting features for quickly drawing something. Computer loses, paper wins.
    • When recording, thinking with a loud voice gives context on what is happening.
    • Write comments in the code for memory even if you remove them later.
    • In your notes, cut and paste the code from the source. Paper loses, computer wins.
    • (personal thoughts): C++ code is ugly to read.
    • (personal thoughts): Good feeling for your own job after watching this. It shows you are not the only one struggling when doing stuff.

    Some Additional Thoughts

    We met Mike Conley in Whistler, Canada last week. He explained he used Open Broadcasting Project for recording his sessions. I'm tempted to do something similar for Web Compatibility work. I'm hesitating in between French and English. Maybe if Mike was doing something in English, I might do it in French. So people in the French community could benefit of it.

    So thanks Mike for telling me about this in the last couple of weeks.

    Otsukare!

    Air MozillaDXR 2.0 (Part 2: Discussion)

    DXR 2.0 (Part 2: Discussion) A discussion of the roadmap for DXR after 2.0

    Air MozillaDXR 2.0 (Part 1: Dog & Pony Show)

    DXR 2.0 (Part 1: Dog & Pony Show) Demo of features new in the upcoming 2.0 release of DXR, Mozilla's search and analysis tool for large codebases

    Daniel GlazmanCSS Working Group's future

    Hello everyone.

    Back in March 2008, I was extremely happy to announce my appointment as Co-chairman of the CSS Working Group. Seven years and a half later, it's time to move on. There are three main reasons to that change, that my co-chair Peter and I triggered ourselves with W3C Management's agreement:

    1. We never expected to stay in that role 7.5 years. Chris Lilley chaired the CSS Working Group 1712 days from January 1997 (IIRC) to 2001-oct-10 and that was at that time the longest continuous chairing in W3C's history. Bert Bos chaired it 2337 days from 2001-oct-11 to 2008-mar-05. Peter and I started co-chairing it on 2008-mar-06 and it will end at TPAC 2015. That's 2790 days so 7 years 7 months and 20 days! I'm not even sure those 2790 days hold a record, Steven Pemberton probably chaired longer. But it remains that our original mission to make the WG survive and flourish is accomplished, and we now need fresher blood. Stability is good, but smart evolution and innovation are better.
    2. Co-chairing a large, highly visible Working Group like the CSS Working Group is not a burden, far from it. But it's not a light task either. We start feeling the need for a break.
    3. There were good candidates for the role, unanimously respected in the Working Group.

    So the time has come. The new co-chairs, Rossen Atanassov from Microsoft and Alan Stearns from Adobe, will take over during the Plenary Meeting of the W3C held in Sapporo, japan, at the end of October and that is A Good Thing™. You'll find below a copy of my message to W3C.

    To all the people I've been in touch with while holding my co-chair's hat: thank you, sincerely and deeply. You, the community around CSS, made everything possible.

    Yours truly.

    Dear Tim, fellow ACs, fellow Chairs, W3C Staff, CSS WG Members,

    After seven years and a half, it's time for me to pass the torch of the CSS Working Group's co-chairmanship. 7.5 years is a lot and fresh blood will bring fresh perspectives and new chairing habits. At a time the W3C revamps its activities and WGs, the CSS Working Group cannot stay entirely outside of that change even if its structure, scope and culture are retained. Peter and I decided it was time to move on and, with W3M's agreement, look for new co-chairs.

    I am really happy to leave the Group in Alan's and Rossen's smart and talented hands, I'm sure they will be great co-chairs and I would like to congratulate and thank them for accepting to take over. I will of course help the new co-chairs on request for a smooth and easy transition, and I will stay in the CSS WG as a regular Member.

    I'd like to deeply thank Tim for appointing me back in 2008, still one of the largest surprises of my career!

    I also wish to warmly thank my good friends Chris Lilley, Bert Bos and Philippe Le Hégaret from W3C Staff for their crucial daily support during all these years. Thank you Ralph for the countless transition calls! I hope the CSS WG still holds the record for the shortest positive transition call!

    And of course nothing would have been possible without all the members of the CSS Working Group, who tolerated me for so long and accepted the changes we implemented in 2008, and all our partners in the W3C (in particular the SVG WG) or even outside of it, so thank you all. The Membership of the CSS WG is a powerful engine and, as I often say, us co-chairs have only been a drop of lubricant allowing that engine to run a little bit better, smoother and without too much abrasion.

    Last but not least, deep thanks to my co-chair and old friend Peter Linss for these great years; I accepted that co-chair's role to partner with Peter and enjoyed every minute of it. A long ride but such a good one!

    I am confident the CSS Working Group is and will remain a strong and productive Group, with an important local culture. The CSS Working Group has both style and class (pun intended), and it has been an honour to co-chair it.

    Thank you.

    </Daniel>

    Air MozillaMozilla Weekly Project Meeting

    Mozilla Weekly Project Meeting The Monday Project Meeting

    Mozilla WebDev CommunityBeer and Tell – June 2015

    Once a month, web developers from across the Mozilla Project get together to try and transmute a fresh Stanford graduate into a 10x engineer. Meanwhile, we find time to talk about our side projects and drink, an occurrence we like to call “Beer and Tell”.

    There’s a wiki page available with a list of the presenters, as well as links to their presentation materials. There’s also a recording available courtesy of Air Mozilla.

    Osmose: SpeedKills and Advanced Open File

    First up was Osmose (that’s me!) presenting two packages for Atom, a text editor. SpeedKills is a playful package that plays a guitar solo and sets text on fire when the user types fast enough. Advanced Open File is a more useful package that adds a convenient dialog for browsing the file system and opening files by path rather than using the fuzzy finder. Both are available for install through the Atom package repository.

    new_one: Tab Origin

    Next was new_one, who shared Tab Origin, a Firefox add-on that lets you return to the webpage that launched the current tab, even if the parent tab has since been closed. It’s activated via a keyboard shortcut that can be customized.

    Potch: WONTFIX and Presentation Mode

    Continuing a fine tradition of batching projects, Potch stopped by to show off two Firefox add-ons. The first was WONTFIX, which adds a large red WONTFIX stamp to any Bugzilla bug that has been marked as WONTFIX. The second was Presentation Mode, which allows you to full-screen any content in a web page while hiding the browser chrome. This is especially useful when giving web-based presentations.

    Peterbe: premailer.io

    Peterbe shared premailer.io, which is a service wrapping premailer. Premailer takes a block of HTML with a style tag and applies the styles within as style attributes on each matching tag. This is mainly useful for HTML emails, which generally don’t support style tags that apply to the entire email.

    ErikRose: Spam-fighting Tips

    ErikRose learned a lot about the current state of spam-fighting while redoing his mail server:

    • Telling Postfix to be picky about RFCs is a good first pass. It eliminates some spam without having to do much computation.
    • spamassassin beats out dspam, which hasn’t seen an update since 2012.
    • Shared-digest detectors like Razor help a bit but aren’t sufficient on their own without also greylisting to give the DBs a chance to catch up.
    • DNS blocklists are a great aid: they reject 3 out of 4 spams without taking much CPU.
    • Bayes is still the most reliable (though the most CPU-intense) filtration method. Bayes poisoning is infeasible, because poisoners don’t know what your ham looks like, so don’t worry about hand-picking spam to train on. Train on an equal number of spams and hams: 400 of each works well. Once your bayes is performing well, crank up your BAYES_nn settings so spamassassin believes it.
    • Crank up spamc’s –max-size to 1024000, because spammers are now attaching images > 512K to mails to bypass spamc’s stock 512K threshold. This will cost extra CPU.

    With this, he gets perhaps a spam a week, with over 400 attempts per day.


    We were only able to get a 3x engineer this month, but at least they were able to get a decent job working on enterprise software.

    If you’re interested in attending the next Beer and Tell, sign up for the dev-webdev@lists.mozilla.org mailing list. An email is sent out a week beforehand with connection details. You could even add yourself to the wiki and show off your side-project!

    See you next month!

    Mozilla Security BlogDharma


    dharma

    As soon as a developer at Mozilla starts integrating a new WebAPI feature, the Mozilla Security team begins working to help secure that API. Subtle programming mistakes in new code can introduce annoying crashes and even serious security vulnerabilities that can be triggered by malformed input which can lead to headaches for the user and security exposure.

    WebAPIs start life as a specification in the form of an Interface Description Language, or IDL. Since this is essentially a grammar, a grammar-based fuzzer becomes a valuable tool in finding security issues in new WebAPIs because it ensures that expected semantics are followed most of the time, while still exploring enough undefined behavior to produce interesting results.

    We came across a grammar fuzzer Ben Hawkes released in 2011 called “Dharma.” Sadly, only one version was ever made public. We liked Ben’s approach, but Dharma was missing some features which were important for us and its wider use for API fuzzing. We decided to sit down with our fuzzing mates at BlackBerry and rebuild Dharma, giving the results back to the public, open source and licensed as MPL v2.

    We redesigned how Dharma parses grammars and optimized the speed of parsing and the generating of fuzzed output, added new grammar features to the grammar specification, added support for serving testcases over a WebSocket server, and made it Python 3 ready. It comes with no dependencies and runs out of the box.

    In theory Dharma can be used with any data that can be represented as a grammar. At Mozilla we typically use it for APIs like WebRTC, WebAudio, or WebCrypto.


    dharma_demo

    Dharma has no integrated harness. Feel free to check out the Quokka project which provides an easy way for launching a target with Dharma, monitoring the process and bucketing any faults.

    Dharma is actively in use and maintained at Mozilla and more features are planned for the future. Ideas for improvements are always greatly welcomed.

    Dharma is available via GitHub (preferred and always up-to-date) or via PyPi by running “pip install dharma”.

    References
    https://github.com/mozillasecurity/dharma
    https://github.com/mozillasecurity/quokka
    https://code.google.com/p/dharma/

    Aaron ThornburghNot Working in Whistler

    A brief retrospective
    Whistler Rock - Shot with my Moto X 2nd Gen

    I just returned from Whistler, BC, along with 1300 other Mozillians.

    Because we’re a global organization, it’s important to get everyone together every now and then. We matched faces with IRC channels, talked shop over finger-food, and went hiking with random colleagues. Important people gave speeches. Teams aligned. There was a massive party at the top of a mountain.

    +++++

    Typically, I learn the most from experiences like these only after they have ended. Now that I’ve had 48 hours to process (read: recover), some themes have emerged…

    1. Organizing and mobilizing a bunch of smart, talented, opinionated people is hard work.
    2. It’s easy to say “you’re doing it wrong.” It takes courage to ask “how could we do it better?”
    3. Anyone can find short-term gains. The best leaders define a long-term vision, then enable individuals to define their own contribution.
    4. Success is always relative, and only for a moment in time.
    5. Accelerated change requires rapid adaptation. Being small is our advantage.
    6. The market is what you make it. Or else the market will make you.
    7. It’s been said that when technology works, it’s magic. I disagree. Magic is watching passionate people – from all over the worldcreate technology together.

    Also, it has now been confirmed by repeatable experiment: I’m not a people person – especially when lots of them are gathered in small spaces. I’m fucking exhausted.

    Officially signing back on,

    -DCROBOT


    About:CommunityRecap of Participation at Whistler

    <noscript>[<a href="http://storify.com/lucyeharris/participation-at-whistler" target="_blank">View the story &#8220;Participation at Whistler&#8221; on Storify</a>]</noscript>

    Bogomil ShopovVoice-controlled UI plus a TTS engine.

    A few days ago I’ve attended the launch of SohoXI – Hook and Loop’s latest product that aims to change the look and feel of the Enterprise applications forever. I am close to believing that and not only because I work for the same company as they do. They have delivered extremely revolutionary UI in … Continue reading Voice-controlled UI plus a TTS engine.

    Dave HuntWhistler Work Week 2015

    Last week was Mozilla’s first work week of 2015 in Whistler, BC. It was my first visit to Whistler having joined Mozilla shortly after their last summit there in 2010, and it was everything I needed it to be. Despite currently feeling jetlagged, I have been recharged and I have renewed enthusiasm for the mission and I’m even more than a little excited about Firefox OS again! I’d like to share a few of my highlights from last week…

    • S’mores – The dinner on Wednesday evening was followed by a street party, where I had my first S’more. It was awesome!
    • Firefox OS – Refreshing honesty over past mistakes and a coherant vision for the future has actually made me enthusiastic about this project again. I’m no longer working directly on Firefox OS, but I’ve signed up for the dogfoxfooding program and I’m excited about making a difference again.
    • LEGO – I got to build a LEGO duck, and we heard from David Robertson about the lessons LEGO learned from near bankruptcy.
    • Milkshake – A Firefox Q&A was made infinitely better by taking a spontaneous walk to Cow’s for milkshakes and ice cream with my new team!
    • Running – I got to run with #running friends old and new on Tuesday morning around Lost Lake. Then on Thursday morning I headed back and took on the trails with Matt. These were my first runs since my marathon, and running through the beautiful scenary was exactly what I needed to get me back into it.
    • Istanbul – After dinner on Tuesday night, Stephen and I sat down with Bob to play the board game Istanbul.
    • Hacking – It’s always hard to get actual code written during these team events, but I’m pleased to say we thought through some challenging problems, and actually even managed to land some code.
    • Hike – On Friday morning I joined Justin and Matt on a short hike up Whistler mountain. We didn’t have long before breakfast, but it was great to spend more time with these guys.
    • Whistler Mountain – The final party was at the top of Whistler Mountain, which was just breathtaking. I can’t possibly do the experience justice – so I’m not even going to try.

    Thank you Whistler for putting up with a thousand Mozillians, and thank you Mozilla for organising such a perfect week. We’re going to keep rocking the free web!

    Yunier José Sosa VázquezDisponible cuentaFox 3.1.2 con añoradas funcionalidades

    Más rápido de lo que esperábamos ya está aquí una nueva versión de cuentaFox con interesantes características que desde hace algún tiempo los usuarios deseaban.

    Instalar cuentaFox 3.1.2

    Con esta liberación ya no tendremos que preocuparnos más porque el certificado no está añadido y se me abren x pestañas, ahora el UCICA.pem se añade automáticamente con sus niveles de confianza requeridos. Sin dudas es un gran paso de avance pues nos quita un gran peso de encima.

    Con el paso del tiempo a algunas personas se les olvida actualizar la extensión por lo que siguen utilizando versiones viejas que presentan algún error. Por esta razón, hemos decido alertar al usuario cuando estén disponibles nuevas versiones mostrando una alerta y abriendo en una nueva pestaña la URL para actualizar.

    v3.1.2-alerta-de-actualizacion

    Nuestro objetivo es que este proceso se realice de forma transparente al usuario pero actualmente no podemos hacerlo.

    Completan la lista de novedades

    • Al mostrar una alerta de error o de consumo se muestra el usuario que la ha generado #21.
    • Solucionado no se mostraba el usuario real del error al obtener los datos para varios usuarios #18.
    • Si existen varios usuarios almacenados, en el botón ubicado en la barra de herramientas se muestra el consumo del usuario que inició sesión #19.
    • Si al obtener los datos del usuario ocurre un error siempre se intenta borrar sus datos del administrador de contraseñas de Firefox #26.
    • Actualizado jQuery a v2.1.4

    Por último, pero no menos importante. En las opciones de configuración del add-on (no de la interfaz) pueden decidir si mostrar uno o más usuarios al mismo tiempo y elegir ocultar las cuotas gastadas.

    v3.1.2-opciones-de-configuracion

    Sirva este artículo para agradecer a todas las personas que han acercado a la página del proyecto en GitLab y nos han dejado sus ideas o errores encontrados. Esperamos que se sumen muchos más.

    Si deseas colaborar en el desarrollo del complemento puedes acceder a GitLab (UCI) y clonar el proyecto o dejar una sugerencia. Quizás encuentres una que te motive.

    Instalar cuentaFox 3.1.2

    John O'Duinn“We are ALL Remoties” (Jun2015 edition)

    Since my last post on “remoties”, I’ve done several more presentations, some more consulting work for private companies, and even started writing this down more explicitly (exciting news coming here soon!). While I am always refining these slides, this latest version is the first major “refactor” of this presentation in a long time. I think this restructuring makes the slides even easier to follow – there’s a lot of material to cover here, so this is always high on my mind.

    Without further ado – you can get the latest version of these slides, in handout PDF format, by clicking on the thumbnail image.

    Certainly, the great responses and enthusiastic discussions every time I go through this encourages me to keep working on this. As always, if you have any questions, suggestions or good/bad stories about working remotely or as part of a geo-distributed teams, please let me know (either by email or in the comments below) – I’d love to hear them.

    Thanks
    John.

    Cameron KaiserHello, 38 beta, it's nice to meet you

    And at long last the 38 beta is very happy to meet you too (release notes, downloads, hashes). Over the next few weeks I hope you and the new TenFourFox 38 will become very fond of each other, and if you don't, then phbbbbt.

    There are many internal improvements to 38. The biggest one specific to us, of course, is the new IonPower JavaScript JIT backend. I've invested literally months in making TenFourFox's JavaScript the fastest available for any PowerPC-based computer on any platform, not just because every day websites lard up on more and more crap we have to swim through (viva Gopherspace) but also because a substantial part of the browser is written in JavaScript: the chrome, much of the mid-level plumbing and just about all those addons you love to download and stuff on in there. You speed up JavaScript, you speed up all those things. So now we've sped up many browser operations by about 11 times over 31.x -- obviously the speed of JavaScript is not the only determinant of browser speed, but it's a big part of it, and I think you'll agree that responsiveness is much improved.

    JavaScript also benefits in 38 from a compacting, generational garbage collector (generational garbage collection was supposed to make 31 but was turned off at the last minute). This means recently spawned objects will typically be helplessly slaughtered in their tender youth in a spasm of murderous efficiency based on the empiric observation that many objects are created for brief usage and then never used again, reducing the work that the next-stage incremental garbage collector (which we spent a substantial amount of time tuning in 31 as you'll recall, including backing out background finalization and tweaking the timeslice for our slower systems) has to do for objects that survive this pediatric genocide. The garbage collector in 38 goes one step further and compacts the heap as well, which is to say, it moves surviving objects together contiguously in memory instead of leaving gaps that cannot be effectively filled. This makes both object cleanup and creation much quicker in JavaScript, which relies heavily on the garbage collector (the rest of the browser uses more simplistic reference counting to determine object lifetime), to say nothing of a substantial savings in memory usage: on my Quad G5 I'm seeing about 200MB less overhead with 48 tabs open.

    I also spent some time working on font enumeration performance because of an early showstopper where sites that loaded WOFF fonts spun and spun and spun. After several days of tearing my hair out in clumps the problem turned out to be a glitch in reference counting caused by the unusual way we load platform fonts: since Firefox went 10.6+ it uses CoreText exclusively, but we use almost completely different font code based on the old Apple Type Services which is the only workable choice on 10.4 and the most stable choice on 10.5. ATS is not very fast at instantiating lots of fonts, to say the least, so I made the user font cache stickier (please don't read that as "leaky" -- it's sticky because things do get cleaned up, but less aggressively to improve cache hit percentage) and also made a global font cache where the font's attribute tag directory is cached browser-wide to speed up loading font tables from local fonts on your hard disk. Previously this directory was cached per font entry, meaning if the font entry was purged for re-enumeration it had to be loaded all over again, which usually happened when the browser was hunting for a font with a particular character. This process used to take about fifteen to twenty seconds for the 700+ font faces on my G5. With the global font cache it now takes less than two.

    Speaking of showstoppers, here's an interesting one which I'll note here for posterity. nsChildView, the underlying system view which connects Cocoa/Carbon to Gecko, implements the NSTextInput protocol which allows it to accept Unicode input without (as much) mucking about with the Carbon Text Services Manager (Firefox also implements NSTextInputClient, which is the new superset protocol, but this doesn't exist in 10.4). To accept Unicode input, under the hood the operating system actually manipulates a special undocumented TSM input context called, surprisingly, NSTSMInputContext (both this and the undocumented NSInputContext became the documented NSTextInputContext in 10.6), and it gets this object from a previously undocumented method on NSView called (surprise again) inputContext. Well, turns out if you override this method you can potentially cause all sorts of problems, and Mozilla had done just that to handle complex text input for plugins. Under the 10.4 SDK, however, their code ended up returning a null input context and Unicode input didn't work, so since we don't support plugins anyhow the solution was just to remove it completely ... which took several days more to figure out. The moral of the story is, if you have an NSView that is not responding to setMarkedText or other text input protocol methods, make sure you haven't overridden inputContext or screwed it up somehow.

    I also did some trivial tuning to the libffi glue library to improve the speed of its calls and force it to obey our compiler settings (there was a moment of panic when the 7450 build did not start on the test machines because dyld said XUL was a 970 binary -- libffi had seen it was being built on a G5 and "helpfully" compiled it for that target), backed out some portions of browser chrome that were converted to CoreUI (not supported on 10.4), and patched out the new tab tile page entirely; all new tabs are now blank, like they used to be in previous versions of Firefox and as intended by God Himself. There are also the usual cross-platform HTML5 and CSS improvements you get when we leap from ESR to ESR like this, and graphics are now composited off-main-thread to improve display performance on multiprocessor systems.

    That concludes most of the back office stuff. What about user facing improvements? Well, besides the new blank tabs "feature," we have built-in PDF viewing as promised (I think you'll find this more useful to preview documents and load them into a quicker viewer to actually read them, but it's still very convenient) and Reader View as the biggest changes. Reader View, when the browser believes it can attempt it, appears in the address bar as a little book icon. Click on it and the page will render in a simplified view like you would get from a tool such as Readability, cutting out much of the extraneous formatting. This is a real godsend on slower computers, lemme tell ya! Click the icon again to go back. Certain pages don't work with this, but many will. I have also dragged forward my MP3 decoder support, but see below first, and we have prospectively landed Mozilla bug 1151345 to fix an issue with the application menu (modified for the 10.4 SDK).

    You will also note the new, in-content preferences (i.e., preferences appears in a browser tab now instead of a window, a la, natch, Chrome), and that the default search engine is now Yahoo!. I have not made this default to anything else since we can still do our part this way to support MoCo (but you can change it from the preferences, of course).

    I am not aware of any remaining showstopper bugs, so therefore I'm going ahead with the beta. However, there are some known issues ("bugs" or "features" mayhaps?) which are not critical. None of these will hold up final release currently, but for your information, here they are:

    • If you turn on the title bar, private browsing windows have the traffic light buttons in the wrong position. They work; they just look weird. This is somewhat different than issue 247 and probably has a separate, though possibly related, underlying cause. Since this is purely cosmetic and does not occur in the browser's default configuration, we can ship with this bug present but I'll still try to fix it since it's fugly (plus, I personally usually have the title bar on).

    • MP3 support is still not enabled by default because seeking within a track (except to the beginning) does not work yet. This is the last thing to do to get this support off the ground. If you want to play with it in its current state, however, set tenfourfox.mp3.enabled to true (you will need to create this pref). If I don't get this done by 38.0.2, the pref will stay off until I do, but the rest of it is working already and I have a good idea how to get this last piece functional.

    • I'm not sure whether to call this a bug or a feature, but scaling now uses a quick and dirty algorithm for many images and some non-.ico favicons apparently because we don't have Skia support. It's definitely lower quality, but it has a lot less latency. Images displayed by themselves still use the high-quality built-in scaler which is not really amenable to the other uses that I can tell. Your call on which is better, though I'm not sure I know how to go back the old method or if it's even possible anymore.

    • To reduce memory pressure, 31 had closed tab and window undos substantially reduced. I have not done that yet for 38 -- near as I can determine, the more efficient memory management means it is no longer worth it, so we're back to the default 10 and 3. See what you think.

    Builders: take note that you will need to install a modified strip ("strip7") if you intend to make release binaries due to what is apparently a code generation bug in gcc 4.6. If you want to use a different (later) compiler, you should remove the single changeset with the gcc 4.6 compatibility shims -- in the current changeset pack it's numbered 260681, but this number increments in later versions. See our new HowToBuildRightNow38 for the gory details and where to get strip7.

    Localizers: strings are frozen, so start your language pack engines one more time in issue 42. We'd like to get the same language set for 38 that we had for 31, and your help makes it possible. Thank you!

    As I mentioned before, it's probably 70-30 against there being a source parity version after 38ESR because of the looming threat of Electrolysis, which will not work as-is on 10.4 and is not likely to perform well or even correctly on our older systems. (If Firefox 45, the next scheduled ESR, still allows single process operation then there's a better chance. We still need to get a new toolchain up and a few other things, though, so it won't be a trivial undertaking.) But I'm pleased with 38 so far and if we must go it means we go out on a high note, and nothing says we can't keep improving the browser ourselves separate from Mozilla after we split apart (feature parity). Remember, that's exactly what Classilla does, except that we're much more advanced than Classilla will ever be, and in fact Pale Moon recently announced they're doing the same thing. So if 38 turns out to be our swan song as a full-blooded Mozilla tier 3 port, that doesn't mean it's the end of TenFourFox as a browser. I promise! Meanwhile, let's celebrate another year of updates! PowerPC forever!

    Finally, looking around the Power Mac enthusiast world, it appears that SeaMonkeyPPC has breathed its last -- there have been no updates in over a year. We will pour one out for them. On the other hand, Leopard Webkit continues with regular updates from Tobias, and our friendly builder in the land of the Rising Sun has been keeping up with Tenfourbird. We have the utmost confidence that there will be a Tenfourbird 38 in your hands soon as well.

    Some new toys to play with are next up in a couple days.

    Marco BonardoAdd-ons devs heads-up: History API removals in Places

    Alex ClarkPillow 2-9-0 Is Almost Out

    Pillow 2.9.0 will be released on July 1, 2015.

    Pre-release

    Please help the Pillow Fighters prepare for the Pillow 2.9.0 release by downloading and testing this pre-release:

    Report issues

    As you might expect, we'd like to avoid the creation of a 2.9.1 release within 24-48 hours of 2.9.0 due to any unforeseen circumstances. If you suspect such an issue to exist in 2.9.0.dev1, please let us know:

    Thank you!

    John O'DuinnMozilla’s Release Engineering now on Dr Dobbs!

    book coverLong time readers of this blog will remember when The Architecture of Open Source Applications (vol2) was published, containing a chapter describing the tools and mindsets used when re-building Mozilla’s Release Engineering infrastructure. (More details about the book, about the kindle and nook versions, and about the Russian version(!).

    Dr Dobbs recently posted an article here which is an edited version of the Mozilla Release Engineering chapter. As a long time fan of Dr Dobbs, seeing this was quite an honor, even with the sad news here.

    Obviously, Mozilla’s release automation continues to evolve, as new product requirements arise, or new tools help further streamline things. There is still lots of interesting work being done here – for me, top of mind is Task Cluster, and ScriptHarness (v0.1.0 and v0.2.0). Release Engineering at scale is both complex, and yet very interesting – so you should keep watching these sites for more details, and consider if they would also help in your current environment. As they are all open source, you can of course join in and help!

    For today, I just re-read the Dr. Dobbs article with a fresh cup of coffee, and remembered the various different struggles we went through as we scaled Mozilla’s infrastructure up so we could quickly grow the company, and the community. And then in the middle of it all, found time with armenzg, catlee and lsblakk to write about it all. While some of the technical tools have changed since the chapter was written, and some will doubtless change again in the future, the needs of the business, the company and the community still resonate.

    For anyone doing Release Engineering at scale, the article is well worth a quiet read.

    Roberto A. VitilloA glance at unified FHR/Telemetry

    Lots is changing in Telemetry land. If you do occasionally run data analyses with our Spark infrastructure you might want to keep reading.

    Background

    The Telemetry and FHR collection systems on desktop are in the process of being unified. Both systems will be sending their data through a common data pipeline which has some features of both the current Telemetry pipeline as well the Cloud Services one that we use to ingest server logs.

    The goals of the unification are to:

    • avoid measuring the same metric in multiple systems on the client side;
    • reduce the latency from the time a measurement occurs until it can be analyzed on the server;
    • increase the accuracy of measurements so that they can be better correlated with factors in the user environment such as the specific build, enabled add-ons, and other hardware or software characteristics;
    • use a common data pipeline for client telemetry and service log data.

    The unified pipeline is currently sending data for Nightly, Aurora and Beta. Classic FHR and Telemetry pipelines are going to keep sending data to the very least until the new unified pipeline has not been fully validated. The plan is to land this feature in 40 Release. We’ll also continue to respect existing user preferences. If the user has opted out of FHR or Telemetry, we’ll continue to respect that for the equivalent data sets. Similarly, the opt-out and opt-in defaults will remain the same for equivalent data sets.

    Data format

    A Telemetry ping, stored as JSON object on the client, encapsulates the data sent to our backend. The main differences between the new unified Telemetry ping format (v4) and the classic Telemetry one (v2) are that:

    • multiple ping types are supported beyond the classic saved-session ping, like the main ping;
    • pings have a common top-level which contains basic information shared between types, like build-id and channel;
    • pings have an optional environment field which consists of data that is expected to be characteristic for performance and other behavior.

    From an analysis point of view, the most important addition is the main ping which includes the very same histograms and other performance and diagnostic data as the v2 saved-session pings. Unlike in “classic” Telemetry though, there can be multiple main pings during a single session. A main ping is triggered by different scenarios, which are documented by the reason field:

    • aborted-session: periodically saved to disk and deleted at shutdown – if a previous aborted session ping is found at startup it gets sent to our backend;
    • environment-change: generated when the environment changes;
    • shutdown: triggered when the browser session ends;
    • daily: a session split triggered in 24h hour intervals at local midnight; this is needed to make sure we keep receiving data also from clients that have very long sessions.

    Data access through Spark

    Once you connect to a Spark enabled IPython notebook launched from our self-service dashboard, you will be prompted with a new tutorial based on the v4 dataset. The v4 data is fetched through the get_pings function by passing “v4″ as the schema parameter. The following parameters are valid for the new data format:

    • app: an application name, e.g.: “Firefox”;
    • channel: a channel name, e.g.: “nightly”;
    • version: the application version, e.g.: “40.0a1″;
    • build_id: a build id or a range of build ids, e.g.:”20150601000000″ or (“20150601000000″, “20150610999999”)
    • submission_date: a submission date or a range of submission dates, e.g: “20150601” or (“20150601″, “20150610”)
    • doc_type: ping type, set to “main” by default
    • fraction: the fraction of pings to return, set to 1.0 by default

    Once you have a RDD, you can further filter the pings down by reason. There is also a new experimental API that returns the history of submissions for a subset of profiles, which can be used for longitudinal analyses.


    Zack WeinbergGoogle Voice Search and the Appearance of Trustworthiness

    Last week there were several bug reports [1] [2] [3] about how Chrome (the web browser), even in its fully-open-source Chromium incarnation, downloads a closed-source, binary extension from Google’s servers and installs it, without telling you it has done this, and moreover this extension appears to listen to your computer’s microphone all the time, again without telling you about it. This got picked up by the trade press [4] [5] [6] and we rapidly had a full-on Internet panic going.

    If you dig into the bug reports and/or the open source part of the code involved, which I have done, it turns out that what Chrome is doing is not nearly as bad as it looks. It does download a closed-source binary extension from Google, install it, and hide it from you in the list of installed extensions (technically there are two hidden extensions involved, only one of which is closed-source, but that’s only a detail of how it’s all put together). However, it does not activate this extension unless you turn on the voice search checkbox in the settings panel, and this checkbox has always (as far as I can tell) been off by default. The extension is labeled, accurately, as having the ability to listen to your computer’s microphone all the time, but of course it does not get to do this until it is activated.

    As best anyone can tell without access to the source, what the closed-source extension actually does when it’s activated is monitor your microphone for the code phrase OK Google. When it detects this phrase it transmits the next few words spoken to Google’s servers, which convert it to text and conduct a search for the phrase. This is exactly how one would expect a voice search feature to behave. In particular, a voice-activated feature intrinsically has to listen to sound all the time, otherwise how could it know that you have spoken the magic words? And it makes sense to do the magic word detection with code running on the local computer, strictly as a matter of efficiency. There is even a non-bogus business reason why the detector is closed source; speech recognition is still in the land where tiny improvements lead to measurable competitive advantage.

    So: this feature is not actually a massive privacy violation. However, Google could and should have put more care into making this not appear to be a massive privacy violation. They wouldn’t have had mud thrown at them by the trade press about it, and the general public wouldn’t have had to worry about it. Everyone wins. I will now dissect exactly what was done wrong and how it could have been done better.

    It was a diagnostic report, intended for use by developers of the feature, that gave people the impression the extension was listening to the microphone all the time. Below is a screen shot of this diagnostic report (click for full width). You can see it on your own copy of Chrome by typing chrome://voicesearch into the URL bar; details will probably differ a little (especially if you’re not using a Mac).

    Screen shot of Google Voice Search diagnostic report, taken on Chrome 43 running on MacOS X. The most important lines of text are 'Microphone: Yes', 'Audio Capture Allowed: Yes', 'Hotword Search Enabled: No', and 'Extension State: ENABLED. Screen shot of Google Voice Search diagnostic report, taken on Chrome 43 running on MacOS X.

    Google’s first mistake was not having anyone check this over for what it sounds like it means to someone who isn’t familiar with the code. It is very well known that when faced with a display like this, people who aren’t familiar with the code will pick out whatever bits they think they understand and ignore everything else, even if that means they completely misunderstand it. [7] In this case, people see Microphone: Yes and Audio Capture Allowed: Yes and maybe also Extension State: ENABLED and assume that this means the extension is actively listening right now. (What the developers know it means is this computer has a microphone, the extension could listen to it if it had been activated, and it’s connected itself to the checkbox in the preferences so it can be activated. And it’s hard for them to realize that anyone could think it would mean something else.)

    They didn’t have anyone check it because they thought, well, who’s going to look at this who isn’t a developer? Thing is, it only takes one person to look at it, decide it looks hinky, mention it online, and now you have a media circus on your hands. Obscurity is no excuse for not doing a UX review.

    Now, mistake number two becomes evident when you consider what this screen ought to say in order not to scare people who haven’t turned the feature on (and maybe this is the first they’ve heard of it even): something like

    Voice Search is inactive.

    (A couple of sentences about what Voice Search is and why you might want it.) To activate Voice Search, go to the preferences screen and check the box.

    It would also be okay to have a duplicate checkbox right there on this screen, and to have all the same debugging information show up after you check the box. But wait—how do developers diagnose problems with downloading the extension, which happens before the box has been checked? And that’s mistake number two. The extension should not be downloaded until the box is checked. I am not aware of any technical reason why that couldn’t have been the way it worked in the first place, and it would go a long way to reassure people that this closed-source extension can’t listen to them unless they want it to. Note that even if the extension were open source it might still be a live question whether it does anything hinky. There’s an excellent chance that it’s a generic machine recognition algorithm that’s been trained to detect OK Google, which training appears in the code as a big lump of meaningless numbers—and there’s no way to know whether those numbers train it to detect anything besides OK Google. Maybe if you start talking about bombs the computer just quietly starts recording…

    Mistake number three, finally, is something they got half-right. This is not a core browser feature. Indeed, it’s hard for me to imagine any situation where I would want this feature on a desktop computer. Hands-free operation of a mobile device, sure, but if my hands are already on a keyboard, that’s faster and less bothersome for other people in the room. So, Google implemented this frill as a browser extension—but then they didn’t expose that in the user interface. It should be an extension, and it should be visible as such. Then it needn’t take up space in the core preferences screen, even. If people want it they can get it from the Chrome extension repository like any other extension. And that would give Google valuable data on how many people actually use this feature and whether it’s worth continuing to develop.

    Chris CooperReleng & Relops weekly highlights - June 26, 2015

    Friday, foxyeah!

    It’s been a very busy and successful work week here in beautiful Whistler, BC. People are taking advantage of being in the same location to meet, plan, hack, and socialize. A special thanks to Jordan for inviting us to his place in beautiful Squamish for a BBQ!

    (Note: No release engineering folks were harmed by bears in the making of this work week.)

    tl;dr

    Whistler: Keynotes were given by our exec team and we learned we’re focusing on quality, dating our users to get to know them better, and that WE’RE GOING TO SPACE!! We also discovered that at LEGO, Everything is Awesome now that they’re thinking around the box instead of inside or outside of it. Laura’s GoFaster project sounds really exciting, and we got a shoutout from her on the way we manage the complexity of our systems. There should be internal videos of the keynotes up next week if you missed them.

    Internally, we talked about Q3 planning and goals, met with our new VP, David, met with our CEO, Chris, presented some lightning talks, and did a bunch of cross-group planning/hacking. Dustin, Kim, and Morgan talked to folks at our booth at the Science Fair. We had a cool banner and some cards (printed by Dustin) that we could hand out to tell people about try. SHIP IT!

    Taskcluster: Great news; the TaskCluster team is joining us in Platform! There was lots of evangelism about TaskCluster and interest from a number of groups. There were some good discussions about operationalizing taskcluster as we move towards using it for Firefox automation in production. Pete also demoed the Generic Worker!

    Puppetized Windows in AWS: Rob got the nxlog puppet module done. Mark is working on hg and NSIS puppet modules in lieu of upgrading to MozillaBuild 2.0. Jake is working on the metric-collective module. The windows folks met to discuss the future of windows package management. Q is finishing up the performance comparison testing in AWS. Morgan, Mark, and Q deployed runner to all of the try Windows hosts and one of the build hosts.

    Operational: Amy has been working on some additional nagios checks. Ben, Rail, and Nick met and came up with a solid plan for release promotion. Rail and Nick worked on releasing Firefox 39 and two versions of Firefox ESR. Hal spent much of the week working with IT. Dustin and catlee got some work on on migrating treestatus to relengapi. Hal, Nick, Chris, and folks from IT, sheriffs, dev-services debugged problems with b2g jobs. Callek deployed a new version of slaveapi. Kim, Jordan, Chris, and Ryan worked on a plan for addons. Kim worked with some new buildduty folks to bring them up to speed on operational procedures.

    Thank you all, and have a safe trip home!

    And here are all the details:

    Taskcluster

    • We got to spend some quality time with the our new TaskCluster teammates, Greg, Jonas, Wander, Pete, and John. We’re all looking forward to working together more closely.
    • Morgan convinced lots of folks that Taskcluster is super amazing, and now we have a lot of people excited to start hacking on it and moving their workloads to it.
    • We put together a roadmap for TaskCluster in Trello and identified the blockers to turning Buildbot Scheduling off.

    Puppetized Windows in AWS

    • Rob has pushed out the nxlog puppet module to get nxlog working in scl3 (bug 1146324). He has a follow-on bug to modify the ec2config file for AWS to reset the log-aggregator host so that we’re aggregating to the local region instead of where we instantiate the instance (like we do with linux). This will ensure we have Windows system logs in AWS (bug 1177577).
    • The new version of MozillaBuild was released, and our plan was to upgrade to that on Windows (bug 1176111). An attempt at that showed that the way hg was compiled requires an external dll (likely something from cygwin), and needs to be run from bash. Since this would require significant changes, we’re going to install the old version of MozillaBuild and put upgrades of hg (bug 1177740) and NSIS on top of that (like we’re doing with GPO now). Future work will include splitting out all the packages and not using MozillaBuild. Jake is working on the puppet module for metric-collective, our host-level stats gathering software for windows (similar to collectd on windows/OS X). This will give use Windows system metrics in graphite in AWS (bug 1097356).
    • We met to talk about Windows packaging and how to best integrate with puppet. Rob is starting to investigate using NuGet and Chocolatey to handle this (bugs 1175133 and 1175107).
    • Q spun up some additional instance types in AWS and is in the process of getting some more data for Windows performance after the network modifications we made earlier (bug 1159384).
    • Jordan added a new puppetized path for all windows jobs, fixing a problem we were seeing with failing sendchanges on puppetized machines (bug 1175701).
    • Morgan, Mark, and Q deployed runner to all of the try Windows hosts (bug 1055794).

    Operational

    • The relops team met to perform a triage of their two bugzilla queues and closed almost 20% of the open bugs as either already done or wontfix based on changes in direction.
    • Amy has been working on some additional nagios checks for some Windows services and for AWS subnets filling up (bugs 1164441 and 793293).
    • Ben, Rail, and Nick met and came up with a solid plan for the future of release promotion.
    • Rail and Nick worked on getting Firefox 39 (and the related ESR releases) out to our end users.
    • Hal spent lots of time working with IT and the MOC, improving our relationships and workflow.
    • Dustin and catlee did some hacking to start the porting of treestatus to relengapi (one of the blockers to moving us out of PHX1).
    • Hal, Nick, Chris, and folks from IT, sheriffs, dev-services tracked down an intermittent problem with the repo-tool impacting only b2g jobs (bug 1177190).
    • Callek deployed the new version of slaveapi to support slave loans using the AWS API (bug 1177932).
    • Kim, Jordan, Chris, and Ryan discussed the initial steps for future addon support.
    • Coop (hey, that’s me) held down the buildduty fort while everyone else was in Whistler

    See you next week!

    Cameron Kaiser31.8.0 available (say goodbye)

    31.8.0 is available, the last release for the 31 series (release notes, downloads, hashes). Download it and give it one last spin. 31 wasn't a high water mark for us in terms of features or performance, but it was pretty stable and did the job, so give it a salute as it rides into the sunset. It finalizes Monday PM Pacific time as usual.

    I'm trying very hard to get you the 38.0.1 beta by sometime next week, probably over the July 4th weekend assuming the local pyros don't burn my house down with errant illegal fireworks, but I keep hitting showstoppers while trying to dogfood it. First it was fonts and then it was Unicode input, and then the newtab crap got unstuck again, and then the G5 build worked but the 7450 build didn't, and then, and then, and then. I'm still working on the last couple of these major bugs and then I've got some additional systems to test on before I introduce them to you. There are a couple minor bugs that I won't fix before the beta because we need enough time for the localizers to do their jobs, and MP3 support is present but is still not finished, but there will be a second beta that should address most of these problems prior to our launch with 38.0.2. Be warned of two changes right away: no more tiles in the new tab page (I never liked them anyway, but they require Electrolysis now, so that's a no-no), and Check for Updates is now moved to the Help menu, congruent with regular Firefox, since keeping it in its old location now requires substantial extra code that is no longer worth it. If you can't deal with these changes, I will hurt you very slowly.

    Features that did not make the cut: Firefox Hello and Pocket, and the Cisco H.264 integration. Hello and Pocket are not in the ESR, and I wouldn't support them anyway; Hello needs WebRTC, which we still don't really support, and you can count me in with the people who don't like a major built-in browser component depending exclusively on a third-party service (Pocket). As for the Cisco integration, there will never be a build of those components for Tiger PowerPC, so there. Features that did make the cut, though, are pdf.js and Reader View. Although PDF viewing is obviously pokier compared to Preview.app, it's still very convenient, generally works well enough now that we have IonPower backing it, and is much safer. However, Reader View on the other hand works very well on our old systems. You'll really like it especially on a G3 because it cuts out a lot of junk.

    After that there are two toys you'll get to play with before 38.0.2 since I hope to introduce them widely with the 38 launch. More on that after the beta, but I'll whet your appetite a little: although the MacTubes Enabler is now officially retired, since as expected the MacTubes maintainer has thrown in the towel, thanks to these projects the MTE has not one but two potential successors, and one of them has other potential applications. (The QuickTime Enabler soldiers on, of course.)

    Last but not least, I have decided to move the issues list and the wiki from Google Code to Github, and leave downloads with SourceForge. That transition will occur sometime late July before Google Code goes read-only on August 24th. (Classilla has already done this invisibly but I need to work on a stele so that 9.3.4 will be able to use Github effectively.) In the meantime, I have already publicly called Google a bunch of meaniepants and poopieheads for their shameful handling of what used to be a great service, so my work here is done.

    Gervase MarkhamPromises: Code vs. Policy

    A software organization wants to make a promise, for example about its data practices. For example, “We don’t store information on your location”. They can keep that promise in two ways: code or policy.

    If they were keeping it in code, they would need to be open source, and would simply make sure the code didn’t transmit location information to the server. Anyone can review the code and confirm that the promise is being kept. (It’s sometimes technically possible for the company to publish source code that does one thing, and binaries which do another, but if that was spotted, there would be major reputational damage.)

    If they were keeping it in policy, they would add “We don’t store information on your location” to their privacy policy or Terms of Service. The documents can be reviewed, but in general you have to trust the company that they are sticking to their word. This is particularly so if the policy states that it does not create a binding obligation on the company. So this is a function of your view of the company’s reputation.

    Geeks like promises kept in code. They can’t be worked around using ambiguities in English, and they can’t be changed without the user’s consent (to a software upgrade). I suspect many geeks think of them as superior to promises kept in policy – “that’s what they _say_, but who knows?”. This impression is reinforced when companies are caught sticking to the letter but not the spirit of their policies.

    But some promises can’t be kept in code. For example, you can’t simply not send the user’s IP address, which normally gives coarse location information, when making a web request. More complex or time-bound promises (“we will only store your information for two weeks”) also require policy by their nature. Policy is also more flexible, and using a policy promise rather than a code promise can speed time-to-market due to reduced software complexity and increased ability to iterate.

    Question: is this distinction, about where to keep your promises, useful when designing new features?

    Question: is it reasonable or misguided for geeks to prefer promises kept in code?

    Question: if Mozilla or its partners are using promises kept in policy for e.g. a web service, how can we increase user confidence that such a policy is being followed?

    Vladan DjericAnnouncing the Content Performance program

    Introduction

    Aaron Klotz, Avi Halachmi and I have been studying Firefox’s performance on Android & Windows over the last few weeks as part of an effort to evaluate Firefox “content performance” and find actionable issues. We’re analyzing and measuring how well Firefox scrolls pages, loads sites, and navigates between pages. At first, we’re focusing on 3 reference sites: Twitter, Facebook, and Yahoo Search.

    We’re trying to find reproducible, meaningful, and common use cases on popular sites which result in noticeable performance problems or where Firefox performs significantly worse than competitors. These use cases will be broken down into tests or profiles, and shared with platform teams for optimization. This “Content Performance” project is part of a larger organizational effort to improve Firefox quality.

    I’ll be regularly posting blog posts with our progress here, but you can can also track our efforts on our mailing list and IRC channel:

    Mailing list: https://mail.mozilla.org/listinfo/contentperf
    IRC channel: #contentperf
    Project wiki page: Content_Performance_Program

    Summary of Current Findings (June 18)

    Generally speaking, desktop and mobile Firefox scroll as well as other browsers on reference sites when there is only a single tab loaded in a single window.

    • We compared Firefox vs Chrome and IE:
      • Desktop Firefox scrolling can badly deteriorate when the machine is in power-saver mode1 (Firefox performance relative to other browsers depends on the site)
      • Heavy activity in background tabs badly affects desktop Firefox’s scrolling performance1 (much worse than other browsers — we need E10S)
      • Scrolling on infinitely-scrolling pages only appears janky when the page is waiting on additional data to be fetched
    • Inter-page navigation in Firefox can exhibit flicker, similar to other browsers
    • The Firefox UI locks up during page loading, unlike other browsers (need E10S)
    • Scrolling in desktop E10S (with heavy background tab activity) is only as good as the other browsersn1 when Firefox is in the process-per-tab configuration (dom.ipc.processCount >> 1)

    1 You can see Aaron’s scrolling measurements here: http://bit.ly/1K1ktf2

    Potential scenarios to test next:

    • Check impact of different Firefox configurations on scrolling smoothness:
      • Hardware acceleration disabled
      • Accessibility enabled & disabled
      • Maybe: Multiple monitors with different refresh rate (test separately on Win 8 and Win 10)
      • Maybe: OMTC, D2D, DWrite, display & font scaling enabled vs disabled
        • If we had a Telemetry measurement of scroll performance, it would be easier to determine relevant characteristics
    • Compare Firefox scrolling & page performance on Windows 8 vs Windows 10
      • Compare Firefox vs Edge on Win 10
    • Test other sites in Alexa top 20 and during random browsing
    • Test the various scroll methods on reference sites (Avi has done some of this already): mouse wheel, mouse drag, arrow key, page down, touch screen swipe and drag, touchpad drag, touchpad two finger swipe, trackpoints (special casing for ThinkPads should be re-evaluated).
      • Check impact of pointing device drivers
    • Check performance inside Google web apps (Search, Maps, Docs, Sheets)
      • Examine benefits of Chrome’s network pre-fetcher on Google properties (e.g. Google search)
      • Browse and scroll simple pages when top Google apps are loaded in pinned tabs
    • Compare Firefox page-load & page navigation performance on HTTP/2 sites (Facebook & Twitter, others?)
    • Check whether our cache and pre-connector benefit perceived performance, compare vs competition

    Issues to report to Platform teams

    • Worse Firefox scrolling performance with laptop in power-save mode
    • Scrolling Twitter feed with YouTube HTML5 videos is jankier in Firefox
    • bug 1174899: Scrolling on Facebook profile with many HTML5 videos eventually causes 100% CPU usage on a Necko thread + heavy CPU usage on main thread + the page stops loading additional posts (videos)

    Tooling questions:

    • Find a way to to measure when the page is “settled down” after loading, i.e. time until last page-loading event. This could be measured by the page itself (similar to Octane), which would allow us to compare different browsers
    • How to reproduce dynamic websites offline?
    • Easiest way to record demos of bad Firefox & Fennec performance vs other browsers?

    Decisions made so far:

    • Exclusively focus on Android 5.0+ and Windows 7, 8.1 & 10
    • Devote the most attention to single-process Nightly on desktop, but do some checks of E10S performance as well
    • Desktop APZC and network pre-fetcher are a long time away, don’t wait

    Doug BelshawWeb Literacy Map v2.0

    I’m delighted to see that development of Mozilla’s Web Literacy Map is still continuing after my departure a few months ago.

    Read, Write, Participate

    Mark Surman, Executive Director of the Mozilla Foundation, wrote a blog post outlining the way forward and a working group has been put together to drive forward further activity. It’s great to see Mark Lesser being used as a bridge to previous iterations.

    Another thing I’m excited to see is the commitment to use Open Badges to credential Web Literacy skills. We tinkered with badges a little last year, but hopefully there’ll be a new impetus around this.

    The approach to take the Web Literacy Map from version 1.5 to version 2.0 is going to be different from the past few years. It’s going to be a ‘task force’ approach with people brought in to lend their expertise rather than a fully open community approach. That’s probably what’s needed at this point.

    I’m going to give myself some space to, as my friend and former colleague Laura Hilliger said, 'disentangle myself’ from the Web Literacy Map and wider Mozilla work. However, I wish them all the best. It’s important work.


    Comments? Questions? I’m @dajbelshaw on Twitter or you can email: mail@dougbelshaw.com

    Planet Mozilla InternsWillie Cheong: Maximum Business Value; Minimum Effort

    enhanced-4875-1433865112-1

    Dineapple is an online food delivery gig that I have been working on recently. In essence, a new food item is introduced periodically, and interested customers place orders online to have their food delivered the next day.

    Getting down to the initial build of the online ordering site, I started to think about the technical whats and hows. For this food delivery service, a customer places an order by making an online payment. The business then needs to know of this transaction, and have it linked to the contact information of the customer.

    Oh okay, easy. Of course I’ll set up a database. I’ll store the order details inside a few tables. Then I’ll build a mini application to extract this information and generate a daily report for the cooks and delivery people to operate on. Then I started to build these things in my head. But wait, there is a simpler way to get the operations people aware of orders. We could just send an email to the people on every successful transaction to notify them of a new incoming order. But this means the business loses visibility and data portability. Scraping for relational data from a bunch of automated emails, although possible, will be a nightmare. The business needs to prepare to scale, and that means analytics.

    Then I saw something that now looks so obvious I feel pretty embarrassed. Payments on the ordering service are processed using Stripe. When the HTTP request to process a payment is made, Stripe provides an option to submit additional metadata that will be tagged to the payment. There is a nice interface on the Stripe site that allows business owners to do some simple analytics on the payment data. There is also the option to export all of that data (and metadata) to CSV for more studying.

    Forget about ER diagrams, forget about writing custom applications, forget about using automated emails to generate reports. Stripe is capable of doing the reporting for Dineapple, we just had to see a way to adapt the offering to fit the business’s use case.

    Beyond operations reporting through Stripe, there are so many existing web services out there that can be integrated into Dineapple. Just to name a few, an obvious one would be to use Google Analytics to study site traffic. Customers’ reviews on food and services could (and probably should) be somehow integrated to work using Yelp. Note that none of these outsourced alternatives, although significantly easier to implement, compromise on the quality of the solution for the business. Because at the end of the day, all that really matters is that the business gets what it needs.

    So here’s a reminder to my future self. Spend a little more time looking around for simpler alternatives that you can take advantage of before jumping into development for a custom solution.

    Engineers are builders by instinct, but that isn’t always a good thing.

    Emma Irwin#Mozlove for Tad

    I truly believe, that to make Mozilla a place worth ‘hanging your hat‘, we need to get better at being ‘forces of good for each other’.  I like to think this idea is catching on, but only time will tell.

    This month’s #mozlove post is for Tom Farrow AKA ‘Tad’,  a long time contributor, in numerous initiatives across Mozilla.  Although Tad’s contribution focus is in Community Dev Ops, it’s his interest in teaching youth digital literacy that first led to a crossing of our paths. You’ll probably find it interesting to know that despite being in his sixth(!!) year of contribution to Mozilla –  Tad is still a High School in Solihull Birmingham, UK.

    Tad starting contribution to Mozilla after helping a friend install Firefox on their government-issued laptop, which presented some problems. He found help on SUMO, and through being helped was inspired to become a helper and contributor himself.  Tad speaks fondly of starting with SUMO, of finding friends, training and mentorship.

    Originally drawn to IT and DevOps contribution for the opportunity of ‘belonging to something’, Tad has become a fixture in this space helping design hosting platforms, and the evolution of a multi-tenant WordPress hosting. When I asked what was most rewarding about contributing to Community Dev Ops, he shared that pride in innovating a quality solution.

    I’m also increasingly curious about the challenges of participation and asked about this as well.  Tad expressed some frustration around ‘access and finding the right people to unlock resources’.  I think that’s probably something that speaks to the greater challenges for the Mozilla community in understanding pathways for support.

    Finally my favorite question:  “How do your friends and family relate to your volunteer efforts? Is it easy or hard to explain volunteering at Mozilla?”.

    I don’t really try to explain it – my parents get the general idea, and are happy I’m gaining skills in web technology.

    I think it’s very cool that in a world of ‘learn to code’ merchandizing, that Tad found his opportunity to learn and grow technical skills in participation at Mozilla :)

    I want to thank Tad for taking the time to chat with me, for being such an amazing contributor, and inspiration to others around the project.

    * I set a reminder in my calendar every month, which this month happens to be during Mozilla’s Work Week in Whistler.  Tad is also in Whistler, make sure you look out for him – and say hello!

     

     

     

     

     

    Aki Sasakion configuration

    A few people have suggested I look at other packages for config solutions. I thought I'd record some of my thoughts on the matter. Let's look at requirements first.

    Requirements

    1. Commandline argument support. When running scripts, it's much faster to specify some config via the commandline than always requiring a new config file for each config change.

    2. Default config value support. If a script assumes a value works for most cases, let's make it default, and allow for overriding those values in some way.

    3. Config file support. We need to be able to read in config from a file, and in some cases, several files. Some config values are either too long and unwieldy to pass via the commandline, and some config values contain characters that would be interpreted by the shell. Plus, the ability to use diff and version control on these files is invaluable.

    4. Multiple config file type support. json, yaml, etc.

    5. Adding the above three solutions together. The order should be: default config value -> config file -> commandline arguments. (The rightmost value of a configuration item wins.)

    6. Config definition and validation. Commandline options are constrained by the options that are defined, but config files can contain any number of arbitrary key/value pairs.

    7. The ability to add groups of commandline arguments together. Sometimes familes of scripts need a common set of commandline options, but also need the ability to add script-specific options. Sharing the common set allows for consistency.

    8. The ability to add config definitions together. Sometimes families of scripts need a common set of config items, but also need the ability to add script-specific config items.

    9. Locking and/or logging any changes to the config. Changing config during runtime can wreak havoc on the debugability of a script; locking or logging the config helps avoid or mitigate this.

    10. Python 3 support, and python 2.7 unicode support, preferably unicode-by-default.

    11. Standardized solution, preferably non-company and non-language specific.

    12. All-in-one solution, rather than having to use multiple solutions.

    Packages and standards

    argparse

    Argparse is the standardized python commandline argument parser, which is why configman and scriptharness have wrapped it to add further functionality. Its main drawbacks are lack of config file support and limited validation.

    1. Commandline argument support: yes. That's what it's written for.

    2. Default config value support: yes, for commandline options.

    3. Config file support: no.

    4. multiple config file type support: no.

    5. Adding the above three solutions together: no. The default config value and the commandline arguments are placed in the same Namespace, and you have to use the parser.get_default() method to determine whether it's a default value or an explicitly set commandline option.

    6. Config definition and validation: limited. It only covers commandline option definition+validation, and there's the required flag but not a if foo is set, bar is required type validation. It's possible to roll your own, but that would be script-specific rather than part of the standard.

    7. Adding groups of commandline arguments together: yes. You can take multiple parsers and make them parent parsers of a child parser, if the parent parsers have specified add_help=False

    8. Adding config definitions together: limited, as above.

    9. The ability to lock/log changes to the config: no. argparse.Namespace will take changes silently.

    10. Python 3 + python 2.7 unicode support: yes.

    11. Standardized solution: yes, for python. No for other languages.

    12. All-in-one solution: no, for the above limitations.

    configman

    Configman is a tool written to deal with configuration in various forms, and adds the ability to transform configs from one type to another (e.g., commandline to ini file). It also adds the ability to block certain keys from being saved or output. Its argparse implementation is deeper than scriptharness' ConfigTemplate argparse abstraction.

    Its main drawbacks for scriptharness usage appear to be lack of python 3 + py2-unicode-by-default support, and for being another non-standardized solution. I've given python3 porting two serious attempts, so far, and I've hit a wall on the dotdict __getattr__ hack working differently on python 3. My wip is here if someone else wants a stab at it.

    1. Commandline argument support: yes.

    2. Default config value support: yes.

    3. Config file support: yes.

    4. Multiple config file type support: yes.

    5. Adding the above three solutions together: not as far as I can tell, but since you're left with the ArgumentParser object, I imagine it'll be the same solution to wrap configman as argparse.

    6. Config definition and validation: yes.

    7. Adding groups of commandline arguments together: yes.

    8. Adding config definitions together: not sure, but seems plausible.

    9. The ability to lock/log changes to the config: no. configman.namespace.Namespace will take changes silently.

    10. Python 3 support: no. Python 2.7 unicode support: there are enough str() calls that it looks like unicode is a second class citizen at best.

    11. Standardized solution: no.

    12. All-in-one solution: no, for the above limitations.

    docopt

    Docopt simplifies the commandline argument definition and prettifies the help output. However, it's purely a commandline solution, and doesn't support adding groups of commandline options together, so it appears to be oriented towards relatively simple script configuration. It could potentially be added to json-schema definition and validation, as could the argparse-based commandline solutions, for an all-in-two solution. More on that below.

    json-schema

    This looks very promising for an overall config definition + validation schema. The main drawback, as far as I can see so far, is the lack of commandline argument support.

    A commandline parser could generate a config object to validate against the schema. (Bonus points for writing a function to validate a parser against the schema before runtime.) However, this would require at least two definitions: one for the schema, one for the hopefully-compliant parser. Alternately, the schema could potentially be extended to support argparse settings for various items, at the expense of full standards compatiblity.

    There's already a python jsonschema package.

    1. Commandline argument support: no.

    2. Default config value support: yes.

    3. Config file support: I don't think directly, but anything that can be converted to a dict can be validated.

    4. Multiple config file type support: no.

    5. Adding the above three solutions together: no.

    6. Config definition and validation: yes.

    7. Adding groups of commandline arguments together: no.

    8. Adding config definitions together: sure, you can add dicts together via update().

    9. The ability to lock/log changes to the config: no.

    10. Python 3 support: yes. Python 2.7 unicode support: I'd guess yes since it has python3 support.

    11. Standardized solution: yes, even cross-language.

    12. All-in-one solution: no, for the above limitations.

    scriptharness 0.2.0 ConfigTemplate + LoggingDict or ReadOnlyDict

    Scriptharness currently extends argparse and dict for its config. It checks off the most boxes in the requirements list currently. My biggest worry with the ConfigTemplate is that it isn't fully standardized, so people may be hesitant to port all of their configs to it.

    An argparse/json-schema solution with enough glue code in between might be a good solution. I think ConfigTemplate is sufficiently close to that that adding jsonschema support shouldn't be too difficult, so I'm leaning in that direction right now. Configman has some nice behind the scenes and cross-file-type support, but the python3 and __getattr__ issues are currently blockers, and it seems like a lateral move in terms of standards.

    An alternate solution may be BYOC. If the scriptharness Script takes a config object that you built from somewhere, and gives you tools that you can choose to use to build that config, that may allow for enough flexibility that people can use their preferred style of configuration in their scripts. The cost of that flexibility is familiarity between scriptharness scripts.

    1. Commandline argument support: yes.

    2. Default config value support: yes, both through argparse parsers and script initial_config.

    3. Config file support: yes. You can define multiple required config files, and multiple optional config files.

    4. Multiple config file type support: no. Mozharness had .py and .json. Scriptharness currently only supports json because I was a bit iffy about execfileing python again, and PyYAML doesn't always install cleanly everywhere. It's on the list to add more formats, though. We probably need at least one dynamic type of config file (e.g. python or yaml) or a config-file builder tool.

    5. Adding the above three solutions together: yes.

    6. Config definition and validation: yes.

    7. Adding groups of commandline arguments together: yes.

    8. Adding config definitions together: yes.

    9. The ability to lock/log changes to the config: yes. By default Scripts use LoggingDict that logs runtime changes; StrictScript uses a ReadOnlyDict (sams as mozharness) that prevents any changes after locking.

    10. Python 3 and python 2.7 unicode support: yes.

    11. Standardized solution: no. Extended/abstracted argparse + extended python dict.

    12. All-in-one solution: yes.

    Corrections, additions, feedback?

    As far as I can tell there is no perfect solution here. Thoughts?



    comment count unavailable comments

    Sean McArthurhyper v0.6

    A bunch of goodies are included in version 0.6 of hyper.

    Highlights

    • Experimental HTTP2 support for the Client! Thanks to tireless work of @mlalic.
    • Redesigned Ssl support. The Server and Client can accept any implementation of the Ssl trait. By default, hyper comes with an implementation for OpenSSL, but this can now be disabled via the ssl cargo feature.
    • A thread safe Client. As in, Client is Sync. You can share a Client over multiple threads, and make several requests simultaneously.
    • Just about 90% test coverage. @winding-lines has been bumping the number ever higher.

    Also, as a reminder, hyper has been following semver more closely, and so, breaking changes mean bumping the minor version (until 1.0). So, to reduce unplanned breakage, you should probably depend on a specific minor version, such as 0.6, and not *.

    The Rust Programming Language BlogRust 1.1 stable, the Community Subteam, and RustCamp

    We’re happy to announce the completion of the first release cycle after Rust 1.0: today we are releasing Rust 1.1 stable, as well as 1.2 beta.

    Read on for details the releases, as well as some exciting new developments within the Rust community.

    What’s in 1.1 Stable

    One of the highest priorities for Rust after its 1.0 has been improving compile times. Thanks to the hard work of a number of contributors, Rust 1.1 stable provides a 32% improvement in compilation time over Rust 1.0 (as measured by bootstrapping).

    Another major focus has been improving error messages throughout the compiler. Again thanks to a number of contributors, a large portion of compiler errors now include extended explanations accessible using the --explain flag.

    Beyond these improvements, the 1.1 release includes a number of important new features:

    • New std::fs APIs. This release stabilizes a large set of extensions to the filesystem APIs, making it possible, for example, to compile Cargo on stable Rust.
    • musl support. It’s now possible to target musl on Linux. Binaries built this way are statically linked and have zero dependencies. Nightlies are on the way.
    • cargo rustc. It’s now possible to build a Cargo package while passing arbitrary flags to the final rustc invocation.

    More detail is available in the release notes.

    What’s in 1.2 Beta

    Performance improvements didn’t stop with 1.1 stable. Benchmark compilations are showing an additional 30% improvement from 1.1 stable to 1.2 beta; Cargo’s main crate compiles 18% faster.

    In addition, parallel codegen is working again, and can substantially speed up large builds in debug mode; it gets another 33% speedup on bootstrapping on a 4 core machine. It’s not yet on by default, but will be in the near future.

    Cargo has also seen some performance improvements, including a 10x speedup on large “no-op” builds (from 5s to 0.5s on Servo), and shared target directories that cache dependencies across multiple packages.

    In addition to all of this, 1.2 beta includes our first support for MSVC (Microsoft Visual C): the compiler is able to bootstrap, and we have preliminary nightlies targeting the platform. This is a big step for our Windows support, making it much easier to link Rust code against code built using the native toolchain. Unwinding is not yet available – code aborts on panic – but the implementation is otherwise complete, and all rust-lang crates are now testing on MSVC as a first-tier platform.

    Rust 1.2 stable will be released six weeks from now, together with 1.3 beta.

    Community news

    In addition to the above technical work, there’s some exciting news within the Rust community.

    In the past few weeks, we’ve formed a new subteam explicitly devoted to supporting the Rust community. The team will have a number of responsibilities, including aggregating resources for meetups and other events, supporting diversity in the community through leadership in outreach, policies, and awareness-raising, and working with our early production users and the core team to help guide prioritization.

    In addition, we’ll soon be holding the first official Rust conference: RustCamp, on August 1, 2015, in Berkeley, CA, USA. We’ve received a number of excellent talk submissions, and are expecting a great program.

    Contributors to 1.1

    As with every release, 1.1 stable is the result of work from an amazing and active community. Thanks to the 168 contributors to this release:

    • Aaron Gallagher
    • Aaron Turon
    • Abhishek Chanda
    • Adolfo Ochagavía
    • Alex Burka
    • Alex Crichton
    • Alexander Polakov
    • Alexis Beingessner
    • Andreas Tolfsen
    • Andrei Oprea
    • Andrew Paseltiner
    • Andrew Straw
    • Andrzej Janik
    • Aram Visser
    • Ariel Ben-Yehuda
    • Avdi Grimm
    • Barosl Lee
    • Ben Gesoff
    • Björn Steinbrink
    • Brad King
    • Brendan Graetz
    • Brian Anderson
    • Brian Campbell
    • Carol Nichols
    • Chris Morgan
    • Chris Wong
    • Clark Gaebel
    • Cole Reynolds
    • Colin Walters
    • Conrad Kleinespel
    • Corey Farwell
    • David Reid
    • Diggory Hardy
    • Dominic van Berkel
    • Don Petersen
    • Eduard Burtescu
    • Eli Friedman
    • Erick Tryzelaar
    • Felix S. Klock II
    • Florian Hahn
    • Florian Hartwig
    • Franziska Hinkelmann
    • FuGangqiang
    • Garming Sam
    • Geoffrey Thomas
    • Geoffry Song
    • Graydon Hoare
    • Guillaume Gomez
    • Hech
    • Heejong Ahn
    • Hika Hibariya
    • Huon Wilson
    • Isaac Ge
    • J Bailey
    • Jake Goulding
    • James Perry
    • Jan Andersson
    • Jan Bujak
    • Jan-Erik Rediger
    • Jannis Redmann
    • Jason Yeo
    • Johann
    • Johann Hofmann
    • Johannes Oertel
    • John Gallagher
    • John Van Enk
    • Jordan Humphreys
    • Joseph Crail
    • Kang Seonghoon
    • Kelvin Ly
    • Kevin Ballard
    • Kevin Mehall
    • Krzysztof Drewniak
    • Lee Aronson
    • Lee Jeffery
    • Liigo Zhuang
    • Luke Gallagher
    • Luqman Aden
    • Manish Goregaokar
    • Marin Atanasov Nikolov
    • Mathieu Rochette
    • Mathijs van de Nes
    • Matt Brubeck
    • Michael Park
    • Michael Rosenberg
    • Michael Sproul
    • Michael Wu
    • Michał Czardybon
    • Mike Boutin
    • Mike Sampson
    • Ms2ger
    • Nelo Onyiah
    • Nicholas
    • Nicholas Mazzuca
    • Nick Cameron
    • Nick Hamann
    • Nick Platt
    • Niko Matsakis
    • Oliver Schneider
    • P1start
    • Pascal Hertleif
    • Paul Banks
    • Paul Faria
    • Paul Quint
    • Pete Hunt
    • Peter Marheine
    • Philip Munksgaard
    • Piotr Czarnecki
    • Poga Po
    • Przemysław Wesołek
    • Ralph Giles
    • Raphael Speyer
    • Ricardo Martins
    • Richo Healey
    • Rob Young
    • Robin Kruppe
    • Robin Stocker
    • Rory O’Kane
    • Ruud van Asseldonk
    • Ryan Prichard
    • Sean Bowe
    • Sean McArthur
    • Sean Patrick Santos
    • Shmuale Mark
    • Simon Kern
    • Simon Sapin
    • Simonas Kazlauskas
    • Sindre Johansen
    • Skyler
    • Steve Klabnik
    • Steven Allen
    • Steven Fackler
    • Swaroop C H
    • Sébastien Marie
    • Tamir Duberstein
    • Theo Belaire
    • Thomas Jespersen
    • Tincan
    • Ting-Yu Lin
    • Tobias Bucher
    • Toni Cárdenas
    • Tshepang Lekhonkhobe
    • Ulrik Sverdrup
    • Vadim Chugunov
    • Valerii Hiora
    • Wangshan Lu
    • Wei-Ming Yang
    • Wojciech Ogrodowczyk
    • Xuefeng Wu
    • York Xiang
    • Young Wu
    • bors
    • critiqjo
    • diwic
    • gareins
    • inrustwetrust
    • jooert
    • klutzy
    • kwantam
    • leunggamciu
    • mdinger
    • nwin
    • parir
    • pez
    • robertfoss
    • sinkuu
    • tynopex
    • らいどっと

    Yunier José Sosa VázquezDisponible cuentaFox 3.1.1

    Pocos días después de presentarse la versión que corregía el problema presentado con el servicio para obtener el estado de las cuotas, ya está aquí cuentaFox 3.1.1.

    ¿Qué hay de nuevo?

    • Ahora se muestra la lista de todos los usuarios que han almacenado sus contraseñas en Firefox.

    v31.1-userlist

    • Las alertas de consumo ahora se muestran pero sin iconos pues al agregarle un icono no se muestran (probado en Linux).

    v3.1.1-alertas

    • También se corrigieron algunos errores menores.

    Firmando el complemento

    A partir de Firefox 41 se introducirán algunos cambios en la gestión de los complementos en el navegador y solo se podrán instalar complementos firmados por Mozilla. Que un complemento esté firmado por Mozilla significa más seguridad para las usuarios ante extensiones malignas y programas de terceros que intentan instalar add-ons en Firefox.

    Para estar preparados cuando llegue Firefox 41 hemos enviando cuentaFox para su revisión en AMO y dentro de poco lo tendremos por aquí.

    Aún muchas personas utilizan versiones viejas, actualiza a cuentaFox 3.1.1

    Desde el panel estadísticas de AMO nos hemos dado cuenta que muchas personas siguen usando versiones viejas que no funcionan y no son recomendadas. Desde aquí hacemos el llamado para que actualicen y difundan la noticia sobre la nueva liberación.

    No obstante, cuando el add-on sea aprobado, Firefox lo actualizará según la configuración del usuario. La idea que tenemos es que el complemento se actualice desde Firefoxmanía y no desde Mozilla pero el certificado autofirmado y otros problemas impiden que lo hagamos.

    stats-cuentafox

    El usuario o la contraseña es incorrecta

    Muchas personas han manifestado que al intentar obtener sus datos se muestra una alerta donde dice “El usuario no es válido o lo contraseña es incorrecta” y nos piden solucionar esto pero no podemos. Nosotros no somos responsables del servicio que brinda cuotas.uci.cu y tampoco sabemos que utiliza para verificar que esos datos son correctos.

    Si deseas colaborar en el desarrollo del complemento puedes acceder a GitLab (UCI) y clonar el proyecto o dejar una sugerencia.

    Instalar cuentaFox 3.1.1

    Matt ThompsonUpdating our on-ramps for contributors

    I got to sit in on a great debrief / recap of the recent Webmaker go-to-market strategy. A key takwaway: we’re having promising early success recruiting local volunteers to help tell the story, evangelize for the product, and (crucially) feed local knowledge into making the product better. In short:

    Volunteer contribution is working. But now we need to document, systematize and scale up our on-ramps.

    Documenting and systematizing

    It’s been a known issue that we need to update and improve our on-ramps for contributors across MoFo. They’re fragmented, out of date, and don’t do enough to spell out the value for contributors. Or celebrate their stories and successes.

    We should prioritize this work in Q3. Our leadership development work, local user research, social marketing for Webmaker, Mozilla Club Captains and Regional Co-ordinators recruitment, the work the Participation Lab is doing — all of that is coming together at an opportune moment.

    Ryan is a 15-year-old volunteer contributor to Webmaker for Android — and currently the second-most-active Java developer on the entire project.

    Get the value proposition right

    A key learning is: we need to spell out the concrete value proposition for contributors. Particularly in terms of training and gaining relevant work experience.

    Don’t assume we know in advance what contributors actually want. They will tell us.

    We sometimes assume contributors want something like certification or a badge — but what if what they *really* want is a personalized letter of recommendation, on Mozilla letterhead, from an individual mentor at Mozilla that can vouch for them and help them get a job, or get into a school program? Let’s listen.

    An on-boarding and recruiting checklist

    Here’s some key steps in the process the group walked through. We can document / systematize / remix these as we go forward.

    • Value proposition. Start here first. What’s in it for contributors? (e.g., training, a letter of recommendation, relevant work experience?) Don’t skip this! It’s the foundation for doing this in a real way.
    • Role description. Get good at describing those skills and opportunities, in language people can imagine adding to their CV, personal bio or story, etc.
    • Open call. Putting the word out. Having the call show up in the right channels, places and networks where people will see and hear about it.
    • Application / matching. How do people express interest? How do we sort and match them?
    • On-boarding and training. These processes exist, but aren’t well-documented. We need a playbook for how newcomers get on-boarded and integrated.
    • Assigning  to a specific team and individual mentor. So that they don’t feel disconnected or lost. This could be an expectation for all MoFo: each staff member will mentor at least one apprentice each quarter.
    • Goal-setting / tasking. Tickets or some other way to surface and co-ordinate the work they’re doing.
    • A letter of recommendation. Once the work is done. Written by their mentor. In a language that an employer / admission officer / local community members understand and value.
    • Certification. Could eventually also offer something more formal. Badging, a certificate, something you could share on your linked in profile, etc.

    Next steps

    Myk MelezIntroducing PluotSorbet

    PluotSorbet is a J2ME-compatible virtual machine written in JavaScript. Its goal is to enable users you run J2ME apps (i.e. MIDlets) in web apps without a native plugin. It does this by interpreting Java bytecode and compiling it to JavaScript code. It also provides a virtual filesystem (via IndexedDB), network sockets (through the TCPSocket API), and other common J2ME APIs, like Contacts.

    The project reuses as much existing code as possible, to minimize its surface area and maximize its compatibility with other J2ME implementations. It incorporates the PhoneME reference implementation, numerous tests from Mauve, and a variety of JavaScript libraries (including jsbn, Forge, and FileSaver.js). The virtual machine is originally based on node-jvm.

    PluotSorbet makes it possible to bring J2ME apps to Firefox OS. J2ME may be a moribund platform, but it still has non-negligible market share, not to mention a number of useful apps. So it retains residual value, which PluotSorbet can extend to Firefox OS devices.

    PluotSorbet is also still under development, with a variety of issues to address. To learn more about PluotSorbet, check out its README, clone its Git repository, peruse its issue tracker, and say hello to its developers in irc.mozilla.org#pluotsorbet!

    About:CommunityMozilla Tech Speakers: A pilot for technical evangelism

    The six-week pilot version of the Mozilla Tech Speakers program wrapped up at the end of May. We learned a lot, made new friends on several continents, and collected valuable practical feedback on how to empower and support volunteer Mozillians who are already serving their regional communities as technical evangelists and educators. We’ve also gathered some good ideas for how to scale a speaker program that’s relevant and accessible to technical Mozillians in communities all over the world. Now we’re seeking your input and ideas as well.

    During the second half of 2015, we’ll keep working with the individuals in our pilot group (our pilot pilots) to create technical workshops and presentations that increase developer awareness and adoption of Firefox, Mozilla, and the Open Web platform. We’ll keep in touch as they submit talk proposals and develop Content Kits during the second half of the year, work with them to identify relevant conferences and events, fund speaker travel as appropriate, make sure speakers have access to the latest information (and the latest swag to distribute), and offer them support and coaching to deliver and represent!

    Why we did it

    Our aim is to create a strong community-driven technical speaker development program in close collaboration with Mozilla Reps and the teams at Mozilla who focus on community education and participation. From the beginning we benefited from the wisdom of Rosana Ardila, Emma Irwin, Soumya Deb, and other Mozillian friends. We decided to stand up a “minimum viable” program with trusted, invited participants—Mozillians who are active technical speakers and are already contributing to Mozilla by writing about and presenting Mozilla technology at events around the world. We were inspired by the ongoing work of the Participation Team and Speaker Evangelism program that came before us, thanks to the efforts of @codepo8, Shezmeen Prasad, and many others.

    We want this program to scale and stay sustainable, as individuals come and go, and product and platform priorities evolve. We will incorporate the feedback and learnings from the current pilot into all future iterations of the Mozilla Tech Speaker program.

    What we did

    Participants met together weekly on a video call to practice presentation skills and impromptu storytelling, contributed to the MDN Content Kit project for sharing presentation assets, and tried out some new tools for building informative and inspiring tech talks.

    Each participant received one session of personalized one-to-one speaker coaching, using “techniques from applied improvisation and acting methods” delivered by People Rocket’s team of coaching professionals. For many participants, this was a peak experience, a chance to step out of their comfort zone, stretch their presentation skills, build their confidence, and practice new techniques.

    In our weekly meetings, we worked with the StoryCraft technique, and hacked it a little to make it more geek- and tech speaker-friendly. We also worked with ThoughtBox, a presentation building tool to “organize your thoughts while developing your presentation materials, in order to maximize the effectiveness of the content.” Dietrich took ThoughtBox from printable PDF to printable web-based form, but we came to the conclusion it would be infinitely more usable if it were redesigned as an interactive web app. (Interested in building this? Talk to us on IRC. You’ll find me in #techspeakers or #devrel, with new channels for questions and communication coming soon.)

    We have the idea that an intuitive portable tool like ThoughtBox could be useful for any group of Mozillians anywhere in the world who want to work together on practicing speaking and presentation skills, especially on topics of interest to developers. We’d love to see regional communities taking the idea of speaker training and designing the kind of programs and tools that work locally. Let’s talk more about this.

    What we learned

    The pilot was ambitious, and combined several components—speaker training, content development, creating a presentation, proposing a talk—into an aggressive six-week ‘curriculum.’ The team, which included participants in eight timezones, spanning twelve+ hours, met once a week on a video call. We kicked off the program with an introduction by People Rocket and met regularly for the next six weeks.

    Between scheduled meetings, participants hung out in Telegram, a secure cross-platform messaging app, sharing knowledge, swapping stickers (the virtual kind) and becoming friends. Our original ambitious plan might have been feasible if our pilots were not also university students, working developers, and involved in multiple projects and activities. But six weeks turned out to be not quite long enough to get it all done, so we focused on speaking skills—and, as it turned out, on building a global posse of talented tech speakers.

    What’s next

    We’re still figuring this out. We collected feedback from all participants and discovered that there’s a great appetite to keep this going. We are still fine-tuning some of the ideas around Content Kits, and the first kits are becoming available for use and re-use. We continue to support Tech Speakers to present at conferences organize workshops and trainings in their communities. And create their own Mozilla Tech Speakers groups with local flavor and focus.

    Stay tuned: we’ll be opening a Discourse category shortly, to expand the conversation and share new ideas.

    And now for some thank yous…

    I’d like to quickly introduce you to the Mozilla Tech Speakers pilot pilots. You’ll be hearing from them directly in the days, weeks, months ahead, but for today, huge thanks and hugs all around, for the breadth and depth of their contributions, their passion, and the friendships we’ve formed.

    Adrian Crespo, Firefox Marketplace reviewer, Mozilla Rep, student, and technical presenter from Madrid, Spain, creator of the l10n.js Content Kit, for learning and teaching localization through the native JavaScript method.

    Ahmed Nefzaoui, @AhmedNefzaoui, recent graduate and active Mozillian, Firefox OS contributor, Arabic Mozilla localizer, RTL (right-to-left) wizard, and web developer from Tozeur, Tunisia.

    Andre Garzia, @soapdog, Mozilla Rep from Rio de Janeiro, Brazil, web developer, app developer and app reviewer, who will be speaking about Web Components at Expotec at the end of this month. Also, ask him about the Webmaker team LAN Houses program just getting started now in Rio.

    Andrzej Mazur, @end3r, HTML5 game developer, active Hacks blog and MDN contributor, creator of a content kit on HTML5 Game Development for Beginners, active Firefox app developer, Captain Rogers creator, and frequent tech speaker, from Warsaw, Poland.

    István “Flaki” Szmozsánszky, @slsoftworks, Mozillian and Mozilla Rep, web and mobile developer from Budapest, Hungary. Passionate about Rust, Firefox OS, the web of things. If you ask him anything “mildly related to Firefox OS, be prepared with canned food and sleeping bags, because the answer might sometimes get a bit out of hand.”

    Kaustav Das Modak, @kaustavdm, Mozilla Rep from Bengalaru, India; web and app developer; open source evangelist; co-founder of Applait. Ask him about Grouphone. Or, catch his upcoming talk at the JSChannel conference in Bangalore in July.

    Michaela R. Brown, @michaelarbrown, self-described “feisty little scrapper,” Internet freedom fighter, and Mozillian from Michigan. Michaela will share skills in San Francisco next week at the Library Freedom Project: Digital Rights in Libraries event.

    Rabimba Karanjai, @rabimba, a “full-time graduate researcher, part-time hacker and FOSS enthusiast,” and 24/7 Mozillian. Before the month is out, Rabimba will speak about Firefox OS at OpenSourceBridge in Portland and at the Hong Kong Open Source conference.

    Gracias. شكرا. धन्यवाद. Köszönöm. Obrigada. Dziękuję. Thank you. #FoxYeah.

    Robert O'CallahanWhistler Hike

    I'm at the Mozilla all-hands week in Whistler. Today (Monday) was a travel day, but many of us arrived yesterday, so today I had most of the day free and chose to go on a long time organized by Sebastian --- because I like hiking, but also lots of exercise outside should help me adjust to the time zone. We took a fairly new trail, the Skywalk South trail: starting in the Alpine Meadows settlement at the Rick's Roost trailhead at the end of Alpine Way, walking up to connect with the Flank trail, turning up 19 Mile Creek to wind up through forest to Iceberg lake above the treeline, then south up and over a ridge on the Skywalk South route, connecting with the Rainbow Ridge Loop route, then down through Switchback 27 to finally reach Alta Lake Rd. This took us a bit over 8 hours including stops. We generally hiked quite fast, but some of the terrain was tough, especially the climb up to and over the ridge heading south from Iceberg Lake, which was more of a rock-climb than a hike in places! We had to get through snow in several places. We had a group of eight, four of us who did the long version and four who did a slightly shorter version by returning from Iceberg Lake the way we came. Though I'm tired, I'm really glad we did this hike the way we did it; the weather was perfect, the scenery was stunning, and we had a good workout. I even went for a dip in Iceberg Lake, which was a little bit crazy and well worth it!

    Liz HenryTrip to Whistler for Mozilla’s work week

    Our work week hasn’t started yet, but since I got to Whistler early I have had lots of adventures.

    First the obligatory nostril-flaring over what it is like to travel with a wheelchair. As we started the trip to Vancouver I had an interesting experience with United Airlines as I tried to persuade them that it was OK for me to fold up my mobility scooter and put it into the overhead bin on the plane. Several gate agents and other people got involved telling me many reasons why this could not, should not, and never has or would happen:

    * It would not fit
    * It is illegal
    * The United Airlines handbook says no
    * The battery has to go into the cargo hold
    * Electric wheelchairs must go in the cargo hold
    * The scooter might fall out and people might be injured
    * People need room for their luggage in the overhead bins
    * Panic!!

    The Air Carrier Access Act of 1986 says,

    Assistive devices do not count against any limit on the number of pieces of carry-on baggage. Wheelchairs and other assistive devices have priority for in-cabin storage space over other passengers’ items brought on board at the same airport, if the disabled passenger chooses to preboard.

    In short I boarded the airplane, and my partner Danny folded up the scooter and put it in the overhead bin. Then, the pilot came out and told me that he could not allow my battery on board. One of the gate agents had told him that I have a wet cell battery (like a car battery). It is not… it is a lithium ion battery. In fact, airlines do not allow lithium batteries in the cargo hold! The pilot, nicely, did not demand proof it is a lithium battery. He believed me, and everyone backed down.

    The reason I am stubborn about this is that I specially have a very portable, foldable electric wheelchair so that I can fold it up and take it with me. Two times in the past few years, I have had my mobility scooters break in the cargo hold of a plane. That made my traveling very difficult! The airlines never reimbursed me for the damage. Another reason is that the baggage handlers may lose the scooter, or bring it to the baggage pickup area rather than to the gate of the plane.

    Onward to Whistler! We took a shuttle and I was pleasantly (and in a way, sadly) surprised that the shuttle liason, and the driver, both just treated me like any other human being. What a relief! It is not so hard! This experience is so rare for me that I am going to email the shuttle company to compliment them and their employees.

    The driver, Ivan, took us through Vancouver, across a bridge that is a beautiful turquoise color with stone lions at its entrance, and through Stanley Park. I particularly noticed the tiny beautiful harbor or lagoon full of boats as we got off the bridge. Then, we went up Highway 99, or the Sea to Sky Highway, to Squamish and then Whistler.

    Sea to sky highway

    When I travel to new places I get very excited about the geology and history and all the geography! I love to read about it beforehand or during a trip.

    The Sea to Sky Highway was improved in preparation for the Winter Olympics and Paralympics in 2010. Before it was rebuilt it was much twistier with more steeply graded hills and had many bottlenecks where the road was only 2 lanes. I believe it must also have been vulnerable to landslides or flooding or falling rocks in places. As part of this deal the road signs are bilingual in English and Squamish. I read a bit on the way about the ongoing work to revitalize the Squamish language.

    The highway goes past Howe Sound, on your left driving up to Squamish. It is a fjord, created by retreated glaciers around 11,000 years ago. Take my geological knowledge with a grain of salt (or a cube of ice) but here is a basic narrative of the history. AT some point it was a shallow sea here but a quite muddy one, not one with much of a coral reef system, and the mountains were an archipelago of island volcanoes. So there are ocean floor sediments around, somewhat metamorphosed; a lot of shale.

    There is a little cove near the beginning of the highway with some boats and tumble-down buildings, called Porteau Cove. Interesting history there. Then you will notice a giant building up the side of a hill, the Britannia Mining Museum. That was once the Britannia Mines, producing billions of dollars’ worth of copper, gold, and other metals. The entire hill behind the building is honeycombed with tunnels! While a lot of polluted groundwater has come out of this mine damaging the coast and the bay waters, it was recently plugged with concrete: the Millenium Plug, and that improved water quality a lot, so that shellfish, fish, and marine mammals are returning to the area. The creek also has trout and salmon returning. That’s encouraging!

    Then you will see huge granite cliffs and Shannon Falls. The giant monolith made me think of El Capitan in Yosemite. And also of Enchanted Rock, a huge pink granite dome in central Texas. Granite weathers and erodes in very distinctive ways. Once you know them you can recognize a granite landform from far away! I haven’t had a chance to look close up at any rocks on this trip…. Anyway, there is a lot of granite and also basalt or some other igneous extrusive rock. Our shuttle driver told me that there is columnar basalt near by at a place called French Fry Hill.

    The mountain is called Stawamus Chief Mountain. Squamish history tells us it was a longhouse turned to stone by the Transformer Brothers. I want to read more about that! Sounds like a good story! Rock climbers love this mountain.

    There are some other good stories, I think one about two sisters turned to stone lions. Maybe that is why there are stone lions on the Vancouver bridge.

    The rest of the drive brought us up into the snowy mountains! Whistler is only 2000 feet above sea level but the mountains around it are gorgeous!

    The “village” where tourists stay is sort of a giant, upscale, outdoor shopping mall with fake streets in a dystopian labyrinth. It is very nice and pretty but it can also feel, well, weird and artificial! I have spent some time wandering around with maps, backtracking a lot when I come to dead ends and stairways. I am also playing Ingress (in the Resistance) so I have another geographical overlay on the map.

    Whistler bridge lost lake

    On Sunday I got some groceries and went down paved and then gravel trails to Lost Lake. It was about an hour long trip to get there. The lake was beautiful, cold, and full of people sunbathing, having picnics, and swimming. Lots of bikes and hikers. I ran out of battery (nearly), then realized that the lake is next to a parking lot. I got a taxi back to the Whistler Village hotel! Better for me anyway since the hour long scooter trip over gravel just about killed me (I took painkiller halfway there and then was just laid flat with pain anyway.) Too ambitious of an expedition, sadly. I had many thoughts about the things I enjoyed when I was younger (going down every trail, and the hardest trails, and swimming a lot) Now I can think of those memories, and I can look at beautiful things and also read all the information about an area which is enjoyable in a different way. This is just how life is and you will all come to it when you are old. I have this sneak preview…. at 46…. When I am actually old, I will have a lot of practice and will be really good at it. Have you thought about what kind of old person you would like to be, and how you will become that person?

    Today I stayed closer to home just going out to Rebagliati Park. This was fabulous since it wasn’t far away, seriously 5 minutes away! It was very peaceful. I sat in a giant Adirondack chair in a flower garden overlooking the river and a covered bridge. Watching the clouds, butterflies, bees, birds, and a bear! And of course hacking the portals (Ingress again). How idyllic! I wish I had remembered to bring my binoculars. I have not found a shop in the Whistler Mall-Village that stocks binoculars. If I find some, I will buy them.

    I also went through about 30 bugs tracked for Firefox 39, approved some for uplift, wontfixed others, emailed a lot of people for work, and started the RC build going. Releng was heroic in fixing some issues with the build infrastructure! But, we planned for coverage for all of us. Good planning! I was working Sunday and Monday while everyone else travelled to get here…. Because of our release schedule for Firefox it made good sense for me to get here early. It also helps that I am somewhat rested from the trip!

    I went to the conference center, found the room that is the home base for the release management and other platform teams, and got help from a conference center setup guy to lay down blue tape on the floor of the room from the doorway to the back of the room. The tape marks off a corridor to be kept clear, not full of backpacks or people standing and talking in groups, so that everyone can freely get in and out of the room. I hope this works to make the space easy for me to get around in, in my wheelchair, and it will surely benefit other people as well.

    Travel lane

    At this work week I hope to learn more about what other teams are doing, any cool projects etc, especially in release engineering and in testing and automated tools and to catch up with the Bugzilla team too. And will be talking a bunch about the release process, how we plan and develop new Firefox features, and so on! Looking forward now to the reception and seeing everyone who I see so much online!

    Related posts:

    Ted ClancyThe Canadian, Day 5

    Today I woke up on the outskirts of Greater Vancouver, judging by the signs in this industrial area. The steward has just announced we’ll be arriving in Vancouver in one hour.

    Thus concludes my journey. Though the journey spanned five calendar days, I left late on Thursday night and I’m arriving early Monday morning, so it’s more like four nights and three days. (A total travelling time of 3 days and 14.5 hours.) Because I travelled over a weekend, I only lost one day of office time and gained a scenic weekend.

    The trip roughly breaks down to one day in the forests of Ontario, one day across the plains of Manitoba and Saskatchewan, and one day across the mountains of Alberta and British Columbia.

    In retrospect, I should have done my work on the second day, when my mobile internet connection was good and the scenery was less interesting. (Sorry, Manitoba. Sorry, Saskatchewan.)

    From here I take a bus to Whistler to attend what Mozilla calls a “work week” — a collection of presentations, team meetings, and planning sessions. It ends with a party on Friday night, the theme of which is “lumberjack”. (Between the bears and the hipsters, don’t I already get enough of people dressing like lumberjacks back in Toronto?)

    Because I’m a giant hypocrite, I’ll be flying back to Toronto. But I heartily recommend travel by Via Rail. Their rail passes (good for visiting multiple destinations, or doing a round trip) are an especially good deal.

    I wonder what Kylie Minogue has to say about rail travel.


    QMOFirefox 39 Beta 7 Testday Results

    Hey Mozillians!

    As you already may know, last Friday – June 19th – we held another Testday event, Firefox 39 Beta 7.

    We’d like to take this opportunity to thank everyone for getting involved in the proposed testing activities and in general, for helping us make Firefox better.
    Many thanks go out to Bangladesh QA Community, which gets bigger and better everyday (Hossain Al Ikram, Nazir Ahmed Sabbir, Forhad Hossain, Ashickur Rahman, Meraj  Kazi, Md. Ehsanul Hassan, Wahiduzzaman Hridoy, Rezaul Huque Nayeem, Towkir Ahmed, Md. Rahimul Islam, Mohammad Maruf Islam, Fahmida Noor, Sayed Mohammad Amir, Saheda reza Antora), Moin, nt, Vairus and AaronRaimist for their efforts and contributions, and to all our moderators. Thanks a bunch!

    Keep an eye on QMO for the upcoming events! :)

    John O'DuinnThe canary in the coal mine

    After my recent “We are ALL Remoties” presentation at Wikimedia, I had some really great followup conversations with Arthur Richards at WikiMedia Foundation. Arthur has been paying a lot of attention to scrum and agile methodologies – both in the wider industry and also specifically in the context of his work at Wikimedia Foundation, which has people in different locations. As you can imagine, we had some great fun conversations – about remoties, about creating culture change, and about all-things-scrum – especially the rituals and mechanics of doing daily standups with a distributed team.

    Next time you see a group of people standing together looking at a wall, and moving postit notes around, ask yourself: “how do remote people stay involved and contribute?” Taking photographs of the wall of postit notes, or putting the remote person on a computer-with-camera-on-wheeled-cart feels like a duct-tape workaround; a MacGyver fix done quickly, with the best of intentions, genuinely wanting to help the remote person be involved, but still not-a-great experience for remoties.

    There has to be a better way.

    We both strongly agree that having people in different locations is just a way to uncover the internal communication problems you didn’t know you already have… the remote person is the canary in the coal mine. Having a “we are all remoties” mindset helps everyone become more organized in their communications, which helps remote people *and* also the people sitting near each other in the office.

    Arthur talked about this idea in his recent (and lively and very well attended!) presentation at the Annual Scrum Alliance “Global Scrum Gathering” event in Phoenix, Arizona. His slides are now visible here and here.

    If you work in an agile / scrum style environment, especially with a geo-distributed team of humans, it’s well worth your time to read Arthur’s presentation! Thought provoking stuff, and nice slides too!

    This Week In RustThis Week in Rust 84

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

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

    This week's edition was edited by: Brian Anderson, Vikrant Chaudhary, Andrew Gallant, and mdinger.

    From the Blogosphere

    Tips & Tricks

    In the News

    New Releases & Project Updates

    • RustLex. Lexical analysers generator for Rust.
    • rsedis. Redis re-implemented in Rust.
    • cargo add. A utility for adding cargo dependencies from the command line.
    • volley. A benchmarking tool for measuring the performance of server networking stacks.
    • Rust Dispatcher. Dispatcher for Rust, broadcast and subscribe many to many.
    • rust-vim-setup. Use VIM as your Rust IDE - set of bash scripts and a customised vimrc for Rust development.
    • Herd. An experimental HTTP load testing application written in Rust.
    • MaidSafe's Rust rewrite is going well.
    • claxon. A FLAC decoder.

    Rust by example has receieved a number of improvements recently:

    What's cooking on master?

    112 pull requests were merged in the last week.

    Now you can follow breaking changes as they happen!

    Breaking Changes

    Other Changes

    New Contributors

    • David Stygstra
    • Gulshan Singh
    • Jake Hickey
    • joliv
    • Markus
    • Steven Walter
    • Yongqian Li

    Approved RFCs

    Final Comment Period

    Every week the teams announce a 'final comment period' for RFCs which are close to reaching a conclusion. Express your opinions now. This week's RFCs entering FCP are:

    New RFCs

    Upcoming Events

    If you are running a Rust event please add it to the calendar to get it mentioned here. Email Erick Tryzelaar or Brian Anderson for access.

    Ted ClancyThe Canadian, Day 4

    The great thing about travelling by train is that there is almost zero environmental impact.

    Before you say “but what about those giant diesel engines burning diesel”, let me explain that I’m talking about marginal impact. That is, this train was going to be running regardless of whether I was on it or not. By choosing to be on it, I’m not contributing any additional environmental impact.

    That’s not true for a bus or plane. If 100 people suddenly decided to travel from Toronto to Vancouver by bus, the bus company would have to schedule another couple busses. If 100 extra people decided to travel by plane, the airline would have to schedule another plane. But if 100 people decided to all take the train, Via Rail can simply add another couple of cars to their existing scheduled train, with negligible environmental impact.

    (Caveat: There are reports that Via Rail no longer does this, and Elizabeth May is not happy about it. See Point 1 in her letter.)

    There are downsides too. It’s more expensive than travelling by plane, though still within my company’s travel policy. (Note that I’m travelling in Economy. Note also that if you’re a member of CAA or Hostelling International, you get 10% off Via Rail tickets.) It also takes more time, but it’s not unproductive time. You can get quite a lot done on the train.

    The main downside is sleeping in a seat. I was fine for the first couple nights, but after that third night (last night), I’m starting to feel a bit rough. And I have one more night to go.

    The cost of the Via Rail ticket includes one stopover in any city for as long as you want. If I had more time, I might have scheduled a stopover in Winnipeg or Jasper for a couple nights to recharge.

    Update: Jasper
    Apparently I slept past Saskatoon and Edmonton.

    Jasper is beautiful, but you already knew that.

    Update: Approaching Kamloops
    I can’t help wishing I was seeing this scenery in winter instead of summer. Green mountains just look like big hills.

    We’re back on tracks laid by the Canadian Northern Railway. It still boggles my mind that we’re following a path chosen by someone 100 years ago. I spend so much of my life surrounded by new technology, it’s strange to be using something created even just 3 or 4 generations ago.

    The 1950s and 1960s saw the decline of passenger rail in Canada. It couldn’t compete with the rise of air travel and new highways like the Trans-Canada and the 401. The federal government created Via Rail in the 1970s to take over passenger operations from CN and CP, since those services were no longer profitable.

    I’m not exactly sure why the government keeps Via Rail running, but I’m glad they do. Last time I travelled by air, security confiscated my penknife.

    Musical Interlude IV
    [This one would have made more sense last night. I might swap them in a later edit.]


    Christian HeilmannThat stream of tweets at conferences…

    A few weeks ago, I wrote the That One Tweet post explaining how one tweet managed to puncture my balloon of happy and question if my work is appreciated. All of this is caused the gremlin of self-doubt living in all of us and it was mostly a reminder to tell it to mind its own business.

    Currently writing event reports, I think it would be terrible of me not to mention the other side of this. I want to take this opportunity to thank deeply and thoroughly people who use twitter to report, comment and encourage presenters and organisers of events. You rock, so here’s a hedgehog wizard to tell you as much:

    hedgehog dressed as a wizard

    I was very humbled and lucky to be at a few events in the last weeks where the audience used Twitter not only to post selfies and tell the world where they are, but also to report and keep a running commentary on talks. Others delivered beyond expectation by doing sketchnotes and posting those. I am humbled by and jealous of your creativity and dedication. Having good Twitter feedback has numerous effects that inflate my happy balloon:

    • It is superbly rewarding to see people deeply care about what you do.
    • It is insightful to see the tidbits of information people extract from your talks and what they considered quote-worthy. Yes, that can also be scary, but is a good reminder to explain some bits in better details next time
    • It makes my professional life so much easier as I can collect feedback and show it to my managers and outreach departments.
    • It allows me to show people that a personal touch and a presenter showing his or her views is much more beneficial to a company than a very polished slide deck people have to present
    • It shows me that I reach people with what I do. Feedback is scarce, and whilst immediate feedback tends to be highly polarised I have something to ponder
    • It gives me a fuzzy feeling when people find the need to align themselves with an event and tell the world how much of a good time they have. We have no lack of soulless events that people go to because they get a random ticket or to drop off as many business cards as they can. It feels great to see attendees go all in and praise an event for being different.
    • ROI of events is tough to measure. By being able to quote tweets, show people’s blog posts and photos I have ammunition to show people why my time there and our money in the support pot of events is worth it.

    So, here’s to the people who give feedback on talks and events on Twitter. You make me happy like this puppy:

    Incredibly happy puppy

    Keep up the great work, you can be sure that it is very appreciated by presenters and conference organisers alike

    Aki Sasakiscriptharness 0.2.0

    I've been getting some good feedback about scriptharness 0.1.0; thank you. I listed the 0.2.0 highlights and changes in the 0.2.0 Release Notes, but wanted to mention a few things here.

    First, mozharness' config had the flexibility of accepting any arbitrary key/value pairs from various sources (initial_config, commandline options, config files...). However, it wasn't always clear what each config variable was for, or if it was required, or if the config was valid. I filed bug 699343 back in 2011, but didn't know how to tackle it then. I believe I have the solution now, with ConfigTemplates.

    Second, 0.1.0 was definitely lacking a run_command() and get_output_from_command() analogs. 0.2.0 has Command for just running+logging a command, ParsedCommand for parsing the output of a command, and Output for getting the output from a command, as well as run(), parse(), get_output(), and get_text_output() shortcut functions to instantiate the objects and run them for you. (Docs are here.) Each of these supports cross-platform output_timeouts and max_timeouts in both python 2.7 and python3, thanks to the multiprocessing module. As a bonus, I was able to add context line support to the ErrorLists for ParsedCommand. This was also a want since 2011.

    I fleshed out some more documentation and populated the scriptharness issues with my todo list.

    I think I know what I have in mind for 0.3.0, but feedback is definitely welcome!



    comment count unavailable comments

    Ted ClancyThe Canadian, Day 3

    I expected to wake up in Winnipeg, but instead we’re stopped in the middle of nowhere. I can tell we’re in Manitoba, because the landscape has become flat and grassy instead of Ontario’s rocky forests and lakes, but I don’t see Winnipeg anywhere. Still no internet connection.

    The train is moving again. We just passed a farm that seems to be raising cows and abandoned trucks.

    Update: Winnipeg

    Our train has a layover of about 3 hours in Winnipeg. The Via Rail station is located beside The Forks, a historic part of Winnipeg of significance to First Nations people. This site has been used as a meeting place for at least 6000 years. It’s especially active today because today is Aboriginal Day.

    The site also hosts the Canadian Museum of Human Rights (which was still under construction last time I was here), a farmer’s market that is open today, and a couple historic rail cars. A pedestrian bridge (the Esplanade Riel) links it to Winnipeg’s French quarter, St Boniface, across the river. (Until 1971, St Boniface was its own predominantly-francophone city, a rarity in Western Canada.)

    I didn’t spend much time looking about, however. I went straight to the Assiniboine Athletic Club, just two short blocks from the Via Rail station’s main entrance, to take a shower. This is the only opportunity to shower between Toronto and Vancouver. It’s $11 for a day pass to the gym. I would have had a workout too, but I didn’t pack any shorts.

    Former rail car of the Temiskaming and Northern Ontario Railway

    The rail car in the above picture used to belong to the Temiskaming and Northern Ontario Railway, later known as the Ontario Northland Railway. Owned by the Ontario government, it’s one of the few railways in Canada which isn’t privately owned. Unfortunately, the Ontario government shut down ONR’s passenger services last year. It now only provides freight service and occasional tourist service.

    Update: Somewhere in Manitoba

    Manitoba is more scenic than you’d think. We’re currently in a rather pleasant-looking valley.

    We’re now on tracks that were built by Grand Trunk Pacific. These tracks go from Winnipeg to Prince Rupert in northern BC. Together, Grand Trunk Pacific (which operated west of Winnipeg) and National Transcontinental Railway (which operated east of Winnipeg) were the third and final transcontinental rail route across Canada.

    Like most Canadian railways, they eventually went bankrupt and were nationalized by the Canadian government, becoming part of the government-owned Canadian National Railway. The only major railway to escape this fate was Canadian Pacific Railway, leading to today’s situation where CNR and CPR (usually now called CN and CP) dominate Canada’s rail industry as a duopoly. CN was privatized in 1995. Apparently the largest shareholder is now Bill Gates.

    The GTP tracks are still well used. Prince Rupert is a popular port for shipments from China. Due to the shape of the Earth, Prince Rupert is closer to China than Vancouver is. It’s easier to see on a globe.

    Musical Interlude III


    About:CommunityBringing Participation to Whistler

    Mozilla at Whistler 2010

    Mozilla at Whistler 2010

    The Participation Team is heading to Whistler this week where we’ll be running an innovative series of discussions, presentations, and workshops all centered around creating an approach to participation that is massive and diverse, local and global, strategic and impactful.

    Whether you will be joining us in person or following along online. Here’s an overview of what we’ll be up to this week and how you can get involved:

    Skills Building: Human Centered Design
    Tuesday July 23rd 3:30pm-5pm

    The Participation Team will be participation in an open session about design thinking and problem solving both generally and as they relate to specific projects. Please arrive promptly at 3:30pm if you’d like to participate!

    Join in person: 3:30pm in the Participation Room in the Delta Whistler Village Suites hotel.
    Join remotely: Follow us on discourse and Twitter using the hashtag #MozParticipation to find out what we’re learning during this session.

    TED Style Talks: Exploring Radical Participation at Whistler
    Wednesday June 24th at 4:30pm

    A series of invited experts on participation will challenge us in short TED-style talks, bringing thought-provoking ideas on Radical Participation. Then join over one hundred Mozillians who care about participation as we come up with some rough designs for what radical participation could look like at Mozilla in the years ahead. Confirmed speakers include:

    • Natalie Foster – Co-founder and Executive Director of Peers, the world’s largest independent sharing economy community, and former digital director for President Obama’s Organizing for America (OFA) and the Democratic National Committee.
    • Jono Bacon – Senior Director of Community at XPrize where he leads community development and growth XPRIZE Foundation. He is the author of The Art of Community and the former Ubuntu Community Manager.
    • Jeremy Bird – is a founding Partner at 270 Strategies and a longtime strategist. He also was the National Field Director for the 2012 re-election camapgin of President Barack Obama where he was  dubbed the campaign’s  “Field General” by Rolling Stone Magazine.
    • See the full list of speakers  here

    Join in person: Wednesday June 24th at 4:30pm in Sea to Sky Ballroom C at the Whistler Conference Center
    Join remotely: Watch live on AirMozilla at 11:30pm UTC on June 24th, join the discussion on discourse and read the  blog afterwards for a synthesis of the most poignant ideas.

    Personalized Design: 26 Participation Lab Sessions
    Wednesday June 24th – Thursday June 25 9:30am – 9:00pm

    We’re hosting customized sessions throughout the work week to help teams solve problems and capture opportunities related to contributor or volunteer engagement, user/supporter/contributor participation, and many other topics related to participation. With over 26 projects registered we’ll be meeting with teams throughout the week.

    View the full schedule and the description of each project below.

    Join us in person: Registration is now closed for customized Lab sessions, however the Participation Room (Raven A + B at Delta Whistler Village Suites hotel) will be open to all throughout the week.
    Join remotely: What do you think of the sessions? Send us your thoughts and questions on discourse.

    Participation Moving Forward – Strategy Session
    Friday July 26th 8:30am-10am

    On the last day of Whistler the Participation Team will be gathering with volunteers, staff, and experts to think about what participation might look like at Mozilla 10, 15, 20 years in the future.

    Join in person: Participation Room (Raven A + B) at Delta Whistler Village Suites. Please arrive promptly at 8:30am if you’d like to participate.
    Join remotely: Share your thoughts/visions for the future of participation at Mozilla on discourse here.

    Read more about the Lab and what we’ve been up to in Emma Irwin’s post “Participation Lab, What We’re Learning”.

     

    Jeff WaldenNew changes to make SpiderMonkey’s (and Firefox’s) parsing of destructuring patterns more spec-compliant

    Destructuring in JavaScript

    One new feature in JavaScript, introduced in ECMAScript 6 (formally ECMAScript 2015, but it’ll always be ES6 in our hearts), is destructuring. Destructuring is syntactic sugar for assigning sub-values within a single value — nested properties, iteration results, &c., to arbitrary depths — to a set of locations (names, properties, &c.).

    // Declarations
    var [a, b] = [1, 2]; // a = 1, b = 2
    var { x: c, y: d } = { x: 42, y: 17 }; // c = 42, d = 17
    
    function f([z]) { return z; }
    print(f([8675309])); // 8675309
    
    
    // Assignments
    [b, f.prop] = [3, 15]; // b = 3, f.prop = 15
    ({ p: d } = { p: 33 }); // d = 33
    
    function Point(x, y) { this.x = x; this.y = y; }
    
    // Nesting's copacetic, too.
    // a = 2, b = 4, c = 8, d = 16
    [{ x: a, y: b }, [c, d]] = [new Point(2, 4), [8, 16]];
    

    Ambiguities in the parsing of destructuring

    One wrinkle to destructuring is its ambiguity: reading start to finish, is a “destructuring pattern” instead a literal? Until any succeeding = is observed, it’s impossible to know. And for object destructuring patterns, could the “pattern” just be a block statement? (A block statement is a list of statements inside {}, e.g. many loop bodies.)

    How ES6 handles the potential parser ambiguities in destructuring

    ES6 says an apparent “pattern” could be any of these possibilities: the only way to know is to completely parse the expression/statement. There are more elegant and less elegant ways to do this, although in the end they amount to the same thing.

    Object destructuring patterns present somewhat less ambiguity than array patterns. In expression context, { may begin an object literal or an object destructuring pattern (just as [ does for arrays, mutatis mutandis). But in statement context, { since the dawn of JavaScript only begins a block statement, never an object literal — and now, never an object destructuring pattern.

    How then to write object destructuring pattern assignments not in expression context? For some time SpiderMonkey has allowed destructuring patterns to be parenthesized, incidentally eliminating this ambiguity. But ES6 chose another path. In ES6 destructuring patterns must not be parenthesized, at any level of nesting within the pattern. And in declarative destructuring patterns (but not in destructuring assignments), declaration names also must not be parenthesized.

    SpiderMonkey now adheres to ES6 in requiring no parentheses around destructuring patterns

    As of several hours ago on mozilla-inbound, SpiderMonkey conforms to ES6’s parsing requirements for destructuring, with respect to parenthesization. These examples are all now syntax errors:

    // Declarations
    var [(a)] = [1]; // BAD, a parenthesized
    var { x: (c) } = {}; // BAD, c parenthesized
    var { o: ({ p: p }) } = { o: { p: 2 } }; // BAD, nested pattern parenthesized
    
    function f([(z)]) { return z; } // BAD, z parenthesized
    
    // Top level
    ({ p: a }) = { p: 42 }; // BAD, pattern parenthesized
    ([a]) = [5]; // BAD, pattern parenthesized
    
    // Nested
    [({ p: a }), { x: c }] = [{}, {}]; // BAD, nested pattern parenthesized
    

    Non-array/object patterns in destructuring assignments, outside of declarations, can still be parenthesized:

    // Assignments
    [(b)] = [3]; // OK: parentheses allowed around non-pattern in a non-declaration assignment
    ({ p: (d) } = {}); // OK: ditto
    [(parseInt.prop)] = [3]; // OK: parseInt.prop not a pattern, assigns parseInt.prop = 3
    

    Conclusion

    These changes shouldn’t much disrupt anyone writing JS. Parentheses around array patterns are unnecessary and are easily removed. For object patterns, instead of parenthesizing the object pattern, parenthesize the whole assignment. No big deal!

    // Assignments
    ([b]) = [3]; // BAD: parentheses around array pattern
    [b] = [3]; // GOOD
    
    ({ p: d }) = { p: 2 }; // BAD: parentheses around object pattern
    ({ p: d } = { p: 2 }); // GOOD
    

    One step forward for SpiderMonkey standards compliance!

    About:CommunityParticipation Lab, What We’re Learning

    Photo from Securing Web @ZAP Day 1

     

    In recent months the Participation Lab has been tracking multiple experiments across the project that demonstrate fresh approaches to participation.  To really understand and bring strategic value to Mozilla, our focus in these experiments has been to encourage human centered design and a deliberate setting of ‘milestones for learning ‘  and measuring success.

    Learning milestones are places in a project’s execution where we stop and evaluate the initial hypothesis about participation: do these goals still make sense? Are we still on track to learn about participation?  What are we already learning? Where can we help?

    What we’re finding is that ‘learning check-ins’ are a critical opportunity to recalibrate, and advance the depth and success of project and contributor success.  Participation shifts, and evolves with the project, it only makes sense to pay attention to those subtle changes. As a result of these conversations, and  analysis we’re starting to see a shift towards a new innovative approaches.

    The lab has also observed a number of trends in terms of what people struggle with most in establishing and measuring their participation experiments, and themes in how we’re trying to solve for better participation.  All of this is leading to more insightful prototyping and execution of participation goals, and in the spirit of the virtuous circle : amplifying impact on contributor success and sense of value, and project goals.

    Education & Training, Evangelism and Representation, and Market Research were identified as our top three themes in the nearly fifty projects we’re following. Learn more about these themes and how they’re being implemented below.

    Education & Training

    Community Education was at the heart of many initiatives we’re following. Many working hypothesis include education and training as a connective tissue for community building and  development of future leaders.  Almost all had a working theory, that through education and training we can build content and generate meaningful outcomes to project as part of learning outcomes.

    Marketpulse

    By building and training a community of core contributors in Market Research, Marketpulse aims to collect data about phone sales in target markets. This project encourages contribution through a series of participation steps, each with complementary training. Marketpulse also recently completed a four-week online course “Interviewing Users for Mozilla” which taught contributors this qualitative research skill in user research.  As a result of this project, Mozilla has gained user research on the “Large Screen Experience”.

    By “Interviewing Users for Mozilla” course participant: Sukanta Pal

    MDN Fellowship

    The Developer Fellowship program provides a model for Mozilla and advanced developers to work together more extensively, allowing Mozilla to gain outside expertise and influence to help build our curriculum, shape our products and evangelize our programs.

    Mozilla Security Project – Securing Web @ZAP

    Is a volunteer-lend series of workshops for students and security enthusiasts. During  the workshop, participants are trained in ways to detect the threats  by performing security attacks using the ZAP security tool.  At it’s core this project is about teaching people about security by contributing to Zap.  Each week focuses on a different method of contribution: source code, creating extensions and addons, documentation and localization. Hypothesis is that by teaching participation as part of curriculum we can gain a greater base of contributors as a result. Very cool!

    Sumath’s Hypothesis is that by embedding contribution opportunities in education & training we can improve the number of, and quality of contributions, and help spread Mozilla’s mission to more people.

    Evangelism and Representation

    Mozilla’s community reaches around the globe, with diversity so great it’s an exciting to imagine the potential of volunteers empowered to share, speak and advocate for Mozilla’s mission.  It makes a lot of sense to work on mechanisms for this type participation. Common hypothesis are that word of mouth marketing is an extremely valuable tool for promotion and that empowering community members with more skills and avenues to share their passion for Mozilla will help raise awareness of Mozilla and Firefox.

    Firefox Friends

    Firefox Friends a program that take advantage of the existing passion of the Mozilla community to make it easier for people to share their love of Mozilla and Firefox within their social networks. Firefox Friends is exploring the hypothesis that providing the community with a tool for collecting and sharing Firefox oriented content will increase awareness and growth of Firefox.  To make it easier for community members to spread the word about Firefox and Firefox initiative,

    Tech Speakers

    Tech Speakers was a six week program combining group speaking practice and technical content development. A fantastic curriculum, combined with live mentorship opportunities is resulting in a growing base of high-quality volunteer speakers.

    Market Understanding

    Mozilla serves users in markets all over the world.  To deliver useful insights and research that will help product and functional teams be successful we’re seeing deep investment in  Mozilla’s global community to bring a competitive edge.

    Firefox OS Core Team Africa

    With Fx OS launching in 21 African countries in 2015 , there is an opportunity to test a new approach to building new relationships and new communities of supporters/volunteers across the continent.  A series of experiments. Goals have been to build out programs that to get new contributors involved in Firefox OS activities to increase awareness on the product and make an impact on product goals

    Webmaker Research

    By creating a launch playbook modeled after Firefox OS we will be able to create launch teams in target markets, this will result in a number of new users. Supporting local content leads we will be able to generate original content and learn from local communities in order to deliver and build a more effective localized product and content.

    Marketpulse

    The Firefox OS team has embarked on many different initiatives and campaigns to bring Firefox OS to market without always having sufficient understanding and knowledge of the reality on the ground, due to a lack of local market data. This local market data is extremely difficult to obtain, let alone, update regularly if you’re not actually on the ground. Leveraging the Marketpulse tool  community regularly collects price and user data for Firefox OS phones in their local market and web stores providing this much needed data.

    You can see there’s a lot going on,  and that even within each of these projects multiple experiments are taking place.  There’s a lot to be excited about in the coming months for participation at Mozilla. You can track the this and other Participation Team activity through our Heartbeat tool, or by reaching out to us directly.  In the near future, we’ll surface more concrete examples of what we’re learning,  and we expect, celebrating the new successes in participation at Mozilla.

    We’re in Whistler next week, check out for Lucy’s post on what we’ll be up to there!

    Air MozillaWebdev Beer and Tell: June 2015

    Webdev Beer and Tell: June 2015 Once a month web developers across the Mozilla community get together (in person and virtually) to share what cool stuff we've been working on in...

    Chris CooperReleng & Relops weekly highlights - June 19, 2015

    Happy Friday once again, releng enthusiasts!

    The release engineering and operations teams are heads-down this week trying to get quarterly deliverables done *before* heading off to Whistler for a Mozilla-wide work week. There’s lots of work in-flight, although getting updates has occasionally been like pulling teeth.

    Because almost everyone will be in Whistler next week, next week’s update will focus less on completed or in-progress work and more on what releng team members took away from their time together in Whistler.

    tl;dr

    Taskcluster: Morgan got 32-bit Linux builds working! Rail reports that funsize update generation is ready to go, pending an AWS whitelist update by IT. Ted reproduced mshal’s previous work to get OS X builds cross-compiling in one of Morgan’s existing desktop build containers.

    Puppetized Windows in AWS: Jake and Rob are working on additional puppet modules for Windows. Q is running performance tests on jobs in AWS after the networking modifications mentioned last week.

    Operational: MozillaBuild 2.0 is out! Mark deployed NSIS 3.0b1 to our windows build/try pools. Kim and Netops have finished up the SCL3 switch upgrades. Jake rolled out changes to enable statsd on our POSIX systems. Dustin’s talk on fwuint was accepted to LISA 15. Dustin merged all of the relengapi blueprints into a single repository and released relengapi 3.0.0.

    Whistler: There’s been a bunch of planning around Whistler, and props to catlee, naveed, and davidb for getting our stuff into the sched site (the tag for releng/relops/ateam/relman is platform-ops). Be sure to take a look and pick some planning, presentation, and hacking sessions to go attend! http://juneworkweekwhistler2015.sched.org/type/platform-ops

    Thank you all!

    And here are all the details:

    Taskcluster

    • Ben has been doing a bunch of work adding S3 support to release automation. The two parts he focused on this week are the uploading partner repacks to S3 (bug 1173384), and generating checksums out of files in S3, and uploading them back there (bug 1174145).
    • Work continues on moving the spidermonkey builds from buildbot to TaskCluster. Anhad, our intern, was able to easily get the existing script running in a novel container type. After talking with Morgan and Rail, he’s now trying to make changes to the scripts and process to allow using an existing container. One side effect of the migration to TaskCluster is that we may be able to provide build artifacts from the spidermonkey test process which is something we’ve never had before.
    • The new S3 buckets for updates still need to be whitelisted, but Rail reports that funsize is otherwise ready to generate updates in TaskCluster. Here’s a sneak peek at what it will soon look like in treeherder, hopefully with less orange: https://treeherder.allizom.org/#/jobs?repo=mozilla-central&revision=a3f280b6f8d5&filter-searchStr=balrog
    • After battling with the base containers and investigating workarounds, Morgan has 32-bit Linux builds working in TaskCluster.
    • Ted dusted off mshal’s cross-compilation work from last year and was able to get OS X builds cross-compiling locally in one of Morgan’s existing desktop build containers. The next step is to hook it up to TaskCluster, and then begin investigating packaging and symbols which were the two outstanding issues we needed to address from our first attempts last year.

    Puppetized Windows in AWS

    • The networking changes we made to Windows may have potentially had a large impact on our performance in AWS, so Q is running more jobs to get new numbers to compare to our hardware performance.
    • There are still a few bits of software that we have managed by the domain (AD+GPO) that we don’t yet have in puppet. Rob is working on getting nxlog support to match the remote system logging we have in the datacenter. Jake is doing the same for metric collective, the program he wrote to gather system statistics and send them to graphite.

    Operational

    • MozillaBuild 2.0 is out! Callek helped the sheriffs make the latest version of the Windows build environment bootstrapping tool available for developers.
    • Now that the new version of MozillaBuild is out, Mark has deployed NSIS 3.0b1 on our build/try machines. This will fix several stub installer and full installer bugs (bug 989531).
    • Kim and Netops have been working together to finish up the last of the SCL3 switch upgrades. For several weeks, we’ve been quietly doing rolling upgrades while keeping the trees open so there’s minimal developer impact.
    • With the collectd upgrades in place, Jake rolled out changes to enable the statsd collectd module so that we we have a hook to get application metrics into graphite as well as system metrics.
    • Q and Morgan have pushed out the Windows runner code to the a number of the try systems, and things are looking quite promising. Next step is to roll it out to all of the try pool next week.
    • Dustin’s talk on fwunit (https://github.com/mozilla/build-fwunit), his software to perform unit tests for network flow rules, was accepted to LISA 15 (https://www.usenix.org/lisa15). He’ll be presenting at the conference on November 12th.
    • In preparation for some of the security work inherent in the move to TaskCluster in Q3, Hal met with the OpSec group to review the state of releng security issues.
    • Hal was also able to troubleshoot some data issues with the VCS-sync mapper, which then allowed him to start using it to map changesets for the gecko-dev repo. This is part of ongoing work to transfer ownership of the VCS-sync tools and process to the new dev-services team. Other cutovers are planned, but Hal is wisely holding off on flipping the switch until *after* the Whistler work week.
    • Dustin provided a very detailed review of Jordan’s work to provide archives of mozharness on-demand (bug 1154795). The scope has increased somewhat to allow for the creation of archives for other build repos as well. Between of this work for archives on-demand, the new hg bundleclone extension we’ve been deploying, and various existing releng pro(x)xy solutions, we will have many options for reducing bandwidth consumption and network overhead going forward.
    • Jordan re-landed a correctness fix that ensures we always use the newly-cloned talos repo for tests rather than a cached version on disk (bug 1112773). Thanks to Jordan for taking this work across the finish line after inheriting it from a community member who had to step away due to school commitments.
    • Mach build stats are being collected in Influxdb for try builds now, thanks to Mike Shal: https://stats.taskcluster.net/grafana/#/dashboard/db/Grafana Mike notes that there are still some issues with the stats for Windows builds, but those will get ironed out in bug 1175895.
    • Dustin merged all of the relengapi blueprints into a single repository and released relengapi 3.0.0. This simplifies development of relengapi by removing a number of workarounds that we needed to straddle multiple repositories. It creates a shared resource that positions the project for longer term and deeper adoption by the team.

    See you next week!

    Mozilla Addons BlogNew add-on community forum

    For a few years we have been running a forum for add-on developers. It’s linked to from the Developer Hub on AMO and has been a good place for discussions about add-ons, particularly add-on development. Unfortunately, we haven’t had the time or resources to keep it properly running and up to date. The software it runs on (phpBB) is notoriously unstable and difficult to manage. It’s time for a change.

    We’ve set up an Add-ons category in the Mozilla Community forum. This is the new official home for discussions about add-ons. Its main benefits are better integration with the larger Mozilla community, authentication with Persona (also used on Bugzilla, MDN, and others), reliable maintenance by Community IT, and running on a more modern forum platform called Discourse. With Discourse you can subscribe to posts or entire categories and interact with them like you would with a mailing list, which great for those who (like me) prefer a more old school approach.

    This is the current plan for the forum move:

    1. On July 1st, the old forum will be switched to read-only mode. In the meantime we’ll encourage all current forum users to move to the new one.
    2. On September 1st, the old forum will be decommissioned. We might try to keep a static copy of its contents somewhere, but for now you should assume that all content will be lost. We looked into migrating the old content to the new forum, but getting all the right sign-offs (legal, IT, security, etc.) proved to be too much for it to be worthwhile.

    There are more details about the move in this announcement.

    We’re very excited to join the rest of the Mozilla community in the new Discourse forum. Please give it a try and join the discussion!

    Will Kahn-GreeneInput status: June 19th, 2015

    Development

    High-level summary:

    • lots of library updates and changes to make way for Django 1.8
    • switch from nose to pytest
    • new suggests and redirector frameworks
    • upgraded from Elasticsearch 0.90.10 to 1.2.4
    • added editorconfig and pre-commit for easier development

    That doesn't sound like a lot, but it was.

    I'll write a more comprehensive blog post about the new suggests and redirector frameworks soon.

    Thank you to contributors!:

    • L Guruprasad: 6
    • Michael Kelly: 1
    • Ricky Rosario: 17

    Skipping the long list of commits and bugs. If you're interested, you can check the commit logs.

    Current head: ac406e4

    Rough schedule going forward

    1. Finish up upgrade to Django 1.8.
    2. Implement trigger-keyword provider.
    3. Redo the Elasticsearch infrastructure in Fjord.

    That's it for this update!

    Robert O'CallahanBug In Newer Linux Kernels Affecting rr

    As of kernel 4.0.4 (and probably earlier), writing to /proc/.../mem at a page which is mapped PROT_NONE causes a kernel BUG at mm/memory.c, which kills the writing process. This breaks rr, although I have a workaround which I'm about to land; the workaround temporarily makes the PROT_NONE regions we're writing to PROT_WRITE.

    Trevor reported this in the kernel bugzilla already, though I was able to come up with a nice small test program.

    Ted ClancyThe Canadian, Day 2

    This is what I saw when I woke up.

    attachment1

    (Taken with my Firefox OS phone.)

    Update: Sudbury
    So, it took us 8 hours to reach Sudbury. Sudbury is only about a 3 and half hour drive by car on the highway. You could call this a leisurely pace.

    We are now on tracks that were originally owned by the Canadian Northern Railway (not to be confused with the Northern Railway of Canada, whose tracks we were on before). These tracks stretch across the country from Vancouver to Quebec City. Canadian Nothern Railway was the second railway to provide transcontinental service across Canada (the first being Canadian Pacific Railway, who still dominate Canada’s rail industry today).

    Now these tracks are owned by CNR (Canadian National Railway).

    Update: Hornepayne

    If you look at a population map of Canada, you’ll see there’s a mostly unpopulated gap between Sault Ste Marie and Kenora, separating western Canada from eastern Canada. I’m currently in that gap.

    I didn’t realize it would be so hard to get internet here. I haven’t managed to get an internet connection since leaving Sudbury, and I suspect I won’t be able to until we’re near Thunder Bay.

    I’m supposed to be working today, but lack of internet is really hindering what I can do. I spent a while glued to my phone, hoping to glimpse a bar of service or two, but eventually gave up. It’s frustrating, because I’m trying to submit a patch for review, and I was hoping to get it approved before this weekend. I don’t like my chances of getting it reviewed next week when everyone’s busy at Whistler.

    After a while, I went to the observation car and stared out the window, which I found relaxing. There seem to be countless beautiful lakes and rivers up here. We never seem to be far from a watercourse. I wonder if these rivers were a route used by fur traders in the early days of Nouvelle France.

    The train stopped a couple times to drop off canoeists. I suspect we’re in a part of the country only accessible by rail.

    I saw a beaver! You know, I’ve been in Canada all these years, and I think that’s the first time I’ve actually seen a beaver.

    Most of the signs on this train are embossed with Braille. The signs use uncontracted Braille. I notice that the English is prefixed with dot-6 (⠠) while the French is prefixed with dot-46 (⠨). I wonder if that’s a standard convention.

    Update: Sioux Lookout

    We’re near Thunder Bay. For about 15 minutes we had cell phone and internet coverage, and everyone was staring to their phones.

    We’re now on tracks that were part of the National Transcontinental Railway, built in 1885. This route spanned from Winnipeg to Moncton. The section from Winnipeg to Quebec City is almost a straight line stretching across northern Ontario and northern Quebec. The idea was that it would provide the quickest route from the Prairies to the Maritimes by bypassing cities like Toronto, Ottawa, Montreal. The railway was never successful.

    Most of the railway is now abandoned and owned by no one. Parts of it are owned by CNR, and we’re currently on one of those parts.

    Many francophone towns in Northern Ontario, like Kapuskasing and Hearst, lie along the abandoned portion of this railway. Those towns are now serviced by Highway 17.

    But there are no highways along this section. There’s barely a road in sight.

    Musical Interlude II


    Mozilla Reps CommunityReps Weekly Call – June 18th 2015

    Last Thursday we had our weekly call about the Reps program, where we talk about what’s going on in the program and what Reps have been doing during the last week.

    cropped-Untitled.png

    Summary

    • Reps improvement: What are the things you would like to improve?
    • Reps in the future: How do you see the program in the next year? What a Rep role should be?
    • Road to Whistler: What would you like Council/Peers to do during the Work Week?

    AirMozilla video

    Detailed notes

    Shout outs to all the Indonesian Reps and Mozillians who attend and work very hard productively on Webmaker App Launch Meeting last Sunday.

    Program Brainstorming

    This call was about brainstorming about the Reps program.

    There were three questions to be answered:

    • What are the things you would like to improve?
    • How do you see the program in the next year? What a Rep role should be?
    • Road to Whistler – What would you like Council/Peers to do during the Work Week?

    Since not everyone could participate in the Call, we have created a Discourse topic to discuss this further. You can find it here.

    For the answers please see the above mentioned discourse thread or the raw notes.

    Raw etherpad notes.

    Don’t forget to comment about this call on Discourse and we hope to see you next week!

    Nick FitzgeraldSource Maps Are An Insufficient Debugging Format For The Web

    I want exceptional debugging support for programs compiled to JavaScript (or wasm) on the web. I want first class developer tools support for these programs. Unfortunately, this isn't the case right now because source maps are currently insufficient.

    When boiled down to their essence, stepping debuggers enable users to do two things:

    1. set breakpoints and incrementally step through their program's execution, and
    2. inspect the values of variables and function parameters as they step through their program's execution.

    A debugging format encodes information about a program that is lost at compile time, enabling source-level debugging of the compiled program. Source maps — the sole debugging format for compilers targeting JavaScript — can reconstruct source-level location information (filename, line, and column) which enables (1). However, that is the only data source maps encode, and the source map format does not attempt to solve (2). The result is that debugging programs compiled to JavaScript is positively maddening.

    The good news is that we can overcome this limitation and extend the source map format to support reconstructing source-level scopes, bindings, and values. Before we do that, we should understand how mature debugging formats encode this information and how it is in turn consumed by debuggers. The prevailing debugging data format for *nix-based systems today is DWARF. It supersedes earlier ad-hoc formats, such as stabs. DWARF's designers worked with earlier formats for years, and used that experience as the foundation upon which DWARF was built. What follows is an exploration of how DWARF encodes scope and binding debugging information while keeping an eye out for lessons we can learn and apply when extending source maps.

    Compact Binary Format

    DWARF uses a compact binary record format to store structured information, conceptually similar to Cap'n Proto or Message Pack serialization formats. These Debugging Information Entries, or DIEs, are made up of a type tag, a set of attribute type and attribute value pairs, and an optional set of child DIEs. With these children, DIEs form a tree structure.

    <DIE tag 1>
        <attribute name and type 1>
        <attribute value 1>
        <attribute name and type 2>
        <attribute value 2>
        <attribute name and type 3>
        <attribute value 3>
    
    <DIE tag 1>
        <attribute name and type 1>
        <attribute value 1>
        <attribute name and type 2>
        <attribute value 2>
        <attribute name and type 3>
        <attribute value 3>
    
    <DIE tag 1>
        <attribute name and type 1>
        <attribute value 1>
        <attribute name and type 2>
        <attribute value 2>
        <attribute name and type 3>
        <attribute value 3>
    
            .
            .
            .
    

    Furthermore, the metadata describing common attribute shapes can be factored out and de-duplicated with abbreviations. By using abbreviations, that previous series of DIEs can be compressed into this:

    <abbreviation definition 1>
        <attribute name and type 1>
        <attribute name and type 2>
        <attribute name and type 3>
    
    <DIE abbreviation tag 1>
        <attribute value 1>
        <attribute value 2>
        <attribute value 3>
    
    <DIE abbreviation tag 1>
        <attribute value 1>
        <attribute value 2>
        <attribute value 3>
    
    <DIE abbreviation tag 1>
        <attribute value 1>
        <attribute value 2>
        <attribute value 3>
    
            .
            .
            .
    

    With abbreviations, none of the attribute name and type metadata is repeated. This helps keep the debugging data compact. Debugging data can be huge in practice. Source maps can already be many megabytes in size, and the format already strives for as much de-duplication of data it can and only encodes limited debugging information as it is. This issue is exacerbated for source maps, because they are sent over the network and downloaded by debuggers. We must go to great lengths to keep debugging formats compact.

    Additionally, because the set of attributes a DIE contains is not fixed, the format is future extensible. New attributes can be added to provide new debugging information that wasn't previously encoded. If a debugger does not know how to interpret a given attribute, it can skip and ignore it. This is a huge deal for the web, where we tend to take many baby steps rather than a few giant leaps at a time. Any extension to the source map format must strive to remain future extensible.

    Lexical Scopes and Bindings

    DWARF encodes data about the program's source-level scopes, bindings, and values in a DIE tree.

    Consider this example program, fact.c:

    #include "stdio.h"
    
    static const int FACT_N = 6;
    
    int main(int argc, char **argv) {
        int i = FACT_N;
        int result = 1;
    
        while (i > 0) {
            result *= i;
    
            int decrement = 1;
            i -= decrement;
        }
    
        printf("%d\n", result);
    
        return 0;
    }
    

    Within this source, there are three scopes we are interested in: the top level, the main function, and the block within the while loop. These scopes nest to form a tree (it would be a more interesting tree with a more complicated example program). DWARF encodes this tree directly with DIEs: scopes have their variables as child DIEs, and nested scopes are also child DIEs of their parent scope's DIE. Different kinds of bindings, such as formal parameters vs. local variables vs. constants, are declared with separate DIE type tags.

    Below is a trimmed down subset of the information clang -g fact.c provides to debuggers via DWARF. It depicts the outline of the scope tree and the various bindings within those scopes. You can use the dwarfdump command line tool to view the text representation of the binary DIEs.

    0x00000026:     TAG_variable [2]
                     AT_name( "FACT_N" )
    
    0x0000003e:     TAG_subprogram [5] *
                     AT_name( "main" )
    
    0x0000005e:         TAG_formal_parameter [6]
                         AT_name( "argc" )
    
    0x0000006c:         TAG_formal_parameter [6]
                         AT_name( "argv" )
    
    0x0000007a:         TAG_variable [7]
                         AT_name( "i" )
    
    0x00000088:         TAG_variable [7]
                         AT_name( "result" )
    
    0x00000096:         TAG_lexical_block [8] *
    
    0x000000a7:             TAG_variable [7]
                             AT_name( "decrement" )
    
    0x000000b5:             NULL
    
    0x000000b6:         NULL
    
    0x000000c8:     NULL
    

    Additionally, the start and end target location bounds of these scopes are embedded as well. These bounds are denoted with the AT_low_pc and AT_high_pc DIE attributes. When the debuggee pauses at a given target location, the debugger finds the innermost scope containing the current target location, and can walk up the DIE tree to find every binding that is in scope.

    Here is the DWARF data describing the bounds for the main function, and the while loop's block:

    0x0000003e:     TAG_subprogram [5] *
                     AT_name( "main" )
                     AT_low_pc( 0x0000000100000f00 )
                     AT_high_pc( 0x0000000100000f75 )
    
    0x00000096:         TAG_lexical_block [8] *
                         AT_low_pc( 0x0000000100000f31 )
                         AT_high_pc( 0x0000000100000f54 )
    

    Locating a Binding's Value

    It is not enough to list the names of bindings that are in scope when paused during the program's execution. A debugger must also provide the current values of those bindings so that the user may inspect them for irregularities.

    Often, a binding's value is simply at some constant offset from the frame pointer. Other times it is in a specific register. Other times, the situation is a more complicated combination of these cases: for the first n instructions of this function, the parameter's value is located in this register, for the rest it is at that constant offset from the frame pointer. Even other times, a value is not located in one contiguous location! An optimizing compiler is free to explode a struct's members and store one member in a register, another member at this offset from the stack pointer, and to avoid even instantiating a value for the last member because that member is never used by the program.

    To handle all of these cases, DWARF employs "location descriptions". These descriptions are expressed in stack-based operations that form a Turing-complete language.

    JavaScript does not have frame pointers or registers. It has local, global, lexical, and dynamic (via this) bindings. It has objects and arrays with properties and indices. Because of that mismatch, it doesn't make sense for the source map format to adopt DWARF's location descriptions. Luckily, JavaScript engines already implement a sandboxed language for accessing and manipulating JavaScript values: JavaScript. We can embed snippets of JavaScript within the debugging data to locate a binding's value.

    Conclusions

    We can extend the source map format to encode the source-level lexical environment, its scopes and bindings, and a way to locate those binding's values. This enables users compiling their programs to JavaScript to do the other half of their debugging: inspecting variables and values as they step through their programs instead of stepping blindly.

    However, we must ensure that source maps remain compact for quick downloads and parse times. The format should also be future extensible so we can add additional features down the line and don't need to reach consensus on everything all at once.

    Finally, we should follow DWARF's lead and encode the scopes as a tree and embed within each scope its set of bindings, their symbol names, the scope's location boundaries, types, etc. We can reuse JavaScript as our language for describing the location of a binding's value.

    If you are interested in being a part of these discussions, please join in at the Source Map RFC Repository.

    Thanks to Tom Tromey and Dave Herman for reading drafts.

    References

    Ted Clancy???

    I have no idea where I am. It is completely dark outside and I can’t see a thing.


    Ted ClancyRichmond Hill

    We just passed Richmond Hill Centre. I recognize it from the giant Cineplex.

    This is an emerging transit hub for York Region. Langstaff GO station is here, and two VIVA lines meet here. There are plans to extend the TTC’s Yonge subway line all the way to here, but they’re held up by the fact that the Yonge Line is already at capacity with regards to ridership.

    I remember when there was a proposal to build a casino here, but that didn’t happen. Occasionally you hear people complain that Richmond Hill (and nearby Markham) is too dominated by Chinese people. That’s obviously bullshit. If this place was dominated by Chinese people, there would have been a casino here years ago.


    Ted ClancyYork Region

    The train is currently stationary, and I figure we’re in York Region, north of Toronto. We passed a sign saying “Parc Downsview Park” about 10 minutes ago, so that must mean we’re on Metrolinx’s Barrie Line (formerly the CNR Newmarket Sub).

    According to Wikipedia, this is the oldest trackage in Ontario, dating back to 1835. This track was laid by the Northern Railway of Canada, which was acquired by Grand Trunk Railway in 1888, which was in turn absorbed into CNR in 1923. CNR sold this trackage to Metrolinx in 2009.

    I guess we’re waiting for a freight train to pass. (They said that would happen a bit.)

    Oh, we’re moving again.


    Yunier José Sosa VázquezProblemas con el cuentaFox [solucionado]

    Hace poco cuentaFox estaba presentado problemas al conectarse con el servicio web para obtener los datos de las cuotas y hoy les traemos una actualización que solventa este problema.

    Desde Mozilla han informado que el Addon SDK (CFX) no será utilizado más desarrollar complementos y en su lugar recomiendan JPM, una nueva herramienta para compilar complementos que brinda muchas más ventajas a los desarrolladores.

    Por esta razón, desde ahora habrán dos versiones de cuentaFox:

    • una compilada con CFX que no recibirá nuevas funcionalidades y  mantendrá 3.0.X para la versión
    • otra empaquetada con JPM (recomendada) que recibirá nuevas características, estará alojada en GitLab y es necesario utilizar Firefox 38 o superior para que funcione.

    ¿Qué hay de nuevo en cuentaFox 3.1?

    • Uso de JPM para compilar el complemento.
    • Cambio del servicio web a utilizar.
    • Ahora el ícono de la barra de herramientas muestra emoticons que representan el estado de la cuota.
    • Adicionado el botón Actualizar.
    • Cambiado algunos botones de la interfaz.

    A continuación se muestran algunas capturas de esta:

    v3.1-emoticons

    Cara feliz que representa el estado de la cuota

    v3.1-interfaz

    Interfaz de la versión 3.1 mostrando una cara alarmada porque la cuota ha sido consumida más del 85%

    Si deseas colaborar en el proyecto pues hacerlo desde GitLab. Si tienes alguna nueva funcionalidad en mente, por favor háznosla saber dejando un issue.

    Instalar cuentaFox 3.1 (es necesario tener Firefox 38 o superior)

    Instalar cuentaFox 3.0.1

    Esperamos que les guste es nueva versión, cualquier duda o sugerencia, por favor déjenla en los comentarios.

    Ted ClancyThe Canadian

    I’m currently sitting aboard Via Rail’s The Canadian, waiting for the train to depart from Toronto’s Union Station. I’m on my way to a company-wide Mozilla event in Whistler.

    This isn’t the first time I’ve travelled on Via Rail, but this is the first time I’ll be travelling all the way to Vancouver.

    I’m thinking I might live blog it.

    Update: Vaughan

    The train is currently stationary, and I figure we’re probably in Vaughan, north of Toronto. We passed a sign saying “Parc Downsview Park” about 10 minutes ago, so that must mean we’re on Metrolinx’s Barrie Line (formerly the CNR Newmarket Sub).

    According to Wikipedia, this is the oldest trackage in Ontario, dating back to 1835. This track was laid by the Northern Railway of Canada, which was acquired by Grand Trunk Railway in 1888, which was in turn absorbed into CNR in 1923. CNR sold this trackage to Metrolinx in 2009.

    I guess we’re waiting for a freight train to pass. (They said that would happen a bit.)

    Oh, we’re moving again.

    Update: Richmond Hill

    We just passed Richmond Hill Centre. I recognize it from the giant Cineplex.

    I remember when there was a proposal to build a casino here. But that didn’t happen.

    Occasionally you hear people complain that Richmond Hill (and nearby Markham) is too dominated by Chinese people. That’s obviously bullshit. If this place was dominated by Chinese people, there would have been a casino here years ago.

    Update: ???

    I have no idea where I am. It is completely dark outside and I can’t see a thing.

    Update: Musical interlude


    Marcia KnousUpcoming joint QA-l10n events

    Jeff Beatty and I have teamed up to work on some interesting "fusion" events in the upcoming quarters. The l10n team has already been planning a bunch of Hackathon style events, so Jeff and I decided it might be interesting to join forces and do some QA presentations at these events.   The first event will be held in July in Lima, Peru, and will be led by Juan and Gabriela of the QA team. The content focus will primarily be on the Firefox Desktop. We also hope to be able to provide the

    Mozilla Addons BlogAdd-on Compatibility for Firefox 40

    Firefox 40 will be released on August 11th. Here’s the list of changes that went into this version that can affect add-on compatibility. There is more information available in Firefox 40 for Developers, so you should also give it a look.

    Extension signing

    • This is the first version of Firefox that will enforce our new signing requirements. All AMO add-ons have already been signed and we’re in the process of reviewing non-AMO add-ons. In this version, there’s a preference to disable the signing requirement (xpinstall.signatures.required), which will be removed in 41.

    General

    XPCOM

    Themes

    Please let me know in the comments if there’s anything missing or incorrect on these lists. If your add-on breaks on Firefox 40, I’d like to know.

    The automatic compatibility validation and upgrade for add-ons on AMO will happen in the coming weeks, so keep an eye on your email if you have an add-on listed on our site with its compatibility set to Firefox 39.

    Air MozillaGerman speaking community bi-weekly meeting

    German speaking community bi-weekly meeting Zweiwöchentliches Meeting der deutschsprachigen Community. ==== German speaking community bi-weekly meeting.

    Laura HilligerWhat’s next for Laura?

    TL;DR My last day at Mozilla already happened, but I’m still me. I bring together disparate things to foster learning, spread openness and design for participation. I’m a creative generalist who likes to make stuff, and I’m open to exploring opportunities.

    About 5.5 years ago I took a broken dream to the first Mozilla Festival (at the time it was called Drumbeat) in Barcelona. Going to this festival with my struggling project was a last ditch effort, I was hanging on, trying to make it work.

    Drumbeat was the place that I was finally able to let go, start over, try again. The people I met there gave me new ideas, they introduced me to a way of working that fit with how my brain operates. Drumbeat lit a fire under me. I met Mozillians.

    photo by Mozilla Europe

    photo by Mozilla Europe

    I’ve resisted the status quo because when I’ve questioned it, I don’t usually receive satisfactory answers. Over the years, Mozillians taught me how to focus my defiance towards a common good. It’s that focus that has cultivated me and my way of being in the professional space.

    I believe in open, and I believe that what Mozilla is trying to do for the world is a just cause. Openness can be hard, but in my experience the right thing is always more difficult.

    Last Monday was my final day as a paid contributor, and I’m in the process of detangling Mozilla from my own identity. We’ve grown up together in this community. We have rallied around a nascent vision and made it something that is resonating throughout the world. I am proud to have contributed to every aspect of the Foundation’s work – from strategy to learning design to prototyping to evangelism to community management to production – I’ve helped Mozilla innovate in the teaching and learning space.

    Our work has inspired people, and I’ll always be a Mozillian. But I want to be more too. Mozilla is a part of me, but it can no longer define me.

    photo by Doug Belshaw

    I don’t know what’s next for me, and that’s ok. I will continue to think and write and make and learn and fail, and I will continue to embody the open ethos. Even when it’s hard, especially when it’s hard. In the immediate future, I will pause, breathe and take stock. I can literally do anything with the competencies and skills I’ve developed and honed over the years. That feels like a powerful invitation to do the right things.

    There is a lot of right in the world. I’m looking for something where I can design learning/engagement opportunities, develop leaders and apply open practices, digital/web literacies and all things geeky. I want to help people/orgs grow, collectively, as they allow me to grow together with them. I want to shift power structures and community dynamics, be a voice for people who need one and just be who I am – defiant, curious, unwavering in the ideals of open.

    If you think you have a right thing for me, let me know. You all know how to find me. laura [at] this domain is where you started interacting with me in 2010, and it’s where you can continue to do so. You can also find me on twitter or LinkedIn (or just google me, I’m all over the web). I hope some of you reach out – there are plenty of wonderful memories and new ideas to discuss, and I will always be here for my Mozilla friends.

    Karl DubostWorking with emails on projects

    I have been working with emails as a tool for the last 20 years. In different communities, setup, etc. I never felt overwhelmed by the number of emails, I have filtering strategies, I could talk about that in a separate post.

    When projects using emails are going awry to havoc, most of the time is because people do not use emails in an optimum way. My main recommendation would be:

    Always copy to an archived mailing-list. Never ever send private emails. (1)

    In a previous working life, I have given a talk about Apprendre à travailler avec le mail (French), Coralie translated it into English last year: Read Learning to work with e-mail.

    (1): In the context of working on a project. Privates emails for HR, personal stuff, etc is fine. Anything which is about the project should be on a linkable, archived mailing-list.

    Otsukare!

    Air MozillaBrownbag: Interactive Documentary Screening of 'Do Not Track'

    Brownbag: Interactive Documentary Screening of 'Do Not Track' Join director Brett Gaylor for a screening and discussion of 'Do Not Track' (https://donottrack-doc.com), a personalized documentary series about privacy and the web economy.

    Air MozillaTech Talk: Adaptive Bitrate Streaming

    Tech Talk: Adaptive Bitrate Streaming Nick Desaulniers will be speaking on, "Adaptive Bitrate Streaming: Let's build a Netflix clone."

    Air MozillaProduct Coordination Meeting

    Product Coordination Meeting Duration: 10 minutes This is a weekly status meeting, every Wednesday, that helps coordinate the shipping of our products (across 4 release channels) in order...

    Luke WagnerWebAssembly

    I’m happy to report that we at Mozilla have started working with Chromium, Edge and WebKit engineers on creating a new standard, WebAssembly, that defines a portable, size- and load-time-efficient format and execution model specifically designed to serve as a compilation target for the Web. As reflected in the high-level goals, a central requirement for WebAssembly is that it integrate well with the rest of the Web platform and that the initial version run efficiently on current browsers using a client-side polyfill. As demonstrated, the polyfill can leverage asm.js to get great performance. For existing Emscripten/asm.js users, targeting WebAssembly will be as easy as flipping a flag. Thus, it is natural to view WebAssembly as the next evolutionary step of asm.js (a step many have requested and anticipated).

    We’re pretty early into the overall process—there is no draft spec or even final formal standards body chosen, just a W3C Community Group, some initial prototyping and early cross-browser consensus on the high-level design documents. Going forward, there will be a lot more iteration and experimentation under the WebAssembly GitHub organization. For questions, check out the still-emerging FAQ. Brendan Eich also has a vibrant blog post with more context, history and JS perspective.

    Mozilla Release Management TeamFirefox 39 beta5 to beta6

    One of the last beta of this cycle. We are taking the last stability patches for the release.

    As a remainder, beta 7 will be built next Thursday, RC next Monday (during the Mozilla work week in Whistler). The release date is June 30.

    • 12 changesets
    • 21 files changed
    • 195 insertions
    • 50 deletions

    ExtensionOccurrences
    cpp7
    h5
    js4
    xml1
    py1
    jsm1
    in1
    css1

    ModuleOccurrences
    dom7
    toolkit4
    media4
    browser4
    tools1
    js1

    List of changesets:

    David KeelerBug 1170303 - Treat malformed name information in certificates as a domain name mismatch. r=Cykesiopka, a=lizzard - 056a30240fae
    Aaron KlotzBug 1171453 - Make ParentNPObjects aware of AsyncNPObject wrappers. r=jimm, a=abillings - 7898db26f3f8
    Andrea MarchesiniBug 1169867 - XMLHttpRequest::SendInternal should not unpin itself when the worker goes away. r=bent, a=abillings - aaf1311249a8
    Chris PearceBug 1174064 - Ensure we don't try to reuse a GMP doing async shutdown. r=edwin,a=lizzard - a6b058d20345
    Nick ThomasBug 1170913, full-update target in tools/update-packaging/ always runs automation-partial-patch, r=glandium a=lizzard DONTBUILD - 4304c0383035
    Magnus MelinBug 1159632 - Fix failure in toolkit/components/jsdownloads/test/unit/test_DownloadImport.js when browser.helperApps.deleteTempFileOnExit true. r=paolo, a=test-only - acaf3ba8f4e4
    Ted MielczarekBug 1171527 - Make upload_symbols.py retry on 500 errors from the API. r=gps, a=NPOTB - 04059bd01b9b
    Gijs KruitboschBug 1169911 - Fix windows 10 titlebar coloring/border issues. r=dao, a=lizzard - 68049b6deb7c
    Jared WeinBug 1170304 - Persist state that Firefox was a user's default browser. r=dolske, a=lizzard - 1997f291fc30
    Jean-Yves AvenardBug 1171629 - Use fallible array to store MP4 samples index. r=kentuckyfriedtakahe, a=lizzard - 82b74e7dea64
    Jan de MooijBug 1114079 - Fix overrecursion check in nsGlobalWindow::SetNewDocument to not report a JS exception. r=bz, a=lizzard - adb302d8d588
    Chris PearceBug 1173144 - Ensure Adobe EME plugin voucher is present before adding GMP dir to GMPService. r=dolske, a=lizzard - 05b522f50491