Like many of my colleagues working in education, for whom the next few weeks are busy with grading students’ assignments or exams, I’m currently marking projects from my Mozilla Development course at Seneca. I’ve been rereading student blogs and looking back at bugs, and started to see some common things emerging. I wanted to share some of them.
The majority of my students worked on bugs in Firefox, specifically Gecko bugs related to the media element, DOM events, fullscreen, and pointer lock. Because they were clustered together in similar areas of the code, they were able to help each other quite a bit, and talk with one another about struggles they were having, and celebrate when things got landed. In general they each worked on 4-8 bugs, usually getting half of them landed by the end of the course, and therefore shipping in some future version of Firefox. They ranged from Good-First-Bug type issues right up to full spec implementations, like Pointer Lock.
In no particular order, here are some of the observations I’m seeing again and again in their blogs:
- Writing code to fix a bug is one thing, but getting the tests written, and passing on all platforms, is often much, much harder
- You can’t measure a fix in lines of code (loc). Often a tiny fix can take dozens of hours to do, since you first have to diagnose the problem, figure out where things are going wrong, and plan how to solve it.
- It’s important to learn how and when to ask for help. Trying to go it alone will end in tears and wasted time. A well timed, intelligent question can short circuit your development time significantly
- Similar to the above, it’s easy to not ask for help because you think people will look at you like an idiot for asking such a simple question. In reality that never happens, and people are very helpful.
- It’s not uncommon for a patch to go through a dozen (or two dozen!) versions on its way to shipping in Firefox: fixing a bug is only part of the process. Reviews take time, testing takes time, landings (and backouts!) take time.
- Working on large, complicated code like Mozilla helps keep you humble and aware that you don’t know everything
- Keeping a patch up-to-date with trunk, as it goes through reviews, can be frustrating. Code that used to work, stops working; things you relied on change, or vanish. You have to build in time for this in your development plan.
- Getting things fixed and landed is really about being patient and not giving in too quickly.
- Fixing bugs in Firefox gives confidence to go work on any other code bases
- Until you’ve done this work, you have no idea how easy it is to say, “Why doesn’t Firefox just fix X?” and how hard it is to actually do in practice.
The other thing I’m reading again and again is that people feel a sense of pride, accomplishment, and increased confidence for having worked on Firefox. Those are exactly the kind of outcomes I want in this class, and with this experience. It’s not possible for me to guarantee it, so when it does happen, it’s rewarding to witness.
I’m indebted to many people in the Mozilla community who helped my students find bugs, did reviews and offered feedback on patches, helped late at night on irc, and generally were there to help my students succeed. There are too many names to list, but I want to centre out Olli Pettay, Chris Pearce, and Jared Wein, who really went above and beyond.
This is my 7th year taking undergraduate students into the Mozilla community and having them work on real bugs. It continues to inspire and excite me. I would also say that things have only gotten better within in the community in that time period, in terms of Mozilla’s willingness and preparedness when it comes to welcoming new (student) developers.
I’m looking forward to doing it all over again in September.
Focus and Select: a cross-browser bed time story
Here’s an annoying little DOM’ism that stumped me last week (don’t worry, there’s a happy ending if you keep reading). In Popcorn Maker’s UI I wanted to fix a few places where we have textboxes that contain data from json manifests. When you click on such a pre-populated textbox, it’s nice if the contents of the textbox are selected. And when you click again, it’s nice if the selection is removed and you instead position the cursor.
These are nice enough that one would sort of expect them to just work, and as such, that the DOM would actually allow you to do it. Well, it’s easy to do on Firefox: just add a
focusevent to your input element, and callelement.select(). Done.Now test in WebKit and it doesn’t work. Sniff around the web a bit and you’ll uncover a nasty 4-digit WebKit bug from 2008 that causes
mouseupto undo your selection.“That’s fine,” you say to yourself, “just stop the mouseup event from doing its thing and clearing the selection.” This is what everything on the web I could find said to do. The trouble is, I want to not only select the contents of the textbox on first click, but I want the opposite on subsequent clicks.
In the end, cross-browser compatible code means unnecessarily elaborate code, but here we are. I’ll leave this for the next person who hits my same edge case–aka the default way a textbox should function. Here’s a little jsfiddle demo of it running, and here’s the code:
var selectaBox = (function(){ function __highlight( e ){ var input = e.target; input.select(); input.removeEventListener( "focus", __highlight, false ); } function __ignoreMouseUp( e ){ e.preventDefault(); var input = e.target; input.removeEventListener( "mouseup", __ignoreMouseUp, false ); } function __addListeners( input ){ input.addEventListener( "focus", __highlight, false ); input.addEventListener( "mouseup", __ignoreMouseUp, false ); } return function(){ var input = document.createElement( "input" ); input.type = "text"; input.addEventListener( "blur", function( e ){ __addListeners( e.target ); }, false ); __addListeners( input ); return input; }; }()); var s = selectaBox(); s.value = "This is some text." document.body.appendChild(s);