Tag Archives: Problem

Version SNAFU

Today I updated WordPress for an “urgent security release,” and as usual there are unexpected side effects. For some reason now, my sliding sidebar panels no longer work. No JavaScript errors; they just don’t do anything. I blame a Scriptaculous update that is probably embedded within. I hope within the next 24 hours to diagnose and fix the problem, but for anyone (emphasis on “one”) who’s wondering why the panels aren’t working, here’s a semi-explanation.

Update (1/1/2008): File under SEU. I think the problem was simply that I needed to clear my cache. The first suspicion was aroused when I fired up MAMP, ran the site locally, and found that the sliders were working just fine. At any rate, I re-uploaded all of my theme files plus the Scriptaculous and prototype.js files, cleared my cache, and now it’s working.

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.

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.

Forget what I said before; we have a winner!

It’s a given that anything I post here is going to be brain-deflatingly stupid. But this one goes beyond even what I would have expected of Microsoft. Fortunately, thanks to a highly effective Google search, I was able to solve the problem in minutes.

The problem was this: For a site I’m working on, we are manipulating the 404 error feature to allow users to set up customized URLs. If the URL entered doesn’t match a real page, it gets fed into this 404 error script, which looks up the path in a database and redirects the user to their customized page. A bit of a hack, but it’s pretty slick.

As usual, I am developing the site using Firefox as my test browser. But… UH-OH! Surprise! When giving a demo of this feature today using Internet Explorer, we discovered it didn’t work! Internet Explorer was not returning the server’s 404 error page, instead using its own internal version (which we’ve all seen and most generally ignore).

Drat! What to do? Well, as it turns out (thanks to the aforementioned Google search), the problem is quite simple. To quote the unbelievable but, as I verified, 100% accurate description I found on this page:

Internet Explorer has a lightly-documented “feature” that stops it from serving any custom 404 error page that is less than 512 bytes long. Your visitors will instead be sent to IE’s own 404 page, which is generic and suggests they use an MSN search to “look for information on the Internet.” That’s one way to lose visitors! Make sure your custom 404 error page is over this limit — about 10 full lines of text and HTML should be enough.

Yep, that’s it. I did my best Bart Simpson-at-the-blackboard impersonation, filling my 404.html file with a large comment block wherein I repeated (about 130 times, for good measure) the phrase “This block exists solely to force Internet Explorer to load this page.”

Sure enough, it worked. D’oh!

Thinking a bit more about this, I at least think I understand why Microsoft chose to do this. “If the server’s default 404 error page is so short,” I imagine them musing, “then it probably doesn’t offer users much helpful information. And since our wonderful web browser is much more important to our users than the web pages themselves, let’s just butt in and do things our way. (Is there really any other way anyway?)”

Microsoft, how do I hate thee? Let me count the ways…

Most people who know me well understand that I am an acknowledged Apple fanboy. But I don’t simply hate Microsoft because I love Apple. There may be more truth to the fact that I love Apple because I hate Microsoft.*

At any rate, it’s clear that I hate Microsoft, and for reasons that are much more concrete, tangible, and, in the context of this article, quantifiable.

As you may know (if you know me, and probably wouldn’t if you don’t, but you do now… get it?), I make my living building websites, which means that I am forced to deal with both Windows and Internet Explorer, like it or not. (Not.) I do my work on Macs, and my day-to-day web browser is Firefox. But everything I do needs to be tested in the Microsoft world, since that’s the context in which 95% of my audience will be viewing my work.

At least once every month or two, I am forced to bring my work to a grinding halt while I attempt to diagnose some obscure Internet Explorer problem I’ve just run into. It is usually some trivial function that I take for granted, but for some mysterious reason simply does not work in Internet Explorer under a particular set of conditions. So I spend a day or so fruitlessly searching Google to find others who’ve experienced the same problem. Eventually I resign myself to the fact that there is no logical explanation for the problem and I will never discover a real solution to it. So, the only alternative is to concoct a hokey workaround that Internet Explorer can accept. These weak victories are always bittersweet: at least I’ve found a way to move on and get back to the real tasks at hand, but my work is forever tainted by Microsoft lameness, without even giving me the satisfaction of a glimmer of understanding as to why I’ve just undergone a day of torture.

Finally, I’ve had enough. I know that as long as I work in this field, I will always have to deal with this problem, but I’m no longer going to silently submit to the whims of mediocre software. I will catalog my woes here for the world to see, so when I finally jump off a bridge with a thousand Windows Vista CD-ROMs tied around my waist, people won’t wonder why.

* For the record, I don’t unequivocally hate everything Microsoft does. I own, and enjoy immensely, an XBOX game console.

The mysterious window.print() problem

It seems an easy task: print the damn window. But no, nothing is ever as easy as it seems with Microsoft. In this particular case, I have a pop-up window which contains a frameset. The frameset consists of a left frame with a tree of page links, and a right frame containing the body of the page linked from the left frame. Within the body of the page in the right frame there are links to allow you to print the frame. So far, so good. But there’s also a special link that opens a new page that contains the full content of all of the pages, so you can basically print the whole lot at once instead of one page at a time.

As expected, all of this works just fine in other browsers, but not in Internet Explorer. It handles the regular single-page window.print() just fine, but when you go to the full page, nothing. No printing, no JavaScript errors, nothing. It’s like it’s just a dead link. With the exact same code as what works on the other pages. And, if you open the page from the frame in a new window by itself, it prints just fine. So, we have some pages printing just fine in the frame, and another page that prints just fine when it’s by itself, but it won’t print if it’s in the same frame that the other pages print fine in, using the same code. You can see why this is driving me insane, can’t you?

Nothing I find anywhere online suggests that this problem exists. So eventually I resort to the only option that’s available… open the troublesome page in its own pop-up (yes, a pop-up opening a pop-up… always a great idea), where window.print() works just fine.

Thanks again, Microsoft!