An even more careful fox

Firefox goes to great lengths to preserve the user's work. For the rare cases when it fails, read this.

If I browse for some time, opening a bazillion tabs before the computer crashes, firefox will offer to restore those tabs as soon as I start it again.

If I type some text in a <TEXTAREA/> form before the computer crashes, firefox will restore the text.

But if I type some text in a fancy editor such as WikEd, my changes will be lost. That's because the (HTML representation of the) text I've created was generated by a great many javascript function calls, and firefox doesn't know whether it's safe to simply call those functions again. Thankfully, firefox does remember the resulting (HTML representation of the) text! It's hidden in your profile's sessionstore.bak file.

~/.mozilla/firefox/*.default/sessionstore.bak

The recovery process, however, is a little bit more involved. In the case of WikEd, I searched for the title of the Wiki article I was editing, and found an innerHTML:"..." assignment soon after. That string contained all of the (HTML representation of the) text I had lost, but it was encoded using escaped hexadecimal sequences ("\xE9"), plus other javascript and HTML annoyances. I found that the easiest way to recover the pure ASCII text was to copy the innerHTML string into the following template:

<script>
document.writeln("...");
</script>

Then, I loaded the resulting html file into a separate firefox tab: the hexadecimal sequences were interpreted, and the HTML code was rendered. Copy-pasting the HTML into WikEd lost the HTML formatting but keep the ASCII text, which is exactly what I wanted. My changes were recovered! Thank you, firefox.

Testing Chrome Overlays

Writing a Firefox extension involves writing a so-called "chrome overlay", which is an xml description of the interface changes you wish to make.

I'm in the process of learning how to write overlays. That means I make mistakes. Lots of them. They're completely normal stepping stones in the process of learning, and I'm totally prepared to spend lots of time doing nothing but mistakes. But while I'm doing this, I'd rather not spend lots of time doing non mistake-related tasks. Non-mistakes reduce the number of mistakes I can do in one day, and thus increase the number of days spent learning.

If, in addition, the non mistake-related task is repetitive and impossible to automate, then I'm likely to get angry. I'm really angry against reinstalling in-progress Firefox extensions right now. Or at least I was, before I found a way to avoid doing it.

My solution is to add two new buttons to my bookmarks toolbar: one for the chrome I want to overlay over, and one which applies my overlay over it. Don't click those links, just look at the URLs to understand the trick, and then only if you're also trying to learn overlays. For everybody else, well... just wait a little bit. The extension I'm working on is going to be really interesting.

...if my attention is not caught by something else before I complete it, that is.

Rant against Firefox version checks (and solution)

I'm not particularly fond of Firefox's XUL+js architecture, but I'm more than willing to live with this unusual choice if it allows people to easily write Firefox extensions to customize their experience.

But did you ever notice that most of the plugins break every time you update Firefox? I thought that APIs which change this fast must reflect a development model where refactoring is frequent. I'm glad when teams decide that code quality is more important that backward compatibility, but my enthusiasm doesn't seem to be widely shared.

As a side-note, I think that the developers of the Linux kernel have found a great way to please everyone. They maintain backward compatibility for their external interface, the system calls which all Linux applications use, while allowing themselves to refactor their internal interface at will. This is unfortunately not enough since drivers depend on this internal interface, just like Firefox plugins depend on the browser's internal XUL interface. But instead of requiring driver developers to update their code at every release, the kernel team encourages driver developers to commit their code to the kernel tree and to let the kernel developers update the drivers themselves.

Today, I've upgraded Firefox from version 3 beta 5 to version 3 RC1, and as usual it broke many of my plugins. Now, the shocking part is that there isn't supposed to be any change at all between those two versions! So if the internal API didn't change... Could it be that the plugins were broken by something bogus?

What happened is that Firefox's extension mechanism requires each plugin to specify a range of versions on which it is supposed to work, and they're not supposed to pretend that they work on versions which haven't been released yet. What a bad idea! This means that every single Firefox release will break every single plugin except those that cheat and pretend to know the future. This in turn means that every single plugin needs a maintainer to diligently follow Firefox's release schedule and to bump the range of his plugin every time. How boring! I'd rather have those people working on new extensions.

So in case your favorite plugin's maintainer is too bored to do this, here's how to do it yourself.

First, find the install.rdf file associated with your plugin:

bash grep 'em:name' ~/.mozilla/firefox/*.default/extensions/*/install.rdf output ~/.mozilla/firefox/5edzcuns.default/extensions/{e4a8a97b-f2ed-450b-b12d-ee082ba24781}/install.rdf: em:name="Greasemonkey"

Inside the file, just increase the value of em:maxVersion to your current Firefox version, or to some absurdly large version number if you're bold enough not to fear the future.