When Browsers Attack!
Published 19 years, 7 months pastRemember my recently posted conversation with Molly? Boy, am I ever feelin’ that today. In spades.
Some of you have noticed earlier today that things were presentationally unstable. Depending on when you dropped by, you would have seen raw document presentation with no author styles at all, or some chunks of the site’s usual styles but not others, or all of the usual styles with a few oddities thrown on top for good measure. For a few hours, during which I had to attend to something else, the site was fine except that in IE/Win, the main content column was quite a bit wider than usual, and some bits of content were visually exceeding the edges of the design box. All that was happening because I was turning styles on and off in an attempt to stop freezing Internet Explorer for Windows.
Freezing? Oh, yes. As in locking it up so that people had to use the Task Manager to force-quit the process. There were probably a few reboots out there as well; there were at least a couple here in Casa de Meyer. Ordinarily, I’d apologize. Not this time. If you want an apology, try finding the person or persons responsible for IE’s CSS handling, and demand an apology from them. I’m not taking the rap for this.
To set the stage, let me back up a couple of days. As I passed by Kat’s office, she called out, “Hey, how come my browser keeps getting screwed up?”
“Because it’s Explorer,” I said. “Next question?”
“Ha ha. Seriously, every time I try to view your ‘ten things to do in Cleveland‘ post, the computer crashes. I think there’s something wrong with it.”
Grumbling, I wandered over to her computer. Sure enough, the browser was completely frozen. She’d already called up the Task Manager and was forcing the browser to quit. She said it was the third time she’d had to do it. As I watched, the screen went blank, then drew the desktop color and stopped. The cursor appeared as an hourglass, and refused to change or even move.
Once the system had gone through a hard reboot, I fired up Netscape 7 and loaded up meyerweb. I surfed around to various posts. No problems at all. I then launched IE and loaded up the home page. No problem. I went to the offending post. Instant freeze.
After a few more invocations of the Fatal Freeze, I wandered out of her office again, muttering about Explorer and Windows and pondering the possibility that her computer had been infected with some kind of virus, malware, or other nastiness. But then, the next day, I got some e-mail reporting similar problems. Then Ian Firth managed to get a comment in about the problem on the post “Really Undoing html.css“, even though others were getting the Fatal Freeze on that very post. And he mentioned that it was happening in both IE and FeedDemon—which meant it was something in IE’s rendering engine, since FeedDemon just wraps itself around the engine. A similar report cropped up in the FeedDemon forums this morning, where it was mentioned that a similar problem had already been seen in the post “Standards Savings“. (Not that anybody had actually bothered to tell me, but hey, whatever.)
So I fired up VirtualPC this morning and tested the problem for myself. And sure enough, I was very quickly the latest resident of Lockup City. So I started narrowing down the cause. I’ll spare you all the nasty details (and foul language) of my bug hunt, and cut to the chase: the lockup was happening on entry pages where the post content included an element that used left padding. Blockquotes and lists were the prime triggers. There wasn’t an absolute 100% guarantee of trouble, but it was close. I could avoid the freeze by commenting out a single declaration in my main style sheet:
#main {
margin: 0 15em 0 0;
/* padding: 3em 4em 3em 4em; */
border-right: 1px solid #AAA;
background: #FFF;
min-height: 30em;
}
That’s why the content was running rampant earlier today. I had to leave that line commented out for a few hours. But I knew that couldn’t be the real cause, because it didn’t cause freezes on the home page, or even on monthly or daily archive pages. The freeze only happened on an individual entry page where there was a padding-indented element inside the content column. Thus, the source was most likely to lie in style sheet that’s applied only to post pages.
So I started digging through my entry style sheet until I narrowed the problem down to this line:
.prev-next {margin: 0; padding: 0.25em 1% 0;
float: left; width: 98%;}
If I commented it out, and uncommented the padding declaration from before, there were no problems. So the culprit lay somewhere in the .prev-next rule. Anyone want to guess at the cause? Go ahead.
Oh, all right, I’ll tell you. It was float: left;. As soon as I removed that declaration, the IE6 freezing problem just melted away. So if you’ve encountered freezes while trying to view entry pages in the past, you shouldn’t any more. (If you do, please comment on this entry with the exact browser and OS you’re using.)
The original point of the float statement was to get the unordered list to wrap around the floated list items within it, since floated elements wrap around floated descendants (for more details, see my article “Containing Floats“). Since that was apparently a recipe for disaster, I modified the rule to read:
.prev-next {margin: 0; padding: 0.25em 1% 0;
width: 98%; height: 1em;}
It isn’t exactly the same as what I was doing before, but the result is close enough for now.
What else might I have done? Well, in all honesty, I thought seriously about leaving things status quo and letting IE users go hang. I don’t cater to potential crash bugs in NN4, for example; why should I make an exception for another browser? But as I always knew I would, I grumbled a bit and then made an accommodation for IE. I may one day restore the float for more modern browsers and use some sort of hack to hide it from IE/Win, but for now I’ll leave things be.
What’s odd to me is that the styles involved in triggering this problem have been in place literally for months. If this was a problem, it should have arisen before now. Yet the first I heard of this freeze bug was two days ago, and then all of a sudden I was hearing about it from multiple sources. If I’d been updating my CSS, that would be understandable, but I wasn’t. So what happened? Did the installed Explorer population just get spontaneously and collectively buggier over the weekend, or what? Is there a subtle worm running around adding bugs to IE’s rendering engine? I’m really at a loss here.
As to why that particular combination of styles would cause IE to freeze up, I’m completely at a loss. Not a clue in the world.
While I was mucking around in the CSS anyway, I decided to see if I could fix the rendering error in IE/Win that made the sidebar hang out over the vertical separator. I did, so far as I can tell. The problem there was the “Exploration” box and the styles I’d applied to it. Apparently, if you set a form element to width: 95%; margin-left 5%; and then set a text input within that form to width: 100%;, it all adds up to something like 120%, or something. So I did a little bit of a hack to hide the input element’s width value from IE/Win. The input box won’t be as wide for IE/Win users, but as far as I’m concerned that’s an acceptable loss.
I hope your morning was substantially less frustrating than mine.