Unfortunately, the browser share statistics I gave last time were incorrect. Although I did my best to try to remove erroneous hits from web crawlers, site grabbers, and the like (which don’t constitute valid visitor hits), I overlooked a growing trend in hits from (what I suspect are) botnets trying to exploit URL parameters that may be used to pass in filenames to a script that subsequently includes that file (i.e. executes the file). Of course, none of my scripts have that glaring vulnerability in them, but the zombies try it anyways, creating bogus hits. The reason I missed these hits earlier was that their volume per distinct IP was low enough such that I passed over deleting them on initial inspection of the log data. Of course, crawlers like Google will often have thousands of hits per IP, which is simple enough to identify and remove.
However, swarms of zombie computers weren’t the only reason my data was off. Microsoft’s search engine also uses subversive techniques to get in under the radar. From a huge pool of IPs under 65.55., they continually run bogus searches on sites like mine using a User Agent that doesn’t identify itself as a bot but rather looks like a normal (of course Windows) user. I would just block MS’s range altogether, but I suspect that would just anger their search engine. They may have reasonable motives for doing these search checks (e.g. to make sure sites display the same content to the crawler that they do to a visitor), but it’s an annoying system nonetheless.
Anyways, I present to you the revised graphs from the cleaner data below. Thankfully, it looks like users are moving towards IE7 and away from IE6 more than I previously reckoned. Also, Firefox seems to be gaining on both flavors of IE more than expected. Meanwhile, Safari and Opera are not to be counted out. However, Netscape is still finding a new definition of pain and suffering as it is slowly digested over a thousand years.
To be sure this new data was reasonably accurate, I found a neat site that analyzes internet market shares at major websites. Their data does concur with mine; however, due to my enthusiast-orientated content, I do get a lot more Firefox visitors than mainstream sites. This is perfectly acceptable, though. 😉
Actually, the reason I was looking at the log data again to begin with was because I got interested in Operating System shares after reading a revisit on the suckiness of Vista in MaxPC. Thankfully, I’m not the only one that’s holding out on upgrading my OS until something significantly better comes along. Unfortunately, a lot of people are having Vista shoved down their throats just because they want a new computer. …It’s been a while since everything Microsoft did didn’t piss me off.
Even though Internet Explorer 7’s adoption is on the rise, web developers can’t rejoice yet, as IE7 is still a faulty product in its own right. Since I’ve been testing my new layout in IE7, I’ve noticed more and more a strange scrolling bug. It is characterized by an incomplete scrollbar and frequently stuck mouse wheel scrolling. It wasn’t until I tested my new version of the Deus Ex guide (a very long page) that I realized how much of an issue this bug was. Googling around, I could find barely a mention of the bug on all the intertubes. However, one bizarrely made page (#41: Infinite loop related to overflow and position: fixed) did have the problem outlined quite well on a list of IE7 bugs. Unfortunately, there’s no simple fix beyond scraping the whole fixed positioning layout. Reportedly the only way to remedy the situation was to scroll to the bottom of the page, which could take a poor visitor several minutes to do on my DX guide.
However, after I thought about it for a little while, I thought there may be a way to force the page to scroll to the bottom and then back up in JavaScript on page load. I recently used a scrollIntoView function on my new content system overhaul that did just that. It worked brilliantly. And with a little creative use of the DOM, the script can be dropped into any page with a fixed positioned content frame and overcome this bug automatically. Unfortunately, the mouse wheel scrolling issue remains–can’t fix everything with the DOM.
//trigger this function with body onload and onresize events
function IE7ScrollBarHack() {
//get the main content frame from id
var mainFrame = document.getElementById('main');
var ie7hackanchor;
//check if our span has already been created
if ((ie7hackanchor = document.getElementById('hackanchor')) == null) {
//create a span and append it to the content frame
ie7hackanchor = document.createElement("span");
ie7hackanchor.setAttribute("id", "hackanchor");
mainFrame.appendChild(ie7hackanchor);
}
//scroll down to that span and then return
var prevScroll = mainFrame.scrollTop;
if (ie7hackanchor != null) {
ie7hackanchor.scrollIntoView(false);
mainFrame.scrollTop = prevScroll;
}
}
Of course, it’s probably best if you only print this function in IE7 using whatever server scripting language you have. I usually use something like this (in PHP):
$IsIE7 = preg_match('/^Mozilla\/\d+\.0 \(compatible; MSIE 7\.0/i', $HTTP_USER_AGENT);
