For the past year or so, my wife and I have successfully kept all of our calendars (home, work, and kids) in Google calendar. We purchased matching phone computers, and calendering is one of the primary uses we have for the phones apart from actual calling. At work I keep an app tab open in Firefox with my calendar and it all works out pretty well.

I would like to extend our calendar system out to the kids. I want a touchscreen computer which I can mount for the older kids to see upcoming events and also see school information such as library/gym day, packing lunch which we keep in their calendar. I’d also like to be able to write a little app for them to check off their chores in the afternoon, or even leave virtual post-it notes for the family.

I have not yet found a suitable computing device which meets my needs and budget. It seems like somebody could make this kind of device pretty inexpensively because it is always plugged in: you don’t need the expensive battery setup of tablet computers. I can’t seem to find a tablet with a wall mount system, and I fear how quickly they could break something which wasn’t securely mounted.

My first choice would probably be an Android system, but any system that runs webapps and a decent browser would meet my needs. I guess I’m looking for something in the 7-12″ screen size range, and less than $500.

Do my readers have any suggestions?

After Firefox 4, the Mozilla community decided that we needed to be more agile and ship Firefox faster. This “rapid release” process has been absolutely fanstastic for the Mozilla engineering/development community: we have been able to develop more quickly, and the process has made Firefox development a lot less stressful because there will always be another release in 6 weeks. But rapid release has its downsides, and I think we, as a community, should consider whether we are serving the needs of our users.

Much has been said about how the rapid release process is problematic for “enterprise” users, or other situations which use managed deployments and have unusual testing requirements. I know that we are discussing a plan to work with enterprises to provide a longer-term support system for these users.

But even for ordinary “consumer” users, there is still a significant pain point in the rapid release process. Not all extensions are keeping up with rapid release. Traditional Firefox addons are given almost infinite power to modify the application, but with this power comes a price: any change we make has the possibility of breaking an addon.

We are working on many projects to mitigate this problem. The Add-on SDK (Jetpack) gives addon authors a way to write addons against a stable API that we promise will be maintained across versions. And most of the time, even though an extension is actually compatible with a new version, we aren’t sure about this compatibility. We are planning on asking our Aurora/Beta testing audience to help us test addons to mark them compatible by default.

But even with all these mitigation strategies, there are still going to be users who have incompatible addons on each 6-week cycle, either because they are using unusual or custom addons, or because an addon which is critical to that user needs major update work which cannot be completed in a particular release cycle. Users are then given the unfortunate choice of updating Firefox and having important extensions broken, or not updating Firefox and potentially being exposed to security flaws.

We should continue the existing rapid release process: it makes our development practices better, and for a majority of users it gets them the newest and best web features and Firefox performance improvements as quickly as possible. But for users who have a long tail of addons which are updated less frequently, we should complement the rapid release vehicle with a stable release which will contain security fixes but won’t break extensions for a longer period of time. This could be a release vehicle which has updates only on a 6-12 month cadence.

This is definitely not an easy decision; maintaining a stable version will cause pain for our community. The development community will have to do security/stability backports against older code. Our testing community will somehow have to deal with an additional train of releases beyond the existing nightly, aurora, and beta release trains. We will have to deal with pressure to rush a feature into an stable release, or delay the schedule in order to pick up an important feature. Finally, a stable release will be a pain for extension authors themselves, because extensions must provide and maintain versions which are compatible with both the rapid and stable releases.

I fear that we are frustrating our users with extensions, which ought to be one of Firefox’s greatest strengths.

As Mozilla increasingly focused on being the best browser for mobile devices, we will need to focus on battery usage. This is already an issue on laptops, where some browser activities like playing movies can chew through battery very quickly, but it is even more an issue on smaller phone and tablet devices where batteries are smaller and users expect at least a full day of battery life.

The first part of this project will be accurately measuring our power usage under various conditions. As with any software engineering project, you are what you measure! To that end, Mozilla is looking for both volunteers and potential paid employees who are experienced at measuring and tuning power usage on small devices. If you have experience with software or hardware tools for measuring power usage (both is even better), please contact me at benjamin@smedbergs.us, or go ahead and apply for the job.

Mozilla is a great place to work, whether you are working out of one of our offices (Mountain View, San Francisco, Toronto, Paris, London, or Auckland) or working remotely. Especially with a new project such as this one there will be plenty of opportunities to chart your own course, and improve software which is shipped to millions of users.

The system is working. We found a crash bug soon after it was introduced, and saved Firefox users pain and aggravation.

Yesterday, dbaron was looking through data from crash-stats.mozilla.com and found a spike in crashes on nightly builds. Because this was a bug related to delivering stream data to plugins, an area that I rewrote for Firefox 4, dbaron cc’ed me as he filed bug 646839.

The bug immediately triggered alarm bells for me: all of the crash stacks were taking “unusual” paths having to do with multipart streams, or networking code that was being intercepted by JavaScript, probably from an extension. In addition, nothing had changed in the Mozilla code that looked remotely related to the crash. After some data mining, I discovered that the users who were crashing had a beta version of Adblock Plus installed. I immediately cc’ed Wladimir Palant, the ABP maintainer.

It turns out that a new feature in Adblock Plus was eating some error codes, leaving our plugin code in a bad state. This resulted in crashes. And the new version of Adblock Plus was schedule for release to Firefox release users soon! Because of dbaron’s quick discovery, a nightly user base who runs beta versions of extensions, and quick thinking all around, we were able to avert a problem for users of Firefox release builds.

This kind of success story is possible because of many tools and systems which interact, but it is mostly possible because Firefox development is an open community where everyone works together and we don’t hide our flaws. And that’s why I love working on Firefox.

Are you interested in becoming a volunteer contributor to Mozilla? See our contribution center for more information about how you can help with coding, QA, documentation, support, localization, marketing, or other efforts of the Mozilla community. Or do you have the skills and experience to be a Mozilla employee? Contact me, or visit the Mozilla careers site and apply today!

In Firefox 4, tab are “on top” by default. When you are in maximized mode, this also means that the tabs move up into the titlebar. I understand that the UI design team decided to do this to make the tabs easier to click (because of Fitts’ law), but I personally find this behavior annoying, because it means that you cannot use the title bar for its normal tasks. I almost always double-click the titlebar to switch between maximized and regular mode, or drag the window to the side to get half-screen mode.

Fortunately, there is a hidden preference which controls this behavior. You can restore normal title bar behavior in two ways:

• Set the hidden preference “browser.tabs.drawInTitlebar” to false, using about:config
• Install my extension Aero Window Title, which not only changes the default preference for you, but also puts the window title back onto the screen so that you can see the title of the current tab easily.

While I’m talking about it, I’d also like to plug my other new extension, Iconic Firefox Menu, which will turn the orange Firefox menu (on Windows) into a Firefox icon. Together, the two extensions look like this:

Suzanne and I are pleased to (belatedly) announce the birth of Gregory Albert Michael Smedberg, born 23 January A.D. 2011.

Somehow the blog announcement got lost in the shuffle this time!

I just published a privacy policy for smedbergs.us. Since I suspect my policy may be a bit unorthodox, I thought I’d post about it.

I, Benjamin Smedberg, will try to do what I think is appropriate with any information collected by this website. I believe that privacy is a tool which should be used to limit the powerful, not a fundamental right. To the extent that I don’t have much power, I don’t feel the need to provide any guarantee of privacy. Any information, including names, email addresses, and other identifying information, may be shared with others or even made public if I believe that is the correct thing to do.

I may make changes to my beliefs or this policy at any time. Please feel free to contact me if you want to ask questions, or change by beliefs.

I get the feeling that I value privacy differently than most of my Mozilla colleagues. I do not think that privacy is a fundamental right of mankind. Privacy is a tool to keep the powerful in check, by limiting how they may use information they have. To the extent that the government has vast information about and power over its citizens, it should be forced to respect their privacy as a counter to its power. This is the true purpose of the fourth amendment to the U.S. constitution.

I do believe that corporations which have information and power should also be limited, especially as they grow in size and scope. But I think that any proposals which treat privacy as a fundamental right instead of a system of checks and balances are ultimately doomed to failure.