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!

It seems a little less stable than version 9 on Linux, at least 64-bit (it’s kind of complicated, because they only have a 32-bit program, so you either need to run a 32-bit version of your web browser, or use a wrapper that will let the 64-bit browser talk to the 32-bit plugin. nspluginwrapper does this for Firefox and other Gecko browsers, while Opera has a wrapper built in). But the annoying part: WordPress’ image upload no longer works.

Current versions of WordPress use SWFUpload to provide an enhanced file uploader. If you don’t have Flash installed, it will just use the standard upload dialog built into your web browser, but then you’re stuck uploading one image at a time — a real pain if you’re making a photo gallery post. Unfortunately for upload libraries, Adobe removed the ability for the Flash API to open a file dialog for security reasons.

So now, you can click on the button, but the dialog never opens. WordPress is tracking the issue in ticket 6979, which mentions that SWFUpload is discussing workarounds, and the YUI Uploader has already released a new version that works with Flash 10.

An update of some sort is likely to happen soon. In the mean time, WordPress users have two choices: hold off on updating Flash, or stick with the browser uploader for now.

Update October 31: SWFUpload has a new version in beta which works with Flash 10, and WordPress is working on integrating the update. It’s targeted for WordPress 2.7, which comes out in a little under two weeks, though the 2.7 writeup lists it as a feature that “didn’t make it” and might be in 2.8. (This seems like something that would affect enough people that I’d hope they would include it, even if it means pushing back the release a few days for more testing.)

There’s also been talk about implementing a file uploader using Gears, which I’d find really appealing if I weren’t 64-bit Linux both at home and at work.

Update November 1: I’ve tested WordPress 2.7 Beta 1 (not on this blog) and can confirm that the fix is included, as I was able to upload two images in one transaction.

In this case, it was a digital camera problem. Since we bought our Canon PowerShot SD600 last December, I’ve used KDE’s digiKam to transfer and manage the photos. DigiKam detected the camera and accessed the photos right out of the box, no configuration needed beyond telling it to remember the model. But something changed in the last two weeks, and last night I started getting an error message: Failed to connect to the camera. Oddly enough, it could still detect the camera when it was connected. But it couldn’t display or download the images.

I searched all over, hitting dead end after dead end, until I got a hint that it was a permissions problem. That’s when I hit the command line to start troubleshooting.

Digikam uses a library called gphoto2 to access cameras. It has utilities that you can run from the command line for testing. I ran gphoto2 --auto-detect, which dutifully reported the correct camera. I ran gphoto2 -l to list the folders on the camera, and it spit out an error including the phrase: Could not claim the USB device. The interesting thing was, if I ran the same command as root, it was able to see the folders.

Way back when, Linux used a static list of devices in /dev. Now that everyone is constantly connecting and disconnecting devices with USB, Firewire, Bluetooth etc., that’s not practical. Most modern Linux distributions use one method or another to dynamically build that list from what’s actually connected to the computer, and react when new devices are plugged in. Fedora 7 uses udev to identify and configure devices. I had to figure out how to tell udev to give me write access.

I finally found the gphoto documentation on setting permissions, and found the command I needed: print-camera-list, which will build a list of rules for udev to use when someone attaches a camera. Unfortunately, the directions were slightly out of date. Instead of adding a “version 0.98″ option, it wanted “udev-rules-0.98″.

So the command I used (as root) was this:

/usr/lib/libgphoto2/print-camera-list udev-rules-0.98 group users mode 0660 > /etc/udev/rules.d/90-libgphoto2.rules

Note that where it says “users” you should substitute the name of the group your account belongs to. (In Fedora, that might actually be the same name as your username, since it likes to create a group just for you.)

It took me about an hour to track this down, since initial searches sent me looking in the wrong direction. I’m hoping this blog post will save someone else a little time and frustration.

Update (June 2008)

I’ve run into a different problem with Fedora 9. In this case, I’m running digiKam under the GNOME desktop. GNOME can mount the camera now, so it auto-mounts and pops up a filesystem window. But when I try to access the camera in digiKam, I get the same error message about not being able to connect.

It turns out this one’s just a conflict: either the virtual filesystem or digiKam can access the camera, but not both at once. I just right-clicked on the icon on the desktop, unmounted it, and was able to connect in digiKam.

I upgraded a system with a Permedia 2 video card, which uses the glint drivers. The installer couldn’t launch the GUI, but I’ve run into that fairly often, so I just used the text-based installer without thinking much of it. The upgrade process itself went fine, but on booting into the new system, it was unable to launch X. I kept getting the following error:

X: symbol lookup error: /usr/lib/xorg/modules/drivers//glint_drv.so: undefined
symbol: RamDacCreateInfoRec

I found a reference to the problem occurring in Debian, as Debian bug #423129, then followed that to Freedesktop.org bug 10906, which has been fixed. It turns out that the xorg X server moved some features from a pluggable module into the server itself, but didn’t keep them available for drivers that use them. I tested the patch with the X server SRPM from Fedora, and was able to run the system in graphics mode again.

Then I checked Fedora’s bug database, and found Red Hat bug 242800, filed just yesterday. I confirmed that I had the same problem, pointed them at the upstream bug, and reported that the fix worked for me.

For those who are comfortable with modifying and building SRPMs, you can grab xorg-x11-server-1.3.0.0-5.fc7.src.rpm from any Fedora mirror, then add the patch from that Freedesktop.org bug report to the SPEC file. That will give you a set of RPMs that will work with the card. (If you don’t know what I’m talking about, you’re probably better off waiting until Fedora has a chance to test the fix and issue an update, but if you want to learn, check out the RPM Guide, particularly chapters 8 and 9.)

Update (June 7): A fixed version, xorg-x11-server-Xorg-1.3.0.0-8.fc7 has hit the testing repository.

Update (June 11): The fix has been released, so all you have to do is install/upgrade in text mode and run yum update after you’re done.

Update: Actually, today’s posts seem OK. The plugin seems to just send the blog ID and post ID. I’ve been trying to figure out how the central server is retrieving the permalink and title. It doesn’t look like Bad Behavior is blocking it. And it doesn’t seem to be using the RSS feed, since posts that are still on the front page (and presumably still in the feed) are also showing up as numbers. *grumble*

Update 2: I just noticed that all of the number-only posts show the same placeholder graph showing “Region A” vs. “Region B” for 2003-2005.

Update 3: It’s a problem with WordPress’ XMLRPC interface, and affects other uses (like connecting with Flock). I’ve got a workaround, though (see comments).

Update 4 (May 10): Thanks to the pingback below from dot unplanned, it’s confirmed to be a bug in PHP 5.2.2. With any luck, the workaround will cease to be necessary when the next PHP bugfix is released.

Anyway, I’m working on it. If you read this site via RSS or Atom, and it is working, let me know (and let me know which feed reader you’re using). I suppose it could be cookie-related, though I’ve already tried clearing cookies. I’ve also tried disabling just about every plugin I use that does something to feeds or headers, to no avail.

Update: I think I’ve got it. By using the Tamper Data extension, I was able to determine that the 304 Not Modified status was not being set properly. Instead of actually issuing the 304 status, it would issue a 200 OK, then send a Status: 304 header later in the response. It never showed any problems on command-line GET or HEAD because they weren’t conditional. That’s also why forcing reload would work.

I looked into wp-includes/functions.php and found the status_header function. Then I looked at the following line:

@header("Status: $header $text");

In theory this should work. Traditionally, setting a “Status” header will replace the actual HTTP status. But that’s not how the PHP manual says to do it. They suggest issuing the actual header that the server would send: HTTP/1.1 304 Not Modified. I noticed that the header function in PHP has some optional parameters, including one to force the HTTP status. That felt a little cleaner than hard-coding the protocol (since an older browser might make an HTTP/1.0 request, and it should get an HTTP/1.0 response), so I changed the line to this:

@header("Status: $header $text", TRUE, $header);

It seems to have fixed the problem.

For the record, this is PHP 5.2.0 on Apache 1.3.37 using the mod_php interface.

Update 2: Simpler fix just removes the if.. statement and else… section so that it’s just the following:

@header("HTTP/1.1 $header $text");

Bug reported as Ticket 3528.

It’s also worth mentioning that I had to apply the workaround in Ticket 3354 for another issue (single-post pages were getting cut off before the comments).

Update 3: Here are the exact changes I made:

Keep in mind that this has only been tested on this config. If feeds still work after you upgrade, don’t change it.

Open the file wp-includes/functions.php and look for this section:

function status_header( $header ) {
	if ( 200 == $header )
		$text = 'OK';
	elseif ( 301 == $header )
		$text = 'Moved Permanently';
	elseif ( 302 == $header )
		$text = 'Moved Temporarily';
	elseif ( 304 == $header )
		$text = 'Not Modified';
	elseif ( 404 == $header )
		$text = 'Not Found';
	elseif ( 410 == $header )
		$text = 'Gone';

		if ( substr(php_sapi_name(), 0, 3) == 'cgi' )
			@header("HTTP/1.1 $header $text");
		else
			@header("Status: $header $text");
}

In the last four lines (not counting the closing }), disable everything but the one with HTTP/1.1 by adding // to the beginning.

		//if ( substr(php_sapi_name(), 0, 3) == 'cgi' )
			@header("HTTP/1.1 $header $text");
		//else
			//@header("Status: $header $text");

Update 4: Mark Jaquith has posted more on this issue, including a patch and a replacement functions.php.

The weird thing was that this form had name and e-mail fields, but AutoFill only recognized e-mail. I figured, OK, people might be using this, let’s see if I can adjust the page and make it compatible.

This form was using “name” and “email” for the actual names of the fields. They were labeled “Your Name” and “E-mail,” in separate table cells before the fields, with explicit <label> elements. A bit of searching turned up the fact that AutoFill looks for field names defined in ECML (RFC 3106). That list applies to the actual field names, not the visible labels, and if I’m reading it correctly, both “name” and “email” should work.

So I started checking other forms, and noticed that on the comments field here in WordPress, it fills in the wrong fields! It shows the email and website fields as being fillable (AutoFill doesn’t have a spot to provide a website). Worse, it fills in your name as in the email field, and your email address as your website!

At this point, I figured I’d read the search hit called Google Toolbar Autofill quirks. The author did some investigation and found that “it apparently looks at a text box and then tries to backtrack from that location looking at text.” In other words, instead of looking at the field’s name, or the content of an explicitly-associated label, it looks to see what text appears before it. This is just plain dumb. It makes sense as a fallback measure, but you don’t start with the heuristics when you have more reliable indicators that you can check just as easily!

It broke on the first contact form because, despite the fact that the field was called “name,” the label said “Your Name.” I pulled out the word your and it recognized it. Strangely, it was perfectly happy with anther form which had a field labeled, “Your Full Name.”

It broke on the WordPress comment form because the Kubrick layout puts the labels to the right of the fields. The fields and labels are paired within lines—in fact, each field/label pair is its own paragraph. So you’d think that some text in the same paragraph would be more closely associated with the field than some text in an earlier paragraph. Plus, each field has a <label> tag, so there should be no ambiguity as to which label applies to which field!

A more sensible approach would be this:

1. Check the field name, as in…
   <input type="text" name="email">
   This is where ECML says to look, after all! If it matches your list, use it and do not continue to step 2; no one is going to ask people to fill out “Ecom_ShipTo_Postal_City.”
2. Check for an explicit label, as in…
   <label for="myfield">E-mail</label> <input type="text" name="indecipherable" id="myfield">
   If it matches, use it. If you find a <label> for the field, even if you can’t use it, do not continue to step 3. The page’s author has already told you what the field is called, and you’ll either get the same label or something irrelevant.
3. If those both fail, check the text immediately before and after. Figure out which is more closely associated. (Hint: If some text is on the same line, and some isn’t… the text on the same line is probably attached to this field!)

I’ll rename the “Your Name” field in the first form, and I’ll tweak any other pages I find having problems, but I’m just plain annoyed at the spectacular failure on the WordPress form.

For future reference, this behavior was observed with the Google Toolbar for Firefox version 2.0.20060515W. The WordPress comment form in question is from the WordPress 2.0 version of the Kubrick theme, modified only slightly (I changed the “URI” label to “Website,” since more people will know what it means).

I’ve run into a couple of gotchas, among them the fact that text is missing in Flash animations. I messed with my font settings, checked SELinux logs, tried switching from the binary installer to the RPM package, to no avail. I tracked down a Fedora mailing list post that pointed to a mozilla bug that had been languishing for a few months, then added what I knew—which was that it affected Flash regardless of the browser.

On Sunday, commenter Dawid Gajownik tracked down the problem: Flash hard-codes the paths where it looks for fonts, instead of letting the X server tell it where to look. Fedora Core 5 includes a new X server, which no longer puts things in /usr/X11R6. Apparently symlinking the old font paths to the new ones works around the problem:

[root@X ~]# mkdir -p /usr/X11R6/lib/X11
[root@X ~]# cd /usr/X11R6/lib/X11
[root@X X11]# ln -s ../../../../etc/X11/fs
[root@X X11]# ln -s ../../../share/X11/fonts

I tried it with absolute links (to /etc/X11/fs and /usr/share/X11/fonts) instead of relative, and it worked fine.

Also, if SELinux is in enforcing mode, you need to allow text relocations on the Flash library. More info on that in Dawid’s bugzilla comment.

So this should take care of Flash until Macrodobe releases an updated version. They’re apparently heading straight for 8.5 on Linux, which is why they haven’t released Flash 8.0 yet.

*Almost. It turns out the repodata on disc 1 isn’t enough for a network or hard disk installation. I copied all the discs onto an internal web server, then had to grab the repodata folder from a mirror. Would’ve been fine with the CDs except for the annoying problem that the CD drive on that machine doesn’t work. Once I had that, though, the upgrade went smoothly.

Just replace this:

function add_tags_textinput() {
	global $postdata;
	$tags = get_post_meta($postdata->ID, 'tags', true);

with this:

function add_tags_textinput() {
	global $post_ID;
	$tags = get_post_meta($post_ID, 'tags', true);

The problem is that it will show existing tags, or let you add a new tag, but it will lose tags when you edit a post. It’s not able to retrieve the tags to fill in the form field, apparently because $postdata isn’t returning the ID it expects.

I’ve submitted the fix to wp-plugins.org, so if the author is keeping track of tickets there, the fix should show up in the next version of the plugin.

Update Jan. 3: The plugin author has released version 0.5 with a slightly different fix (plus a few other improvements), and it’s now compatible with WordPress 2.0.

There’s only one problem. Since SpamAssassin and ClamAV do such a good job of catching the phishing scams before they reach my inbox, Thunderbird has yet to catch any actual phish. But there’ve been a lot of false positives. It’s hit LiveJournal reply notices, newsletters from IEEE and Golden Key, a Spam Karma notice from my own blog, and I’ve seen it on both outbid notices and updates to saved searches from eBay.

I found myself wondering just how Thunderbird’s phishing detection decides that a message is suspicious—and how to teach it that the next LJ notice isn’t a scam.

The Thunderbird support website doesn’t seem to have been updated yet. Most of the articles I’ve found only talk about TB adding the feature, not how it works. The best information I found was this Mozillazine forum thread, which included a link to the actual code that makes the decision, in phishingDetector.js. Thunderbird looks at the following:

• Links that only use an IP address, including dotted decimal, octal, hex, dword, or some mixed encoding.
• Links that claim to go to one site, but actually go to another. (Phishers do this to fool you into going to their site. Legit mailing lists sometimes do this with redirectors for tracking purposes.)
• Forms embedded in the email. (This explains the LiveJournal notices.)

It also appears to trap text URLs containing HTML-escaped characters, which explains the Spam Karma reports. In this case the report includes a spammer’s link with ​ in the hostname. The message is plain text, so Thunderbird leaves the entity as-is when displaying it…but decodes it when it creates the link. Result: a link where the text and URL don’t match.

The easiest way to prevent it from freaking out over the next message? Add the sender to your address book. I’m not sure that’s a great idea, since a phisher could guess which addresses you have saved and spoof them, but it’s at least simple. I guess I’ll find out whether it works the next time I get a reply notice from LJ. Update: Adding the sender to your address book doesn’t seem to have any effect.

Update 2 (July 12, 2006): The comment thread’s gotten long enough that I can see people might miss this, so here’s how to disable it:

1. Open Options or Preferences (this will be under the Tools menu on Windows, Thunderbird on Mac, or Edit on Linux).
2. Click on Privacy (there should be a big padlock icon).
3. Click on the E-mail Scams tab.
4. Disable the “Check mail messages for email scams” option and click on Close.

That’s it.

There are enough of them that I think they’re worth labeling. Although the category list is getting complicated enough it might be worth chopping everything down to 4 or 5 and using tags for everything else.

This site was built with ColdFusion, and used a then-freely-available library called PDFFormFiller.cfm (I can’t find any sign of it now) to generate the FDF code. After saving the offending FDF to a file (eliminating the browser as a factor), I started manually editing the code to see what happened.

The problem turned out to be parentheses appearing in the form data. FDF uses parentheses-delimited strings, and it was finding ) in the code and trying to parse what was left as FDF tokens. The solution was simple: just escape the parentheses as \( or \).

In this case, I changed this expression:

#Evaluate("VarStruct.#VarName#")#

to

#ReplaceList(Evaluate("VarStruct.#VarName#"),"(,)","\(,\)")#

I don’t know whether older versions of Acrobat Reader were more lenient about this or whether this site just never ran into anyone using parentheses before. Either way, there’s precious little useful information about this problem online. In case anyone else runs into it, this entry should help.

If you get syntax errors in krb5.h while trying to build Apache with mod_ssl, it’s probably because your Linux distribution puts the Kerberos include files in their own subdirectory (Red Hat/Fedora and derivatives do this), and the configure script has somehow missed them.

Solution: Configure mod_ssl and Apache as normal. Then edit the file path_to_apache_source/src/modules/ssl/Makefile. Look for the CFLAGS1 line and add -I/usr/kerberos/include to it.

Then continue with the build as normal.

We now return you to your regularly scheduled blog.

The second was that SELinux denied access to about a dozen services on start-up. It was in auditing mode, not enforcing mode, so the services still worked, but I wanted to be able to start enforcing the policy once I resolved some other issues.

After digging through the Fedora Core SELinux FAQ, messing with restorecon and relabeling, I noticed that it didn’t log any errors when I restarted the services manually, only when they started on boot. I looked more closely at log entries. Here’s a typical one:

Jun 22 09:21:06 <servername> kernel: audit(1119457266.772:14): avc: denied { use } for pid=1941 comm="ntpdate" name=init dev=rootfs ino=8 scontext=system_u:system_r:ntpd_t tcontext=system_u:system_r:kernel_t tclass=fd

The device, rootfs, was the key. When I had installed the new kernel, it was running under the simpler SELinux policy for Fedora Core 3. The “targeted” policy in Fedora Core 4 covers more services. So the initial ramdisk the kernel uses to boot had everything labeled for the old policy.

Solution: Rebuild the initrd. Reboot. Done.

mv /boot/initrd-2.6.11-1.1369_FC4.img \
   /boot/initrd-2.6.11-1.1369_FC4.img.bak;
/sbin/mkinitrd initrd-2.6.11-1.1369_FC4.img \
    2.6.11-1.1369_FC4

It’s all down to “Treat as specified in Server Manager,” which seems to be either the default or the way an old preference got interpreted after upgrading. First of all, you get to Server Manager by clicking on the “Manage cookies…” button. I’d been looking for something labeled Server Manager and didn’t find anything. Secondly, it seems to mean “Ignore any cookie for a site that isn’t explicitly listed in Server Manager.”

Once I added my.opera.com to the list, I was able to log in.

I may switch to “Accept all cookies,” though, since I’ve finally figured out another cookie issue.

A nice feature in Firefox lets you choose how long to keep cookies: until they expire (which could be years from now), or until you close the browser. You can set exceptions for sites that you want to remember your settings. So sites that require cookies will work, but you can clear out all the junk just by closing Firefox, and it will keep only the cookies you want.

Opera has a similar feature, “Delete new cookies when exiting Opera.” There’s no way to define an exception, but you can fudge your way around it by unchecking the box, then visiting the site, then checking the box again. (That way it’s not a new cookie at the point the feature is turned on.) It’s kind of roundabout, but it seems to work.

Edit: Still trying to work out the settings for third-party cookies. If www.example.com sets a cookie for example.com, it considers that third-party, so if you block third-party cookies, it ignores that cookie entirely. But setting third-party cookies to “Let me choose each time” just seems to accept it.

Sense, it makes not.