Category Archives: Computers & Technology

The Case of the Missing Nav Bar

I will admit, sometimes the problems I encounter in Internet Explorer are simply due to slight differences in browsers’ implementation of HTML or CSS or whatever, and I’m just not properly accounting for the way IE does certain things. Other times, it’s true, they’re due to a flat-out bug in my code that Safari and/or Firefox (usually “and”) will just graciously accept, whereas IE will not. (The cases where IE catches errors that Safari and Firefox permit, however, are rare compared to the vast, cluttered landscape of bad code that IE welcomes with open arms but that Safari and Firefox rightly reject.)

And then there are the cases such as the one I encountered today. There’s no way around it. I can’t find a nicer way to put it, IE is just plain fucked up.

Yesterday I was going along innocently enough, demonstrating to a coworker the site I had been working on for him. As usual I had worked with Safari and Firefox as my test browsers, firing up IE through a remote connection to my PC as needed to make sure things weren’t completely off track. (In a perfect world, I would never have to do this, of course. But, well…) And then, wham! Of course this kind of problem only rears its head when you’re showing your work to someone who has the authority to reject it. I was convinced it was a fluke on his computer, but sure enough when I went back to my desk, I observed the same thing happening in IE on my own PC. Time to hit the brakes once again and go into IE debugging mode.

I tested all of the obvious things. No luck. So I dug a little deeper and started testing the more obscure, but at least logical things. Still nothing. And like so many times before, I was reduced to just randomly trying anything to see if I could get a different result, no matter how seemingly absurd.

Fortunately it only took about an hour to track down the problem this time. But as usual there was no satisfying resolution, no “Aha!” moment as I suddenly recognized a stupid mistake I had made. Oh no. The problem was that the CSS definition for the <div> tag containing the entire body of the page specified a background color. Of course! (No, not of course, as this should not have any impact whatsoever!)

*SIGH* Seeing as how that background color specification wasn’t technically necessary, I removed it. Problem solved. Frustration with Microsoft, higher than ever.

Salvage (part of) a corrupted zip archive in Mac OS X

Perhaps this has been pointed out elsewhere; I haven’t really searched for it, so I don’t know. But it’s rare that I stumble, completely on my own, onto what I believe is truly a “hot tip” for dealing with computer problems, and when I do, I’m excited to share it.

Now then, the problem we’re dealing with here is corrupted zip archives, which seems to be common for me these days given the fact that I’ve foolishly been using some cheap off-brand CD-R’s that have been sitting around my house on a spindle for a couple of years.

The situation manifests as such: You double-click a zip archive to extract the files, BOMArchiveHelper fires up (don’t worry if you have no idea what this is — basically it’s just a background application embedded in Mac OS X for working with zip files), and the extraction process begins.

But then, oh dear. After a while (usually right near the end), the progress bar will change to a disconcerting alert: Unable to unarchive... (Error 1 - Operation not permitted.) Aside from the meaninglessness of the error message itself, you realize, dishearteningly, that the only thing you can do is click the “OK” button, at which point… *poof* everything is gone. Well, the zip file itself is still there, but what good is it if the goodies are forever locked inside?

I’ve discovered, however, that while BOMArchiveHelper is busily extracting the archive, it creates a hidden temporary directory on the hard drive in the same directory as the zip file. Once you click “OK” on this alert, it deletes this temporary directory, but until then, it’s there. With all of the files so far extracted waiting inside. Oblivious to the doom that shortly awaits them.

So what do you do? Well, the first thing you do is get your pointer away from that “OK” button! Leave the alert on the screen, and fire up Terminal. You’re going to need to get your hands dirty with some command line mucky-muck, so if you don’t know where Terminal is, I advise you to just stop right here. Cup your hands over your face and sob quietly.

Now then, this is most likely going to require root access, so type sudo -s and enter your administrator password. Then navigate to the directory where the zip file is. Type ls -al and amongst the hidden files at the top of the list (the ones whose filenames begin with a period), you’ll see a subdirectory named .BAH1234. (The 1234 will be some random number, which I am guessing is the process ID. But it’ll always start with .BAH.) Make note of the exact name, because you’ll need it in a minute.

Everything that’s been extracted so far is inside this directory! So now you can move or copy the contents to another directory and BOMArchiveHelper won’t take it upon itself to “tidy up” after you click the OK button. Here’s some code to try:

mkdir Rescued
mv .BAH1234/* Rescued/

Be sure to change the 1234 portion to whatever the correct name is, as you determined by running ls -al earlier. Also, note that if you’re extracting multiple zip archives at the same time, they may be handled by the same process, so you’ll have a second directory named .BAH1234 2 or something similar. Since this name contains a space, when you’re referring to it at the command line you need to wrap it in quotes, like this:

mv “.BAH1234 2″/* Rescued/

This will create a new (visible) directory at the same place on the hard drive, called Rescued, and it will copy everything from BOMArchiveHelper’s invisible temporary directory into Rescued, where you can now work with the files as you wish. It’s unlikely that everything from the zip file will be in here, but everything that’s not corrupted in the archive will be, and it might just be the things you were looking for.

Once everything’s been moved into your Rescued directory, you can go ahead and succumb to the temptation of that gently pulsating, deliciously blue (or not-so-deliciously gray, depending on your system settings) “OK” button.

Web 2.0 — opening up a whole new world of Internet Explorer quirks!

Just when I needed it least, Internet Explorer has thrown me another curveball.

I’m hard at work trying to seem like less of a 20th Century web dinosaur by acquiring new skills with these techniques that are loosely lumped together into what some call “Web 2.0.” Key among these is an approach called AJAX (Asynchronous JavaScript and XML). Fun stuff. I’ve been working for the past several days on an interactive registration form for a site at work, using AJAX. Of course, as usual, I’m plugging away in Safari and Firefox, but eventually I decided to check out how things are looking in Internet Explorer.

[When I figure out an emoticon that represents my head exploding, I’ll insert it here.]

IE is consistently barfing on what it claims is a syntax error that I eventually tracked down to the evalScripts function in prototype.js. Well, at least it’s not my own code that’s making it crap out this time. Or is it? With IE you never can tell. Maybe evalScripts is buggy (even though I can find no evidence to that effect) or maybe it’s just the code in my script that’s being thrown at it. Whatever the case, once again all forward progress has come to a grinding halt while I scour the Internet fruitlessly for a solution.

Although this turned out not to be a solution to my problem, I just have to refer you to this developer’s blog entry on a typical IE workaround. Yes, I tried this, even though I was almost positive his problem was completely unrelated to my own (which was the case). Nevertheless, when a problem does arise in IE, the most likely eventual result of one or more days’ worth of sleuthing is the resigned acceptance of such hokey code bloat, rather than anything even remotely satisfying (or even logical).

There you have it. As for my own problem using prototype.js with IE, I did find a solution. Yes, it was my code, and it was something I had seen previously that was pretty much staring me in the face, if I had just bothered to heed Thomas Fuchs’s sage advice.

It all comes down to standard practice for wrapping <script> tags in HTML. I still have the habit of doing it this way:

<!–
//–>

The funny thing about that is that I know it’s completely pointless these days. It’s done so that browsers that don’t support JavaScript don’t inadvertently display the JavaScript code in the web page. But every browser has supported JavaScript since about 1997, so it’s pretty ridiculous to keep doing that. Especially given that, the way the sites I’m working on are so utterly dependent upon JavaScript, you’d never even get to the page in question without it.

However, with XMLHttpRequest (which is at the heart of AJAX), and just the increasing complexity of JavaScript in general, it’s become necessary to wrap script code in a new tag to ensure that browsers handle the code properly. To wit:

// <![CDATA[
// ]]>

Just as Thomas Fuchs said. And just as has been lingering in the back of my mind for the past several weeks, since I first discovered his wonderful tool based on prototype.js, Scriptaculous. I’ve learned my lesson.