This is the first in a series of posts I'm going to write about my work to implement the Mouse Lock API in Mozilla. I've got a number of things to say about the API and the need we have for it in Firefox, and on the web in general; but perhaps just as importantly, I want to start with some discussion of how I'll do the work.
I've had good experiences in the past with documenting my work to add new features to the web. This time I'm going to do something I've never tried before: I'm going to invite my students to do the work with me, and make this implementation work the subject of the second half of my Mozilla Development course at Seneca. When I did the Audio Data API and Joystick API, I worked with a small group of peers and friends. Working with people on projects like this, in highly collaborative and open ways, is my preferred style of development. However, working with a group of students is something different, and there are risks to this approach.
First, the fact that we're adding a new feature to Mozilla means it has to be done well. It isn't good enough to mean well, or to just try our best. In order to see this code land in Mozilla, our work has to be great, pass pass reviews and super reviews, not regress other parts of the browser, have sufficient test coverage, etc. I know from experience that getting there is a lot of work. Second, none of my students have done work like this before. The code is new, the processes are new, the scale is new. A large part of what I'll have to do is bootstrap them into Mozilla development, explaining the guts of our DOM, events, etc code (hint: it isn't fun code!).
Working with a group in this way, where the process is foregrounded in order that those involved might learn as they go, means I have to talk about things that aren't always talked about. For most Mozilla developers, this process is background to the thing that's actually being created. As such, I have to do my best to explain things for which I often lack perfect understanding. People sometimes ask me why I don't film every class I give, and the answer is, in part, that I don't enjoy that level of personal scrutiny. I don't love exposing all the things I don't know, or revealing my own weaknesses. However, I think it's important for me to model what I want my students to do, and dive into something scary in full view of the web. I'm comfortable doing this in the Mozilla community, which I know to be supportive and welcoming of community involvement like ours. I'd ask that you correct me when you see me making mistakes, help me provide answers for questions, and get involved as you are interested and able. Most of our work will be done in the #seneca and #paladin irc channels and on our wiki page.
And now, why the Mouse Lock API?
One of the Mozilla projects I'm involved in this year is Paladin, an umbrella project with the goal of enabling web gaming through the creation of browser and web tools, APIs, and community. I like to play at the edges of what the browser and the web can do, and skate back and forth across that line--it's always moving, so it never gets boring. One of the web's current shortcomings, as far as gaming and 3D tooling is concerned, is the lack of Mouse Lock.
Mouse Lock locks the mouse cursor and events to a single element, and gives users/developers limitless X and Y movement. Just about any first-person-shooter style game you've ever played uses a form of Mouse Lock in order to allow you to tilt and rotate your view 360 degrees. With the current web mouse events, your mouse eventually hits some limit--the edge of the element or the edge of the window. With Mouse Lock it's possible to continue moving beyond the limits of the element/screen.
Two of my fellow Paladin developers, Alan and Alon, first voiced the need for us to take on adding this issue. Alon suggested a simple API and we were ready to dive in when Vincent Scheib suggested another way, using a spec he was implementing in Chrome and WebKit (now hosted at the W3C). The spec looked good to us, and after various discussions with a number of Mozilla module owners and a security review, we're ready to go in Mozilla as well.
So to sum up, I'm going to take a spec authored at Google, a group of students, and hack something into Firefox. I want to show my students that you neither have to be an employee of a particular corporation, nor an enemy of corporations, in order to have an impact on the open web. You can be just some college kid in Toronto and write code that changes the browser for hundreds of millions of users. The web is open, the code is there, and you can make it do new things if you're willing to put your back into it.
Sounds fun, right? I hope so. Here goes.