kaioa.com

It's a trap

I just trashed my history again. Same accident as last time. Was it my fault? Well, herein lies the problem. I pressed a specific key sequence which triggered the delete. However, it's very similar to a key sequence I'm using a dozen times a day. The only difference is the order of one down and one release key event.

But let me explain it a bit first. If you hold the Control key you can jump from one word to the next with the left and right cursor keys. If you also hold Shift you can quickly highlight a couple of words. I often highlight parts of the URL like this in the address bar. Then I press Delete and then I either add something new or press Return right away.

The problem is that I can trigger Firefox's Clear Private Data dialog with Control+Shift+Delete (i.e. if I don't release Control or Shift quickly enough). If I now press Return right away, which isn't all that unusual if you've done it a million times before, it will delete my history (among other things) instantaneously.

Case in Point

Caching is a very hot topic these days. Aggregation of scripts and style sheets, compression, setting Expires and Last-Modified headers. All of that is about improving loading times and reducing the amount of traffic. It's pretty smart stuff and it works pretty well.

There are always two cases to consider: a user with a non-primed cache and a user with a primed cache. If the cache is primed, the user will need to download far less files, because most of it is already cached. Scripts are the same, style sheets are the same, lots (or even all) images are the same, and maybe even the document itself is the same. Well, that's the deal basically.

Yesterday I noticed something odd, however. I visited some page I visited just the day before and all those images were reloaded. I also observed this on a lot of other websites I visit regularly. Of course I checked the headers and everything looked fine. Pretty odd. Especially if you consider that I already ramped up the cache size to 150mb ages ago.

It's not that difficult, is it?

The diagram on the right illustrates how things everywhere are. Everywhere except Firefox, that is. For reasons unknown to me Firefox does the exact opposite of what would have been intuitive. I.e. increase the font size with up and decrease it with down. Firefox, however, does it the other way around.

I'm using Firefox for years and I still mix that up over and over again. Today was the first day I became aware of that though. After failing to increase the font size I stopped reading, looked at the mouse wheel, and wondered why it didn't increase the font size. I moved the mouse wheel up, didn't I?

Since Opera 9.5 started to support :last-child, I changed the markup/styling of the reports generated by my PNG batch processing utility. Finally the markup was down to an absolute minimum. There wasn't even a single extraneous character (except for new lines... for the bare minimum of legibility). I was really happy with the simplicity/elegance and lived happily ever after.

Well, not quite.

Two hours ago I did a checkout and after the tool processed the 2 new/changed files I took a look at the report. Instead of 682 rows there were now 684 rows, which happens to be just enough to trigger the bug on my machine. Firefox doesn't render the page in one go anymore, and whenever it stops elements which happen to be the last element right now get the :last-child rule applied. It stays this way even if the layout changes (e.g. by loading the rest or via JavaScript).

The sprite sheet:

As APNG: (You need Firefox 3 Alpha 7 or newer, if you want to see the animation)

MNG was supported in some nighty builds many moons ago, but it never went into a stable release. The MNG specs are sort of complex and the lib was too big. The growth of the executable couldn't be really justified with this little feature. Especially since most browsers don't support MNG at all and therefore it isn't used anywhere.