Safari's Lazy Repaint Bug on iOS 7

Last week, iOS 7 finally saw the light of day. For Apple, it was an important step away from their original mobile design paradigms. I, on the other hand, was looking forward to the new Safari (which always comes bundled with major iOS updates), at least until I actually took it for a spin. Apart from some dreadful UI problems that are sure to haunt us in the coming months, I saw some rendering bugs I really wish I hadn't.

It's not entirely unnatural for stuff to break with a new browser update, yet one problem in particular stood out as quite perplexing. For some reason, the main navigation flyout on my smallest responsive view had stopped working. Rather than fail completely, the entire flyout just wouldn't appear unless you started to scroll a little, after which it reappeared where it was supposed to be. The thing that got me worried is that the code I used to make this flyout work is incredibly basic.

body #site {right:-17em; width:17em; position:fixed;} 
body.showSite #site {right:0;} 

Of course I have some extra CSS on there to make everything transition more smoothly between states, but even with that bit of code gone, it just wouldn't work. It didn't take me very long to remember a similar bug I once encountered, though. A nifty little bug on the Android Stock Browser I often use as an anecdote to illustrate what a crap browser that really is.

What happens is that browsers are getting a little too lazy for their own good. When a class is set (or removed) using javascript (and especially when it is set as high up the DOM tree as the body element), they pretty much have to run through the entire page to check whether one or more elements are impacted on CSS level (the extra class might trigger some extra selectors). In order to save time, some browsers are attempting an educated guess. Some attempts fail, painfully, which happens to be the case on Safari for iOS 7.

There are basically two ways to fix this. The first is to make sure the class is set on the element that is affected (you might even gain a minor performance boost), as the browser knows it should at least re-evaluate the element that received the extra class. Not too difficult, but not always possible when multiple elements on a page are affected by a single state change.

 body #site.showSite {...} 

The other fix is to force a repaint on the element with JavaScript. On Android Stock Browser, you could fix things by applying zoom:1; (which felt rather appropriate), and on the latest Safari for iOS z-index seems to do the trick.

 $("#site").css("z-index", "5"); 

It's a bit worrisome to see such bugs introduced in the latest update of what is one of the oldest browsers on mobile. I understand the pressure they face to improve performance with each new iteration of their browser, but this clearly shouldn't go at the expense of faulty rendering/lazy repaints. This really is basic CSS that shouldn't be allowed to break, but sadly, I don't expect to see a fix for it any time soon.