The following is an all too real account of what happened to our site, hackingui.com, over Thanksgiving weekend.

Out of nowhere the site stopped working.

At first I thought it was an issue with our hosting company, because we had a lot of problems with them in the past. Our service was interrupted on three separate occasions and this had all the symptoms of a typical issue on their end.

When I tried to access HackingUI.com I saw just a blank, white screen. Sometimes after refreshing the page it would load, albeit very slowly, but then it was almost impossible to scroll. All of the hover effects were missing for links, and I couldn’t click on anything to navigate to another page. It wasn’t just on the home page, it was on all of the post pages as well.

So I opened up the Chrome dev tools to see what was going on under the hood. All of the HTML was there. It loaded correctly, and I could see all of the elements that were supposed to be on the page.

I checked the error logs in cPanel, nothing. Damn.

That meant that this time it wasn’t our hosting company’s fault. The denial phase was over, and I began to accept that we had a serious problem on our end. So feeling all sorry for myself about some shitty code I must have wrote, I started to debug it.

The Debugging Process

I first checked for JavaScript errors in the dev tools console, nada.

Hmm no JavaScript errors and no server errors. I wondered what it would like in another browser. I opened it up in Firefox and everything worked fine.

Things were starting to get really weird. I hadn’t pushed any new code to the site in more than a week. Moreover, the site had worked fine for the past year, how could it suddenly just stop working in Chrome?

I googled “site scrolls slow in chrome” and  saw one post that mentioned background-size: cover could cause issues. We have a full-screen featured image that loads on every page and uses background-size: cover to make it responsive.

I removed that line of CSS, still nothing. Maybe it could be some other over-ambitious use of a CSS3 property? A transform that was really heavy and hogged the CPU or something of that nature?

That full-screen background image is something kind of unique, so I continued to play around with the HTML and CSS around it. When I added display: none to the image, the rest of the site worked fine. Aha!

So I started removing CSS properties on the image one by one until I found the sneaky bastard: 

box-shadow: inset 0 -360px 360px -160px #000, inset 0 290px 330px -160px #000;

That single line of CSS rendered our entire site unusable!

How I Fixed It

This box-shadow wasn’t just there for aesthetic purposes, it provided a dark background for the post title text and navigation menu, and without it they were both unreadable.

I needed to add that shadow effect back, so I created it with two position: absolute pseudo elements and some background-image: linear-gradient magic.

&:before, &:after {
    content: '';
    position: absolute;
    left: 0;
    width: 100%;
}
&:before {
    top: 0;
    height: $headerHeight + 20px;
    background-image: linear-gradient(#000, rgba(0, 0, 0, .6), rgba(0, 0, 0, 0));
}
&:after {
    bottom: 0;
    height: 40%;
    background-image: linear-gradient(to top, #000, rgba(0, 0, 0, .7), rgba(0, 0, 0, 0));
}

The effect is about the same. It gets the job done, and the post title text and nav menu are readable again.

It’s not perfect though. With box-shadow I had the ability to frame the inside of the rectangular image perfectly. With 2 linear gradients, I can only give shadow to the top and bottom parts of the image. I thought about using a reverse radial-gradient, but that gives the image a sort of fish-eye lens look. Too prominent for what we wanted to do here.

So What the Hell Happened?

This wasn’t code that I recently changed, and even more infuriating, this was pure CSS. This is a real, live Chrome regression issue that was introduced in the latest version of Chrome, M39, and was first reported on November 26th.

Apparently there is an issue calculating inset box-shadows with large numbers. I see the browser starting to lag at about 200px or so. The issue doesn’t affect the default positioning of box-shadow (outset), only when inset is specified.

You can see it reproduced in this Codepen on Chrome. I won’t embed it in this post for obvious reasons.

Try scrolling up and down in the viewer and depending on the speed of your computer you’ll see the browser start to lag more and more. Make the box-shadow larger, try 1000px, and it will become completely unusable. Then just comment out the line of CSS that has the box-shadow and you’ll see the browser snap back to life. 

I imagine tons of other sites must have experienced this same problem. I personally saw that The Toyota France website was affected, and they have since removed the box-shadow from their main image in order to fix it.

Conclusion

A few years ago, a bug of this nature on the box-shadow property would have been acceptable, even expected. But nowadays almost every CSS3 property is considered safe to play around with and use in production.

Furthermore, such a large box-shadow might seem like an edge case, but it’s really not. A 1980px background image is extremely common on large screens, and there’s no better way to frame it then with box-shadow. I seriously hope the Chrome devs fix this one soon.