Tag: Internet Explorer - Page 2 - UNDERDOG of PERFECTION

CakePHP Auth component, Flash and Internet Explorer… a deadly combination

OK, it’s not really deadly at all… other than that it will kill your CakePHP session and log you out.

My CakePHP-based CMS uses YUI Uploader, a Flash-based file uploader utility. It’s much better than the default HTML file uploader, because it supports a fully CSS-customizable progress bar and multiple file uploads.

It’s pretty slick, even though I did tear some hair out earlier in the year trying to get it integrated into the CMS. All went well for several months, until one particular client, using Windows Vista and Internet Explorer 8, discovered a showstopper of a problem: whenever you uploaded a file, all would seem well until you went to save your changes and you’d get kicked back to the login screen, without the changes being saved. Bad news!

I did some diagnostics and determined that, yes indeed, the CakePHP session was in fact being dropped as soon as the Flash process finished queuing the file uploads (an AJAX-based process), before you actually click the “Save” button… but since there’s nothing else happening dynamically on the page, it wasn’t obvious that the session had been killed in the background.

Anyway, some research led me to a perfect explanation of the problem, and an equally perfect solution: Flash is sending a different user agent string, which was resetting the CakePHP session. I’m still not sure why it was only affecting Internet Explorer, but at any rate, a simple change to the app/config/core.php file solved the problem in a snap. The critical line:

Configure::write('Session.checkAgent', false);

I suppose by removing this line, the application is ever-so-slightly less secure, but there should be enough other precautions in place that removing the user agent check as part of the process of validating a session should not pose a significant security risk.

Internet Explorer and transparent CSS layers

Here’s the scenario: I’m working on an image gallery for a client site, sort of a slideshow concept. The client wants the user to be able to click on the left half of the current image (“slide”) to move to the previous image, and on the right half of the current image to move to the next.

OK, no problem.

In the days of yore, I might have handled this with an imagemap. But my solution now, drenched in jQuery goodness, involves a pair of empty <div> tags, with set dimensions, absolute positioning and z-index in the CSS. These transparent <div>s are overlaid on the image, and the jQuery code triggers a refresh of the HTML code in the slideshow <div> itself, underneath, that contains the <img> tag for the current “slide.”

If you’re not a web developer that last paragraph is probably little more than a steaming pile of (to follow John Hodgman‘s lead) “bullroar,” but the point is that this allowed me to stick to semantic HTML (more or less — there is a chunk of JavaScript code directly in the page, but I may optimize that out of there soon), and keep most of the presentation in the CSS and the functionality in a separate JavaScript file, the way it should be.

Only it doesn’t work in Internet Explorer.

“It doesn’t work in Internet Explorer” is nothing new to me, and in fact I wasn’t totally surprised by that. My first hunch was that IE didn’t like the empty <div>s, even though they have dimensions specified in the CSS, so I gritted my teeth and stuck   inside each one. Didn’t help.

Next I decided to make sure my dimensions were being interpreted properly, since it seemed clear that they weren’t: when I say it didn’t work in Internet Explorer, that’s only a half-truth. It didn’t work properly in Internet Explorer, but there were clickable areas on the slide — they were just really small and not in the right places.

So I set the background of the “previous” area to red and the background of the “next” area to blue. Reloaded in IE. Yep, the dimensions looked perfect — my photo was now covered precisely by equal-sized red and blue rectangles. And, curiously, the links worked properly now. I thought maybe it was just because I had added some CSS code for these <div>s in my IE-specific stylesheet (yeah, I do that… get over it). So I changed them both to transparent within the IE-specific stylesheet, and the problem reappeared.

And then, it hit me. No… could it be?

Yes, it could: IE was just ignoring the presence of those z-indexed <div>s simply because their backgrounds were transparent. This is probably a “known issue” with IE, but I had never had to deal with it before, and regardless, it sure as hell didn’t make any sense.

My solution? I went for a play straight out of the book of web design circa 1997: a one-pixel transparent GIF. Except I used a PNG, but same thing. I made a completely transparent image, and in the IE CSS file, I used that as the background for these <div>s.

Problem solved. But as is so often the case with IE issues, the solution is so bitterly unsatisfying, so fundamentally wrong, that there is no joy in its discovery. Just the impetus to blog about it.

Fun with site usage stats

OK, “fun” may be an exaggeration, but it is interesting to look at these stats for room34.com courtesy of Google Analytics.

The usage statistics that are always of the most interest to web designers and developers are the web browser and operating system breakdown among site visitors. “Conventional wisdom” is that Windows makes up about 90-95% of most sites’ users (with Mac OS X making up almost all of the rest), and that among Windows users, Internet Explorer is at about 80-90%, with Firefox making up the bulk of the rest, while on the Mac about 90-95% are using Safari and the rest are on Firefox.

The stats for my site paint a much different picture. Now, granted, I am probably by at least a couple of orders of magnitude the most frequent visitor to my site. I can accept that. So that means Mac OS X/Safari should skew high in the results. But just how high? Let’s take a look.

The following are room34.com stats from the past month, January 19 to February 18.

Web Browsers

Here’s the breakdown of web browser usage among my site’s visitors:

Firefox appears to be winning this war, with Safari close behind and Internet Explorer strong, but decisively in third place. Chrome trails far behind in fourth place, but I get a twisted pleasure from seeing Opera disappearing into irrelevance.

Operating Systems

And now for the operating systems:

Well, how about that? There are enough other people looking at my site that Windows manages to still be the most widely used OS, though its 56% share is far below the roughly 92% share it (supposedly) holds among the general populace of computer users. And what do you know, the iPhone is third! Actually, iPhone and iPod should be identified together, since they run the same OS. I’m not sure why Google breaks them out (but doesn’t break out something much more useful: the different versions of Windows). Look at #7: the Wii! Sweet. Those were not from me. I must confess I’ve never heard of Danger Hiptop, but it’s obviously a mobile OS. Perhaps I should care, at least 0.04% of the time. (That works out to about 2.9 hours a month. Considering the average time on my site is about 3 minutes, one could [carelessly] deduce that Danger Hiptop users like to spend nearly 60 times the average amount of time per visit!)

OS/Browser Combinations

And now, all together:

It’s no surprise that the Windows/IE combination manages to land the top spot, but it is surprising that the combo’s share is less than 29%. I’m a little surprised that Windows/Firefox also edges out Mac/Safari, although I should be glad that I represent, at most, about 1/5 of the visits to my own site. (I’m sure it’s actually only about half that!) Fully 12% of visitors to my site are coming to it on an iPhone or iPod touch. That’s incredible. And almost none of those are me. I guess it’s time to make sure I’ve optimized for that platform! I think this represents a turning point in the viability of mobile browsers, and we web designers and developers had best take notice.

Yet another new home page redesign

I’ve reorganized the room34.com home page yet again. If you’re looking at this page and the layout looks totally hosed, you either: a) need to clear your cache, or b) are using Internet Explorer 6.

I still need to test the site in Windows, so maybe there are some other “legitimate” errors on my part, and ultimately I do try to make the site look right in IE6 these days, but… well… that’s all. I’ll be testing the site in Windows within the next day or two and adjusting as needed.

Enjoy!

OK, Microsoft, you’re off the hook…

But not in the way that the Cheat is off the hook.

I fixed the IE6 CSS problem I ranted about yesterday, and it was perhaps one of the more satisfying solutions I’ve encountered where IE is concerned, because all it required was that I remove a few lines of CSS code that turned out to be unnecessary anyway.

My approach to CSS is one of building a solid page structure and then fine-tuning the details until I have exactly what I want. A side effect of this is that sometimes I leave in unnecessary definitions along the way. If they don’t alter the output in the browsers I test (Firefox always, Safari often, IE7 at least once or twice along the way), then it’s good.

But in this case I had an entire definition that was completely unnecessary. It wasn’t hurting anything in Firefox or Safari, but it was doing all sorts of crazy crap in IE6. Naturally, in such a situation, I blame Microsoft.

To be honest it’s not really (entirely) Microsoft’s fault. I have to recognize that I’m building pages to be interpreted by different rendering engines (the latter part of which is where Microsoft’s blame, to the extent it exists, resides). But there are an unlimited number of ways to write standards-compliant code (which I think I do pretty well, most of the time), not all of which lead to the same desirability of output. So if there’s a standards-complaint way to also accommodate IE’s quirks, that’s the way to go. My biggest problem is that my access to IE6 is fairly limited, and IE7, although it has its own quirks, is a lot closer to what Firefox and Safari produce.

So… there you have it. The site should now look good in every major browser currently in use (Firefox, Safari, IE7 and IE6). If not, complain below!

On a side note, Steve Ballmer sticks out his tongue a lot. (Even when you’re not deliberately looking for it.)