« Book-shifting day, plus the Chicago Seven trial | Main | Eight hours »



I forget whether I mentioned here that the main page of the TSA website crashes Safari. If you're using Safari and you want to see it crash, just make sure you don't have any unsaved data in any Safari windows, then go to http://www.tsa.gov. (I'm not linking to it so nobody will click the link by accident.) Fortunately, some other pages on the site work fine in Safari, so even Safari users can view things like the permitted and prohibited items list.

I reported this to both Apple and the TSA back in August. I gather that it's fixed in a nightly build of WebKit, so presumably the fix will be part of the next major release of Safari. I got several automated "we've received your email" notes from the TSA, and then no further response.

I didn't think about it further 'til tonight, when I received a completely generic email from the TSA that said, in part:

Thank you for your e-mail message. So that we can better assist you we encourage you to call us at 1-866-289-9673 for assistance.

Even though it was way past normal business hours, on a whim I decided to try calling them tonight. I got a recording telling me that due to unusually high call volume, I'd have to wait. A couple of steps further through the menu tree, there was a suggestion that I contact them by email, using their website. Hee! Later, I was informed that my wait time would probably be under 30 minutes. I considered waiting, but decided I might as well try again in the morning. I doubt anyone who'd be on duty this time of night would be able to do anything about the problem anyway.

~A sterling example of customer service.~ Take ten weeks to respond to email, then respond with a form letter telling the customer to call a phone number; then make sure that the phone lines are understaffed. Aren't you glad to know these are the people in charge of keeping our air travel safe?

I'm almost certain that when I do get through, I'll have to spend ten or fifteen minutes explaining to them what Safari is, what a Macintosh is, why I can't just use Internet Explorer, and that I don't just want to be told a list of what I can't take on an airplane, I want them to fix the problem. And then they'll tell me there's nothing they can do, and to go talk to Apple. Oh, joy. Maybe I won't bother calling.

Anyway, having forgotten that I'd heard that the problem was fixed in a future WebKit, I decided to try to track it down; I figured it was an image bug of some sort. After a fair bit of confusing poking at the relevant files, I eventually figured out that in fact it's a CSS rendering bug--and it's dependent on a very specific set of CSS boxes being set up in an extremely particular way, resulting in Safari apparently trying to render text in a particular place outside of a visible area, resulting in a crash.

Unfortunately, in my zeal to track down the problem, I copied the relevant page to my local machine, and then reloaded it a bunch of times. Which presumably caused TSA to receive a bunch of mysterious requests for all the assets loaded by the page--the images, the JavaScript code, the Flash file, the CSS files. Which means TSA's server logs are going to show a whole bunch of requests for those items coming from my IP address.

So if I disappear tomorrow, and you come by my place and find my door busted in, and you eventually learn that I'm being held as a terrorist, you'll know why. Kids, let this be a lesson to you: always download local copies of the asset files so you can experiment on them without sending requests to government servers.

. . . I'm joking (I don't actually think I'll be disappeared or even accused of terrorism), but I'm honestly mildly worried that someone will notice the odd series of requests and will think I was somehow trying to hack their server. With anyone else it probably wouldn't be a big deal, but we're talking Homeland Security here; I may end up having to do a lot of explaining to someone. On the plus side, if their response time is anything like their customer-service-email response time, I won't have anything to worry about 'til around New Year's.

Anyway, just so my work won't be for naught, I figure I may as well post the minimal reduced version of the CSS and HTML here. I've removed all TSA content and assets from the reduced version; pretty much the only thing this has in common with the original is the names of the CSS classes.

The remarkable thing is just how fragile this bug manifestation is. If TSA were to change a single number in any of five different CSS classes, the page would stop crashing.

The other funny thing is that the original CSS had a long comment in it about browser compatibility, including a note about having to do something a certain way to make Safari work. So apparently they did test it in Safari, but didn't see the crashing bug.

But that's actually plausible; due to the nature of the bug, it's possible that the following code won't crash Safari unless you happen to have the same default font and font-size settings that I do; a change of even a few pixels may result in no crash.

Here's the listing. If you save it as an HTML file and open it in Safari, and if your settings are close enough to mine, and if you're very, very good, and if you're pure in heart and say your prayers by night, and if you're not somehow using a more recent version of Safari than mine (which is 2.0.4), then Safari will crash. Whee! Again, be sure you don't have any important unsaved data in an open Safari window before you try this.

For extra credit, after you've verified that it crashes, try changing a single number anywhere in the file (without changing anything else). Chances are good that it will no longer crash.

<style type="text/css">

#fixedpage {

#home-col-a {width:100px;
	margin:0px 0px 10px 0px;}

.stamp-last {width:50px;

#home-col-b {width:101px;

#inthenews {width:100px;

<div id="fixedpage"> 
  <div id="home-col-a"><p>a</p>
    <div class="stamp-last"><p>text</p>
  <div id="home-col-b"> 
    <div id="inthenews"> 


Do you think it would be reasonable for the TSA people to tell you, "it works with Firefox"? I've seen a few websites that do this, and it doesn't bother me that much. I keep a copy of Firefox around as my alternate web browser for those problem sites, including some which seem to have problems with Safari but don't bother suggesting an alternative. (For instance, it seemed to me that after visiting one particular site, Safari was noticeably slower until I quit and restarted it, while Firefox works fine with it.)

The problem is that there isn't any way for the TSA people to communicate to me, as a Safari user, that the site works with Firefox (unless I call them on the phone), because loading the main TSA page actually crashes Safari. It's not just that it doesn't look good, or doesn't display all the content; it actually causes Safari to crash.

Sure, I can try another browser (I prefer Camino to Firefox), and then I would be able to see such a notice, but that's no help to the people who don't know to try other browsers. Their experience is just that they go to the TSA's website and their browser dies.

Also, the TSA's CSS files make clear that they actually do intend the site to work with Safari; they have a comment specifically referring to doing something in particular to help with Safari. So it's not that they don't want to support Safari; it's that they've inadvertently run afoul of a rendering bug. It's even possible that they've tested their site with Safari and that the specific settings for things like font size in their copy of Safari cause the crash not to happen.

Thanks for posting this ... it helped me solve this problem happening on one of our sites, Austin360.com. In our CSS, we had this:

.ent_news img {float: right; margin-left: 10px;}

and when we followed that image with an H3, it would crash. I could put in a <br /> or an H4 and it was fine, but that img follwed by an H3 was no go. I ended up changing the margin to 12px and it worked.

Very, very strange.

Post a comment