K-Squared Ramblings

@font-face Crashes Firefox on Fedora

With the release of Firefox 3.5, I decided it was finally time to get serious about setting up a custom headline font on Speed Force. Cross-platform @font-face embedding in CSS is now possible on Firefox, Safari, the beta version of Opera, and (I think) Chrome. So I pulled out some bookmarks, looked for some fonts with licenses that allowed embedding, messed around with a test page and finally settled on two custom fonts: one for the post headlines, and one for the title and the sidebar section headers.

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!

Flash 10 and WordPress File Upload Problems

Well, Flash 10 is out with new features, security updates, and a fix for a Firefox video problem that I never noticed because it only affected Windows, and only sometimes.

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.

When digiKam Failed to Connect

In the decade I’ve been using Linux, it’s gone from something that required lots of technical know-how just to set up, to something that (in its major flavors) can auto-detect most hardware and provides friendly GUIs for most configuration tasks. But every once in a while, I have the kind of experience that would turn a new user off of Linux. Usually because Fedora has decided to change something during an update.

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. Read the rest of this entry »

Fedora 7 problems with glint video driver

Just a warning for any Fedora Linux users preparing to upgrade to Fedora 7: Grab the Live CD first and make sure that all your hardware works properly. If not, see if the fix is available before you actually upgrade.

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: Read the rest of this entry »

Automattic Stats, or PHP 5.2.2 vs. WordPress XMLRPC

Experimenting with the new Automattic Stats Plugin that uses the WordPress.com statistics infrastructure to track traffic. So far, so good… except for one problem. Titles and links are missing from all the “most visited” posts. They’re just listed as numeric IDs.

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.

Fixing Feed Problems with WordPress 2.0.6 and PHP 5.2

Upgraded to WordPress 2.0.6 and now feeds are broken. At least, they’re broken in Firefox, IE7, and KDE (Konqueror & Akregator). Something seems to be interrupting the transfer, causing them to get a blank file. Oddly, they work fine in Opera, the LWP “GET” command-line utility, and Dillo (not that Dillo can do anything but display the source, but it gets the whole file.) Even more oddly, SeaMonkey seems to have no problems. You’d think Firefox and SeaMonkey would have the same issues. Also, I seem to be able to sometimes get it to work on reload.

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.

Read the rest of this entry »

Google Toolbar AutoFill is Weird

I briefly enabled the Google Toolbar to check some PageRank stats, and noticed some fields on contact forms were highlighted in yellow. A little experimentation revealed that this was part of the toolbar’s AutoFill capability, which will try to identify standard form fields and fill in your name, address, etc. (There’s a config box where you fill it all in once.)

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. Read the rest of this entry »

Fixing Flash in Fedora Core 5

I upgraded two computers at work to Fedora Core 5. One was a network upgrade that went without a hitch.* The other was trashed so badly I had to do a fresh install.

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.

Bunny’s Technorati Tags and WordPress 2.0

Solved! To make Bunny’s Technorati Tags fully compatible with WordPress 2.0 you need to change two lines in the add_tags_textinput() function.

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.

How Thunderbird’s Scam Detection Works

Since upgrading to Mozilla Thunderbird 1.5 beta 2, I’ve seen a number of messages slapped with a warning label that “Thunderbird thinks this message might be an email scam.” It appears at the top of the message, in the same style as the junk mail notice bar or the warning that remote images have been blocked, and there’s a button to mark the message as “Not a Scam.”

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.

Troubleshooting by Blog

From time to time I’ve written up the results of a particularly interesting (or annoying) computer problem with the intent of helping out other people who run into the same issue. Daring Fireball calls this Writing for Google and provides suggestions on how to make sure the write-up gets found.

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.

“Expected dict” Errors in FDF Acrobat Forms

Today I was trying to fix a problem in a section of a website that hadn’t been changed in roughly 5 years. The page in question retrieved data from a database and filled out an Acrobat form using FDF. Under some circumstances, Adobe Reader would generate an error message, “Expected a dict object.” Then it would freeze, and crash the web browser for good measure.

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 \). Read the rest of this entry »

Apache, mod_ssl, and syntax errors in krb5.h

Upgraded the Apache web server today. I’d forgotten about a problem compiling mod_ssl on some systems. Fortunately I had left myself a note about it.

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.

Resolving SELinux audit errors on boot in Fedora Core 4

I’ve upgraded two systems at work from Fedora Core 3 to Fedora Core 4: a desktop using the normal installer, and a test server upgrading with yum. The yum upgrade worked well except for two snags. The first was a conflict with the old kernel-utils package. I followed the recommendation by installing the new kernel first, rebooting, then removing the old kernel.

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.
Read the rest of this entry »

Opera Cookie Weirdness Explained (sort of)

I finally figured out why I’ve had so much trouble logging into sites with the latest version of Opera! (I’ve actually had to log into My Opera using Firefox. How’s that for irony?)

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.
Read the rest of this entry »