Mozilla Nederland LogoDe Nederlandse

Bas Schouten: When silence just isn't an option

Mozilla planet - vr, 10/02/2017 - 00:57

Disclaimer: The opinions I will be expressing will be solely my own, they will in no way be related to Mozilla or the work I do there.

Today, I will be doing something I didn’t think I would ever be doing. I will start to post publicly on topics that may be considered somewhat political. My personal opinions and thoughts, if you will. This is something I have always said I would never do, once something is written, it is unlikely to ever go away, and may always be associated with you and the work we do. Having said that, I do believe the climate we currently live in has reached a point where I don't think I have any other choice.

Why wouldn't I speak up?

As engineers, scientists, and other types more concerned with what we're building and discovering about the world around us, it seems to only make sense that we wouldn't publicly take a stance that could be considered political. Above all our task is to follow the data, wherever it leads and use that data in various ways to benefit human kind. In this process our personal feelings about topics only pose a threat to our scientific integrity, every one of us is susceptible to biases, and all we can do is try as much as possible to eliminate them from our work. Throwing out a bit of data because it doesn't seem to support the hypothesis you're trying to prove, building something that inherently puts one group at a disadvantage compared to another for personal gain, all those things are fundamental crimes against our professional integrity. And not only that, they will always backfire eventually, but more on this later.

And this is where it all started. If I speak openly about my political opinions, won't the data I present, the things I built, inevitably be viewed as colored by them? I have genuinely seen someone comment on a crash once along the lines of 'Firefox always crashes when I go to conservative websites, it never does when I go to your liberal websites. If you don't stop promoting your liberal agenda I will switch browsers.'. Whether that is true or not (it is not), it was exactly that phenomenon, an organization perceived as liberal produced a product, and people believed that product was inherently designed to put them and their ideas at a disadvantage. Considering the amount of effort I put into letting the data I collect and the things that I produce not be colored by my personal positions, this is something I want to avoid at all costs.

After all, as long as scientists collect a wealth of data, ensure that experiments are reproducible by any group of people, and the knowledge we gather is then used to build things that obviously and visibly work, we don't need to make a public political stance, right? People will look at the data we collect and the things we build, realize that they're good, and be able to make well-informed opinions for themselves, that fit within their ideological views. Since I believe only a tiny percentage of the population is inherently evil, things will then work themselves out just fine, so we're good!

So what changed?

With the tools we're building, giving people the ability to communicate with people from all over the world, people with different ideas and cultural backgrounds, I always believed an atmosphere of compassion, understanding and a desire to help others, whoever they are, would automatically arise. I thought that with the knowledge we were collecting and spreading - about our place in the universe and how small and vulnerable we are on a cosmic scale - we could automatically foster an appreciation of life on this planet, we would cherish it going forward.

I thought we were at a point where history wouldn't repeat itself, where things would only get better from here.

I have now come at a point where I can no longer deny that it seems that I was wrong. Both new and old problems are festering among our species, and we have to find new ways of dealing with them, because the old ones aren't working. As humans we appear to be inherently complacent, particularly when our own livelihood isn't directly threatened, but the time for that is past, we have to change course now, the risk of 'sitting this one out' is simply too great. As engineers and scientists we have given humanity the means to do a tremendous amount of damage, and now we have a role to play in making sure it doesn't.

What are you going to do about it?

It is likely not many people will ever see what I write here, and most likely much less of those people will read anything they didn't already know. However it has occurred to me that if I can say just one sensible thing, give just a couple of people a nudge in the right direction, that may have a trickle down effect that makes something of a difference in the world, and that, I have to try. Perhaps more importantly for me directly it will help me structure my thoughts, give me a place to point to rather than explaining standpoints over and over again, and possibly even get some useful feedback to improve on my own understanding of the world I live in.

And so, I have decided that over the next couple of weeks I will write a couple of posts in which I outline my thoughts on a number of topics that seem to apply to the troubles of the world today. Feel free to disagree with me, but please do so respectfully, and if you want to have a debate, support your argument with (conventional) facts. On most of the topics I will be writing about I will not be an expert, sometimes I will presumably be wrong and say things which aren't true, although I will do my best to include reliable references whenever I can. I'm okay with all of that, because even in the cases where I am, somewhere I might spark a debate, create some more understanding and ever so slightly nudge someone towards my utopian fantasy of a world where we all live together in peace on a planet (or multiple planets) that we care for.

Original post blogged on b2evolution.

Categorieën: Mozilla-nl planet

Why Is Mozilla Firefox The Best Browser For You? [INFOGRAPHIC] - ValueWalk

Nieuws verzameld via Google - do, 09/02/2017 - 21:42

TNH Online

Why Is Mozilla Firefox The Best Browser For You? [INFOGRAPHIC]
Do you have any idea about the best browser that we are talking about? Well, we are talking about Mozilla Firefox. If you've been a frequent internet user, then you're already familiar with it. The only question is, how well do you know about Mozilla ...
Struggling for Relevance: Is Mozilla Really Killing Off Firefox?CIO Today
Mozilla Firefox Tips & Tricks for a Better Browsing ExperienceTNH Online
Which is the best browser for Windows 10: Firefox or Chrome?The Guardian

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

Support.Mozilla.Org: What’s Up with SUMO – 9th February 2017

Mozilla planet - do, 09/02/2017 - 21:30

Hello, SUMO Nation!

Today’s post has a slightly different format for two reasons:

  1. We are rethinking the way these (regular) blog posts work and the way they should be shaped – but that’s going to take a while because…
  2. We have migrated to a Completely New Site™ and we need to update you on a few things regarding its current (and future) state. (hint: we’re all really busy)

There you have it. So, while we may be returning to your regularly scheduled programming at a slightly later time, now it’s time talk about…

The Completely New Site™
  1. The migration process was not easy from a technical point of view and things did go wrong in some expected (and some unexpected) ways. Moving 8 years of data from one custom platform to another is like that.
  2. The delay in switching to the new site was caused by last minute issues we managed to fix (but we needed time for that).
  3. We are live at but there are still a lot of things to work on, most of which we are trying to tackle now using Admin powers.
  4. We have a long list of outstanding issues to fight with in the first two weeks after the launch. You can add more to it, don’t worry. Please keep filing bugs. Thanks to all of you who already did so. Before you file a bug, please remember to check this list.
  5. If you are confused about the way the site works (its options, basic features, etc.), you can start fighting that confusion using the site FAQ (“How do things work?”).
  6. Our priorities for the next two weeks are:
    • Making sure site navigation and content are in correct places and work well for all launch locales.
    • Making sure that all users have the right permissions and access to the right resources based on that for all launch locales. As a refresher, take a look at the Roles & Responsibilities doc (as shared with you at the beginning of the migration process in 2016)
    • Working on fixing the bugs from the list linked above.
    • Improving the UX design of the site.
    • Improving the notifications.
    • Improving the onboarding and “ask a question/find an answer” flows.
    • Sharing documentation that explains how we can all get “back to SUMO business as usual” using the new platform (answering questions, working on the KB).
  7. The following are not a priority at the moment but will be worked on later:

So, if you are on the new site (yay!), we ask you for a little extra patience while we make it our new home. In the meantime, if you have questions about:

Now, let me tell you a bit more about…

The Next Month (or so) for the KB / L10n of SUMO…
  1. The KB content of the launch locales is mostly ready for use and consumption by the users, thanks to your help.
  2. All Editors, Reviewers, and Locale Leads should have the right permissions to work within their locale’s KB, but for now we are not localizing anything – please hold off with edits for now.
  3. Joni is coming back on Monday (13th February) and will make sure the English KB is in shape.
  4. Once the English KB is cleaned up and reorganized, we will work on copying the same structure for all launch locales.
  5. The documentation explaining how the localization process works on the new site is coming once we knock all the l10n bugs out of the way. For now, you can get a taste of it reading these two documents (one) (two).
  6. Our goal is to ensure that:
    • All KB Editors, Reviewers and Locale Leads have the right permissions for their locale’s KBs
    • The visible KB nodes are all in the right place and reflect the English version as close as possible (for now, this may be changing in the future, depending on your needs/ideas)
    • The new KB nodes are in place and localized accordingly
    • All KB templates are organized under a separate KB for each launch locale
    • All KB content that should be archived is moved to a separate Archive KB for each launch locale
    • Key UI elements are reviewed and retranslated for each launch locale
    • Locales that were not included in the launch are prepared for addition to the main site
…and how you can help with that
  1. Subscribe to the changes in your locale’s KB (and the English KB as well). You can do it following the instructions from this site.
  2. Keep filing bugs about things that don’t work for your locale (or globally). You can use Bugzilla (as usual) or this spreadsheet.
  3. Wait for further information – I am working on making the site better for localizers (and international users), but everything takes time. I really appreciate your patience and support.

We hope that the above information will help you understand where we are now with the site switch and what are our next goals and steps. If you have questions, you know where to find us. We are looking forward to seeing you around the new SUMO site. Thank you for being there for the users!

Categorieën: Mozilla-nl planet

Mozilla Addons Blog: web-ext 1.8 released

Mozilla planet - do, 09/02/2017 - 21:08

A new version of web-ext has been released! Web-ext is the recommended tool for developing WebExtensions on Firefox, because it has the ability to automatically reload your WebExtension as you make changes.

Since our last blog post, version 1.7 and 1.8 have been released. The full change log is on github.

The run command now shows a desktop notification if auto-reloading results in an error: image01

Other options added to the run command include:

  • Addition of a –start-url option. This will start Firefox at a particular URL and assists in testing.
  • Addition of a –browser-console option. This will open the Browser Console by default, which is where any errors or logging will be shown.
  • Addition of –pref option. This will load the specified preferences into Firefox. For example: –pref privacy.userContext.enabled=true
  • When a reload occurs, it will show you the last reload time more concisely.

An –ignore-files option was added, so by default the web-ext-artifacts directory is added to that list when building your extension.

A new option to linting, –warnings-as-errors, will allow you to make the linter more strict, so that warnings are raised as errors. Also, when you run web-ext and you have an error in your JSON, you’ll get an error message showing the line number. As an example:


Any command run will let you check to see if a new version of web-ext exists, ensuring that you are using the latest version of web-ext.

Finally a regression on Windows was fixed, but more importantly the test suite was enabled on Windows to reduce regressions on Windows in the future.

Special thanks to all the people who contributed to this release: Aniket Kudale, Jostein Kjønigsen and eight04. A special thanks to Elvina Valieva and Shubsheka Jalan who have been contributing via the Outreachy program.

Categorieën: Mozilla-nl planet

Dustin J. Mitchell: TaskCluster-Github Improvements

Mozilla planet - do, 09/02/2017 - 19:54

Repositories on Github can use TaskCluster to automate build, test, and release processes. The service that enables this is called, appropriately enough, taskcluster-github.

This week, Irene Storozhko, Brian Stack, and I gathered in Toronto to land some big improvements to this service.

First, the service now supports “release” events, which means it can trigger tasks when a new release is added to github, such as building and uploading binaries or making release announcements.

Second, we have re-deployed the service as an integration Irene has developed. This makes the set-up process much easier – just go to the integration page and click “Install”. No messing with web hooks, adding users to teams, etc.

The integration gives users a great deal more control over our access to repositories: it can be installed organization-wide, or only for specific repositories. The permissions required are much more restricted than the old arrangement, too. On the backend, the integration also gives us much better access to debugging information that was previously only available to organization administrators.

Finally, Irene has developed a quickstart page to guide new users through setting up a repository to use TaskCluster-Github. With this tool, we hope to see many more Mozilla projects building automation in TaskCluster, even if that’s as simple as running tests.

Categorieën: Mozilla-nl planet

Dennis Schubert: Introducing 'The Joy of Diagnosis'

Mozilla planet - do, 09/02/2017 - 17:22

We Mozillians really love to share the stuff we are working on with everyone interested. A great example of a Mozillian sharing his work is Mike Conley, who started a weekly live hacking series called “The Joy of Coding” back in 2015 (he just had his two years anniversary!). It is really great to watch him work on a wide series of Firefox tasks, no matter if it is about UI stuff, electrolysis work, or even porting and improving internal tools to Rust.

It is even better to sometimes see him struggle on what felt like a really simple task. That just makes everyone feel more human. Also, it is a great way of introducing contributors from all over the place to our work and provide them with insight into the steps needed to tackle their first project. This is definitely a thing we should do more often, everywhere inside Mozilla.

Let us jump to another topic for a second. Have you heard of Mozilla’s Web Compatibility team, of which I am part of? Are you aware of the work we do, our motivations, and goals? Basically, we… fix the internet, so it is actually pretty great if you have never heard of us. That means we are doing a great job.

So, what better way is there to get the word out and to make more people aware of our mission than to share the work we do, right?

There we go, you have just discovered “The Joy of Diagnosis”, a cheesy copy of Mike Conley’s idea for our team. We already made an introductory episode, which we called Episode 0. If you want, you can watch it on either Air Mozilla or YouTube.

Please note that this is the very first episode, I did not spend much time planning ahead, and this is not the most polished video you will ever see. If you have any feedback, please reach out to me! I would love to get in touch with you.


Basically, we do not have a schedule since we usually do not have many isolated tasks to work on for recording. Some issues easily take up more time than we would ever have in a video, so we will probably just publish episodes whenever we have something cool. Please follow us on Twitter at @MozWebCompat to know when we published something new!

Although I tagged this stuff with “livehacking”, the first episode was not streamed live. :) However, I like the idea of enabling people to provide live feedback and asking questions in a chat, so if this project turns out to be interesting for at least some people, we surely will consider something.


I spent most of the time introducing our idea and the team as well as the individual parts of work we do and where people could jump in. However, we had a quick look at web-bug #4176.

If you want, check the Compatibility pages on the Mozilla Wiki to learn more about the team, our projects, and our work. Also, be sure to check out Mike Conley’s The Joy of Coding.

Categorieën: Mozilla-nl planet

Air Mozilla: Reps Weekly Meeting Feb. 09, 2017

Mozilla planet - do, 09/02/2017 - 17:00

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

Categorieën: Mozilla-nl planet

Mozilla-Knight OpenNews journalism program spins out as independent ... - VentureBeat

Nieuws verzameld via Google - do, 09/02/2017 - 16:12


Mozilla-Knight OpenNews journalism program spins out as independent ...
Mozilla and the Knight Foundation have announced that they're spinning out its OpenNews program as an independent body, six years after its inception. OpenNews was launched as a collaboration between the two organizations back in 2011, serving to ...
With $1.1 million in funding from Knight, OpenNews is becoming an independent ...Nieman Journalism Lab at Harvard
Knight Foundation invests $1.1M in OpenNews, becomes independent ...Talking New Media

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

Chris H-C: Data Science is Hard: Client Delays for Crash Pings

Mozilla planet - do, 09/02/2017 - 16:00

Second verse, much like the first: how quickly do we get data from clients?

This time: crash pings.

Recording Delay

The recording delay of crash pings is different from main pings in that the only time information we have about when the information happens is crashDate, which only tells you the day the crash happened, not the time. This results in a weird stair-step pattern on the plot as I make a big assumption:

Assumption: If the crash ping was created on the same day that the crash happened, it took essentially 0 time to do so. (If I didn’t make this assumption, the plot would have every line at 0 for the first 24 hours and we’d not have as much information displayed before the 96-hour max)


The recording delay for crash pings is the time between the crash happening and the user restarting their browser. As expected, most users appear to restart their browser immediately. Even the slowest channel (release) has over 80% of its crash pings recorded within two days.

Submission Delay

The submission delay for crash pings, as with all pings, is the time between the creation of the ping and the sending of the ping. What makes the crash ping special is that it isn’t even created until the browser has restarted, so I expected these to be quite short:


They do not disappoint. Every branch but Nightly has 9 out of every 10 crash pings sent within minutes of it being created.

Nightly is a weird one. It starts off having the worst proportion of created pings unsent, but then becomes the best.

Really, all four of these lines should be within an error margin of just being a flat line at the top of the graph, since the code that creates the ping is pretty much the same code that sends it. How in the world are these many crash pings remaining unsent at first, but being sent eventually?

Terribly mysterious.

Combined Delay


The combined client delay for crash pings shows that we ought to have over 80% of all crash pings from all channels within a day or two of the crash happening. The coarseness of the crashDate measure makes it hard to say exactly how many and when, but the curve is clearly a much faster one than for the main ping delays previously examined.

Crash Rates

For crash rates that use crashes counted from crash pings and some normalization factor (like usage hours) counted from main pings, it doesn’t actually matter how fast or slow these pings come in. If only 50% of crashes and 50% of usage hours came in within a day, the crash rate would still be correct.

What does matter is when the pings arrive at different speeds:


(Please forgive my awful image editing work)

Anywhere that the two same-coloured lines fail to overlap is a time when the server-recorded count of crashes from crash pings will not be from the same proportion of the population as the sever-recorded count of usage hours from main pings.

For example: On release (dark blue), if we look at the crash rate at 22 or 30-36 hours out from a given period, the crash rate is likely to approximate what a final tally will give us. But if we check early (before 22h, or between 22 and 30h), when the main pings are lagging, the crash rate will seem higher than reality. If we check later (after 36h), the crash rate will seem lower.

This is where the tyranny of having a day-resolution crashDate really comes into its own. If we could model exactly when a channels’ crash and main submission proportions are equal, we could use that to generate accurate approximations of the final crash rate. Right now, the rather-exact figures I’m giving in the previous paragraph may have no bearing on reality.


If we are to use crash pings and main pings together to measure “something”, we need to fully understand and measure the differences in their client-side delays. If the curves above are stable, we might be able to model their differences with some degree of accuracy. This would require a higher-resolution crash timestamp.

If we wish to use this measured “something” earlier than 24h from the event (like, say, to measure how crashy a new release is), we need to either chose a method that doesn’t rely on main pings, or speed up main ping reporting so that it has a curve closer to that of crash pings.

To do my part I will see if having a better crash timestamp (hours would do, minutes would be the most I would need) is something we might be willing to pursue, and I will lobby for the rapid completion and adoption of pingSender as a method for turning main pings’ submission delay CDF into a carbon copy of crash pings’.

Please peruse the full analysis on if you are interested in the details of how these graphs were generated.


Categorieën: Mozilla-nl planet

Software-update: Pale Moon 27.1.0 - Tweakers

Nieuws verzameld via Google - do, 09/02/2017 - 15:45


Software-update: Pale Moon 27.1.0
Pale Moon logo (75 pix) Versie 27.1 van Pale Moon is uitgekomen. Deze webbrowser maakt gebruik van de broncode van Mozilla Firefox, maar is geoptimaliseerd voor moderne hardware. De Windows-versie van Mozilla Firefox wordt namelijk ontwikkeld ...

Categorieën: Mozilla-nl planet

Mozilla bindet Firefox an Rust - Pro-Linux

Nieuws verzameld via Google - do, 09/02/2017 - 13:03

Mozilla bindet Firefox an Rust
Erstmals tauchten Rust-Komponenenten in Mozillas Browser mit Firefox 48 auf. Bislang gab es zum Kompilieren von Firefox die Option --disable-rust . Diese Option fällt mit Firefox 53 weg, sie wurde laut dem Fehlerbericht, der sie jetzt entfernen soll ...

Google Nieuws
Categorieën: Mozilla-nl planet

The Mozilla Blog: Launching an Independent OpenNews Program

Mozilla planet - do, 09/02/2017 - 12:35

At Mozilla, one of our essential roles is convener: working to identify, connect and support like-minded people who are building a healthier Internet.

An early — and strong — example of that work is the OpenNews program. Six years ago, Mozilla and Knight Foundation created an initiative to combine open-source practices with journalism. Our aim: strengthen journalism on the open web, and empower newsroom developers, designers and data reporters across the globe.

The program flourished. Since 2011, OpenNews has placed 33 fellows in 19 newsrooms, from BBC and NPR to La Nacion and the New York Times. It built a global community of more than 1,100 developers and reporters. It spawned the annual SRCCON conference, bolstered newsroom diversity and gave way to innovative newsgathering tools like Tabula. OpenNews has also played a key role in building the annual MozFest in London and Mozilla’s nascent leadership network initiative.

Mozilla is immensely proud of OpenNews — and immensely grateful to the team behind its success. And today, we’re announcing  that OpenNews is spinning out as  an independent organization. Going forward, OpenNews — with the support of nonprofit fiscal partner Community Partners — will build on the success it achieved when incubated at Mozilla. OpenNews will continue to play an active role in MozFest and Mozilla’s leadership network.

Mozilla isn’t departing the realm of journalism and media — they will remain central topics as we develop Mozilla’s Internet Health strategy over the coming years. MozFest will increasingly focus on issues like fake news, online harassment and advertising economics. This will be bolstered by Mozilla’s involvement in events like MisInfoCon in Boston later this month, where Mozilla is a sponsor and participant. On the technology front, we’ll continue to host the Coral project, which builds platforms that increase trust and engagement. We see news and media as key to our nascent Mozilla Leadership Network — and to our growing Internet health agenda.

As we chart a course forward in this work, we will be reaching out to the community to talk more specifically about where Mozilla should focus its efforts in the news and media space. If you want us to reach out to you as part of this conversation, please contact Mozilla’s Chris Lawrence at

See also:

Knight Foundation: OpenNews network of journalists and technologists to launch with $1.1 million from Knight Foundation

OpenNews: OpenNews Ascent Stage Initiated

Categorieën: Mozilla-nl planet

Launching an Independent OpenNews Program

Mozilla Blog - do, 09/02/2017 - 12:35

At Mozilla, one of our essential roles is convener: working to identify, connect and support like-minded people who are building a healthier Internet.

An early — and strong — example of that work is the OpenNews program. Six years ago, Mozilla and Knight Foundation created an initiative to combine open-source practices with journalism. Our aim: strengthen journalism on the open web, and empower newsroom developers, designers and data reporters across the globe.

The program flourished. Since 2011, OpenNews has placed 33 fellows in 19 newsrooms, from BBC and NPR to La Nacion and the New York Times. It built a global community of more than 1,100 developers and reporters. It spawned the annual SRCCON conference, bolstered newsroom diversity and gave way to innovative newsgathering tools like Tabula. OpenNews has also played a key role in building the annual MozFest in London and Mozilla’s nascent leadership network initiative.

Mozilla is immensely proud of OpenNews — and immensely grateful to the team behind its success. And today, we’re announcing  that OpenNews is spinning out as  an independent organization. Going forward, OpenNews — with the support of nonprofit fiscal partner Community Partners — will build on the success it achieved when incubated at Mozilla. OpenNews will continue to play an active role in MozFest and Mozilla’s leadership network.

Mozilla isn’t departing the realm of journalism and media — they will remain central topics as we develop Mozilla’s Internet Health strategy over the coming years. MozFest will increasingly focus on issues like fake news, online harassment and advertising economics. This will be bolstered by Mozilla’s involvement in events like MisInfoCon in Boston later this month, where Mozilla is a sponsor and participant. On the technology front, we’ll continue to host the Coral project, which builds platforms that increase trust and engagement. We see news and media as key to our nascent Mozilla Leadership Network — and to our growing Internet health agenda.

As we chart a course forward in this work, we will be reaching out to the community to talk more specifically about where Mozilla should focus its efforts in the news and media space. If you want us to reach out to you as part of this conversation, please contact Mozilla’s Chris Lawrence at

See also:

Knight Foundation: OpenNews network of journalists and technologists to launch with $1.1 million from Knight Foundation

OpenNews: OpenNews Ascent Stage Initiated

Categorieën: Mozilla-nl planet

Mike Conley: Things I’ve Learned This Week (May 25 – May 29, 2015)

Thunderbird - ma, 01/06/2015 - 07:49
MozReview will now create individual attachments for child commits

Up until recently, anytime you pushed a patch series to MozReview, a single attachment would be created on the bug associated with the push.

That single attachment would link to the “parent” or “root” review request, which contains the folded diff of all commits.

We noticed a lot of MozReview users were (rightfully) confused about this mapping from Bugzilla to MozReview. It was not at all obvious that Ship It on the parent review request would cause the attachment on Bugzilla to be r+’d. Consequently, reviewers used a number of workarounds, including, but not limited to:

  1. Manually setting the r+ or r- flags in Bugzilla for the MozReview attachments
  2. Marking Ship It on the child review requests, and letting the reviewee take care of setting the reviewer flags in the commit message
  3. Just writing “r+” in a MozReview comment

Anyhow, this model wasn’t great, and caused a lot of confusion.

So it’s changed! Now, when you push to MozReview, there’s one attachment created for every commit in the push. That means that when different reviewers are set for different commits, that’s reflected in the Bugzilla attachments, and when those reviewers mark “Ship It” on a child commit, that’s also reflected in an r+ on the associated Bugzilla attachment!

I think this makes quite a bit more sense. Hopefully you do too!

See gps’s blog post for the nitty gritty details, and some other cool MozReview announcements!

Categorieën: Mozilla-nl planet

Mike Conley: The Joy of Coding (Ep. 16): Wacky Morning DJ

Thunderbird - do, 28/05/2015 - 04:12

I’m on vacation this week, but the show must go on! So I pre-recorded a shorter episode of The Joy of Coding last Friday.

In this episode1, I focused on a tool I wrote that I alluded to in the last episode, which is a soundboard to use during Joy of Coding episodes.

I demo the tool, and then I explain how it works. After I finished the episode, I pushed to repository to GitHub, and you can check that out right here.

So I’ll see you next week with a full length episode! Take care!

  1. Which, several times, I mistakenly refer to as the 15th episode, and not the 16th. Whoops. 

Categorieën: Mozilla-nl planet

Rumbling Edge - Thunderbird: 2015-05-26 Calendar builds

Thunderbird - wo, 27/05/2015 - 10:26

Common (excluding Website bugs)-specific: (23)

  • Fixed: 735253 – JavaScript Error: “TypeError: calendar is null” {file: “chrome://calendar/content/calendar-task-editing.js” line: 102}
  • Fixed: 768207 – Make the cache checkbox default-on in the new calendar dialog
  • Fixed: 1049591 – Fix lots of strict warnings
  • Fixed: 1086573 – Lightning and Thunderbird disagree about timezone support in ics files
  • Fixed: 1099592 – Make JS callers of ios.newChannel call ios.newChannel2 in calendar/
  • Fixed: 1149423 – Add Windows timezone names to list of aliases
  • Fixed: 1151011 – Calendar events show up on wrong day when printing
  • Fixed: 1151440 – Choose a color not responsive when creating a New calendar in Lightning 4.0b1
  • Fixed: 1153327 – Run compare-locales with merging for Lightning
  • Fixed: 1156015 – Email scheduling fails for recipients with URN id
  • Fixed: 1158036 – Support sendMailTo for URN type attendees
  • Fixed: 1159447 – TEST-UNEXPECTED-FAIL | xpcshell-icaljs.ini:calendar/test/unit/test_extract.js
  • Fixed: 1159638 – Getter fails in calender-migration-dialog on first run after installation
  • Fixed: 1159682 – Provide a more appropriate “learn more” page on integrated Lightning firstrun
  • Fixed: 1159698 – Opt-out dialog has a button for “disable”, but actually the addon is removed
  • Fixed: 1160728 – Unbreak Lightning 4.0b4 beta builds
  • Fixed: 1162300 – TEST-UNEXPECTED-FAIL | xpcshell-libical.ini:calendar/test/unit/test_alarm.js | xpcshell return code: 0
  • Fixed: 1163306 – Re-enable libical tests and disable ical.js in nightly builds when binary compatibility is back
  • Fixed: 1165002 – Lightning broken, tries to load libical backend although “calendar.icaljs” defaults to “true”
  • Fixed: 1165315 – TEST-UNEXPECTED-FAIL | xpcshell-icaljs.ini:calendar/test/unit/test_bug759324.js | xpcshell return code: 1 | ###!!! ASSERTION: Deprecated, use NewChannelFromURI2 providing loadInfo arguments!
  • Fixed: 1165497 – TEST-UNEXPECTED-FAIL | xpcshell-icaljs.ini:calendar/test/unit/test_alarmservice.js | xpcshell return code: -11
  • Fixed: 1165726 – TEST-UNEXPECTED-FAIL | /builds/slave/test/build/tests/mozmill/testBasicFunctionality.js | testBasicFunctionality.js::testSmokeTest
  • Fixed: 1165728 – TEST-UNEXPECTED-FAIL | xpcshell-icaljs.ini:calendar/test/unit/test_bug494140.js | xpcshell return code: -11

Sunbird will no longer be actively developed by the Calendar team.

Windows builds Official Windows

Linux builds Official Linux (i686), Official Linux (x86_64)

Mac builds Official Mac

Categorieën: Mozilla-nl planet

Rumbling Edge - Thunderbird: 2015-05-26 Thunderbird comm-central builds

Thunderbird - wo, 27/05/2015 - 10:25

Thunderbird-specific: (54)

  • Fixed: 401779 – Integrate Lightning Into Thunderbird by Default and Ship Thunderbird with Lightning Enabled
  • Fixed: 717292 – Spell check language setting for subject and body not synchronized, but temporarily appears so when changing language and depending on focus (confusing ux)
  • Fixed: 914225 – Support hotfix add-on in Thunderbird
  • Fixed: 1025547 – newmailaccount/jquery.tmpl.js, line 123: reference to undefined property def[1]
  • Fixed: 1088975 – Answering mail with sendername containing encoded special chars and comma creates two “To”-entries
  • Fixed: 1101237 – Remove distribution directory during install
  • Fixed: 1109178 – Thunderbird OAuth implementation does not work with Evernote
  • Fixed: 1110166 – Port |Bug 1102219 – Rename String.prototype.contains to String.prototype.includes| to comm-central
  • Fixed: 1113097 – Fix misuse of fixIterator
  • Fixed: 1130854 – Package Lightning with Thunderbird
  • Fixed: 1131997 – Adapt for Debugger Server code for changes in bug 1059308
  • Fixed: 1135291 – Update chat log entries added to Gloda since bug 955292 to use relative paths
  • Fixed: 1135588 – New conversations get indexed twice by gloda, leading to duplicate search results
  • Fixed: 1138154 – Plugins default to “always activate” in Thunderbird
  • Fixed: 1142879 – [meta] track Mozilla-central (Core) issues that we want to have fixed in TB38
  • Fixed: 1146698 – Chat Messages added to logs just before shutdown may not be indexed by gloda
  • Fixed: 1148330 – Font indicator doesn’t update when cursor is placed in text where core returns sans-serif (Windows). Serif and monospace don’t work (Linux).
  • Fixed: 1148512 – TEST-UNEXPECTED-FAIL | mailnews/imap/test/unit/test_dod.js | xpcshell return code: 0||1 | streamMessages – [streamMessages : 94] false == true | application crashed [@ mozalloc_abort(char const * const)]
  • Fixed: 1149059 – splitter in compose window can be resized down to completely obscure composition area
  • Fixed: 1151206 – Using a theme hides minimize, maximize and close button in composer window [Mac]
  • Fixed: 1151475 – Remove use of expression closures in mail/
  • Fixed: 1152299 – [autoconfig] Cosmetic changes for WEB.DE config
  • Fixed: 1152706 – Upgrade to Correspondents column (combined To/From column) too agressive
  • Fixed: 1152796 – chrome://messenger/content/folderDisplay.js, line 697: TypeError: this._savedColumnStates.correspondentCol is undefined
  • Fixed: 1152926 – New mail sound preview doesn’t work for default system sound on Mac OS X
  • Fixed: 1154737 – Permafail: TEST-UNEXPECTED-FAIL | toolkit/components/telemetry/tests/unit/test_TelemetryPing.js | xpcshell return code: 0
  • Fixed: 1154747 – TEST-UNEXPECTED-FAIL | /builds/slave/test/build/tests/mozmill/session-store/test-session-store.js | test-session-store.js::test_message_pane_height_persistence
  • Fixed: 1156669 – Trash folder duplication while using IMAP with localized TB
  • Fixed: 1157236 – In-content dialogs: Port bug 1043612, bug 1148923 and bug 1141031 to TB
  • Fixed: 1157649 – TEST-UNEXPECTED-FAIL | dom/push/test/xpcshell/test_clearAll_successful.js (and most other push tests)
  • Fixed: 1158824 – Port bug 138009 to fix packaging errors | Missing file(s): bin/defaults/autoconfig/platform.js
  • Fixed: 1159448 – Thunderbird ignores proxy settings on POP3S protocol
  • Fixed: 1159627 – resource:///modules/dbViewWrapper.js, line 560: SyntaxError: unreachable code after return statement
  • Fixed: 1159630 – components/glautocomp.js, line 155: SyntaxError: unreachable code after return statement
  • Fixed: 1159676 – mailnews/mime/jsmime/test/test_custom_headers.js | run_next_test 0 – TypeError: _gRunningTest is undefined at /builds/slave/test/build/tests/xpcshell/head.js:1435 (and other jsmime tests)
  • Fixed: 1159688 – After switching/changing the window layout, dragging the splitter between threadpane and messagepane can create gray/grey area/space (misplaced notificationbox)
  • Fixed: 1159815 – Take bug 1154791 “Inline spell checker loses red underlines after a backspace is used – take two” in Thunderbird 38
  • Fixed: 1159817 – Take “Bug 1100966 – Inline spell checker loses red underlines after a backspace is used” in Thunderbird 38
  • Fixed: 1159834 – Consider taking “Bug 756984 – Changing location in editor doesn’t preserve the font when returning to end of text/line” in Thunderbird 38
  • Fixed: 1159923 – Take bug 1140105 “Can’t query for a specific font face when the selection is collapsed” in TB 38
  • Fixed: 1160105 – Fix strict mode warnings in protovis-r2.6-modded.js
  • Fixed: 1160106 – “Searching…” spinner at the bottom of gloda search results never goes away
  • Fixed: 1160114 – Strict mode warnings on faceted search
  • Fixed: 1160805 – Missing Windows and Linux nightly builds, build step set props: previous_buildid fails
  • Fixed: 1161162 – “Join Chat” doesn’t focus the newly joined MUC
  • Fixed: 1162396 – Take bug 1140617 “Pasting an image loses the composition style” in TB38
  • Fixed: 1163086 – Take bug 967494 “changing spellcheck language in one composition window affects all open and new compositions” in TB38
  • Fixed: 1163299 – “TypeError: getBrowser(…) is null” in contentAreaClick with Lightning installed and started in calendar view
  • Fixed: 1163343 – Incorrectly formatted error message “sending failed”
  • Fixed: 1164415 – Error in comment for imapEnterServerPasswordPrompt
  • Fixed: 1164658 – TypeError: Cc[‘;1’] is undefined at resource://gre/modules/FxAccountsWebChannel.jsm:227
  • Fixed: 1164707 – missing toolkit_perfmonitoring.xpt in aurora builds
  • Fixed: 1165152 – Take bug 1154894 in TB 38 branch: Disable test_plugin_default_state.js so Thunderbird can ship with plugins disabled by default
  • Fixed: 1165320 – TEST-UNEXPECTED-FAIL | /builds/slave/test/build/tests/mozmill/notification/test-notification.js

MailNews Core-specific: (30)

  • Fixed: 610533 – crash [@ nsMsgDatabase::GetSearchResultsTable(char const*, int, nsIMdbTable**)] with virtual folder
  • Fixed: 745664 – Rename Address book aaa to aaa_test, delete another address book bbb, and renamed address book aaa_test will lose its name and appear deleted after restart (dataloss! involving localized names)
  • Fixed: 777770 – get rid of nsVoidArray from /mailnews
  • Fixed: 786141 – Use nsIFile.exists() instead of stat to check the existence of the file
  • Fixed: 1069790 – Email addresses with parenthesis are not pretty-printed anymore
  • Fixed: 1072611 – Ctrl+P not working from Composition’s Print Preview window
  • Fixed: 1099587 – Make JS callers of ios.newChannel call ios.newChannel2 in mail/ and mailnews/
  • Fixed: 1130248 – |To: “” <>| becomes |”foo@example.comfoo”| when I compose mail to it
  • Fixed: 1138220 – some headers are not not properly capitalized
  • Fixed: 1141446 – Behaviour of malformed rfc2047 encoded From message header inconsistent
  • Fixed: 1143569 – User-agent error when posting to NNTP due to RFC5536 violation of Tb (user-agent header is folded just after user-agent:, “user-agent:[CRLF][SP]Mozilla…”)
  • Fixed: 1144693 – Disable libnotify usage on Linux by default for new-mail notifications (doesn’t always work after bug 858919)
  • Fixed: 1149320 – fix compile warnings in mailnews/extensions/
  • Fixed: 1150891 – Port changes from Bug 1115495 – Part 2: PAC generator for browsing and system wide proxy
  • Fixed: 1151782 – Inputting 29th Feb as a birthday in the addressbook contact replaces it with 1st Mar.
  • Fixed: 1152364 – crash in Address Book via nsAbBSDirectory::GetChildNodes nsCOMArrayEnumerator::operator new(unsigned int, nsCOMArray_base const&)
  • Fixed: 1152989 – Account Manager Extensions broken in Thunderbird 37/38
  • Fixed: 1154521 – jsmime fails on long references header and e-mail gets sent and stored in Sent without headers
  • Fixed: 1155491 – Support autoconfig and manual config of gmail IMAP OAuth2 authentication
  • Fixed: 1155952 – Nesting level does not match indentation
  • Fixed: 1156691 – GUI “Edit filters”: Conditions/actions (for specfic accounts) not visible
  • Fixed: 1156777 – nsParseMailbox.cpp:505:55: error: ‘do_QueryObject’ was not declared in this scope
  • Fixed: 1158501 – Port bug 1039866 (metro code removal) and bug 1085557 (addition of socorro symbol upload API)
  • Fixed: 1158751 – Port NO_JS_MANIFEST changes | mozbuild.frontend.reader.SandboxValidationError: calendar/base/backend/icaljs/
  • Fixed: 1159255 – Build error: MSVC_ENABLE_PGO = True is not permitted to be used in mailnews/intl/
  • Fixed: 1159626 – chrome://messenger/content/accountUtils.js, line 455: SyntaxError: unreachable code after return statement
  • Fixed: 1160647 – Port |Bug 1159972 – Remove the fallible version of PL_DHashTableInit()| to comm-central
  • Fixed: 1163347 – Don’t require scope in ispdb config for OAuth2
  • Fixed: 1165737 – Fix usage of NS_LITERAL_CSTRING in mailnews, port Bug 1155963 to comm-central
  • Fixed: 1166842 – Re-enable binary extensions for comm-central

Windows builds Official Windows, Official Windows installer

Linux builds Official Linux (i686), Official Linux (x86_64)

Mac builds Official Mac

Categorieën: Mozilla-nl planet

Mike Conley: Things I’ve Learned This Week (May 18 – May 22, 2015)

Thunderbird - za, 23/05/2015 - 23:54

You might have noticed that I had no “Things I’ve Learned This Week” post last week. Sorry about that – by the end of the week, I looked at my Evernote of “lessons from the week”, and it was empty. I’m certain I’d learned stuff, but I just failed to write it down. So I guess the lesson I learned last week was, always write down what you learn.

How to make your mozilla-central Mercurial clone work faster

I like Mercurial. I also like Git, but recently, I’ve gotten pretty used to Mercurial.

One complaint I hear over and over (and I’m guilty of it myself sometimes), is that “Mercurial is slow”. I’ve even experienced that slowness during some of my Joy of Coding episodes.

This past week, I was helping my awesome new intern get set up to tear into some e10s bugs, and at some point we went through this document to get her .hgrc all set up.

This document did not exist when I first started working with Mercurial – back then, I was using mq or sometimes pbranch, and grumbling about how I missed Git.

But there is some gold in this document.

gps has been doing some killer work documenting best practices with Mercurial, and this document is one of the results of his labour.

The part that’s really made the difference for me is the hgwatchman bit.

watchman is a tool that some folks at Facebook wrote to monitor changes in a folder. hgwatchman is an extension for Mercurial that takes advantage of watchman for a repository, smartly precomputing a bunch of stuff when the folder changes so that when you fire a command, like

hg status

It takes a fraction of the time it’d take without hgwatchman. A fraction.

Here’s how I set hgwatchman up on my MacBook (though you should probably go by the Mercurial for Mozillians doc as the official reference):

  1. Install watchman with brew: brew install watchman
  2. Clone the hgwatchman extension to some folder that you can easily remember and build it: hg clone cd hgwatchman make local
  3. Add the following lines to my user .hgrc: [extensions] hgwatchman = cloned-in-dir/hgwatchman/hgwatchman
  4. Make sure the extension is properly installed by running: hg help extensions
  5. hgwatchman should be listed under “enabled extensions”. If it didn’t work, keep in mind that you want to target the hgwatchman directory
  6. And then in my mozilla-central .hg/.hgrc: [watchman] mode = on
  7. Boom, you’re done!

Congratulations, hg should feel snappier now!

Next step is to try out this chg thingthough I’m having some issues still.

Categorieën: Mozilla-nl planet

Mark Banner: Using eslint alongside the Firefox Hello code base to help productivity

Thunderbird - wo, 13/05/2015 - 21:19

On Firefox Hello, we recently added the eslint linter to be run against the Hello code base. We started of with a minimal set of rules, just enough to get us something running. Now we’re working on enabling more rules.

Since we enabled it, I feel like I’m able to iterate faster on patches. For example, if just as I finish typing I see something like:

eslint syntax error in sublime I know almost immediately that I’ve forgotten a closing bracket and I don’t have to run anything to find out – less run-edit-run cycles.

Now I think about it, I’m realising it has also helped reduced the amount of review nits on my patches – due to trivial formatting mistakes being caught automatically, e.g. trailing white-space or missing semi-colons.

Talking about reviews, as we’re running eslint on the Hello code, we just have to apply the patch, and run our tests, and we automatically get eslint output:

eslint output - no trailing spacesHopefully our patch authors will be running eslint before uploading the patch anyway, but this is an additional test, and a few less things that we need to look at during review which helps speed up that cycle as well.

I’ve also put together a global config file for eslint (see below), that I use for outside of the Hello code, on the rest of the Firefox code base (and other projects). This is enough, that, when using it in my editor it gives me a reasonable amount of information about bad syntax, without complaining about everything.

I would definitely recommend giving it a try. My patches feel faster overall, and my test runs are for testing, not stupid-mistake catching!

Want more specific details about the setup and advantages? Read on…

My Setup

For my setup, I’ve recently switched to using Sublime. I used to use Aquamacs (an emacs variant), but when eslint came along, the UI for real-time linting within emacs didn’t really seem great.

I use sublime with the SublimeLinter and SublimeLinter-contrib-eslint packages. I’m told other editors have eslint integration as well, but I’ve not looked at any of them.

You need to have eslint installed globally, or at least in your path, other than that, just follow the installation instructions given on the SublimeLinter page.

One configuration I change I did have to make to the global configuration:

  • Open up a normal javascript (*.js) file.
  • Select “Preferences” -> “Settings – More” -> “Syntax Specific – User”
  • In the file that appears, set the configuration up as follows (or whatever suits you):
{ "extensions": [ "jsm", "jsx", "sjs" ] }

This makes sure sublime treats the .jsm and .jsx files as javascript files, which amongst other things turns on eslint for those files.

Global Configuration

I’ve uploaded my global configuration to a gist, if it changes I’ll update it there. It isn’t intended to catch everything – there’s too many inconsistencies across the code base for that to be sensible at the moment. However, it does at least allow general syntax issues to be highlighted for most files – which is obviously useful in itself.

I haven’t yet tried running it across the whole code base via eslint on the command line – there seems to be some sort of configuration issue that is messing it up and I’ve not tracked it down yet.

Firefox Hello’s Configuration

The configuration files for Hello can be found in the mozilla-central source. There’s a few of these because we have both content and chrome code, and some of the content code is shared with a website that can be viewed by most browsers, and hence isn’t currently able to use all the es6 features, whereas the chrome code can. This is another thing that eslint is good for enforcing.

Our eslint configuration is evolving at the moment, as we enable more rules, which we’re tracking in this bug.

Any Questions?

Feel free to ask any questions about eslint or the setup in the comments, or come and visit us in #loop on (IRC info here).

Categorieën: Mozilla-nl planet

Andrew Sutherland: Talk Script: Firefox OS Email Performance Strategies

Thunderbird - do, 30/04/2015 - 22:11

Last week I gave a talk at the Philly Tech Week 2015 Dev Day organized by the delightful people at on some of the tricks/strategies we use in the Firefox OS Gaia Email app.  Note that the credit for implementing most of these techniques goes to the owner of the Email app’s front-end, James Burke.  Also, a special shout-out to Vivien for the initial DOM Worker patches for the email app.

I tried to avoid having slides that both I would be reading aloud as the audience read silently, so instead of slides to share, I have the talk script.  Well, I also have the slides here, but there’s not much to them.  The headings below are the content of the slides, except for the one time I inline some code.  Note that the live presentation must have differed slightly, because I’m sure I’m much more witty and clever in person than this script would make it seem…

Cover Slide: Who!

Hi, my name is Andrew Sutherland.  I work at Mozilla on the Firefox OS Email Application.  I’m here to share some strategies we used to make our HTML5 app Seem faster and sometimes actually Be faster.

What’s A Firefox OS (Screenshot Slide)

But first: What is a Firefox OS?  It’s a multiprocess Firefox gecko engine on an android linux kernel where all the apps including the system UI are implemented using HTML5, CSS, and JavaScript.  All the apps use some combination of standard web APIs and APIs that we hope to standardize in some form.

Firefox OS homescreen screenshot Firefox OS clock app screenshot Firefox OS email app screenshot

Here are some screenshots.  We’ve got the default home screen app, the clock app, and of course, the email app.

It’s an entirely client-side offline email application, supporting IMAP4, POP3, and ActiveSync.  The goal, like all Firefox OS apps shipped with the phone, is to give native apps on other platforms a run for their money.

And that begins with starting up fast.

Fast Startup: The Problems

But that’s frequently easier said than done.  Slow-loading websites are still very much a thing.

The good news for the email application is that a slow network isn’t one of its problems.  It’s pre-loaded on the phone.  And even if it wasn’t, because of the security implications of the TCP Web API and the difficulty of explaining this risk to users in a way they won’t just click through, any TCP-using app needs to be a cryptographically signed zip file approved by a marketplace.  So we do load directly from flash.

However, it’s not like flash on cellphones is equivalent to an infinitely fast, zero-latency network connection.  And even if it was, in a naive app you’d still try and load all of your HTML, CSS, and JavaScript at the same time because the HTML file would reference them all.  And that adds up.

It adds up in the form of event loop activity and competition with other threads and processes.  With the exception of Promises which get their own micro-task queue fast-lane, the web execution model is the same as all other UI event loops; events get scheduled and then executed in the same order they are scheduled.  Loading data from an asynchronous API like IndexedDB means that your read result gets in line behind everything else that’s scheduled.  And in the case of the bulk of shipped Firefox OS devices, we only have a single processor core so the thread and process contention do come into play.

So we try not to be a naive.

Seeming Fast at Startup: The HTML Cache

If we’re going to optimize startup, it’s good to start with what the user sees.  Once an account exists for the email app, at startup we display the default account’s inbox folder.

What is the least amount of work that we can do to show that?  Cache a screenshot of the Inbox.  The problem with that, of course, is that a static screenshot is indistinguishable from an unresponsive application.

So we did the next best thing, (which is) we cache the actual HTML we display.  At startup we load a minimal HTML file, our concatenated CSS, and just enough Javascript to figure out if we should use the HTML cache and then actually use it if appropriate.  It’s not always appropriate, like if our application is being triggered to display a compose UI or from a new mail notification that wants to show a specific message or a different folder.  But this is a decision we can make synchronously so it doesn’t slow us down.

Local Storage: Okay in small doses

We implement this by storing the HTML in localStorage.

Important Disclaimer!  LocalStorage is a bad API.  It’s a bad API because it’s synchronous.  You can read any value stored in it at any time, without waiting for a callback.  Which means if the data is not in memory the browser needs to block its event loop or spin a nested event loop until the data has been read from disk.  Browsers avoid this now by trying to preload the Entire contents of local storage for your origin into memory as soon as they know your page is being loaded.  And then they keep that information, ALL of it, in memory until your page is gone.

So if you store a megabyte of data in local storage, that’s a megabyte of data that needs to be loaded in its entirety before you can use any of it, and that hangs around in scarce phone memory.

To really make the point: do not use local storage, at least not directly.  Use a library like localForage that will use IndexedDB when available, and then fails over to WebSQLDatabase and local storage in that order.

Now, having sufficiently warned you of the terrible evils of local storage, I can say with a sorta-clear conscience… there are upsides in this very specific case.

The synchronous nature of the API means that once we get our turn in the event loop we can act immediately.  There’s no waiting around for an IndexedDB read result to gets its turn on the event loop.

This matters because although the concept of loading is simple from a User Experience perspective, there’s no standard to back it up right now.  Firefox OS’s UX desires are very straightforward.  When you tap on an app, we zoom it in.  Until the app is loaded we display the app’s icon in the center of the screen.  Unfortunately the standards are still assuming that the content is right there in the HTML.  This works well for document-based web pages or server-powered web apps where the contents of the page are baked in.  They work less well for client-only web apps where the content lives in a database and has to be dynamically retrieved.

The two events that exist are:

DOMContentLoaded” fires when the document has been fully parsed and all scripts not tagged as “async” have run.  If there were stylesheets referenced prior to the script tags, the script tags will wait for the stylesheet loads.

load” fires when the document has been fully loaded; stylesheets, images, everything.

But none of these have anything to do with the content in the page saying it’s actually done.  This matters because these standards also say nothing about IndexedDB reads or the like.  We tried to create a standards consensus around this, but it’s not there yet.  So Firefox OS just uses the “load” event to decide an app or page has finished loading and it can stop showing your app icon.  This largely avoids the dreaded “flash of unstyled content” problem, but it also means that your webpage or app needs to deal with this period of time by displaying a loading UI or just accepting a potentially awkward transient UI state.

(Trivial HTML slide)

<link rel=”stylesheet” ...> <script ...></script> DOMContentLoaded!

This is the important summary of our index.html.

We reference our stylesheet first.  It includes all of our styles.  We never dynamically load stylesheets because that compels a style recalculation for all nodes and potentially a reflow.  We would have to have an awful lot of style declarations before considering that.

Then we have our single script file.  Because the stylesheet precedes the script, our script will not execute until the stylesheet has been loaded.  Then our script runs and we synchronously insert our HTML from local storage.  Then DOMContentLoaded can fire.  At this point the layout engine has enough information to perform a style recalculation and determine what CSS-referenced image resources need to be loaded for buttons and icons, then those load, and then we’re good to be displayed as the “load” event can fire.

After that, we’re displaying an interactive-ish HTML document.  You can scroll, you can press on buttons and the :active state will apply.  So things seem real.

Being Fast: Lazy Loading and Optimized Layers

But now we need to try and get some logic in place as quickly as possible that will actually cash the checks that real-looking HTML UI is writing.  And the key to that is only loading what you need when you need it, and trying to get it to load as quickly as possible.

There are many module loading and build optimizing tools out there, and most frameworks have a preferred or required way of handling this.  We used the RequireJS family of Asynchronous Module Definition loaders, specifically the alameda loader and the r-dot-js optimizer.

One of the niceties of the loader plugin model is that we are able to express resource dependencies as well as code dependencies.

RequireJS Loader Plugins

var fooModule = require('./foo'); var htmlString = require('text!./foo.html'); var localizedDomNode = require('tmpl!./foo.html');

The standard Common JS loader semantics used by node.js and io.js are the first one you see here.  Load the module, return its exports.

But RequireJS loader plugins also allow us to do things like the second line where the exclamation point indicates that the load should occur using a loader plugin, which is itself a module that conforms to the loader plugin contract.  In this case it’s saying load the file foo.html as raw text and return it as a string.

But, wait, there’s more!  loader plugins can do more than that.  The third example uses a loader that loads the HTML file using the ‘text’ plugin under the hood, creates an HTML document fragment, and pre-localizes it using our localization library.  And this works un-optimized in a browser, no compilation step needed, but it can also be optimized.

So when our optimizer runs, it bundles up the core modules we use, plus, the modules for our “message list” card that displays the inbox.  And the message list card loads its HTML snippets using the template loader plugin.  The r-dot-js optimizer then locates these dependencies and the loader plugins also have optimizer logic that results in the HTML strings being inlined in the resulting optimized file.  So there’s just one single javascript file to load with no extra HTML file dependencies or other loads.

We then also run the optimizer against our other important cards like the “compose” card and the “message reader” card.  We don’t do this for all cards because it can be hard to carve up the module dependency graph for optimization without starting to run into cases of overlap where many optimized files redundantly include files loaded by other optimized files.

Plus, we have another trick up our sleeve:

Seeming Fast: Preloading

Preloading.  Our cards optionally know the other cards they can load.  So once we display a card, we can kick off a preload of the cards that might potentially be displayed.  For example, the message list card can trigger the compose card and the message reader card, so we can trigger a preload of both of those.

But we don’t go overboard with preloading in the frontend because we still haven’t actually loaded the back-end that actually does all the emaily email stuff.  The back-end is also chopped up into optimized layers along account type lines and online/offline needs, but the main optimized JS file still weighs in at something like 17 thousand lines of code with newlines retained.

So once our UI logic is loaded, it’s time to kick-off loading the back-end.  And in order to avoid impacting the responsiveness of the UI both while it loads and when we’re doing steady-state processing, we run it in a DOM Worker.

Being Responsive: Workers and SharedWorkers

DOM Workers are background JS threads that lack access to the page’s DOM, communicating with their owning page via message passing with postMessage.  Normal workers are owned by a single page.  SharedWorkers can be accessed via multiple pages from the same document origin.

By doing this, we stay out of the way of the main thread.  This is getting less important as browser engines support Asynchronous Panning & Zooming or “APZ” with hardware-accelerated composition, tile-based rendering, and all that good stuff.  (Some might even call it magic.)

When Firefox OS started, we didn’t have APZ, so any main-thread logic had the serious potential to result in janky scrolling and the impossibility of rendering at 60 frames per second.  It’s a lot easier to get 60 frames-per-second now, but even asynchronous pan and zoom potentially has to wait on dispatching an event to the main thread to figure out if the user’s tap is going to be consumed by app logic and preventDefault called on it.  APZ does this because it needs to know whether it should start scrolling or not.

And speaking of 60 frames-per-second…

Being Fast: Virtual List Widgets

…the heart of a mail application is the message list.  The expected UX is to be able to fling your way through the entire list of what the email app knows about and see the messages there, just like you would on a native app.

This is admittedly one of the areas where native apps have it easier.  There are usually list widgets that explicitly have a contract that says they request data on an as-needed basis.  They potentially even include data bindings so you can just point them at a data-store.

But HTML doesn’t yet have a concept of instantiate-on-demand for the DOM, although it’s being discussed by Firefox layout engine developers.  For app purposes, the DOM is a scene graph.  An extremely capable scene graph that can handle huge documents, but there are footguns and it’s arguably better to err on the side of fewer DOM nodes.

So what the email app does is we create a scroll-region div and explicitly size it based on the number of messages in the mail folder we’re displaying.  We create and render enough message summary nodes to cover the current screen, 3 screens worth of messages in the direction we’re scrolling, and then we also retain up to 3 screens worth in the direction we scrolled from.  We also pre-fetch 2 more screens worth of messages from the database.  These constants were arrived at experimentally on prototype devices.

We listen to “scroll” events and issue database requests and move DOM nodes around and update them as the user scrolls.  For any potentially jarring or expensive transitions such as coordinate space changes from new messages being added above the current scroll position, we wait for scrolling to stop.

Nodes are absolutely positioned within the scroll area using their ‘top’ style but translation transforms also work.  We remove nodes from the DOM, then update their position and their state before re-appending them.  We do this because the browser APZ logic tries to be clever and figure out how to create an efficient series of layers so that it can pre-paint as much of the DOM as possible in graphic buffers, AKA layers, that can be efficiently composited by the GPU.  Its goal is that when the user is scrolling, or something is being animated, that it can just move the layers around the screen or adjust their opacity or other transforms without having to ask the layout engine to re-render portions of the DOM.

When our message elements are added to the DOM with an already-initialized absolute position, the APZ logic lumps them together as something it can paint in a single layer along with the other elements in the scrolling region.  But if we start moving them around while they’re still in the DOM, the layerization logic decides that they might want to independently move around more in the future and so each message item ends up in its own layer.  This slows things down.  But by removing them and re-adding them it sees them as new with static positions and decides that it can lump them all together in a single layer.  Really, we could just create new DOM nodes, but we produce slightly less garbage this way and in the event there’s a bug, it’s nicer to mess up with 30 DOM nodes displayed incorrectly rather than 3 million.

But as neat as the layerization stuff is to know about on its own, I really mention it to underscore 2 suggestions:

1, Use a library when possible.  Getting on and staying on APZ fast-paths is not trivial, especially across browser engines.  So it’s a very good idea to use a library rather than rolling your own.

2, Use developer tools.  APZ is tricky to reason about and even the developers who write the Async pan & zoom logic can be surprised by what happens in complex real-world situations.  And there ARE developer tools available that help you avoid needing to reason about this.  Firefox OS has easy on-device developer tools that can help diagnose what’s going on or at least help tell you whether you’re making things faster or slower:

– it’s got a frames-per-second overlay; you do need to scroll like mad to get the system to want to render 60 frames-per-second, but it makes it clear what the net result is

– it has paint flashing that overlays random colors every time it paints the DOM into a layer.  If the screen is flashing like a discotheque or has a lot of smeared rainbows, you know something’s wrong because the APZ logic is not able to to just reuse its layers.

– devtools can enable drawing cool colored borders around the layers APZ has created so you can see if layerization is doing something crazy

There’s also fancier and more complicated tools in Firefox and other browsers like Google Chrome to let you see what got painted, what the layer tree looks like, et cetera.

And that’s my spiel.


The source code to Gaia can be found at

The email app in particular can be found at

(I also asked for questions here.)

Categorieën: Mozilla-nl planet