I’ve been hoping to try out Google Buzz, but it hasn’t hit my Gmail account yet and it won’t run on my phone*…even though it’s a web app. Comments at Android and Me and at Mashable show that I’m not alone.

It turns out that Buzz uses HTML5 features (specifically appcache, database and location) to store local data and to detect your physical location…and those capabilities were added in Android 2.0.

The support thread mentions that they are “working on another version that will make Buzz for mobile accessible on older Android OS versions (and some other smartphones as well).” The browser in Android 1.6 and below supports similar capabilities through Gears, so they may be planning a Gears-based workaround.

This would be a lot less of an issue if it weren’t for the fact that most of the Android phones out there still run 1.6 or even Android 1.5. IIRC only the Droid and Nexus One have officially been updated to 2.0 so far**, so unless you have one of those two models, you’re more likely to get Buzz to run on an iPhone than Android.

Funny, that.

*I’ve got a G1. It can only access Buzz through the updated Maps app, which brought up a bunch of people in nearby office parks posting things like “Testing Buzz” and “WTF is Google Buzz?”

**A few other phones have had updates announced, but I don’t think any have actually shipped yet. I could be wrong.

  • Usability question: Is it better for a form to auto-detect the credit card type from its number, or have the user select it as an error check? (Consensus on Twitter & Facebook was to have the user select it.)
  • Yay, the PC isn’t totally crashed! Grabbed a current backup & now running chkdsk. Work last week, home this week. Pattern?
  • Chkdsk is FINALLY running. If you get a “cannot open volume for direct access” error trying to run it on Windows XP, try running msconfig and selecting a Diagnostic startup.

I tried out the Chrome beta for Linux on two different computers yesterday. On the first one, Flash worked right “out of the box.” On the second, it wouldn’t even show up in about:plugins. I couldn’t figure out what was different.

  • Both are 64-bit systems running Fedora 12.
  • Both are running the 32-bit version of Flash from Adobe’s yum repository.
  • Both are running the 64-bit version of Google Chrome from the beta download page.
  • I had run mozilla-plugin-config -i to create the 64-bit wrapper on both computers after updating Flash. (A security update came out yesterday.)
  • Flash works just fine in 64-bit Firefox and Opera.

I looked thoroughly at my home computer last night and came up empty. This morning I took another look at my work computer — the one where Flash actually showed up — and I think I’ve found it.

Chrome is using nswrapper_32_64.libflashplayer.so according to about:plugins. The actual file is in /usr/lib64/mozilla/plugins-wrapped/. This system has two symbolic links to that file, one in /usr/lib/mozilla/plugins/ and one in /usr/lib/mozilla/plugins-wrapped/. IIRC Only one of these was present on my home computer.

So I think this will fix it:

ln -s /usr/lib64/mozilla/plugins-wrapped/nswrapper_32_64.libflashplayer.so /usr/lib/mozilla/plugins/

Run the command as root or using sudo.

I’ll check back tonight and update this entry to show whether it worked.

Update: Yes, it worked!

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!

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.