Planet Firefox

April 15, 2014

Matthew Noorenberghe (MattN)

An easy way to test the New Firefox Beta look and feel before it's released

Screenshot of the new Firefox UI on Windows 7 with the menu panel openThe new Firefox Beta is faster, simplified and easier to customize and we need your help to test it out before it gets released in a few weeks time. There is now an easy way to review Firefox user interface changes without even installing the new version. "How is that possible?" you might ask. We have a collection of hundreds of screenshots of the new Firefox in various different configurations (affecting features such as tabs, toolbars, themes, customization mode, and the new menu) that are ready for you to review. It's fast and easy to do in three simple steps:
  1. Open up the screenshot review tool and enter a nickname to log in (there may be a small reward for the most valuable contributions so keep that in mind when choosing)
  2. A random screenshot will be displayed where you can simply identify any visual issues related to the new user interface that you may see. Simply drag to select the region of the image and add a comment (and optionally a bug number). See an example.
  3. When you're done reviewing that image, simply click the button to get another and go to step 2. Endless fun ensues!
Of course, installing Firefox Beta, testing the functionality and filing bugs is still really valuable and encouraged. Areas to focus on include the new customization mode, menu panel, tabs, and Firefox Account Sync. So, what are you waiting for? Start reviewing now.

April 15, 2014 01:14 AM

April 07, 2014

Tim Taubert (ttaubert)

A ready-to-use virtual build environment for Firefox

If you ever wondered what contributing to Firefox feels like but you never had the time to read and follow through our instructions to setup a build environment or wanted to avoid screwing around with your precious system then this might be for you.

This article will guide you through a small list of steps that in the end will leave you with a virtual machine ready to modify and build your own development version of Firefox.

I hope this will be valuable to novice programmers that do not have a full C++ development environment at hand as well as to the more experienced folks with little time and lots of curiosity.

1) Install VirtualBox

Note: The Open Virtualization Format (OVF) is supported by other Virtualization Environments such as VMWare, etc. You can use those if already installed instead of VirtualBox.

Go to the VirtualBox Downloads page and download the latest version available for your operating system. Should you already have VirtualBox installed then please ensure you are running the latest version by checking for updates before continuing.

2) Download the Firefox Build Environment

Now is the time to download the virtual machine containing our development environment ready to modify and build Firefox. You can get it here:

http://vmimages.mozilla.net/ovf/FirefoxBuildEnv.ova
(sha1 = c5717af5cccdc2c42e0a236a9859abffd940df9a)

Downloading ~2.6 GB might take a while if you are on a slow connection, sorry.

3) Set up the virtual machine

Once the image has been downloaded you can double-click the .ova file and import the new virtual machine into VirtualBox. Please give it at least 2048MB of RAM (4096MB if you can) and the same number of processors that your host machine has available. Building Firefox takes up a lot of resources and you want it to build as fast as possible.

Now that your virtual machine is ready, boot it and wait for the Ubuntu desktop to be shown. A terminal will pop up automatically and do some last steps before we can get started. After a successful installation Sublime 2 should start automatically.

Note: Should you ever need root credentials, use “firefox-dev” as the password. If you want to change your Language and Keyboard settings then follow the instructions on How to change the UI Language in Ubuntu.

4) Build Firefox

Click Tools > Build to start the process. This might take a long time depending on the features of your host machine, please be patient. You can watch the build progress in the text editor’s console at the bottom. Once the build has finished you can use Tools > Run to start your custom Firefox build and check that everything works as expected.

Note: if you want to switch from an optimized to a debug build then choose Tools > Build System > Firefox (Debug) and hit Tools > Build again to start a debug build.

5) Now what?

You successfully built Firefox for the first time and wonder what’s next? How about picking a small bug for a start, contribute code and get your changes shipped to half a billion people? If that sounds compelling then take a look at Bugs Ahoy! and find something to work on that sounds interesting to you.

If you are interested in digging deeper into the build system or the version control system, or want to know more about how to create your first patch and post it to our bug tracker then take a look at our Code Firefox Lessons.

I would love to hear your feedback about the Firefox Build Environment! Please tell me what can be improved and what you would like to see in the next version. Do not hesitate to drop me a mail should you have a more detailed opinion.

April 07, 2014 04:00 PM

April 04, 2014

Tim Taubert (ttaubert)

Starting my fourth year at Mozilla

Today marks the beginning of my fourth year at Mozilla. It has been an amazing three years and the best job I could hope for. Since March I am now in the position of an Engineering Manager with a few highly intelligent and great people that I am very grateful to call my team.

I am super excited about all the personal and professional challenges I will be facing this year. It is my core belief that it is all about growth and for that Mozilla is exactly the right place to be.

<3

April 04, 2014 09:00 AM

March 27, 2014

Gavin Sharp (gavin)

even more new firefox reviewers

I’m pleased to announce two additions to the list of Firefox reviewers:

Please join me in congratulating Mike and Florian!

March 27, 2014 03:00 AM

March 23, 2014

Matthew Noorenberghe (MattN)

PSA: Deployed Firefox profiles should not contain profile lock files

In short

If you are making a base Firefox profile which will be deployed to other machines, be sure to delete the profile lock files before creating the template/image. The filenames to delete vary by operating system and can be found in the roaming profile directory: When a lock file exists, the modification timestamp of that file needs to reflect the time when that profile was locked/used and so having a lock file from months ago when a base profile or image is made will lead to incorrect results.

Longer version

In the past (prior to bug 294260 in Firefox 13), the profile lock files (mentioned above) would be deleted upon successful shutdown of the Mozilla application. Since bug 294260, we now leave the profile lock files in place and simply update the existing file (and thus its modification time). We use the modification time and a preference to detect startup crashes related to the profile. In this case that means a crash from the time of locking the profile to the browser window appearing for 30 seconds. If the timestamp of the profile lock file doesn't match what was stored in the preferences, we assume that there was a crash in the last startup before it got to updating the preference. After three consecutive startup crashes detected within 6 hours, we will ask the user if they want to reset their profile or enter safe mode to resolve the crashes.

Offering to reset unused profiles

More recently, we added a new use of the last time of profile use in order to detect profiles which hadn't been used in a while (60 days) and offer to reset them (bug 498181 in Firefox 25). The idea is that there are people returning to Firefox after having been away for a while using another browser and they'd like to give Firefox another try. If they left Firefox due to technical issues such as slow startup or crashes, we don't want them to return to that problem and so we offer a reset as a way to get a fresher Firefox experience while still preserving key data such as bookmarks, history, passwords, etc. (the list is outlined in the reset dialog). If the profile lock file is part of a base profile or image like DeepFreeze and its timestamp is more than 60 days ago users may get prompted to reset immediately. Some users have already run into this and that's what prompted this email. In summary, the profile lock file must accurately reflect when the profile was last locked. Deleting it from base profiles is the best way to do this. Let me know in the comments if you have any questions.

March 23, 2014 09:00 PM

March 18, 2014

Brian Bondy (bbondy)

Does Modern UI Firefox usage indicate Windows 8.1 modern UI is in trouble?

On Friday, Mozilla announced it would not ship its Modern UI Firefox browser due to low adoption.

Is Windows 8.1 modern UI in trouble?

No.


Did Mozilla make the right decision with Metro given the current circumstances?

Yes.


Modern UI Firefox usage, in Mozilla's measurements, is not necessarily a true reflection of Modern UI usage in general.

Modern UI Firefox Usage != Modern UI usage

I do believe that Microsoft's modern UI is important for touch hardware, and I do believe that touch hardware is something people are adopting and will adopt more.


I believe that the Modern UI Firefox usage was low, at least in part, for 2 specific reasons:

  1. Microsoft doesn't allow your browser to run in Modern UI unless you are the default browser. Several people could have had a Modern UI capable Firefox pre-releases installed, but just never knew it.

  2. Microsoft makes it a lot harder to set your browser as the default in Windows 8. Before Windows 8, each browser could prompt you, and then they could set your default for you. As of Windows 8 you need to ask first, then tell Microsoft to show a prompt that shows a list of browsers (confusing). And that only sets the HTTP default. If you want all defaults, such as HTML and HTTP, then you have to send the user to control panel, make them search for the browser, then make them select your browser and set all defaults.


It would be great if Microsoft could fix these issues around default status. More competition leads to better software, and having good software on your platform is important. Every Windows Modern UI user loses when there's only one Modern UI browser choice.

March 18, 2014 07:38 PM

March 14, 2014

Brian Bondy (bbondy)

Switching careers, next steps

I made one of the hardest decisions of my life, I'll be leaving Mozilla, a company that I thought I'd be at forever. Mozilla has amazing people and culture, and is easily the best job I've ever had.

I plan to remain a contributor, both on the Code Firefox site, and on Firefox Desktop itself.


I'll be joining Khan Academy, a like minded, mission oriented, open and non-profit company.

Khan Academy provides a free, world class education, to anyone, anywhere.

I'm leaving because the Khan Academy mission speaks more to me personally.

Along with that mission comes a lot of thoughts I believe in, such as:

I'll be joining the Computer Science department at Khan Academy in particular. I'm extremely excited for this new opportunity and I can't wait to do amazing things at Khan Academy.

March 14, 2014 08:58 PM

March 06, 2014

Dave Townsend (Mossop)

Developer Tools meet-up in Portland

Two weeks ago the developer tools teams and a few others met in the Portland office for a very successful week of discussions and hacking. The first day was about setting the stage for the week and working out what everyone was going to work on. Dave Camp kicked us off with a review of the last six months in developer tools and talked about what is going to be important for us to focus on in 2014. We then had a little more in-depth information from each of the teams. After lunch a set of lightning talks went over some projects and ideas that people had been working on recently.

After that everyone got started prototyping new ideas, hacking on features and fixing bugs. The amount of work that happens at these meet-ups is always mind-blowing and this week was no exception, even one of our contributors got in on the action. Here is a list of the things that the team demoed on Friday:

This only covers the work demoed on Friday, a whole lot more went on during the week as a big reason for doing these meet-ups is so that groups can split off to have important discussions. We had Darrin Henein on hand to help out with UX designs for some of the tools and Kyle Huey joined us for a couple of days to help work out the final kinks in the plan for debugging workers. Lot’s of work went on to iron out some of the kinks in the new add-on SDK widgets for Australis, there were discussions about memory and performance tools as well as some talk about how to simplify child processes for Firefox OS and electrolysis.

Of course there was also ample time in the evenings for the teams to socialise. One of the downsides of being a globally distributed team is that getting to know one another and building close working relationships can be difficult over electronic forms of communication so we find that it’s very important to all come together in one place to meet face to face. We’re all looking forward to doing it again in about six months time.

March 06, 2014 01:52 AM

March 05, 2014

Dave Townsend (Mossop)

An editable box model view in the devtools

This week the whole devtools group has been sequestered in Mozilla’s Portland office having one of our regular meet-ups. As always it’s been a fantastically productive week with lots of demos to show for it. I’ll be writing a longer write-up later but I wanted to post about what I played with over the week.

My wife does the odd bit of web development on the side. For a long time she was a loyal Firebug user and a while ago I asked her what she thought of Firefox’s built in devtools. She quickly pointed out a couple of features that Firebug had that Firefox did not. As I was leaving for this week I mentioned I’d be with the devtools group and she asked whether her features had been fixed yet. It turns out that colour swatches had been but the box model still wasn’t editable. So I figured I could earn myself some brownie points by hacking on that this week.

The goal here is to be able to inspect an element on the page, pull up the box model and be able to quickly play with the margins, borders and padding to tweak the positioning until it looks right. Then armed with the right values you can go update your stylesheets. It saves a lot of trial and error with positioning.

It turned out to be relatively simple to implement a pretty full version. The feature allows you to click one of the box model values and type whatever value you like, in any CSS unit you prefer. If the size had been set in the stylesheet in some specific unit then that is what appears in the input box for you to change. Better yet as you type numbers the element updates in the page on the fly and you can use the arrow keys to increase/decrease the value until you’re happy. It’s a really natural way to play with the element’s position.

The changes made appear on the element so you can find them in the rule view pretty easily. This patch is based on an updated version of the box model view which is why it looks so different to existing Firefox, all my work does is make the numbers editable.

I actually completed this so quickly that I decided to take this one step further. One thing missing from the box model display is information about border colours. So I added some colour swatches for each border and made them editable with the regular devtools colour picker.

Both of these patches are pretty much complete but they’ll have to wait for the new box model highlighter to be complete before they can be reviewed and land.

March 05, 2014 05:29 PM

Brian Bondy (bbondy)

Investing in our community through Code Firefox

Mozilla 2014 Goal

As Deb Cohen (VP, Chief of People) said:
Our goal this year is to find new ways for people to become part of us. This year we have a very aggressive goal, for all of us to look inside our teams, our work, our organization, and create some of these pathways.


What is Code Firefox?

The Code Firefox site (@codefirefox), is a new video and exercise framework which is highly inspired by Khan Academy. Its purpose is for on-boarding contributors and sharpening the skills of existing community members.

People learn differently. Providing different ways to consume information is crucial to growing Mozilla. For many people, Code Firefox provides an easier, and more consumable approach to learning how to contribute to Mozilla.

Would you like to start contributing patches to Mozilla? Start here


Testimonial

One prime example of Code Firefox's usefulness is of a new contributor who joined last month, and actively uses Code Firefox. He has already submitted 18 patches.

In a personal email Anuj Agarwal (Student at Vellore Institute of Technology) writes:
Just for fun, here is the patch I got reviewed today! And it was made possible only because of your tutorials. Thank you!


Code Firefox statistics

The site has not been promoted yet, but it already has:


What has Code Firefox accomplished?

51 videos, 3 exercises focused mostly on on-boarding new Firefox developers
Videos are captioned
Ability to track watched videos and completed exercises when logged in
Exercise framework that parses code and gives immediate feedback and experience

Videos and Exercises are accessible and searchable through tags


Where is the Code Firefox site going? (Code Firefox Goals)

Opening up the ability to post videos to other people
Ability to create different "Outline tracks", for example, a QA track.
More video and exercise content being added, initially for Firefox OS and Desktop
Integrate with Mozilla Open Badges
Working more closely with Student Ambassadors
Implement a point system
Interoperability with Mozillians in creative ways
Implementing hints for exercises

Other goals


Highlights of benefits gained by Mozilla from the site

Brings in new contributors
Retains new and existing contributors
Sharpens skills of existing members of our community
Code Firefox uses and promotes Persona
Code Firefox will use and promotes Open Badges

Will train employees with advanced skills with advanced tracks


Media coverage of Code Firefox so far

Some people have taken the time to write about Code Firefox:


What our community is saying


Would you like to create Code Firefox videos?

Please contact me at bbondy[at]gmail.com if you'd like to make a series of videos on Code Firefox for your area of expertise.

March 05, 2014 03:49 PM

March 03, 2014

Margaret Leibovic (margaret)

Dare 2B Digital 2014: Remix the Web!

Dare 2B Digital is an annual South Bay conference that brings 300 young women ages 12-16 together to encourage them to consider STEM fields in college by coming together for a full day of inspiring talks and workshops showcasing women’s work and relevance in technology. For the past four conferences, Lukas has signed Mozilla up as a sponsor and created a workshop that is run 3 times that day and reaches about 80-100 attendees. Last year, Lukas and I created a workshop to teach these girls how to create mobile HTML5 games. This year, Lukas couldn’t make it to the conference because she was busy organizing another great outreach event, so I volunteered to organize our workshop, and I recruited Katie and Heather to help me.

I really love Webmaker, a Mozilla project dedicated to helping people learn how to create amazing things on the web, so I decided to create a workshop to teach the girls how to use some of the Webmaker tools. My goal was to teach the girls how to use these tools to understand the basic building blocks of the web, as well as show them how easy it is to make their own web content. To prepare for the conference, I gathered 20 loaner laptops, ordered some swag, and remixed an existing Webmaker teaching kit to create an outline for the workshop.

We started off each workshop with a brief overview of how the web works (Katie used her teacher skills to create some nice whiteboard diagrams), and then we jumped right into using the Webmaker tools. We started by walking the girls through using the X-Ray Goggles to inspect webpages, and taught them that they can modify what they see in their browsers. We definitely heard lots of “This is so cool!!!” when we showed them how to change text and images on any webpage.

Once they felt comfortable with X-Ray Goggles, we pointed them to a gallery of existing Webmaker projects, and showed them how to use Thimble to remix those projects into their own. At this point, we let them loose to start working on their own remixes, and there was lots of enthusiasm and laughter as they started working on their own projects. We also felt thoroughly out of touch with youth culture when they started filling their projects with images of young male celebrities we had never even heard of.

Unfortunately, we only had an hour and 15 minutes for each workshop, which flew by, but we encouraged the girls to make their own Webmaker accounts to continue working on their remixes at home. They were definitely really excited to learn that all of these resources are available to them at home, and that they only need a web browser to get started!

March 03, 2014 07:15 PM

February 14, 2014

Johnathan Nightingale (johnath)

Four

FourFour is a big deal. Big girl bed. Big girl bike. You explain this to me, in case I’d missed it.

“Soon I will be four, and then I’ll be a teenager.”

Eef.

I travel a lot these days. Not constantly, probably not even 25% of the time, but enough that I often go a week without giving you a hug. And being the overthinker dad that I am, that makes me wonder what effect it has on you. We video chat when I’m gone, whenever the internet connection is good enough. When it isn’t, I record videos for you and send them to your mom to play. I’ve never missed a weekend with you, though it’s sometimes been quite a trick to make that work. I think I’m a really present dad, I try to be, but I wonder how you feel about it, and how you’ll think about it years from now. I hope you’ll agree.

My dad, your grandpa, tells me that when I was a kid and he had a weekend with me, he felt protective. Like he didn’t want to share. Like he wanted me all to himself. And how that wasn’t very helpful and we had a much better time once he got past it and made room. Boy do I understand that, now. Time with you is the best thing, and sometimes I don’t want to share. But grandpa’s wise, and sharing you with others is great, and watching you venture off and be social and own a room is just wonderful. But I’m still glad that you let me read you stories and tuck you into bed at night.

Today was your birthday and you ran around like an idiot with a birthday cake tiara and a birthday bear and made goofy faces any time I tried to take your picture. You ordered pizza and oreo cake and tried to splash me with bathwater. And you fell asleep while I stroked your hair and you snored a little and it was the best thing ever.

Goodnight, Lil. Sweet dreams. I love you.

February 14, 2014 03:03 AM

February 04, 2014

Margaret Leibovic (margaret)

WIP: Home Page Customization in Firefox for Android

In Firefox 26, we released a completely revamped version of the Firefox for Android Home screen, creating a centralized place to find all of your stuff. While this is certainly awesome, we’ve been working to make this new home screen customizable and extensible. Our goal is to give users control of what they see on their home screen, including interesting new content provided by add-ons. For the past two months, we’ve been making steady progress laying the ground work for this feature, but last week the team got together in San Francisco to bring all the pieces together for the first time.

Firefox for Android has a native Java UI that’s partially driven by JavaScript logic behind the scenes. To allow JavaScript add-ons to make their own home page panels, we came up with two sets of APIs for storing and displaying data:

image

During the first half of our hack week, we agreed on a working first version of these APIs, and we hooked up our native Java UI to HomeProvider data stored from JS. After that, we started to dig into the bugs necessary to flesh out a first version of this feature.

image

Many of these patches are still waiting to land, so unfortunately there’s nothing to show in Nightly yet. But stay tuned, exciting things are coming soon!

February 04, 2014 03:45 AM

January 09, 2014

Felipe Gomes (felipc)

Hello 2014

Happy new year everyone! During the holidays I had been thinking about my goals for 2014, and I thought it’d be a good exercise to remember what I’ve done in the past year, the projects I worked on, etc. It’s nice to look back and see what was accomplished last year and think about how to improve it. So here’s my personal list; it doesn’t include everything but it includes the things I found most important:

Related to performance/removing main-thread-IO:

Related to hotfixes:

Related to electrolysis:

Other things:

Events attended:

And:

That’s it. Looking forward to a great 2014!


January 09, 2014 07:09 PM

December 03, 2013

Matthew Noorenberghe (MattN)

Introducing a Google spreadsheet library to fetch Talos results

As part of the performance investigation for Australis (the in-progress Firefox desktop redesign), we wanted to be able to easily track Talos performance benchmark numbers across all of the relevant platforms without having to open 52 graph server links (Datazilla wasn't ready at the time) . My goal was to use the graph server API to pull in the data and display the regression percentage for all of the tests we were tracking in an overview. Rather than writing a new tool from scratch, I decided to look into Google Apps Script, which I had only heard about before, and it seemed to be able to help implement what I wanted on top of Google Spreadsheets. The result is a shared Talos Google Apps Script Library [Google login required] (revision log) (API docs) that anyone can use. You can see it in use for TART and other tests for Australis along with the demo spreadsheet.

How to use the Talos library in a Google spreadsheet

Also see Google's documentation on Libraries and the demo spreadsheet.

  1. In your Google Spreadsheet, choose Tools > Script Editor
  2. In the new tab, click Close to skip the tutorials and templates.
  3. In the menu, choose Resources > Manage Libraries. If you are asked to save your project, do so.
  4. In the "Included Libraries" window, paste the following in the "Find a Library" textbox and click Select: MCurDezZ1B01NQX34URNDye9_pJh_2yq6
  5. The "Talos" library should have appeared above. Choose a version of the library (the latest is probably best), and click Save.
  6. Replace the contents of the default script file ("Code.gs" at the time of writing) with pass-through wrappers for every function you want to use (example). Let me know if there is a better way to do this as it's not ideal.
  7. Call your wrapper functions from within your spreadsheet. e.g. =getTalosResult(226, 59, 25, "ca7577238ef4"). You can get test, branch and platform IDs from the compare.py script or from the URLs output on TBPL.
Now you can use the power of spreadsheets to slice and dice the data as you please. Perhaps you like custom graphs?

Caveats

Eventually the library should switch to using Datazilla but this works for now since talos results are being reported to both services. If you would like to contribute changes to the library, let me know.

December 03, 2013 10:22 AM

December 02, 2013

Johnathan Nightingale (johnath)

NSID 2013 – Travelogue

To everything there is a season.

I’m driving today. The road races by, cold with the oncoming winter. The trees, skeletal without their leaves, look dead. The fields are frozen, shorn of their fruits long ago. Picturesque. But even from within the heat of the car, the sight of it all makes me shiver.

The seasons make us. They mete out our minutes of sunlight and degrees of warmth and millimeters of rain. Not with a parent’s loving tenderness, or even a teacher’s careful pedagogy, but with a metronome’s mindless repetition. And today they have made the world outside this car cold, and still, and dead.

But you are not bound by their rhythm! You are vibrant, and alive, and your own self. What the seasons decree must be a cold and barren time you can make into growth and flourishing life. Hooray for you, that have this freedom and this power to make your world better than it was before!

To shave is to suppress. So much suppression infuses what we do that, hoodwinked by fashion, we become our own gaolers. We shave ourselves. And as the seasons swirl around us to make us cold, to make us withdraw, in that moment, friends, I say that we should fight back against their mindless cruelty.

One month of the year I will not go gently into my cell. One month of the year I will make, upon my person, rebellion against desolation around me. One month, this month, I will be as beautiful as I am able. I will take no blade against myself, I will not lessen me. And I invite you. I entreat you. From the cold of this frozen highway I beg you to do the very same.

And then tweet about it, and post pictures on flickr.

noshavingindecember.org

December 02, 2013 02:40 AM

November 18, 2013

Brian Bondy (bbondy)

Short one video per concept Firefox development videos

I'd like to introduce a new site I'm working on named Code Firefox.


Elevator pitch

Becoming a Mozilla contributor can be intimidating. There's a lot of information to consume, and that information can be dispersed in a variety of different places. This site aim to outline the process of becoming a Mozilla contributor, from the start, with gentle, short, consumable 2-10 minute videos.


A long time coming

In July 2012 I blogged about my first year at Mozilla, and where I'd like to go in the future.

I'm starting work on a project to bring videos for code contributors. The plan is to have short 5-10 minute videos that each cover a single topic. This would be similar to Khan Academy videos in the 1 video per concept way, but will be more like a tutorial and will be focused on contributing to Mozilla.

It took me a while to actually start on that goal, partly because I kept making excuses for why it wasn't a good time to start yet.

Maybe I was just scared of presenting something in a way that wasn't the best way. But when it comes down to it, I know a lot of people can benefit from the content of the videos I'm creating. And because of that, I'm no longer afraid to be corrected.

A couple month ago, sitting in the airport coming home from the Mozilla 2013 Summit, I registered codefirefox.com. I also created a github project and started coding the site that would be used for those videos.


The future of Code Firefox

Code Firefox aims to focus on Desktop Firefox videos from the ground up. I'd love to also do videos on Firefox for Android, Firefox for Windows 8 style UI, and especially for Firefox OS.

I'd like to eventually get to a place where the videos can be used for onramping new hires, and perhaps also used by some schools as the basis of a class.


Status and focus

Since I began posting videos, I've been posting an average of over 1 video per day, I'm close to 20 videos so far.

These videos are not focused on perfection, partly because I'm far from it, and partly because I have so much content to go out, that there is more of a benefit to do new videos instead of focusing on old ones.

One statistic I found interesting is that the average visit duration on my blog is under 1 minute; whereas, the average visit duration of the Code Firefox site is over 5 minutes.


The process

I’m using ScreenFlow on OS X to make the videos in a Windows 8 VMware Fusion VM, and a Blue Yeti microphone.

As each video is posted, I post a message about it on this twitter account.

November 18, 2013 03:52 AM

November 06, 2013

Brian Bondy (bbondy)

Shared profiles for Metro Firefox and Desktop Firefox

Up until recently, Metro Firefox was designed to use a separate profile from desktop Firefox. We had planned to rely on sync to bring the data from the 2 profiles together.

We've had feedback around this, and we've found that a better experience would be obtained by sharing a single profile.

We're in the process of implementing shared profiles.


What is a profile?

A profile in Firefox stores all of your personal settings, including: bookmarks, preferences, extensions, passwords, history, and more.

We'll be sharing profiles from both applications, but there are some exceptions:


What are the upsides of having a shared profile?

Sharing a single profile would allow you to instantly retain bookmarks, login status, cookies, and other profile data between environments.

You would never need to wait for some kind of 'sync service' to complete its work to see your data in the other environment.

Another task highly related to sharing a single profile is adding a "Relaunch in Desktop" option from Metro Firefox and a "Relaunch in Metro" option from Desktop Firefox.


Are there any downsides to having a shared profile?

Yes, but we believe them to be corner case issues that the user can work around, see below.

The main disadvantage is that before you could run both Metro and Desktop browsers at the same time. This will change so that you can only run either one or the other at any given time.

Windows 8 is a clash of 2 environments:

  1. a Desktop environment which is optimized for mouse and keyboard
  2. an immersive environment which is optimized for touch

If you're using a keyboard and mouse, and since we will be having a shared profile, there is no reason you'd want to use the Metro browser. If you really want to you can, but surely you don't need to use both Desktop and Metro at the same time.

The opposite argument is also true for touch. Most of the time when using touch you'll want to use the Metro browser, but there are special cases where you'll want to switch, like if you need an addon or plugin to take effect.

For users who really want to run both at the same time, they can force the use of a different profile using the -ProfileManager command line argument from Desktop Firefox.


Will having a shared profile change the release date?

Having a shared profile is not expected to change the release of Metro Firefox. A smooth async panning and zooming experience is being worked on before we want to release, and during that time we're implementing shared profiles.

The switch to Desktop / Metro feature may not retain all opened tabs and filled in form status in v1 if time does not permit. We plan to use session restore to do this, but there's some non trivial work to do there.


Where is this work being tracked?

Shared profile work is being tracked in bug 924860.


Other implementation details


Current progress

If you'd like to see general progress of Metro Firefox you should use either the Nightly or Aurora builds.

Current progress for profile sharing can be seen in Oak builds (Not recommended for general use). These patches will also move to mozilla-central (Nightly builds) after QA'ing is done to ensure there is no harm to the Desktop profile.

The completed list of tasks related to this feature so far include:


Feedback

Constructive feedback is appreciated and wanted. Please feel free to leave a comment here or post in the profile sharing tracking bug: Bug 924860.

November 06, 2013 02:46 PM

October 29, 2013

Margaret Leibovic (margaret)

MozFest Recap: Building Your First Mobile Web App

This past weekend I attended Mozilla Festival in London, and it was incredibly energizing! Everyone at MozFest was so excited about the web, but unlike your average tech conference, there was a much more diverse set of participants, including hackers, makers, journalists, educators, and even lots of kids. The focus of this year’s MozFest was about creating a web-literate world, so I decided to facilitate a session on building your first mobile web app.

Although projects like Webmaker and Appmaker are designed to make content creation more accessible for everyone, I wanted to create some learning materials that could put people on the path towards becoming more serious web developers. This path includes learning the fundamentals of HTML/CSS/JS, as well as how to use the developer tools built into browsers, and popular collaboration tools like Github.

To teach these basics, I made a slide deck that walks you through building a simple stopwatch app that’s hosted using Github pages. At the start of my session, I presented these slides (and of course threw in some Firefox dev tools demos!), but then I let everyone loose to start hacking at their own speeds. There were about 25 participants with a wide range of ability levels, and I think this format worked well to keep everyone engaged (and gave me the opportunity to offer more individual help).

My hope is that other people might find these resources useful, so please use them and share them! Also, because they’re open source, pull requests are welcome :)

October 29, 2013 08:27 PM

October 15, 2013

Margaret Leibovic (margaret)

Remote Developer Tools and Firefox for Android

A lot of the Firefox for Android UI is written in Java, but under the hood there’s still quite a bit of JS that controls core browser logic. We also use HTML to create the content of most of our chrome-privileged pages, such as about:addons. Today I found myself working on a polish bug for about:apps. In the past, tweaking the CSS for these pages has been a pain, since testing changes required pushing a new APK to your device. However, I remembered that the remote inspector recently landed for Firefox 26, so I decided to try it out. Verdict: it was amazing!

imageimage

Setting up the remote developer tools is as easy as flipping prefs on desktop and mobile (these prefs are now exposed in the UI!), running an adb command to set up port forwarding, and hitting a button. The directions are really well documented on MDN, so you should look there for more detailed instructions.

While playing around with the inspector, I also realized that remote chrome debugging is enabled for Firefox for Android. It wasn’t immediately obvious to me that in order to attach the debugger to the main chrome window, you need to select the “Main Process” link on the desktop “Connect to remote device page”, but once I did that, I had access to all of the browser chrome JS. And since add-ons for Firefox for Android are written in JS, this means that you can easily debug all of your add-on code!

image

Big thanks to the Firefox Developer Tools Team for doing so much awesome work. And I know they’re always looking for new contributors to help them out!

October 15, 2013 04:42 AM

October 01, 2013

Felipe Gomes (felipc)

GSoC 2013 completed

Last week, the 2013 edition of the Google Summer of Code officially finished. The Firefox team had come up with a few project ideas for this year and I mentored Abhishek Choudhary in the project dubbed “about:memory for real people”. The goal was to produce a friendlier and prettier version of about:memory that could be used by users and web developers to investigate the memory usage aspects of their webpages.

Mentoring GSoC was a nice experience again (it was my 4th time as a mentor) and I’m happy to say that the project was completed successfully! On Sep 16th, the “soft pencils down” goal on GSoC timeline, Abhishek tagged the 1.0 version on GitHub and the code was called complete. After a small extra bug fix, 1.0.1 was tagged and then submitted to addons.mozilla.org!

The project itself was very interesting because it was not a straightforward coding exercise: there was also a creative element to it which allowed us to experiment different visualization styles to try and see what worked best. It began with a few different separate visualizations but it evolved over time to one main integrated viz that supports seeing the data consumed by each tab and to watch how it evolves over time. The user can take manual time snapshots or let it take one every 5 seconds, and then use the time slider to go back and forth between the last 5 snapshots. The main hope is that this should be useful for a web developer who wants to see how a particular action on the website might affect its memory usage and if it fits the expectations (does that operation increase memory? does it release it as expected?).

Here’s a screenshot of the main interface:

fx-statistics screenshot

You can see more details and install it from AMO. There’s a small catch: the add-on currently won’t work with Aurora or Nightly, just Beta and Release. This was an interesting part of the project: on the few last weeks of the project, the API that the add-on had been using changed, and it was not possible to change it to the new API among the other wrap-up tasks for the project. But luckily add-on versioning works well, and as the goal of this add-on is end users, shipping for beta and release is ok for now, and we’ll soon be posting a new version that is compatible with FF25+.

Abhishek also has a very nice blog post that you should be reading instead of mine :), describing the project progression and his experience working on it. I want to take this opportunity to say congrats to him and thanks to all students who participated in the GSoC project this year! I hope everyone had a nice time and hopefully the experience have interested some of you to continue to be part of community! Looking forward to next year’s projects.

 


October 01, 2013 04:37 PM

September 27, 2013

Margaret Leibovic (margaret)

Home Page Snippets for Firefox for Android

Have you ever noticed the messages that appear under the search box on desktop Firefox’s home page? We call these messages snippets, and they’re dynamically created from web content hosted by Mozilla. These snippets provide an easy way to communicate with desktop users, but right now there’s no equivalent feature for Firefox for Android.

Since we first released the native version of Firefox for Android, we’ve included a hard-coded promotional banner as part of our home page — you’re probably seen it encourage you to set up Firefox Sync. However, we’ve been working on a complete rewrite of the home page for Firefox 26 (exciting!), and we’re taking the opportunity to replace this with a new customizable banner.

Because this banner is part of our native Java UI, we can’t just load web content the way desktop does. Instead, we decided to build a JS API to let add-ons customize it. We came up with a simple API that lets developers add and remove items from a set of messages that rotates through this banner. Right now, these messages just consist of an icon, some text, and a click handler. We put this banner API in a new Home.jsm module, since we have plans to add more home page customization APIs to this module in the future!

As a demo, I made an add-on that fetches data from a basic snippets server, and turns that data into messages that are added to the home banner. This server currently serves data from the 5 most recent @FennecNightly tweets, which is actually pretty relevant to Nightly users. If you’re using Nightly, I’d encourage you to try it out, and as always, please file any bugs you find!

September 27, 2013 01:05 AM

September 17, 2013

Margaret Leibovic (margaret)

Reader Mode Improvements in Firefox 24

Firefox 24 was released today! Along with a lot of other great features, this release includes a bunch of improvements to Reader Mode. The most noticeable improvements are a polished options menu and a “Night Mode” that automatically changes the background/text colors depending on ambient light levels. However, many other small bugs were fixed in the process, increasing the quality of this feature.

I’m making this post because I want to highlight that over half of the bugs fixed for these Reader Mode improvements were fixed by volunteers! I want to thank the 7 volunteers who fixed these 12 Reader Mode bugs. You all rock!

September 17, 2013 09:10 PM

September 03, 2013

Justin Dolske (dolske)

Mozilla office history

If you don’t live in the San Francisco Bay area, you may not be aware that the culmination of a major infrastructure project is underway this holiday weekend. The Bay Bridge, one of 5 major Bay-area bridges, is in the middle of a 5 1/2 day closure as it’s transitioned over to its replacement. (The other 4 major bridges, in case you’re wondering, are the
Richmond–San Rafael Bridge, the San Mateo Bridge, the Dumbarton Bridge, aaaand… hmmm… oh, right, the Golden Gate bridge)

The Bay Bridge was originally built in the 1930s, and after the Loma Prieta earthquake in 1989 it became clear it needed to be replaced. One of the flashbulb memories many people have of the quake — in addition to it interrupting the ’89 World Series and the collapse of the double-decker Cypress Street Viaduct — is the failure of a span on the Bay Bridge, with cars driving over it. Since then, the western half of the Bay Bridge has been retrofitted to be earthquake-safe, but the eastern span of the bridge has taken longer to completely replace. This weekend’s work is to transition the connection points, so that tomorrow people will be driving over a completely new bridge that’s been 11 years and $6.4 billion in the making!

(I’m getting to the part where Mozilla ties into this.)

Last Friday @BurritoJustice tweeted a link to a slideshow that dove into the engineering history of the Bay Bridge, complete with photos taken during the construction.

It’s some fantastic engineering porn, and I spent my lunch reading through all of it. I happened to notice that the building in the background of one of the photos looked familiar…

Mozilla’s San Francisco office, in the historic Hills Brothers Coffee building at 2 Harrison Street, is literally next-door to where the western span of the Bay Bridge lands in S.F. It makes for some really great views of the bridge from our top-floor patio:

As well as a first-row seat beneath the giant “HILLS BROS COFFEE” sign atop the building.

It’s this sign that made it easy to spot our building in the engineering history slideshow. The building was constructed in 1926, and the Bay Bridge wasn’t built until 1933-1936, so I was curious to see if the sign was visible in other contemporaneous photos. I started digging though some online resources, and got lucky right away by finding a highres version of that picture at the Library Of Congress:

I skimmed through the other 415 photos in this collection and another 1160 from UC Berkeley (So You Don’t Have To™), and found some other nice shots with the Hills Coffee sign peeking out from the background:






So there you have it. Pics of the Mozilla San Francisco office from both ends of an 80 year span of history.

September 03, 2013 01:58 AM

August 21, 2013

Justin Dolske (dolske)

On Firefox’s Password Manager

It’s been a while since I last blogged about Firefox’s password manager. No big deal, it really hasn’t fundamentally changed since since I rewrote it 6 years ago for Firefox 3.0. Well, ok, the storage backend did switch to SQLite, but that’s mostly invisible to users. There’s a noteworthy change coming soon (see next post!), but I figured that would be easier to explain if I first talked about how things currently work. Which I’ve been meaning to do for a long time, ahem.

The first thing you should know is that there is no standard or specification for how login pages work! The browser isn’t involved with the login process, other than to do generic things like loading pages and running javascript. So we basically have to guess about what’s going on in order to fill or save a username/password, and sometimes sites can do things that break this guesswork. I’m actually surprised I don’t get questions about this more often.

So let’s talk about how two of the main functions work — filling in known logins, and saving new logins.

Filling in a known login

The overall process for filling in an existing stored login is simple and brutish.

  1. Use the chrome docloader service and nsIWebProgress to learn when we start loading a new page.
  2. Add a DOMContentLoaded event listener to learn when that page has mostly loaded.
  3. When that event fires…
    1. Check to see if there are any logins stored for this site. If not, we’re done.
    2. Loop through each form element on the page…
      1. Is there an <input type=password> in the form? If not, skip form.
      2. Check to see if any known logins match the particular conditions of this form. If not, skip form.
      3. Check to see if various other conditions prevent us from using the login in this form.
      4. Fill in the username and/or password. Great success!

Phew! But it’s the details of looking at a form where things get complex.

To start with, where do the username and password go? The password is fairly obvious, because we can look for the password-specific input type. (What if there’s more than one? Then we ignore everything after the first.) There’s no unique “username” type, instead we just look for the first regular input field before the password field. At least, that was before HTML5 added more input types. Now we also allow types that could be plausibly be usernames, like <input type=email> (but not types like <input type=color>). Note that this all relies on the order of fields in the DOM — we can’t detect cases where a username is intended to go after the password (thankfully I’ve never seen anyone do this), or cases where other text inputs are inserted between the actual username field and the password (perhaps with a table or CSS to adjust visual ordering).

And then there’s the quirks of the fields themselves. If your username is “alice”, what should happen if the username field already has “bob” filled in? (We don’t change it or fill the password.) Or, more common and depressing, what if the username field already contains “Enter your sign in name here”? In Mongolian? (We treat it like “bob”.) What if the page has <input maxlength=8> but your username is “billvonweiterheimerschmidt”? (We avoid filling anything the user couldn’t have typed.)

And then there’s the quirks of the saved logins. What if the username field already has “ALICE” instead of “alice”? (We ignore case when filling, it’s a little trickier when saving.) Is there a difference between <input name=user> and <input name=login>? (Nope, we stopped using the fieldname in Firefox 3 because it was being used inconsistently, even within a site.) What about a site has both a username+password _and_ a separate password-like PIN? (Surprisingly, we were able to make that work! Depending on the presence of a username field, we prefer one login or the other.)

And then. And then and then and then. Like I said, there’s no spec, and sometimes a site’s usage can break the guesses we make.

Saving a new/changed login

In comparison, the process for saving a login is simpler.

  1. Watch for any form submissions (via a chrome earlyformsubmit observer)
  2. Given a form submission, is there a password field in it? If not, we’re done.
  3. Determine the username and password from the form, and compare with existing logins…
    • If username is new, ask if user wants to save this new login
    • If username exists but the password is different, ask if user wants to change the saved password
    • If username and password are already saved, there’s nothing else to do.

Of course, there are still a number of complicating details!

This whole process is initiated by a form submission. If a site doesn’t actually submit a form (via form.submit() or <button type=submit>), but just runs some JavaScript to process the login, the password manager won’t see it. And thus can’t offer to save a new/changed login for the user. (Note that this is easy for a site to work around — do your work in the form’s onsubmit, but return |false| to cancel the submission).

Oh, and there’s still the same question as before — how to determine which fields are the username and password? We reuse the same algorithm as when filling a page, for consistency. But there are a few wrinkles. The form might be changing a password, so there could be up to 3 relevant password fields (for the cases of: just a new password, old and new passwords, and old + new + confirm.). And the password fields could be in any order! (Surprisingly, again, this works.) The most common problem I’ve seen is an account signup page with other form fields between the username and password, such as “choose a user name, enter your shipping address, set a password”. The password manager will guess wrong and think your zipcode is your username.

Oh, and somewhere in all this I should mention how differences in URLs can prevent filling in a login (or result in saving a seemingly-duplicate login). Clearly google.com and yahoo.com logins should be separate. But we also match on protocol, so that a https://site.com login will not be filled in on http://site.com. And what about www.foo.com and foo.com or accounts.foo.com? (We treat them separately.) What about mail.mozilla.com and people.mozilla.com? (Also separate.) What you might not realize is that we also use the form’s action URL (i.e., where the form is submitted to), ever since bug 360493. While this prevented sending your myspace.com password to evilhacker.com, it also breaks things when a site uses slightly different URLs in various login pages, or later changes where their login forms submit to.

Oh, bother.

All the gory details

This is one of the benefits of being Open Source. If you want to see alllll the gory details of how the Firefox password manager works, you can look at the source code. See http://mxr.mozilla.org/mozilla-central/source/toolkit/components/passwordmgr/. In particular, LoginManagerContent.jsm contains the code implementing the stuff discussed in this post, with the main entry points being onContentLoaded() and onFormSubmit().

Finally (!), I’ll mention that the Firefox password manager has some built in logging to help with debugging problems. If you find it not working in some particular case, you can enable the logging and it will often make the problem clear — or at least clearer to a developer when you file a bug!

August 21, 2013 12:54 AM

August 13, 2013

Johnathan Nightingale (johnath)

Three and a Half

Lily eating a pearWell, Lil, I have some news for you: I think you’re an introvert.

I don’t want to box you in, and anyhow it’s more of a continuum than a yes/no, but I see things I recognize. The way you play for an hour by yourself without any outside stimulation. The way you stand at the edge of a group of kids at the park, watching them and trying to figure them out. You come by it honestly, but it still makes my heart hurt a bit. Not because I disapprove; far from it. Introverts are some of my very favourite people, and also pretty in vogue among the techie, cerebral, introspective types I tend to run with. But introversion is tricky. You’ll pick up labels like “shy” and “awkward” and you’ll either take those in as parts of your identity or you’ll rebel against them. Or maybe you won’t. Maybe you’ll be a perfectly well-adjusted human. It is a pretty consistent folly of your dad’s to extrapolate from today to your entire future life. It’s probably silly and I probably shouldn’t, but I do. And sometimes it makes my heart hurt.

Speaking of extrapolation, I’ve been thinking about who, what, and where you’ll be when you read these. I imagine you in your 20s. I don’t know why. I don’t know how I expect to keep them secret from you that long. But I think of you reading them in your 20s, all of them in a sitting, and I wonder what you’ll want to know about being three and a half. You like pears and corn on the cob and sausages with mustard. You love the beach. You’re in circus school on Sunday mornings. You find the word “toots” hilarious. Your youtube favourites are vihart’s math videos, and goats yelling like humans.

That will change. You change quickly now. You went away to California for a few weeks to visit some friends and you came back a different kid. It made me feel protective for a minute. Like I didn’t want you influenced by the outside world. Which is stupid, because those influences are wonderful kids, but also because your life is going to be full of other influences and the last thing I would want to do is stop it. But parenthood is a conservative force – we love you the way you are, and we resist change that we didn’t initiate. Forgive me that, if it happens again when you’re old enough to notice. It’s not a rational response; it’s a reflex. Parental lizard brain.

The world will be different, too. Right now, we — the collective we — worry about some things. We worry about the planet – we think we’re heating it up and we think that’s going to cause big problems. We’re spending a frustrating lot of time debating the evidence and agreeing with each other, but we also have lots of excellent people trying to make it better. We worry about humanity – it’s getting easier for one angry person to hurt a lot of people, and the fear of that is pushing governments into reactions straight out of science fiction: armed drone patrols, global mass surveillance. I don’t talk about this much with the three and a half year old you, but I want the adult you to know that we see these things happening, and we’re not sure how to fix them, but we’ll try. I have hope that we’ll succeed.

Right now, that’s not your biggest concern, though. And that’s fine. Right now your biggest concerns are whether there is ice cream at the beach (there is), and whether tonight is a hair-washing night (it is), and whether I will read you one more story (I will). Thank you for adding so much silly to my life. Thank you for asking “why?” about everything. Thank you for sneaking quietly into the bedroom on Saturday morning, staring at me inches from my face until I startle awake, and then announcing that it’s time for pancakes.

I love you, Lil, and I love the person you’re becoming.

Daddy

 

August 13, 2013 01:27 PM

August 07, 2013

Margaret Leibovic (margaret)

Increasing Volunteer Participation on the Firefox for Android Team

Over the past year, the Firefox for Android team has really seen increased volunteer participation. It’s been amazing to see our community grow, and I want to share some of the strategies we’ve been using to engage volunteers.

1. Make it easy to get started. We maintain a "Get Involved" page with links to a bunch of resources to help newcomers get started, including clear and up-to-date build instructions. We also share some guidelines for how exactly to get started, including things like making sure you have a build environment set up before trying to dive into a bug, and how to reach out to us when you need help.

2. Be available to help. Our team is always on IRC, and we’re quick to answer questions. We also make an effort to respond to Bugzilla comments/requests in a timely fashion, especially if we see it’s someone’s first bug. Helping newcomers can require patience, but being responsive is a really important part of keeping volunteers engaged.

3. Create contribution opportunities. We mark bugs as mentor bugs as often as we can. In addition to simple “good first bugs”, we also try to mark more challenging bugs as mentor opportunities. The key with that is to set clear expectations about how challenging we expect the bug to be, and redirect newcomers to easier bugs if they find themselves in one that’s too hard.

4. Recognize contributors. We made a "Friends of the Mobile Team" section of our weekly meeting notes, where we call out volunteer contributions that were made over the past week. We recently created a badge that we award to anyone who appears in this section (people love badges!) and we also try to publicize important contributions with our @FennecNightly Twitter account.

5. Develop a culture of mentorship. This last point is a bit harder to act on, but it’s the most important. A big part of why we have more (and stronger) volunteer contributors is that we’ve taken the time to mentor them. On our team, most developers have mentored at least one bug (if not many), and make an effort to mark bugs as mentor bugs whenever they can. We also make a big effort to remain patient and friendly, and I think that attitude has spread through our community. One of the greatest rewards of developing this culture is seeing new contributors evolve into mentors themselves. It is an amazing feeling to watch some of the volunteers I mentored helping newcomers write their first patches, and do so with so much kindness and patience.

I’ve been having lots of fun bringing new people into our team, and I’d love to help other teams at Mozilla do the same. Please reach out to me if you have any questions, or share any other tips I may have omitted in the comments below!

August 07, 2013 12:25 AM

July 18, 2013

Gavin Sharp (gavin)

changes to the list of Firefox reviewers

I’ve made a few updates to the list of Firefox reviewers:

Please join me in welcoming the new reviewers – send patch review requests their way! :)

July 18, 2013 10:26 PM

July 17, 2013

Gavin Sharp (gavin)

measuring Firefox responsiveness improvements with jydoop

One of the other cool things that came out of the Firefox Desktop work week that I mentioned in my previous post was increased exposure to a handy tool written by taras and bsmedberg: jydoop. Benjamin has a post explaining what it is and how it works, but I wanted to describe one specific use: measuring main-thread responsiveness issues in the wild.

First, a bit of backstory!

One of my team’s overarching goals for a long time has been eliminating all sources of main-thread file I/O.[1] One of the worst main-thread I/O offenders in Firefox code is our SQLite Storage API. A few years ago we went a bit overboard using a version of this API that is synchronous, and does its file I/O work on the main thread. So recently we’ve been focused a lot on eliminating all users of that API.

One consumer of this API that we fixed in Firefox 23 is the Form History code (responsible for remembering information entered into web forms and offering to re-fill it). Neil Deakin, markh and mak worked together to fix the core service (based on earlier work from a previous Mozilla intern, Felix), but after landing that improvement, taras noticed that there were still some remaining issues. We eventually determined that the likely primary culprit for the remaining Form History main-thread I/O was Firefox Sync’s use of the older Form History API. markh and rnewman worked together to fix Sync, but we weren’t entirely sure whether that was sufficient to eliminate all of the main thread I/O we were seeing reported by telemetry.

Now, to the jydoop part

Taras had identified that our initial Form History fix wasn’t complete using the SlowSQL telemetry dashboard. This gives a high-level overview of slow SQL statements occurring in the wild, and he noticed that after we landed the original fix for form history, some formhistory.sqlite statements were still showing up. Unfortunately, the SlowSQL dashboard only offers two time ranges: previous week, and the previous month, and it aggregates data across all builds from a specific channel (e.g. “nightly”), which means that I couldn’t easily use it to confirm whether our Sync fix was effective.

That’s where jydoop came into the picture. It allows much more sophisticated analysis of the SlowSQL data. I wrote a couple of jydoop scripts: one to summarize the slowSQL reports for formhistory.sqlite from builds before the Sync fix (i.e. Nightly builds with a build ID < 20130623) and another to do the same for builds containing the fix. I then ran those scripts against Telemetry reports from the period from 2013-06-21 to 2013-06-24 (inclusive, i.e. roughly two days on either side of the landing of the fix).

The results!

The results are pretty conclusive: the reports of slow SQL statements for formhistory.sqlite from builds including the Sync fix were dramatically reduced. The most frequently slow statement from builds before the fix (“COMMIT TRANSACTION”) was responsible for a total of 417 seconds of main-thread unresponsiveness (174993 occurences of slowness at an average of 143ms of “jank” at a time), over that period. The Sync fix prevented that statement (and many other slow statements) from occurring at all, thus removing a significant cause of main-thread responsiveness issues experienced by Firefox users in the wild.

Next steps

If you look at the results in more detail, they reveal that there are still some slow SQL main-thread operations happening on formhistory.sqlite – they’re less frequent and severe, and are tracked by other bugs. I’m going to be using jydoop to gather more data on the improvements my team’s already made, as well as gauge the potential for improvement in areas we’re still working on. I also want others on the team to learn to use jydoop, so that people can make their own measurements to validate the improvements they’re working on.

[1] Main-thread file I/O is a term used to describe trying to read from or write to the disk on the same thread (the “main thread”) as you’re trying to respond to user input (e.g. mouse/key events) and do other things like drawing the UI. Reading from or writing to the disk can take a relatively long time, particularly if you have a slow hard drive, so we want to always do it on a background thread so that those other important responsiveness tasks (responding to input and updating the UI) aren’t affected.

July 17, 2013 06:18 PM

high-level introduction to Firefox front-end code

At the end of June the Firefox desktop team held a Performance-themed work week Toronto, which included representatives from the Performance team as well as some other teams (QA, automation/testing, project management, etc.). During the week a bunch of us got together and held a little “intro to Firefox code” session – partially for the benefit of a new hire on our team (Steven MacLeod), but also partially because it can be fun to share different perspectives on how we understand Firefox. This was a group discussion, but a lot of it involved me giving my perspective on how Firefox front-end code works at a high level, and how it all fits together. We also went off on a few tangents discussing Mozilla development in general.

mconley was kind enough to take some notes from the session on an etherpad (UPDATE: Etherpad is having issues, here’s an alternate link). These could serve as a good base for an MDN article, or perhaps something similar to https://wiki.mozilla.org/Gecko:Overview.

July 17, 2013 12:09 AM

July 16, 2013

Felipe Gomes (felipc)

FISL 14

Firefox, Tux and Gnu at FISL

Two weeks ago, almost the entire Mozilla community in Brazil assembled together in Porto Alegre to attend FISL, the largest free software conference in the country, which brings together about 7000 people every year to talk about every side of open source: communities, business, government, education, etc.

I think the community had its best attendance ever this year. For one thing, it was the largest group: there were about 30 contributors from all over the country who contribute to every area of Mozilla. For another, our participation this year was entirely planned and run by the community, and everyone was working together in sync to make it a success.

Our activities included various talks on the main conference track, an apps hackaton, a Mozilla room, SUMO sprints, and just a lot of engagement with the students and developers at the conference. As expected, interest in Firefox OS was very high, and this brought to us a lot of people who wanted to hear more about the OS, take a look at the devices (we had a few Geeksphones for demonstrations!) and learn how to build apps. With the dedicated Mozilla room we were able to run several “Apps 101″ sessions to get people started on apps and the hackaton (at times back-to-back sessions to keep up with the demand!), and to provide a welcoming place for them to hack on the apps or to get some hands-on help when they needed.

Mozilla Room at FISL

Welcome to the Mozilla Room at FISL 14

In true free software spirit, most of the talks at FISL are live streamed and also recorded, and you can see the full program here. Below are all the talks we had (I think I’ve included them all but apologies if I forgot any).

(p.s.: if you want to see an entertaining explanation of how Persona works I highly recommend you watch François’ presentation at the 11’30″ mark)

The hackaton ran during the conference and finished on Saturday afternoon. We got a total of 7 apps submissions, which are all posted on github, and the winner was announced at the end of Surman’s talk and received a Geeksphone Keon! There were also e-books as prizes for other teams. Big props to Adriano, André Garzia and Morvana for running the hackaton!

Hackaton Prize

With all that, what I have to say is thanks to all the contributors who helped with all our activities. It was great to meet again some of the old-timers and specially nice to meet the newer members of the community to whom I had only known online before. I was very impressed with everyone’s dedication and passion for Mozilla! Attending FISL is always a special experience for me because that’s where I started my true involvement with open source and Mozilla. After meeting Marcio and Fabricio in São Carlos in 2005 and been following things online for a while, I attended my first FISL in 2008 where I gave a presentation about add-ons development and there I met Chofmann, Blizzard, Taras, Mitchell, Mary, and that was a big push for me to start contributing. I’ve been attending the event ever since, and nowadays I often get people asking my story and how they too can get involved and I hope that I can too serve as support and inspiration for the new people joining who wants to participate and grow in the community. Last but not least, a special thanks to Sérgio for being the lead organizer and volunteering an incredible amount of his time in the past N months to make FISL happen this year!

Until FISL 15!


July 16, 2013 09:42 AM

July 02, 2013

Felipe Gomes (felipc)

Firefox Performance Week

Last week, the Firefox front-end team got together in Toronto to discuss various of our ongoing projects, with a special focus on performance-related goals. The performance team also joined us as there are various joint projects between our teams. After the week is over it’s interesting to look back and see what was accomplished during the week and what it opened as guidance for our future work. Here is my personal recap, some of the highlights of what I did and what I saw during the week. In no particular order:

And beyond that there were also various other topics that benefited from having the team all together in one place, specially Social API and Australis. To me personally the week was immensely helpful as a motivator and as a way to get consensus and clarity into our upcoming projects, not to mention the fine chance of directly interacting with the entire team which not often happens as we’re all spread around the around!

As a side note, this blog post was an exercise in itself as one of the outcomes for me from the Summit Assembly meeeting we had at the week before. There’s more on it that needs a separate blog post to explain, but a personal action that I’ve taken from that event is to increase the transparency and involvement with the community about the work I do.


July 02, 2013 06:35 AM

May 21, 2013

Dave Townsend (Mossop)

Six years revisited

Two years ago I blogged about how it had been six years since I wrote my first patch for Firefox. Today I get to say that it’s been six years since I started getting paid to do what I love, working for Mozilla. In that time I’ve moved to a new continent, found a wife (through Mozilla no less!), progressed from coder to module owner to manager, seen good friends leave for other opportunities and others join and watched (dare I say helped?) Mozilla, and the Firefox team in particular, grow from the small group that I joined in 2007 to the large company that will soon surpass 1000 employees.

One of the things I’ve always appreciated about Mozilla is how flexible they can be about where you work. Recently my wife and I decided to move away from the bay area to be closer to family. It was a hard choice to make as it meant leaving a lot of friends behind but one thing that made it easier was knowing that I wouldn’t have to factor work into that choice. Unlike many other companies I know there is no strict requirement that everyone work from the office. True it is encouraged and it sometimes makes sense to require it for some employees, particularly when starting out, but I knew that when it came time to talk to my manager about it he wouldn’t have a problem with me switching to working remote. Of course six years ago when I started I was living in the UK and remained so for my first two years at Mozilla so he had a pretty good idea that I could handle it, and at least this time I’m only separated from the main office by a short distance and no time-zones.

The web has changed a lot in the last six years. Back then we were working on Firefox 3, the first release to contain the awesomebar and a built-in way to download extensions from AMO. Twitter and Facebook had only been generally available for about a year. The ideas for CSS3 and HTML5 were barely written, let alone implemented. If you had told me back then that you’d be able to play a 3D game in your browser with no additional plugins, or watch videos without flash I’d have probably thought they were crazy pipe-dreams. We weren’t even Jitting our JS code back then. Mozilla, along with other browser makers, are continuing to prove that HTML, CSS and JS are winning combinations that we can build on to make the future of the web open, performant and powerful. I can’t wait to see what things will be like in another six years.

May 21, 2013 12:05 AM

May 15, 2013

Dave Townsend (Mossop)

Firefox now ships with the add-on SDK

It’s been a long ride but we can finally say it. This week Firefox 21 shipped and it includes the add-on SDK modules.

We took all the Jetpack APIs and we shipped them in Firefox!What does this mean? Well for users it means two important things:

  1. Smaller add-ons. Since they no longer need to ship the APIs themselves add-ons only have to include the unique code that makes them special. That’s something like a 65% file-size saving for the most popular SDK based add-ons, probably more for simpler add-ons.
  2. Add-ons will stay compatible with Firefox for longer. We can evolve the modules in Firefox that add-ons use so that most of the time when changes happen to Firefox the modules seamlessly shift to keep working. There are still some cases where that might be impossible (when a core feature is dropped from Firefox for example) but hopefully those should be rare.

To take advantage of these benefits add-ons have to be repacked with a recent version of the SDK. We’re working on a plan to do that automatically for existing add-ons where possible but developers who want to get the benefits right now can just repack their add-ons themselves using SDK 1.14 and using cfx xpi --strip-sdk, or using the next release of the SDK, 1.15 which will do that by default.

May 15, 2013 10:31 PM

Margaret Leibovic (margaret)

New Coding Stewards Mailing List

As part of the Grow Mozilla effort, the coding stewards have been working to grow our coding community. Our main focus has been to increase the number of contributions to the core mozilla-central codebase, which includes making it easier for newcomers to get started, as well as keeping existing contributors engaged. Recent work has been focused on things like mentored bugs and recognizing contributors.

We hold open weekly meetings every Wednesday to discuss progress on these goals, but we want to give more developers the opportunity to get involved with this effort, so we created the coding-stewards@mozilla.org mailing list for broader discussion. If you’re interested in growing our coding community, but you might not be interested in another weekly meeting, please join the list!

May 15, 2013 06:18 PM

May 14, 2013

Tim Taubert (ttaubert)

Scotland.JS 2013 in Edinburgh

I got to spend Wednesday through Friday in Edinburgh last week to attend Scotland.JS. Edinburgh is a lovely city and I will definitely return to get to know it better. It has great people, beers, food and even a castle - what could one want more?

I arrived on Wednesday, just in time for the TechMeetup. It took place in the Appleton Tower and had about 70-80 attendees with quite diverse technical backgrounds. I had a very interesting talk to a freelance patent attorney and also met a couple of people I knew from recent conferences and meetups in Berlin. After we were out of free pizza and beers we met most of the Scotland.JS attendees in a pub right next to the Appleton Tower. Cue more beers and tech conversations.

Thursday was the first day of Scotland.JS that started with a great keynote from Jan Lehnardt. The most memorable talk of the day was about Functional Reactive Programming using Bacon.js by Philip Roberts. There of course were a lot more great talks but the possibilities of creating and combining event streams kept my head spinning the most. At the end of the day we again went to a neat pub near the venue and I headed to bed rather early, still a little tired from travel and the day before.

Friday started with a short 20-minute walk through Edinburgh’s old town that I needed to pass on my way to the venue. My favorite talk of the second and last day was held by Dominic Tarr that tought us about the internals of leveldb. I also really enjoyed Mark Boas talking about making audio a first-class citizen of the web - a very entertaining and impressive mix of technologies. A GitHub drinkup in the venue’s own pub was a great way to end the conference - lots of good conversations with Scotland.JS attendees and speakers as well as people from the local tech community and visitors of the Scottish Ruby Conf.

I flew home the very next day and already miss Edinburgh with its neat little alleys and pubs everywhere. The JavaScript community has once again shown its value as a very interesting mix of nice welcoming people coming from so many different technical backgrounds. Like after most conferences I feel a little exhausted and my head is full of ideas for future or current (side-)projects. I will try my best to return next year, it has been a lot of fun!

May 14, 2013 06:00 AM

May 08, 2013

Margaret Leibovic (margaret)

Dominant Favicon Color, Revisited on Android

Almost two years, I experimented with using the dominant color of a favicon to give a small icon a colorful background. And over the past week, I wrote some patches to incorporate this design into Firefox for Android!

image

The simple algorithm I wrote long ago was done in JS with canvas, but to use this in our native Android UI, it’s simplest to just do it in Java. Luckily, we already had a dominant color utility method in the tree, but creating a background and border with different saturation levels was trickier than I thought it would be. To solve this problem, I gave the ImageView a background drawable with a solid white interior and a gray border, then applied a transparent version of the dominant color as a color filter. This worked pretty well once I figured out which PorterDuff mode to use, but it made me appreciate the simplicity of CSS.

When testing with various icons, I found that our dominant color algorithm could use some improvement. Our Java algorithm is different than the one I experimented with in JS mainly because it uses the HSV color model as opposed to RGB. Instead of counting every distinct color, we split the range of hues into different bins and find the bin that holds the most colors. For the winning bin, we compute the average H, S, and V values within that bin, and return that as the dominant color. To make sure we only return colorful colors, we ignore transparent pixels, as well as pixels that are close enough to black or white. This simple algorithm may not be perfect, but it works pretty well for us, especially for small favicons.

As an interesting bit of history, after I blogged about my dominant color experiment, Mardak wrote an add-on that used an improved version of my JS snippet. At the time, Wes saw this add-on and incorporated the code into XUL Fennec to create icons for homescreen shortcuts. During the Fennec Native rewrite, Wes reimplemented this feature in Java, and that’s the code I found myself in last week. And for those interested in a more robust solution implemented in JS, there’s actually a toolkit service that does this now.

May 08, 2013 06:37 PM

May 06, 2013

Tim Taubert (ttaubert)

Working with infinite sequences in JavaScript

JavaScript comes with most of the little functional tools you need to work on finite sequences that are usually implemented using Arrays. Array.prototype includes a number of methods like map() and filter() that apply a given function to all items of the Array and return the resulting new Array.

[1, 2, 3].map(x => x + 1); // result: [2, 3, 4];

These tools however are not a good fit for infinite sequences as they always consume the whole sequence at once to return a new one. Implementing infinite sequences by yourself means you would have to come up with your own API that clients need to adhere to. You often would keep state variables whose values need to be maintained for the duration of the computation process.

Generators to the rescue

Using ES6 generators implementing the infinite sequence of all natural numbers turns out to be a trivial task. We even have language support to iterate over them.

function* nat() {
  let i = 1;
  while (true) {
    yield i++;
  }
}

for (let num of nat()) {
  print(num);
}

// prints 1 2 3 4 ...

Now that we have a first infinite set we need a couple of functions that help us working with, combining, and building new sequences.

Mapping

Let us start with map() - a function at the very heart of functional programming. It builds a new sequence by applying a function to all elements of a given sequence.

function* map(it, f) {
  for (let x of it) {
    yield f(x);
  }
}

Using the generator implementation of map() we can now easily write a function called squares() that represents the set of squares of all natural numbers (1², 2², 3², …, n²).

function squares() {
  return map(nat(), x => x * x);
}

for (let num of squares()) {
  print(num);
}

// prints 1 4 9 16 ...

As we are using for…of we can also pass an Array to map() to retrieve a new generator with a finite source. The given function is applied to value after value instead of to all values at once when using Array.prototype.map.

let squares = map([1, 2, 3], x => x * x);

for (let num of squares) {
  print(num);
}

// prints 1 4 9

Filtering

Another common task is filtering specific values from a sequence. Our custom implementation of filter() takes an iterator and a predicate - the returned sequence will consist of all items of the original one for which the predicate holds.

function* filter(it, f) {
  for (let x of it) {
    if (f(x)) {
      yield x;
    }
  }
}

We can now use filter() to create the set of all even natural numbers.

function even() {
  return filter(nat(), x => x % 2 === 0);
}

for (let num of even()) {
  print(num);
}

// prints 2 4 6 8 ...

A common derivation from filter() is filterNot() that simply negates the given predicate. We can use that to implement even() as well.

function filterNot(it, f) {
  return filter(it, x => !f(x));
}

function even() {
  return filterNot(nat(), x => x % 2);
}

Mersenne primes

Suppose we were to implement a sequence that represents all Mersenne prime numbers. Mersenne primes are defined as prime numbers of the form Mn = 2n - 1, that is the set of all numbers of the given form that have no positive divisors other than 1 and themselves. The set of Mersenne primes is assumed to be infinite though this remains unproven, yet.

Let us first define some helper functions. range(from, to) and forall() are common helpers in functional programming languages. range() returns the set of natural numbers in a given range. forall() returns whether the given predicate holds for all items in the sequence and should therefore only be used for finite sequences.

function* range(lo, hi) {
  while (lo <= hi) {
    yield lo++;
  }
}

function forall(it, f) {
  for (let x of it) {
    if (!f(x)) {
      return false;
    }
  }

  return true;
}

mersenneNumbers() is the set of all numbers of the form Mn = 2n - 1. isPrime() is a very simple and naive (and slow) primality checker that returns whether the given candidate is divisible by any of the numbers in the range of [2, candidate - 1]. We will use isPrime() as a filter to remove all non-prime numbers from mersenneNumbers().

function mersenneNumbers() {
  return map(nat(), x => Math.pow(2, x + 1) - 1);
}

function mersennePrimes() {
  function isPrime(n) {
    return forall(range(2, n - 1), x => n % x);
  }

  return filter(mersenneNumbers(), isPrime);
}

for (let mprime of mersennePrimes()) {
  print(mprime);
}

// prints 3 7 31 127 ...

Flattening

As a last example we will implement a function that flattens nested sequences.

function* flatten(it) {
  for (let x of it) {
    if (typeof(x["@@iterator"]) == "function") {
      yield* flatten(x);
    } else {
      yield x;
    }
  }
}

Note that using for…of comes in handy again as we can use it to iterate over Arrays and generators. Using flatten() we can now do:

let it = flatten([1, [2, 3], [[4], [5]]]);

for (let num of it) {
  print(num);
}

// prints 1 2 3 4 5

Combining flatten() and map() to flatMap() we can implement another very common function that flattens the result of applying a given function to all items of a sequence. Let us use it to re-build the set of all natural numbers from the set of all even natural numbers.

function flatMap(it, f) {
  return flatten(map(it, f));
}

let it = flatMap(even(), x => [x - 1, x]);

for (let num of it) {
  print(num);
}

// prints 1 2 3 4 ...

Generators are powerful

It is quite obvious that studying ES6 generators really repays. Thanks to Andy Wingo these are available in the latest versions of Firefox and Chrome. They will be in the toolbox of every professional JavaScript developer soon and I am sure we can count on the community to come up with lots of great uses and libraries.

May 06, 2013 10:00 AM

May 03, 2013

Tim Taubert (ttaubert)

Stop. Iteration time!

You have probably already heard of generators and iterators coming to a browser near you. They have been available in Firefox for a long time and are used extensively all over the Mozilla code base. The V8 team will implement iterators and generators once ES6 has been finalized.

This post describes the current implementation in SpiderMonkey and tries to include the current state of the ES6 draft and discussions.

A simple generator

Let us take a look at a simple example of a generator function that represents an infinite sequence containing all the numbers from 0 to Number.MAX_VALUE. Once it reaches MAX_VALUE it will not increase any further but always return the same number.

function myInfiniteGenerator() {
  var i = 0;
  while (true) {
    yield i++;
  }
}

var iter = myInfiniteGenerator();

while (true) {
  console.log(iter.next());
}

Any object of the following shape is an iterator:

{ next: function() -> any }

The next() method simply returns the item next in the sequence.

Finite sequences

As you surely noticed the generator of the first example produces iterators that will never run out of items. The next example shows an iterator representing a finite sequence:

function MyFiniteIterator(max) {
  this.cur = 0;
  this.max = max;
}

MyFiniteIterator.prototype.next = function () {
  if (this.cur < this.max) {
    return this.cur++;
  }

  throw StopIteration;
};

The given code implements a custom iterator without writing a generator function. Note that it throws StopIteration as soon as it reaches the maximum value to signal that the sequence is exhausted. It is a lot more elegant to implement the same sequence using a generator function:

function myFiniteGenerator(max) {
  var i = 0;
  while (i < max) {
    yield i++;
  }
}

Generator functions will automatically throw StopIteration when terminating. So how should one consume iterators with finite sequences?

Consuming sequences

In Java for example, you would check iter.hasNext() and stop when it returns false. In JavaScript however you need to use a try…catch statement to catch StopIteration when it is being thrown.

var iter = myFiniteGenerator(10);

while (true) {
  try {
    console.log(iter.next());
  } catch (e if e === StopIteration) {
    break;
  }
}

You might wonder if there is a better way to do this and indeed there is. Using for…in or for…of you do not have to catch StopIteration yourself, the JavaScript engine will do it for you. As soon as the sequence is exhausted the loop will terminate normally without the exception being propagated:

var iter = myFiniteGenerator(10);

for (var i in iter) {
  console.log(i);
}

StopIteration is special

StopIteration actually is a standard variable that is bound to an object of class StopIteration. It is an ordinary object with no properties of its own and it is not a constructor function.

try {
  throw StopIteration;
} catch (e if e instanceof StopIteration) {
  // This works because:
  StopIteration instanceof StopIteration === true;
}

As StopIteration is a singleton of type StopIteration you can also catch it by checking for equality:

try {
  throw StopIteration;
} catch (e if e === StopIteration) {
  // ... handle exception
}

StopIteration is mutable

You should be aware that StopIteration is a mutable global. Just like undefined it can be modified to hold any other value. If you write a library and want to shield against modifications from outside you can use this neat little trick I found on Dave Herman’s blog:

(function(){try{(function(){true||(yield)})().next()}catch(e){return e}})()

The inner function is a generator that terminates immediately and therefore will throw a StopIteration. The outer function simply catches and returns it.

StopIteration may become a constructor

The current iterator strawman states that StopIteration will become a constructor to maintain compatibility with generator functions returning values.

Iter.prototype.next = function () {
  if (this.cur < this.max) {
    return this.cur++;
  }

  var stop = new StopIteration();
  stop.value = "sequence exhausted";
  throw stop;
};

The equality check from above would not work anymore so it might be better to just use instanceof.

StopIteration may not be part of ES6

The Python way of throwing to denote the end of a sequence is backwards compatible with old ECMAScript versions but there seem to be people not happy with the current proposal. While I can’t tell whether StopIteration is really to be removed a couple of alternative suggestions have been made:

Introduce a keyword to end a frame

To not misuse exceptions for normal control flow ES6 could introduce a stopiteration or endframe keyword that would end the current frame with an optional return value. The obvious downside is that it is probably not backwards compatible.

Iter.prototype.next = function () {
  if (this.cur < this.max) {
    return this.cur++;
  }

  stopiteration [reason];
  // or endframe [reason];
};

Add an iterator.hasNext() method

Just like Java the iterator API could consist of the two methods next() and hasNext(). The client would then need to check hasNext() every time before calling next().

Iter.prototype = {
  hasNext: function () {
    return this.cur < this.max;
  },

  next: function () {
    if (this.hasNext()) {
      return this.cur++;
    }

    throw new Error("sequence exhausted");
  }
};

Let next() always return an object

Custom iterators would be required to implement a single method but would not need to throw. Instead they would return an object with the property done set to true to indicate that the sequence has ended. The value property would be used to store values passed to yield or return in a generator function.

{
  next() -> { done: false , value: any }
          | { done: true[, value: any] }
}

Food for thought

This is in no way a complete list of possibilities or proposals that were brought up on es-discuss so please make up your own mind about the current iterators implementation and the suggested improvements.

The future is bright

Whether or not StopIteration will end up in ES6, generators and iterators are great and you should make sure to be prepared when they become available in modern browsers as well as on Node.js.

I concentrated particularly on StopIteration but there are lots of great posts out there that go way more into depth about generators and their usage. Make sure to also take a look at libraries like Task.js that combines generators with promises to cooperative tasks.

May 03, 2013 04:00 PM

May 02, 2013

Johnathan Nightingale (johnath)

Stargazing

1 year ago, I started a spreadsheet. For 9 months we’d been rewriting Firefox for Android from the ground up, and on May 16, 2012 we released the first beta version to the Android market. I started a spreadsheet to track our star rating. I was nervous.

9 months of rewrite. In web time— in mobile web time— that’s years. Rewrites are almost always the wrong call. You get to throw away bad code, but you throw away good code, too. Hard won, battle-hardened fixes are expensive to throw away, and the code is never cleanly labelled “baby” and “bathwater.” The decision to rewrite Firefox was one of the loudest weeks I’ve had. Even once we’d decided, my hand hovered over the send key for a long time.

3.5 stars. We didn’t pull the old version from the market during the rewrite. We wanted to keep those users safe with regular security updates; that meant keeping the product online. It meant taking black eyes every day from users who tried us, who loved us for our desktop product, and who were disappointed. And because the Android rating system rounds, our already painful 3.7-star rating rounded down to 3.5. We were dead last.

7:1. If you want to maintain a 4.5 star rating, it takes seven 5-star reviews to counteract each 1-star review. Star ratings are deeply flawed for all kinds of reasons: selection bias, survivorship bias, false dilemmas, unidimensionality, reporting bias, et cetera. I know this. And still I watched them. When you try to reach people through an app store, your star rating is the first assessment of your product they’ll see. And when you try to make something great, reviews are real pieces of feedback from real human beings and they are painful and they are frustrating and they are golden.

1181 reviews in the first week. 588 of them were 5-stars. 105 of them were 1-star. I argued with my screen over 1-star comments about bugs we had already fixed. I swooned at 5-star reviews that said they were reversing earlier 1-star reviews.

6 weeks after beta, we pushed to release. By this point beta had climbed to 3.8, which rounds to 4 stars. Fists were pumped. Release sat at 3.6.

Time passed.

200,000 reviews and 6 releases later, this week, today, Firefox and Beta both show 4.5 (rounded) stars in the market and the team is still going strong. I’m immensely proud of the work they’ve done. It’s made me reflective and maybe a bit wordy. I want to have some profound and pithy lesson to separate then and now. Something that I can package up and hand to you. We certainly learned lessons, profound lessons, but in repeating them they sound trite:

Listen. Care about what people think. Be hungry for feedback. Don’t work forward from the tech you have to the product you can build; work backward from the product your users deserve to the tech you’ll need to get there. Ask for help, and accept it even when it hurts to admit that you need it. Don’t throw things away lightly, but be able to throw them away in those rare cases where it’s necessary. Surround yourself with the most excellent people you can find. That one helps a lot.

The haters will say I over-focus on star ratings. There are certainly lots of other good things to measure, and lots of bad things to say about stars. But the stars abide. They are inescapable. They sit front and center in your primary distribution channel. Those five little stars. And I believe they do say something about what we’ve built.

Building good things is hard and my hat is off to anyone who earnestly tries. If the good thing you build reaches people through an app store, I want you to know that I know how you feel. And I’m rooting for you.

[I posted a version of this post on Medium, because it's fun to try new things.]

May 02, 2013 01:57 PM

May 01, 2013

Marco Bonardo (mak)

New download experience post mortem

The new download experience was released along with Firefox 20, just one month ago.

While the rapid release trains provide a very good userbase for testing a feature, it's only at the release time that the "real world" feedback allows to prioritize improvements.
Unfortunately, at that time, there's the concrete risk of a disconnection:

Thanks to the open and transparent nature of the Mozilla project, the feedback is never lost, very often it naturally converts to bugs and discussions. On the other side this disconnection may cause a delay before actionable items are created.

Thus I decided, after the release, to collect the most common feedback about the new download experience and setup a meeting with people involved in its development, to work toghether towards a plan.
I went through bugs, input.mozilla.org, comments to IT articles, Mozilla newsgroups, and forum discussions, extracted the most common topics and put them on the discussion table.

I'd like to point out this is not an exotic behavior at all, persons involved in development do read feedback and are active part of the community, there is also a User Research dedicated team. Though, it is worth writing this tale to clarify that what is sometimes confused with "indifference", is instead the unavoidable challenge of satisfying a large, heterogenous and passionate community.

What came out of that is a very concrete list of things we can do. Please forgive me if I don't go too much into details for each item, I'm still in the process of adding required information to bugs. Also notice many more suggestions were evaluated, this is a filtered list.

Priority improvements:

Backend improvements:

Minor changes:

Now, to the bad news: we are low on resources.  Clearly everyone has many projects to follow, we'll try to dedicate available time to these changes, but we'd like having some help from the community.
So, if you are able in javascript, xul and css, your help will be very welcome.  I've added a status near each item, indicating the current needs, those having [code] are already well defined and can be worked on, the others will be defined in the next days.

May 01, 2013 12:00 AM

April 23, 2013

Felipe Gomes (felipc)

Details about some of our Google Summer of Code projects

The Google Summer of Code 2013 project is about to get started: today the application submission period officially starts (and is open until May 3). Mozilla is again a participating org, and students can find a list of project ideas and application advice in our Summer of Code wiki page. It’s important to remember that the list on the wiki is for possible ideas, but students are not limited to those on the list: project proposals with your own ideas are also welcome. With this disclaimer in mind, I’d like to describe in a bit more details some of the projects that we from the Firefox team have included on the list, and to answer some of the more frequent questions that we have received through e-mail and IRC about them. If you’re a student interested in one of those, read on. I wrote a blog post for each of them:

To make a good proposal, it’s important to keep in mind the goals and non-goals of the project, to demonstrate that you’ve understood how to approach the implementation of the project, and that you’re capable of doing so. It’s also important to create a solid schedule of deliverables that are used both to guide the steps of the project and to validate the pace and the progress up until that point. I’ve already written enough about the specifics and there’s a lot of content out there explaining what makes a good candidate and a good proposal, so i’ll keep this post brief.

Just as a last note, if you’ve sent us e-mail or pinged us on IRC, please be patient because we’re not online all the time or available to immediately reply, and so far we have seen a lot of interest in GSoC, so it takes us a while to reply to everyone’s emails. We hope that these blog posts will help more students to clarify some common questions about our proposals. Good luck to everyone, and remember that you’re always welcome to contribute to Mozilla, during the Summer of Code and every other season too :D


April 23, 2013 02:17 AM

Summer of Code project – about:memory for real people

This entry is part of a series of posts about some of our proposed GSoC projects. See here the introduction blog post.

about:memory for real people

What is it: about:memory is a tool that is used by Firefox developers to diagnose and understand the memory usage behaviors of the browsers. It has been immensely useful for us to find bugs in the MemShrink project and validate the fixes to those bugs. However, it is too focused on Firefox’s internals for the browser developers, but the available data there could be presented in different ways to also help web developers and regular users who wants to understand how each website consumes memory.

Example use case: User opens the new about:memory and sees that website A (tab 1) is taking 15mb and website B (tab 2) is taking 12mb. After 30min, the user opens the tool again, now to see website A still taking 17mb and website B taking now 30mb. They then can conclude that website B is consuming more memory as time passes, while website A is able to maintain its memory requirements steady.

What does it involve:

Non-goals: This project will not remove the existing about:memory, but will create a new one. Also, you should not try to create your own graphics library as part of the project, as there’s not enough time available to do both things during the official schedule.

Where to start: You should start by looking into the current about:memory and its code and to understand how data is retrieved from the memory measurements code. You then need to analyze the available data to undestand its meaning and start thinking on how you want to present that in a more visually interactive way. The usage of the Add-on SDK will also be required but will be very limited to packaging and setting up the add-on, as the main code will be a simple html page that implements your new about:memory (along with its supporting CSS and JS files).

Skills needed: JavaScript and CSS skills, and experience with data visualization. Experience with one JS graphics library would be great.

What is expected in your project proposal: A great understanding of the project, its goals and non-goals, and a good idea on how to approach each of the features involved and how to time slice them. A proposal for at least 4 different ways to visualize the data, describing what type of graphs will be used and the possible interactions that it will provide. The selection of the graphics library to be used. Links to open-source code (e.g. a github profile) that you have produced (specially ones involving data visualization).


April 23, 2013 02:17 AM

April 05, 2013

Margaret Leibovic (margaret)

Building the Firefox for Android Community

Last week I attended a community building meetup in Toronto, where I had the opportunity to meet with individuals who are driving volunteer participation across different areas of the Mozilla project. Together we discussed the things our teams are doing to engage volunteers, and we brainstormed ways that we can continue to grow Mozilla. These discussions gave me lots of ideas about what we can do to grow our Firefox for Android community, but most of them boiled down to three main points.

1. Improve communication. The first part of getting involved in a project is figuring out what’s going on. Our team tends to have lots of discussions on IRC and in Bugzilla, which is great if you’re following those channels closely, but it can be hard for a casual observer to keep up. We’re already trying to address this issue with a new mailing list for development discussions, as well as Twitter and Tumblr accounts for more lightweight updates. Mark Finkle just wrote a blog post covering these communication channels in more detail.

2. Diversify opportunities. When newcomers show up, we help them set up a build environment and point them at a list of mentor bugs. This is a great way to get started, but it doesn’t provide a path to becoming a core contributor, or a path toward other types of contributions. I’d like us to encourage more advanced contributions, such as helping debug difficult crashes, or working on bugs that will help us complete a feature we’re targeting for a given release. I also want us to do a better job advertising all the different ways someone can contribute to Firefox for Android, especially testing and support. Our "Get Involved" page mentions some of these opportunities, but there’s probably more we can do.

3. Manage expectations. Even though we do our best to make it easy, writing a patch is hard. New contributors need to remember that it can take a significant amount of effort to get a patch accepted, and core team members need to remember that it takes time for newcomers to develop the knowledge that we often take for granted. We also need to recognize that newcomers are volunteering their time to help improve Firefox, and that mentors are volunteering their time to help grow our community. It’s a lot of work all around, but no one ever said open source software was easy!

April 05, 2013 06:38 PM

March 19, 2013

Dave Townsend (Mossop)

Hacking on Tilt

Tilt, or 3D view as it is known in Firefox, is an awesome visual tool that really lets you see the structure of a webpage. It shows you just how deep your tag hierarchy goes which might give signs of your page being too complex or even help you spot errors in your markup that you wouldn’t otherwise notice. But what if it could do more? What if there were different ways to visualise the same page? What if even web developers could create their own visualisations?

I’ve had this idea knocking around in my head for a while now and the devtools work week was the perfect time to hack on it. Here are some results, click through for larger images:

Normal 3D view

Normal 3D view

Only give depth to links

Only give depth to links

Only give depth to links going off-site

Only give depth to links going off-site

Only give depth to elements that have a different style on hover

Only give depth to elements that have a different style on hover

This is all achieved with some changes to Firefox itself to make Tilt handle more generic visualisations along with an extension that then overrides Tilt’s default visualisation. Because the extension has access to everything Firefox knows about the webpage it can use some interested sources of data about the page, including those not found in the DOM. This one I particularly like, it makes the element’s depth proportional to the number of attached DOM event listeners:

Give depth to elements based on the number of attached event listeners

Give depth to elements based on the number of attached event listeners

Just look at that search box, and what’s up with the two buttons having different height?

The code just calls a JS function to get the height for each element displayed in 3D view. It’s really easy to use DOM functions to highlight different things about the elements and while I think some of the examples I made are interesting I think it will be more interesting to just let web-devs come up with and share their own visualisations. To that end I also demoed using scratchpad to write whatever function you like to control the visualisation. You can see a screencast of it in action.

Something that struck me towards the end of the week is that it could be awesome to pair this up with external sources of data like analytics. What about being able to view your page with links given depth proportional to how often users click them? Seems like an awesome way to really understand where your users are going and maybe why.

I’m hoping to get the changes to Firefox landed soon maybe with an additional patch to properly support extensibility of Tilt, right now the extension works by replacing a function in a JSM which is pretty hacky, but it wouldn’t be difficult to make it nicer than that. After that I’ll be interested to see what visualisation ideas others come up with.

March 19, 2013 01:38 AM

March 18, 2013

Alexander Limi (limi)

Checkboxes that kill your product

(To read this article with its formatting and typography intact, click here)

If I told you that a company is shipping a product to hundreds of millions of users right now, and included in the product are several prominent buttons that will break the product completely if you click them, and possibly lock you out from the Internet — can you guess which product it is?

Sounds like that’s the kind of product that only a large enterprise software company like Oracle or IBM would ship, right? Maybe some of the antivirus extortionware software for Windows? Maybe VPN software?

Well, we have met the enemy, and he is us.* In the currently shipping version, Firefox ships with many options that will render the browser unusable to most people, right in the main settings UI.


How did we get to this point with Firefox? Most of these options exist for historical reasons — whenever there’s a new feature, it often gets a checkbox to turn it off. The other common case is when a feature isn’t obviously useful to everyone, and it’s hard to make an obvious choice about whether to have it enabled by default or not — so we build in a switch. Or sometimes the person implementing it thinks it should have a switch, and nobody stops to ask if it’s a good idea.

I’m not going to retread discussions about this, there are many versions of that article across the web — the main point is that it is usually a failure of design, and a failure to agree on sensible default behaviors. Options are “the cheap way out,” and they usually speak to an inability to agree on what to do in a given situation.

Design by committee often looks like a row of checkboxes.

What I do want to put the focus on, however, is that you have to perform an audit of your product every so often and see how the people using your product have changed, and what kind of functionality that made sense at the time may not make much sense anymore.

Of course, we should start in our own backyard, so here are some obvious examples from Firefox. These are things we need to fix:

Load images automatically

From the Content panel in our settings, try unchecking the box:

Here’s how Google’s front page looks like if you uncheck that box:

That’s right, you can’t even see the text box you’re supposed to type your search into. Congratulations, we just broke the Internet.

Of course, there are legitimate uses for this, from low-bandwidth situations to web development testing, but that’s where our excellent add-ons ecosystem comes to the rescue. Are more than 2% of our users likely to use this setting on a regular basis? Probably not.

Enable JavaScript

More fun from our Content panel, you can turn off JavaScript with a simple click:

Try booking a travel on Hipmunk without JavaScript:

Most sites these days that aren’t just displaying content will fail in interesting & mysterious ways if you don’t have JavaScript enabled. For the general population, Firefox will appear broken.

Fun historical fact: If you disabled JavaScript in Netscape 4, CSS would also stop working — because CSS was applied to the page using… JavaScript.

And yes, I know that some people have reasons (privacy, web development) to turn off JavaScript. There are many add-ons that can help with this — but it’s not something that we should ship to hundreds of millions of users.

Turning off navigation

Firefox is very customizable! In fact, it’s so customizable that we allow you to make the browser unusable with a single click. Try turning off the Navigation Toolbar, for instance:

Good luck trying to find a web site that can help you fix this problem when your son was clicking around the menus in Firefox yesterday, and today your browser has no buttons:

Turning off SSL & TLS

Now we’re getting to the “shooting fish in a barrel” category — there are many fun options in this preference panel:

If you turn off SSL or TLS, Gmail, Google Reader, and other Google services will look like this:

Note that we don’t even tell you that you can turn it back on in the settings. We just tell you that it has been disabled, and that you should “contact the website owners to inform them of this problem.”

Good luck trying to do that when you can’t even see the web site or load your email.

The entire certificate manager

Oh boy, where do we start?

Personally, I feel pretty confident that the number of people that know how any of this works can be narrowed down to the people that work in these companies in the list. At least not too far off.

This entire thing — possibly with the exception of the personal certificate list — needs to be moved out into an add-on for people with interest in managing their own certificates. It’s our job as a browser to keep you safe, we shouldn’t outsource this to individuals.

You probably don’t want your bank to look like this because two days ago, you read an article on the Internet — authored by who-knows — telling you to remove an entry in your certificates “for added safety”:

Also, is that an NSS Internal PKCS #11 module in your pocket, or are you just happy to see me? Do I need to enable my FIPS?

As Privacy Engineer Monica Chew at Mozilla asks, “Is it really worth having a preference panel that benefits fewer than 2% of users overall?” — obvious spoiler alert: The answer is no.

On the flipside, from that same article: how many users have we broken the web for when 1.6% of them may have TLS support turned off, and possibly not be aware of it? Even 1% of a few hundred million isn’t a trivial number of people.

The people that need to do these things should use add-ons, or at the very least an about:config tweak.

Override automatic cache management

Another way to slow down the browser and make Firefox look bad is to give it no disk space to use for caching:

What about computers with very little disk space? Shouldn’t you be able to restrict how much disk space is being used? It turns out, we know that you are low on disk space, and will reduce our usage accordingly. It’s pretty likely that Firefox keeps better track of this than humans do. So let’s make computers do what they’re good at: keeping track of numbers.


So what have we learned? There are a lot of options in our products that are used by very few people, and some of them can have disastrous effects. We’re trying to design software that can be used by everyone — that also means we have to keep them safe and not make it so easy to break a product they rely on every day. None of these are put there with malicious intent — some of them even made sense at the time — but it’s time for us to do some scrubbing and cleaning of the Firefox settings.

What about the product that you are building? Is it time to take a fresh look at what kind of options you include?

Thanks to Frank Yan, Blake Winton, Tony Santos, Monica Chew, Sid Stamm & Madhava Enros for reading drafts of this.

March 18, 2013 02:00 PM

March 08, 2013

Johnathan Nightingale (johnath)

Horseplay

I want to make a point about changing the world, but first we need to talk about the horse head.

For Christmas last year I bought my brother a horse head and, while I was at it, picked one up for the office. It felt like the kind of thing that Mozilla Toronto would enjoy.


Good times.

Between meetings we needed a place to store it; the sad, flat way it sort of collapsed when left on a desk was unsatisfying. So Madhava and I went out in search of a head on which to mount it. Steps from our office is a mannequin supply store, which helped.

I put the horse head on its styrofoam mount and, for giggles, set it up in the window. Facing outwards. Staring at the office in the next building.

For 2 weeks it sat there and I was pretty happy with it. And then something happened. Something wonderful and magical happened. I wasn’t there for it, but lmandel and overholt were.

The other office responded.

They taped a note to the glass.

“What’s with the horse?”

We responded.

“Who you callin’ a horse?”

They responded.

“Why you, of course!”

And so it went. Back and forth.

Stick with me, I’m getting to the world changing.

So last week we bought them their own horse head. And yesterday mconley delivered it to their office. They invited him in. They brought the box over to the window where we could see. They gathered around their window and we gathered around ours. And when they opened it and realised what it was they actually jumped up and down, and applauded, and mouthed “thank you” through the window at us.

In Bowling Alone, Robert Putnam’s utterly definitive work on society and community, he writes that the best predictor of a school’s success is the activity of its PTA, and that the activity level of a PTA can be changed dramatically by one or two committed parents. Derek Sivers’ TED talk is all about the powerful change that happens when one person being silly becomes two people being silly, and cognitive scientists have been talking about the power of allies for 50 years.

The horse head(s) didn’t change the world; I’m not that pompous. But changing the world is hard work and it’s worth getting some practice in. So go start something. And, this is crucial, if you see someone else starting something: play along. Maybe the thing you’re playing with draws a great big crowd and changes the world. Maybe it never amounts to more than an office of strangers 50ft away silently jumping up and down and saying thanks.

It’s not such a terrible downside.

 

UPDATE: The world keeps getting more awesome. Denise from the other office just sent me email saying that the 4th floor office in our building saw their “best day ever” sign, and posted a reply. They don’t even know about the horses. They just wanted to share in the happy.

and tomorrow will be even better (photo credit: denise)

March 08, 2013 02:28 PM

March 05, 2013

Marco Bonardo (mak)

Colorize Windows mach builds

It's often hard to write cross-platform code for console coloring, and for mach there have not been exceptions.  It colorizes build and tests output, so that you can easily scroll and find warnings and failures, but unfortunately only on Unix consoles.

We are not new to this kind of issues in the Windows build environment, and there's a bug filed to properly support that, though, in the meanwhile, we can apply the same trick used with pymake to get colorization on mach.  Kudos to Shawn Wilsher and Justing Dolske for first implementing this idea with pymake, now let's also colorize our mach build!

First of all, you need a version of sed that supports the unbuffered option, download it from the update sed in mozilla-build bug and copy it to the msys/bin folder in your mozilla-build install path.

Then you need a .profile file in your user home folder, for example for me it's C:\Users\Marco\.profile, then just add this code snippet into the .profile file:

mach()
{
  # ANSI colors.
  _black=$(echo -e "\E[30m")
  _red=$(echo -e "\E[31m")
  _green=$(echo -e "\E[32m")
  _yellow=$(echo -e "\E[33m")
  _blue=$(echo -e "\E[34m")
  _magenta=$(echo -e "\E[35m")
  _cyan=$(echo -e "\E[36m")
  _white=$(echo -e "\E[37m")
  _bright=$(echo -e "\E[1m")
  _reset=$(echo -e "\E[0m")

  # Shortcuts for quick styling.
  _time=$_green
  _misc=$_bright$_black
  _info=$_cyan
  _result=$_bright$_green
  _warning=$_bright$_yellow
  _error=$_bright$_red
  _leak=$_bright$_magenta

  ./mach $@ 2>&1 | sed -r -u \
    -e "s/^(.+)(:\swarning|warning:\s)(.+)$/$_warning\1\2\3$_reset/i" \
    -e "s/(leaked\s[0-9]+)(.+)$/$_leak\1\2$_reset/i" \
    -e "s/(adding:?|creating library|generating)(.+)$/\1$_info\2$_reset/i" \
    -e "s/(changing directory to:|processing script file:)(.+)$/\1$_info\2$_reset/i" \
    -e "s/^(\s?\S+\s){1}(processing\s)(\S+)$/\1\2$_info\3$_reset/" \
    -e "s/^(.+)(interrupted|\serror|No rule to make target)(\s.+)$/$_error\1\2\3$_reset/i" \
    -e "s/^(.?)(finished)(.+)$/$_info\1\2\3$_reset/i" \
    -e "s/^(\s?\S+\s+\-*\s?){1}(\S+)$/\1$_misc\2$_reset/" \
    -e "s/(TEST-PASS|result summary:|passed: [1-9]{1}[0-9]*)/$_result\1$_reset/i" \
    -e "s/(TEST-INFO)/$_info\1$_reset/i" \
    -e "s/(TEST-UNEXPECTED-\S+|failed: [1-9]{1}[0-9]*)/$_error\1$_reset/i" \
    -e "s/^(\s?[0-9]+\:[0-9]+\.[0-9]+\s)/$_time\1$_reset/"
}

At this point, just close and reopen the console (fwiw, I use console2 and these steps are just tested there) and you should be able to just execute mach build browser and get this nicer output, instead of a wall of white text:

Colorized mach

You are free to use, modify and adapt the rules and coloring to your needs, if you have improvements you can drop me a mail or ping me on IRC, the latest version is on my wiki page.

March 05, 2013 10:15 PM

February 27, 2013

Tim Taubert (ttaubert)

getUserMedia() part 3: simple motion detection in a live video

Now that you should already know how to build a live green screen and an EyeToy-like mini-game using nothing but plain JavaScript and a modern browser supporting WebRTC, let us move on to another interesting example: simple motion detection in a live video.

The initialization code

To detect motion in a video we need to compare at least two frames. We will use typed arrays to store the lightness data of the previous frames:

function initialize() {
  // ... code to initialize the canvas and video elements ...

  // Prepare buffers to store lightness data.
  for (var i = 0; i < 2; i++) {
    buffers.push(new Uint8Array(width * height));
  }

  // Get the webcam's stream.
  nav.getUserMedia({video: true}, startStream, function () {});
}

We want two frame buffers - a single one results in a heavily flickering motion video but the more frames we store the more motion blur we will see. Two seems like a good value for demonstration purposes.

Illustrating lightness changes

The main draw() function from part 1 did not change except that we now call markLightnessChanges() for every frame. This is also the probably most interesting function of the whole demo:

function markLightnessChanges(data) {
  // Pick the next buffer (round-robin).
  var buffer = buffers[bufidx++ % buffers.length];

  for (var i = 0, j = 0; i < buffer.length; i++, j += 4) {
    // Determine lightness value.
    var current = lightnessValue(data[j], data[j + 1], data[j + 2]);

    // Set color to black.
    data[j] = data[j + 1] = data[j + 2] = 0;

    // Full opacity for changes.
    data[j + 3] = 255 * lightnessHasChanged(i, current);

    // Store current lightness value.
    buffer[i] = current;
  }
}

We determine the lightness value of every pixel in the canvas and compare it to its values in the previously captured frames. If the difference to one of those buffers exceeds a specific threshold the pixel will be black, if not it becomes transparent.

function lightnessHasChanged(index, value) {
  return buffers.some(function (buffer) {
    return Math.abs(value - buffer[index]) >= 15;
  });
}

Blend mode difference

The simple method we use to detect motion is called a blend mode difference. That is a quite fancy word to say: we compare two images (also called layers or frames) by putting them on top of each other and subtracting the bottom from the top layer. In this example we do it for every pixel’s L-value of the HSL color model.

function lightnessValue(r, g, b) {
  return (Math.min(r, g, b) + Math.max(r, g, b)) / 255 * 50;
}

If the current frame is identical to the previous one, the lightness difference will be exactly zero for all pixels. If the frames differ because something in that picture has moved then there is a good chance that lightness values change where motion occured. A small threshold ensures that we ignore noise in the signal.

Demo and screencast

That is all! Take a look at the live demo or watch the screencast below:

You can create some really great demos with this simple technique. Here is a neat one of a xylophone you can play by waving your hands (which unfortunately does not work in Firefox).

Whatever your ideas may be, I encourage you to fiddle around with the small demos I provided in my three getUserMedia() examples so far and let me know if you built something amazing!

February 27, 2013 11:00 AM

February 26, 2013

Gavin Sharp (gavin)

announcing the firefox-dev mailing list

For several years now, the Firefox project’s official development discussion forum has been mozilla.dev.apps.firefox. It has served us well, but I don’t really ever recall it being an optimally useful tool for development discussions.

I think there are a few reasons for this. I think the primary reason is that the list does not have a moderation policy. We don’t have one partially because it is hard to do given the tools we are using (a custom mash-up of NNTP, Google Groups and a mailman mailing list), but also partially because Mozilla discussion forums have just not traditionally had them. Given the size and diversity of the Firefox user base and community, no moderation means that inevitably there are posts from users seeking support, abusive posts from people upset with our decisions, or off-topic/bike shed threads that dragged on forever and didn’t end up anywhere useful. The combination of these results in a mailing list with a low signal-to-noise ratio, that many core Firefox contributors either don’t read at all, don’t follow closely, or need to filter aggressively. That’s a poor situation to be in, and often means that some of our development discussion ends up occurring in other less accessible, less reference-able venues (e.g. on IRC, or in video meetings).

Three years ago, the Thunderbird folks saw many of these same issues with their development forum, and came up with a solution in the form of tb-planning. That list and its policies have succeeded in creating a more productive and useful venue for discussion. So I’d like to try the same experiment for Firefox development.

firefox-dev is a new list whose goal is to offer an easy, transparent venue for getting constructive, Firefox-related development work done. Some members of the Firefox development team have already started using the list to that end. Its moderation policy has been shamelessly stolen from tb-planning. For the moment, it will co-exist with mozilla.dev.apps.firefox. It’s a mailing list only (no NNTP mirroring update: there’s an NNTP read-only mirror provided by gmane), but the archives are also available (read-only) via Google Groups.

If you’re interested in following or contributing to our development discussions, please subscribe to the new list!

February 26, 2013 04:59 PM