Zarro Boogs: Mozilla

Awesome.

Thu, 03 Jul 2008 10:51:54 -0700

The Pencil Project is pretty awesome, and has a ton of potential. This took me two minutes to build.

Linux, your distro, and you!

Thu, 22 May 2008 00:19:02 -0700

Quite some time ago we announced that we would be fully supporting distro Firefox packages, in conjunction with the distributions and their maintainers. This continues to be the case, even though we’re still shipping official builds of our own to make sure everyone on Linux can experience the goodness that is Firefox 3. We’re going to be working on web site changes to help users connect back to their distro package where appropriate.

Much has been made of the issues related to fsync, and this is where the distro connection comes in especially handy. We’ve already received a firm committment from Red Hat/Fedora, Ubuntu, and Novell/OpenSUSE to ship the mitigation patch from the bug, if we do not otherwise need to do an RC2 and thus have a chance to take it in Firefox 3 proper. We’re going to continue to reach out to the rest of the distros shipping Firefox to roll in the patch. This means we can ship sooner, while still ensuring the vast majority of Linux users get the patch. I’d like to thank Alexander Sack, Chris Aillon, and Michael Wolf for being highly responsive to our requests.

Five Years

Fri, 16 May 2008 09:20:18 -0700

Five years ago, I had just left IBM, and was pretty unsure about what I really wanted to do next. I didn’t know whether I wanted to switch my goals back to software development, or stay on the IT track I’d picked before the bubble blew. Firebird 0.6 came out that day, and I found some bugs, so I started poking around Bugzilla. Things sort of snowballed from there, as I got more involved with QA, and later fixing UI bugs. I ended up hacking cookies with dwitte, and front end with Ben and Blake, and I found myself more and more involved and enmeshed with Mozilla.

Its pretty fantastic to look back at those five years, from the uncertainty of the Foundation startup, through the huge buzz around Firefox 1.0 and the launch, the growth and maturity of the organization through the challenges of shipping follow-on releases, all the way up until today, where we expect to ship the first release candidate for Firefox 3. I can say honestly that its the best release we’ve ever done, and I’m excited about getting it to 170 million people as soon as possible.

What’s most interesting to me is that we’ve now grown enough that we’re no longer aiming for It Just Works. We’ve done that already, so now we’re aiming for the holy grail of Does What I Mean. Its a much higher bar, but that’s where we need to go next. We need to do it on mobile, we need to do it on the desktop, and we need to figure out how help people do it everywhere. And that is my new Five Year Plan.

I hope you’ll all come along for the ride.

One last call for credits updates

Mon, 05 May 2008 12:16:31 -0700

Those marked as “yes” for active in Fx3 are going to be the indivuals in the credits for Firefox 3. Please take a look and mail me with suggested changes ASAP. Please don’t comment in the bug, I don’t want anyone put in an awkward position…

As a reminder, the criteria is anyone who made a substantial contribution to shipping Firefox 3, from design and engineering, to critical support people, and marketing/PR. There isn’t a hard line, or a truly objective set of criteria, everything comes down to my discretion as the product owner.

On the care and feeding of Hydras

Wed, 05 Mar 2008 14:45:47 -0800

(No, this isn’t related to DeHydra at all, I make no pretensions to being smart enough to work in that world.)

Shipping software is hard. Shipping any web browser is probably harder than most software. Shipping Firefox might be harder still, built on top of the multi-faceted Gecko platform (is it a web rendering engine? is it an app platform for building thick clients? it’s both, and more!)

A Firefox release always results in a new Gecko version, and that make things much harder, because while we are the primary consumer of Gecko, there is a large and diverse ecosystem of software that relies on Gecko aside from Firefox and even web browsing in general. We’ve spent considerable amounts of effort over the years to build a great app platform that does more than just browse the Web, and beyond obvious Mozilla-built apps like Thunderbird, lots of other apps are out there. And those are just the ones we know about, but there’s lots of anecdotal evidence that there’s a long tail of small apps floating around.

Because of all of this, Gecko enters into the class of software Fred Brooks called a “system software product” in the Mythical Man-Month. It is not sufficient that it perform well in a single task or in a single place, it must perform many tasks, in many unexpected ways, in many places, and must do so reliably. This makes it the hardest class of software to develop (Brooks estimated the cost and complexity of a system software product as nine times that of a purpose-built piece of software). It’s tempting to cut corners here, but the fallout is often painful and/or catastrophic.

The flipside of this, of course, is that there is considerable pressure to continue to crank out releases, to get better platform capabilities to both web and application developers, and to support continued releases of Firefox. As a result, we are often placed in a difficult middle ground between shipping Firefox sooner and building/fixing a better app platform for others. Every tradeoff we make in those cases tends to be unique and needs to be evaluated on its own merits. Sometimes it’s a part of the platform that very few apps use or need, and we can fix it in a point release (1.9.0.x), or even a minor platform release (i.e. a theoretical Gecko 1.9.1) depending on when the fix is needed, since many non-browser apps tend to lag behind Gecko releases and build on stable versions. Other times, we need to not call Gecko done until the platform bustage is resolved, even if it doesn’t affect Firefox, because it will cause severe and ongoing problems for other Gecko consumers. There will never be a canonical “a Gecko release can/cannot regress other consumers” answer, as a result, but drivers will continue to drive as hard as we can to make Gecko a success story for platform consumers. Ultimately the buck stops at drivers’ door, because we own blocking and prioritization, and it is incumbent upon us to make the hard calls.

It isn’t easy, or fun, to try to ship a pair of symbiotic releases with overlapping priorities, but it’s a critical part of our DNA as an organization, and I’m glad that we continue to make the effort to preserve the ecosystem.

Next time: The Joy of Herding Cats.

Visual Refresh and Linux (and you?)

Thu, 11 Oct 2007 08:19:34 -0700

Alex seems to have stirred up some debate regarding visual refresh on Linux. I wanted to talk a little about why its not as big of a priority right now, and longer-term thinking I’ve been doing about Linux.

First off, I think there’s a lot of “Mozilla doesn’t invest anything in Linux” comments which are pretty untrue, both currently and historically. We’ve actually had more people in the project working on integration with Linux since I’ve been around than on Mac or Windows. We’ve had really good native appearance and drawing hooks for GTK2 (Qt doesn’t get much love, but we’ve asked/begged/pleaded for interest, and no one really seems to have it, including the distros that invest time into Firefox). Where we use native look and feel, we are pretty solidly compatible. The current trunk adds native theme form widgets and other goodies, in no small part thanks to the work of Michael Ventnor. There’s a lot of other work that involved significant time spent on Linux, including pango and cairo integration, and we’ve fixed a lot of things that required just as much effort on Linux as on other platforms, so I don’t think its anywhere close to zero, despite some people’s assertions to the contrary.

Second, we’re not going to share much between platforms other than icons between Linux and Windows. We use -moz-appearance for most things, and that works really well, as I’ve noted. There’s some comments suggesting that we’ll look like Vista on Linux, which is really not grounded in fact. In the absence of separate work on a Linux iconset, we’ll likely share the Windows XP icons, since I think that color palette works better with Linux themes, but we’ll be able to do either/or between the two sets once we have them.

Third, designing a universal icon set specifically for all of the distros using GTK2 is a pretty hard challenge (I’d say nearly impossible), and I don’t think there’s any way we’ll really get it right, and there’s some painful discussions about who to target if we really try to target a specific reference distro. A lot of the time it feels like the best we can do with the full icon set is broken clock correctness (actually right a small percentage of the time). We could design a set of icons for one distro’s defaults, but that would look bad on other distros. Ubuntu has a firefox-themes-ubuntu which adds three themes designed to integrate with their distinctive default look and feel. We couldn’t use those themes though, and anything we ship is probably not going to look right on their end.

I’ve wanted to use stock icons as the base for the theme, but there’s definitely gaps where we don’t have obvious icons, and that’s something we never quite figured out when we were experimenting with the Fedora guys a couple of years back (that’s when we added the stock icons to the buttons/dialogs). Its worth looking at again now that we’re raising the bar on Linux library reqs, but there’s still some scary issues about how to fill the gap where stock icons don’t exist for the function you want to expose, without the icon looking totally broken and wrong.

Finally, Stephen Garrity posted about creating a Tango -based theme for Firefox 3 on the newsgroups some months back. There wasn’t a lot of initial interest/activity there, but if you’re interested in helping improve Firefox 3 on Linux, at least for some subset of distros, please check out bug 381206. We’re not saying we don’t want a better icon set on Linux as well, but no one has a clear vision of what the right thing to do is. Hopefully some people can jump in and start making progress there.

Putting a stake in the ground

Fri, 28 Sep 2007 14:11:45 -0700

Performance matters more than ever in the browser space, and even as the Web grows up and gets bigger we need to continue to push harder on getting smaller and faster. New tools and frameworks continue to evolve and provide more fodder for the performance team to chew on, and we’re going to do our part even as we continue to push on innovation in the browser. As a result, the Firefox team is going to put a really big stake in the ground on performance, with the bulk of the focus on cleaning up our own house.

We’re starting with three straightforward goals:

Cut app overhead on pageload by 50% against Firefox 2. Measuring “pure” Gecko performance against total Firefox performance is a hard problem, but one well worth solving. Pageload is the sum of a lot of parts, the more we can fix those parts, the better.
Improve Txul (new window opening) performance by 20% against Firefox 2.
Improve Ts (overall app startup time) performance by 10% against Firefox 2.

These goals feel right, and should be within our reach. There’s a lot of hard work involved between now and these goals, but I believe we have the people and, thanks to the perf team (especially Robert Sayre and his awesome work with dtrace), the tools to start moving faster here.

Into the Endgame

Tue, 18 Sep 2007 11:21:18 -0700

We’re close to shipping Gran Paradiso Alpha 8, and we have a handful of features that still have yet to see the light of day. These will for the most part come into the M9 release, but as we were technically feature frozen we’re going to declare them up front as exceptions.

In no particular order, here are the things we’re still working on, and what we’re getting out of them:

New notification system (aka “door hanger” notifications)
- This is designed to improve upon the longstanding “infobar” UI by moving it mostly out of content, and providing a way to revisit or easily ignore decisions.
Add-ons Manager rework
- This will likely land after M9, but it is well isolated and mostly front end display refactoring. This will bring integration with AMO, unified display of add-ons, and a cleaner interaction model than we have had previously

Remaining Places UI work
- There’s a lot to do here, primarily around making the search and organization tasks easier and more obvious. The link has far more details than I can provide without overwhelming.
Offline Apps
- Dave Camp has been doing some fantastic work on supporting WHATWG-style offline web apps, and we’re ready to hook up UI to allow “installing” webapps and boosting their ability to store data via DOMStorage.
Full page zoom
- One of the biggest unexpected bonuses from one of our interns this past summer, we now have the ability to do full page zoom instead of just text zoom. We expect to make this the primary zoom UI.
Search in the password manager
- This does what you think it does.
Cross Session Resumable Downloads
- Another awesome intern/SoC success story, a big thanks to brahmana (original SoC student), sdwilsh, Mardak, and biesi (MoCo interns this summer). We’ve wanted this for a really long time, and now we’re going to get it.
Places integration for Download Manager
- As we were reworking the new and improved download manager for Firefox 3, it became apparent that integrating downloads into the global history of where you’ve been is a major win, and it will help users to have access to those items via autocomplete and other searches. It also allows us to have a much greater amount of data linked to the download for better searching/sorting.
Error pages for SSL
- It’s been an article of faith for many that SSL dialogs are at best an annoyance, or at worst a giant hole that one can drive a social engineering truck through. This aims to make SSL dialogs that shouldn’t be ignored full on error pages, as many SSL errors are ignorable

One more thing… we’re still working on fixing usability bugs and adding “delight” to the product. Beltzner will have more details on what we’re doing later today.

Remixing Mac

Sat, 23 Jun 2007 19:01:43 -0700

I think its fair to say that many people weren’t 100% happy with the visual refresh on Mac in Firefox 2. We haven’t forgotten about this, so I took 15 minutes and hacked a few pieces of things into a bit of a PoC. Results are below.

This is combining Uno (to achieve the unified look) and Kevin and Steven Horlander’s tabs from Pinstripe. There’s a lot of great work in Pinstripe (notably the tabs, sidebars and findbar) that we’d like to pull into Firefox 3, but I haven’t been able to get a hold of Kevin to find out if he’s cool with this, and what the licensing is like, since the jar lacks any licensing info.

As beltzner noted in last week’s meeting, we’re looking for themers to drive this work, please contact him with recommendations or details if you’re interested and available.

The Joy of Sharing

Wed, 20 Jun 2007 11:54:33 -0700

It started as a question about a stack of paperbacks in the Toronto office. It turned into a discussion of putting together a list of required reading based on the collective wisdom of Mozilla Canada (currently spread between Orillia, Toronto, Ottawa, and Munich!). The discussion quickly overwhelmed any ability to take notes, so I created a Google doc, gave everyone access, and in 20 minutes there were 100+ revisions in the history, and we had the result.

Editing is still going on, but this is what the web can mean. No new software to install, no platform lock-in, just the pure joy of sharing knowledge. You should all try this at home.

More new people!

Sun, 03 Jun 2007 06:31:10 -0700

Welcome to Dave Townsend and Jim Mathies, both of whom will be helping in the final big push to get Firefox 3 finished.

Dave, who many in the community will know as Mossop, has written a number of extensions and fixed a bunch of bugs (and commented in a lot more). He’ll be working first on getting more work around Addons wrapped up for Firefox 3.

Jim joins us by way of Verisign (yes, he wrote the EV Cert extension). He’s primarily a Windows hacker, and will be helping us get better integration on Vista and generally help out with Windows-specific issues as needed.

Please welcome both Dave and Jim!

Raising the Bar on Linux

Thu, 10 May 2007 14:52:24 -0700

I’ve been having discussions with various Linux distro vendors around updating our runtime requirements to newer/more stable versions. We have been building binaries that work across a large range of runtimes and with a fairly aggressive backwards compatibility story. We were still working with Red Hat 8.2 until sometime after Gecko 1.8, IIRC. However, this has resulted in a lot of workarounds and ugly hacks to keep going, especially as we start to use pango and other newer libraries.

As a result, we’ve looked at how other apps interact with distros, and I’ve spoke to Chris Aillon of Red Hat/Fedora, and Alexander Sack of Ubuntu for their opinions. What we’ve come up with, based primarily on Chris and Alexander’s input, is a set of fairly current runtime requirements that we will commit to supporting for Firefox 3. Older distros will be able to have build-time support/workarounds as necessary, but Mozilla will not ship or test builds for older platforms. This is still a proposal, but it seems as if everyone is very much on the same page, so I am hoping to make this final in two weeks’ time. Please direct any feedback to the discussion page on the wiki.
Proposed Runtime Requirements

Firefox and Linux redux (and OpenBSD)

Fri, 04 May 2007 08:45:55 -0700

Part of the behind-the-scenes stuff that people don’t see is the coordination that goes on as part of our trademark approval process. Red Hat and Novell have been working closely with us for quite some time, but other distros have not been as involved. I was very fortunate to work with Alexander Sack of Ubuntu and Martynas Venckus of OpenBSD to get their distros in the same loop. The primary goals are to ensure that all versions of Firefox are of a very high quality and to reduce the overhead involved in shipping distro-specific packages. There will always be distro-specific links and tweaks, but minimal code differences means that testing is less segmented and more globally useful (and Mozilla maintainers can put their time into core work instead of hacking around upstream issues!).

Here’s a quick rundown on progress in the last few months:

Ubuntu

Ubuntu has been shipping with official branding since Ubuntu 6.10, but it took a lot of painstaking work on Alexander’s part to untangle the monolithic Debian patch and turn it into an organized set of patches. In the Firefox 3 timeline we hope to either upstream or render obsolete as many of these patches as possible. The smaller the changeset is, the easier it is to manage, and the more our community testing becomes relevant.

I’m quite excited to be working closer with Ubuntu, we’ve made a lot of progress and will make more on the road to Firefox 3.

OpenBSD

OpenBSD’s patchset has been waiting for quite some time. Martynas was able, through no small amount of patience, and some fortunate timing while I was at FOSDEM, to get everything wrapped up finally, and OpenBSD is now shipping officially branded and approved builds. We’re working on getting most of the port code upstream, since they don’t do anything extra for their own hooks they could get to the point where they’re simply shipping stock builds, which would make everyone’s lives easier.

A huge thanks to both Martynas and Alexander for all of their hard work here, it should make things a lot better for everyone.

Additionally, I’ll be posting later today about some related discussions to raise the bar for runtime requirements for *nix, which should help us do better on Linux going forward.

Firefox code review update

Mon, 02 Apr 2007 19:13:53 -0700

Effective immediately, there are a number of changes in the Firefox review process. Most notably, there are a lot more reviewers who can share the load, including Seth Spitzer who is now a module peer. Dietrich Ayala, Simon Bünzli, Tony Chang, Myk Melez, Robert Sayre, Benjamin Smedberg, and Robert Strong are now officially appropriate reviewers for various sub-modules within the app code (please see the linked document).

Just as importantly, there is now a formal requirement for unit testing. However, much of the window-level testing will depend on bug 375469, so in the meantime we should be making liberal use of in-testsuite? to flag bugs that we have to go back and get tests for. This should be limited to UI-level fixes, components and helper methods should get appropriate tests with the patch. Please talk to me if you have questions about this change, which now officially follows the lead of toolkit.

_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_

The insanity continues

Tue, 13 Feb 2007 20:43:03 -0800

From Saturday’s drive to Toronto:11:13 AM

11:14 AM

11:15 AM

omgsnow

Thu, 08 Feb 2007 08:52:03 -0800

Boy, I don’t blog much lately. Now that I have a BB Pearl to play with, I think I’m going to start blogging more, pictures are fun.

That whole “mild winter” thing we were thinking when even after New Year’s there wasn’t snow…. all gone. This is the most snow I remember at one stretch in a long time. Makes for some fun driving, especially if you didn’t get snow tires because it didn’t really snow for the first two months of winter. And even more especially when you’re driving down this:

For extra fun, I keep brushing off my car, four or more inches of buildup at a time (and I keep forgetting to leave time for this task when heading out to pick up kids etc). Three feet or more since Saturday. The parking lot was fully plowed Tuesday, and this is what the car next to mine looks like now:

Someone asked how people survive winter up here. The answer is drive through coffee.. city of 30000 people, eight Tim Horton’s franchises. And even after 9 AM, when people are supposedly at work already, this is what the line looks like:

Yes, that line goes onto the road, and the building is in behind the KFC at the left. The people brave enough to go inside have overflown the parking lot into the KFC side as well. I would not lie to the humble reader, but on those few occasions where I have arisen in time to see the 7-8 AM lines, there are human lines leading outside filled with people unwilling to idle on busy streets to actually be in the drive through line.
Great place to live, actually.

Firefox and Linux

Mon, 18 Dec 2006 15:58:55 -0800

At the recent Firefox Summit, a group of people led by Chris Aillon (Red Hat), Robert O’Callahan (Novell), and myself met to discuss Firefox on the Linux desktop. Historically, there has been a great deal of tension between mozilla.org and the Linux distros, notably over maintenance of branches, divergence between distros, and lack of sustained communication between the groups. All seemed in agreement that closer cooperation and dividing responsibilities appropriately would benefit everyone involved. A number of changes were proposed that have general consensus among the stakeholders.

It is hoped that the proposed changes will drive a stronger and more balanced partnership among Mozilla contributors, and enable the Linux community to work more closely with the Mozilla community. More importantly, we believe this will drive a bigger focus on creating a better Linux user experience for everyone.

Development

In the Firefox 3 timeline, establish a strong group of maintainers to drive and own Linux-specific development. caillon and roc will likely act as owners here. This is not an exclusionary group, anyone wishing to help in this effort will be able to participate and contribute. This certainly includes other projects that are based on or share code with Firefox (Flock, Iceweasel, etc).
This group will share responsibility for branch policies for Linux-specific code. In particular, they may choose to land Linux integration features on branches.
The vast majority of downstream patches will be pushed upstream and into shared CVS, in order to minimize patch sets to distro-specific packaging/build requirements, with minor exceptions from time to time.

Distribution

Most Firefox Linux users are using builds packaged by their Linux distribution. We will encourage this by having mozilla.com’s download page point to packages from various Linux distributions.
The Mozilla Corporation will continue to provide nightly builds for testing and development, and will make available reference builds for each release in an unsupported form.
By minimizing upstream vs. downstream differences, it should be much easier for Linux distributions to comply with Mozilla trademark requirements. The current situation involves a great deal of overhead per distribution due to the large and diverse patch sets. Therefore the Mozilla Corporation will be able to work with more Linux distributions around branding than we have been able to in the past.

Please direct feedback and discussion to the mozilla.dev.planning newsgroup, or dev-planning@lists.mozilla.org

Update: caillon has blogged about the changes from the Linux side

Collecting feedback

Mon, 18 Dec 2006 15:58:54 -0800

With some early help from Digg and /. the Firefox Brainstorming doc has seen thousands of revisions and has 700+ categories now. That’s great, but its a tad overwhelming to review, and since the hits keep on coming, its becoming a massive effort just to keep up with new suggestions.

Obviously we need to do the best we can for now, but I think there has to be a better way of handling an incoming stream of ideas in such a way that people can both keep up and somewhat organize themselves. There’s been suggestions around using something like Chirpy, and my triage-trained brain could handle a suitably modified Bugzilla, but both of those have shortcomings.

Also, if someone wanted to somehow summarize new ideas as they get added to the various sub-docs, that’d be pretty helpful in the short term.

Barriers to Entry #3

Mon, 18 Dec 2006 15:58:54 -0800

I talked about barriers to entry a couple of times already, and I think that as we start to plan for Firefox 3, we need to make sure that as we try to advance the web, it is critical that we continue to identify and eliminate barriers to entry for users who would otherwise use our products. We need to continue to improve the core features for our existing userbase, and to keep up with the web, but most of the thinking there isn’t solving the barriers question, since by and large we’re innovating in new directions.

Here’s a few that I know are problems already:

Better integration with systemwide settingsIf a user switches to larger fonts and icons in Windows, we should match those increases in the app. We force users to specify and update proxy data, helper apps and passwords separately within the app, where we could use system settings and APIs instead (the last perhaps on Mac only, but for how long?). A lot of this integration can be done, and should be done.

Site compatibilityWe’re doing pretty good, marketshare helps, but we need to be better. We need to push Reporter, and put real time into analysis of the top sites showing up there. Sometimes its our fault and we need to prioritize bugfixing, sometimes its Tech Evangelism (and we need to get back to doing that too).

Firefox lacks feature X from Browser YIt could be a serious shortcoming, or it could be something that should be addressed with extensions. We should make sure we identify these deal-breaking features and ensure that the right solution is in place, and that there are docs in place to point users at the answers they seek.

These are a few, but there are more out there. Please comment here or post to d-a-f with your own!

Barriers to Entry #2

Mon, 18 Dec 2006 15:58:54 -0800

One of the things that’s pretty key about barriers to entry is that each one has a potential veto over users continuing to enjoy and use the app. If multiple barriers exist for a user, each must be addressed in order for the user to continue using the app.

As an example, if you rely on a site that fails in Firefox, AND you sometimes need to read pages that use complex scripts we don’t handle well, AND you have an authenticating NTLM proxy that uses some weird variant on the protocol that we fail on, addressing just two of those still blocks you from using Firefox full time. And eventually, people get sick of running two browsers, and switch back to the one that always works, even if it doesn’t work as well overall.

The big question, and I don’t have an answer to this, is how do we identify all of these, and how do we get a real-world answer on how many potential users these issues are barriers for? Thoughts welcome, as always.

Barriers to Entry #1

Mon, 18 Dec 2006 15:58:54 -0800

Was at my parents’ house last night after trick or treating and “fixed” the resolution in use for their new LCD monitor (was set to 1024×768 instead of 1280×1024, a huge pet peeve for me). I turned on large icons and fonts and rebooted, thinking everything was the same size, and shouldn’t be a problem. Lo and behold, when my dad sat down, he promptly reset the display resolution because “the fonts were too small.” After exercising the tech support “report to reality translation” part of my brain for a while, I discovered that the fonts he was having trouble with were in Firefox (which wasn’t open still), in the content pane (not the desktop icons he was pointing at). Another 25% bump in the Firefox fonts pane and a judicious setting of a minimum font size later, we were in business, and he was finally able to accept that maybe LCDs needed to be run at native resolution.

The moral of the story? Having to remember to set the font sizes in Firefox separately was a barrier to entry for my dad running at native resolution, and other users with those settings already cranked who try Firefox might not find the font prefs, or even figure out that they exist, before they just decide to go back to IE because “I can’t read webpages in Firefox.” In an ideal world we pick up changes to system font sizes and follow the OS lead, but I don’t know how that particular piece of voodoo works. It does strike me, as we move towards higher resolutions in the same physical space (think 1920×1200 on a 15.4″ laptop display) that this is something we need to figure out.

More thoughts on this later.