David Baron's weblog: August 2007

One video driver issue solved (17:36 -0700)

Karl Tomlinson gave me a simple solution to one of my various video driver problems. I used to have the problem that if I started X (usually due to rebooting) without my external monitor connected, I couldn't increase the screen size later (without extensive display corruption that made things unusable). Karl pointed out that if I add a Virtual line giving the maximum dimensions I'll need (in the Display subsection of the Screen section of my /etc/X11/xorg.conf), this problem goes away. I end up with a large virtual display when I start, but it can be quickly resized to the laptop's size if I'm not connected to the external monitor, and I don't need to log out and log in again when I first connect to the external monitor.

hCard autofill? (13:48 -0700)

At the Microformats discussion at BarCampBlock, somebody mentioned a site (I already forget which) that allows auto-filling forms based on the user's profile at certain other sites, when that profile is an hCard (as profiles are at flickr and a number of other sites). It occurred to me that if forms for identity information were marked up as hCards, then the browser could fill in the form appropriately (at the user's request) based on saved information. I'm not sure how much people use microformats to mark up forms for entering data (as opposed to pages that already contain the data), but I don't see any reason they couldn't.

It would be neat if there were a Firefox extension that allowed users to auto-fill forms that were marked up as hCards. (Or maybe there already is, and I don't know about it.)

RLk: 0B (01:14 -0700)

I've been working on memory leaks in Mozilla for a while. Back in 2000, when I first got interested in fixing memory leaks (at least partly thanks to reading some bugs filed by Bruce Mitchener), one of the things I focused on was trying to fix the leak number that showed up on tinderbox. The first bug in that quest was a pretty interesting one, and a number of the other early bugs were real leaks that affected users (including a whole bunch related to form controls). The leak numbers on tinderbox got pretty low, and most of the number shown was due to shutdown leaks: leaks where we allocated an object that was supposed to exist for the lifetime of the application, but then we didn't free it at shutdown. Not a real problem, and only harmful in that it cluttered up the list of objects that weren't freed at shutdown and made it slightly harder to find real leaks.

So I eventually moved on to working on reducing measures of memory leaks that were more relevant to problems that users experience (the amount of memory Firefox uses being large and increasing over time). I eventually added a better leak test to tinderbox and renamed the old one (which only measured leaks of XPCOM objects and certain other logged objects) to RLk. (That improved the measurement of leaks during the test, but we still really need a leak test that exercises more code.)

But recently, sayrer revived an old patch to make XPConnect shut down more cleanly and stop giving false leak reports anytime somebody did anything interesting in a JS component, and bsmedberg fixed some leaks very near main, and the RLk number dropped precipitously close to zero. I debugged the last issue last week (amazingly enough, it was not a shutdown leak, although the only XPCOM object leaked was a singleton). I checked that patch in just now, so now, for the first time, we have a tinderbox showing RLk: 0B for reasons other than the leak test being broken. It's not very important compared to the other memory leak work going on, but it is rather satisfying.