Category: Troubleshooting

Posted on
by

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 \). Continue reading →

Posted on
by

Opera BrowserI 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.
Continue reading →

Posted on
by

If you want to build a Linux or FreeBSD system around a RAID array, don’t use the Promise SuperTrak SX6000 controller. At least not for now.

The card used to work under Linux using the standard I2O drivers (i2o_block, etc.), but sometime last year Promise changed the firmware so that it no longer uses I2O. Now you’re stuck with Promise’s own driver, so if you want to use an old enough distribution* (say, Red Hat 7.3) that you can find a driver disk, or make your own driver disk, go ahead…but don’t expect to be able to upgrade it unless you can create a driver disk for the newer distro. This assumes the source code for the driver will work with recent 2.4 kernels—it won’t compile with 2.6. There has been talk of merging the pti_st driver into the kernel (fortunately it’s GPLed), but I can’t find anything more recent than August. Someday it might work again, but not today.

Now, FreeBSD is another matter. It has built-in drivers (pst), the installer will detect it automatically, and even let you install your entire system to it—without warning you that FreeBSD can’t boot from the SX6000. You can boot from another drive and interact with it once the system’s running, but you can’t put your entire system on the RAID array. (This information is not in the installer, not in the hardware notes, not in the driver man page. I only found the one 1½-year-old mailing list post by the driver’s author, and a bunch of “I don’t think it works” comments in other lists and forums.)

I hope this post will save someone a lot of frustration.

*Of the distributions for which Promise has provided driver disks, only one—SuSE 9.0—hasn’t already been retired.

Posted on
by

One of the reasons our Powerbook stays in Mac OS most of the time (aside from the fact that It Just Works™) is that Yellow Dog Linux 3.0 didn’t have drivers for Airport Extreme, so it can’t connect to the wireless network. I had hoped that YDL 4 (just released) would resolve this — perhaps the driver was only available for the 2.6 kernel, or something.

I finally started looking, and that’s not the case. It seems that the Airport Extreme chipset manufacturer, Broadcom, refuses to release Linux drivers or to release specs to allow anyone else to write Linux drivers.

I don’t expect it to do any good, but I signed my first online petition.

Ah, well, I can do almost everything under Mac OS, and for those occasions that I actually need Linux, I can always go solo or plug in a cable, though it does limit where I can hook it up.

Posted on
by

Pet peeve: Login forms that move the cursor to the username field AFTER the page finishes loading. Sometimes I’m already typing by then.

While working on a website for work, I inadvertently discovered why a web application I use frequently has the annoying habit of moving the cursor to the username field when I’m halfway through typing the password.

The basic way to set initial focus on a form field is to use JavaScript like this:

document.loginForm.usernameField.focus();

You can either embed it in the HTML after the form, or call it in the page’s onload() function. The problem with using onload is that it fires when everything is loaded, which means it waits for images, plugins, and so on. That’s very useful for some tasks, but isn’t the best choice here.

I’m impatient, especially with login forms. I don’t need the logos and background, I want to type in my username and password as quickly as possible and start using the app. Since this particular site isn’t exactly the fastest around, invariably the images don’t finish loading until I’ve started typing the password — and suddenly I’m typing the second half of the password in the username box.

Needless to say, I’m using the inline method on the site I’m building. Not that the login page has any images right now, but if I add any later on, it’ll save the users some aggravation.

Note: I’ve attached a 2009 tweet and the subsequent LiveJournal discussion to the original 2005 article.