Whatever vehicle had done the damage was long gone, and the area around was cordoned off with yellow caution tape. Since I like to take pictures of weird stuff, I snapped a photo with my cell phone. (No, I didn’t cross the tape; it’s just not visible in the frame.)

This morning, I stopped at the same post office again. This time, my eye was drawn to a new addition to the facility:

One of these bright yellow posts stood in front of each parking space along the building. You can still see where the concrete has been spread around the base, and absolutely no paint has worn off. Clearly someone decided not to take any more chances with wayward cars!

Of course I tried it again to see if it was a fluke. Same thing. Then I decided to try with another CD. Apparently any audio CD crashes it. Shows how often I use CDs these days.

At least the DVD-RW drive works. IIRC it doesn’t have CD-audio hooked up, but the player seems perfectly happy to just read it digitally.

I guess I’ll have to set aside some time on Sunday to figure out what’s causing the problem. It’s a bit late tonight, and tomorrow’s going to be busy!

• Today’s flashback post: T-Shirt Irony. #
• The Spam Primer has been “completely revamped.” #
• Mars Express Orbiter catches video of moons Phobos and Deimos. #

And then the “fun” started.

• Me: I’m going to focus on project X today!
  Computer needed for project X: I’m going to lock up today!
  Me: Argh! #
• Someone thought it would be a good idea to cover “Wonderful Christmastime?” # (For the record: Shazam says it was Hilary Duff.)
• OK, after 3½ hours stuck at 74%, I think I can assume chkdsk is stalled. *grumble* #
• Ate some blackberries I’d forgotten about from a week ago. Good news: I only threw out 1! Bad news: I should’ve thrown out 2. Blech! #
• Chkdsk round 3 is at 55% on Stage 5 of 5. Going to call it a night & hope my PC runs tomorrow. # (According to Facebook, this posted at 5:55pm!)

I tested it in a couple of browsers, both on my Linux desktop and on the Mac laptop, and planned to test it on the Windows desktop when Katie was done with it. But then something weird started happening.

Firefox started crashing. Repeatedly. Not quite predictably, but only when that test page was open.

I figured maybe it was a corrupted font, so I removed one, then the other, then both. If the page tried to download an embedded font, Firefox would eventually crash. If not, it was rock solid.

This seemed kind of bizarre for such a high-profile new feature to cause consistent crashing.

I did some searches online but didn’t come up with anything until I tried running Firefox from the command-line, so that I could read the error message. It complained, "firefox: cairo-ft-font.c:554: _cairo_ft_unscaled_font_lock_face: Assertion `!unscaled->from_face' failed." Searching for that led me to Fedora bug 509501 and bug 502274, and this blog entry.

To make a long story short:

• On Linux, Firefox uses a library called cairo to handle graphics, including fonts.
• An old version of cairo had a bug that would cause crashes with fonts under certain circumstances.
• Cairo fixed the bug in December.
• Fedora 11 is still using the old version of cairo.

So until Fedora ships a newer (or at least patched) version of cairo, my primary browser on my primary desktop will crash on any web page with an embedded font.

Nice.

I guess I could patch my own system for now and put the fonts up for the benefit of the rest of the Firefox+Safari+Opera-using audience on Windows and Macs (and probably other Linux distributions). But that means causing a crash for anyone else running Fedora 11 when they visit my site. I’m not too thrilled about that idea. I have no problem with adding enhancements that only appear under certain browser+os combinations, but actively crashing a browser? Not something I want to do.

Update (July 21): Aha! Fedora submitted an updated cairo for inclusion in the stable release last night!

I’d like to see something like this picked up by Firefox and Opera as well. They both have crash recovery already, but it still means restoring the entire session. If you have 20 tabs open, it’s great that you don’t have to hunt them down again. But it also means you have to wait for 20 pages to load simultaneously. It would be much nicer to only have to wait for one (or, if I read the IE8 article correctly, three).

Edited to add:

On a related note, I’ve run into an interesting conflict between crash recovery and WordPress’ auto-save feature. If you start a new post, WordPress will automatically save it as a draft. If the browser crashes, it will bring up the new-post page, but restore most of the form data you filled in. So the title, the text of your post, etc will all be there. But WordPress will see it as a new post, and you’ll end up with a duplicate.

This wasn’t a major problem when I encountered it — I had to reset the categories, tags, and post slug after I hit publish (since I hadn’t noticed that they’d been reset to defaults), and I just deleted the older, partial version of the post — but I can imagine if I’d uploaded an image gallery, I would have been rather annoyed, since there’s no way (that I’ve noticed) to move images from one post to another. Reuse them, sure, but not such that the gallery feature would work.