It was a lovely January morning. The sun was shining, the birds were singing, and all was right with the world.
Okay — actually, it was like 33 degrees, the snow was coming, and so was the report of a really nasty bug. So in the tech world of Josh Palmeri, things weren’t quite 100%.
I’ll let the picture speak 1,000 words:
The Finding
I had just arrived at work, set down my backpack, lunch and water. I glanced at my phone and saw that a client (whom I know on a personal basis as well) had tagged me in a post in which she reported the following:
Is anyone else having a problem getting on to the website with their electronic device or phone? Every Time I try on my iPad it says their has been multiple errors and then it says the webpage crashed! I can access the site on my PC by clicking on the link and by google search. But for some reason my iPad won’t let me. It did at first, but suddenly after clicking on the FB link one time it just wouldn’t open and I’ve been seeing that scary message Any thoughts? Could updating to IOS 8 on Saturday have something to do with this?
Ahh, iOS 8… The wheels began to spin in this brain o’ mine. Oh the possibilities.
Now, I’m not a downer, but I just haven’t been thrilled to jump at each new release of iOS over the past year or so. Just my preference. (Before this issue, I was still running iOS 7, and mighty fine with that, so long as I had SauceLabs to check out iOS 8*)
Where to start
Where to start… well, there were a few places to start looking in my mind…
Google! I started searching for that “A problem occurred with this webpage so it was reloaded.” error that I had never once before seen.
Okay, it has something to do with the page reloading… what could be causing that… looks like the tab is actually crashing causing Safari to reload the tab in 3 total attempts before giving up and spitting out this error message.
I thought the culprit may have been one of these, being that they are more newly-developed pieces, yet were functioning as expected on iOS 8 on another major site I am running.
- The Filename Based Cachebusting Script that I had written with the help of some phenomenal resources and research done by my colleagues in the web community (post on that coming soon). Basically, a last-modified timestamp is appended to the css filename in each <link>’s href value. Apache then sees main.12345678.css and calls for main.css, allowing newly modified files to be refreshed in the browser’s cache.
- Any other Apache Rewrite rules that were used. E.g. redirect www.abc.com traffic to abc.com.
- My cat ate my code (more like scratched it till a semicolon fell off the end of a line in JavaScript).
And so, I started on an hours-long journey testing by process-of-elimination.
I opened up my .htaccess on the server and yanked everything, saved a blank file back to the server. Look at that — my site worked! No styles, but it loaded.
Ahh, it must be something in here! Nice and quick find.
I proceeded to comment out chunks of Rewrite rules at a time. Refresh my iOS simulator, wait for it to load…
OK, while I’m here… I love SauceLabs… but the time it took to test on there was mind-boggling. I couldn’t clear the cache in the same simulation instance and had to quit and reboot another VM each time. (Remember I said I wasn’t running iOS 8 on my devices? :-D)
Anyway, I had effectively used up my lunch hour first-thing-in-the-morning on a quest to “quickly" fix the site.
Back At It
When “later on” came, I resumed my quest. Well, more like, started fresh, which often proves to be the best thing when tackling a pesky bug. Hack at it till you’re not sure which end is up, then put it down and come back later.
Google again. That pesky error… iOS 8… Safari… search, browse, test, repeat…
I’m determined and I will conquer this! God, please give me your grace.
And He did.
Okay… clear my iPad photos to get enough space… backup iPad… install iOS 8… set up installation… clear browser cache… open Safari… check it out… yup, got the error. Cool, I successfully reproduced it (that wasn’t very hard). Now let’s check Chrome… hm, crashes with no error… Mercury? Same deal, crashes…
Based on my findings here, thoughts began to spark:
- A memory issue. Hm, it’s happening on Safari, Chrome, Mercury… any web browser on my iPad iOS 8. (iOS 7.1 was showing it fine.)
More searching… more breadcrumb trail… on one forum, davidtheclark was saying something about CSS where using position:absolute and shoving the item off-screen was using up a lot of device memory and causing a crash. Oh, that sounds promising! I use a class that looks like the following.
This allows me to “hide” an item (rather, move it from the viewport) while keeping it accessible to screen readers at its position in the DOM. (Thanks, Chris Coyier.)
Let’s set that just to display: none and see if that fixes it…
Nope.
The Search Continues
A few more attempts…
- Check my PHP includes, just in case. Do some trial-and-error there.
- Start pulling out chunks of PHP includes. Nothing substantial showing there.
- Pull out my CSS includes from the header. (Remember that Filename Based Cachebusting Script? Well, I have a php function creating the correct <link> declaration by setting the href value as needed with that timestamp, then echo-ing the <link> call. Maybe I can’t have php in my CSS on iOS 8? craziness…)
Pulling the CSS worked! I now have a site on iOS 8 that isn’t styled. Cool!
Let’s put those CSS includes back in and pull them one-by-one…
Look at that, main.css is the culprit causing the crash!
Great! Now I open main.css and start the process of elimination.
- Remove everything before my media queries. Yup, it’s something in there.
- Put that back and remove just the helper classes and normalization styles. Yup, getting hotter!
- Put that back and take a look at what I have in that chunk of code.
[Looking for anything out-of-the-ordinary]
Hm… I wonder if it’s those CSS3 animations…
And the class that applies these animations…
As you can see, I have a pulsing-arrow that, well, pulses in size to provide a subtle effect as if to say, “click meeee!” It’s a nifty little effect I came up with. Fallback? Well, if no CSS3, it just stays one size. Fine by me.
I didn’t think that’s what would cause an entire crash… but…
I’ll remove the -webkit-keyframes declarations…
Cut… Save… Clear cache again (oh yeah, after every try on the iPad)… Reload…
BINGO!
I have a website! That worked!
Apparently, the animation was just too much for iOS 8. No pulsing arrow, but I’ll take it. Now, to look further into the specifics on if this is a bug. Seems to me that this shouldn’t be so memory-heavy to have caused my iPad 3 to crash every time without fail (negated pun intended).
I thought maybe it’s the combination of -webkit-transition and -webkit-animation that’s throwing things off, but nope. Even with just the animation property on that class, it still fails.
Okay, so I found the issue, but technically I didn’t really fix anything. I made it work by removing the -webkit-animate property.
Find the Solution
I found a bunch of sources talking about using a hack to force CSS hardware acceleration on the device. However, these attempts failed.
Unsuccessful attempts to resolve:
- "Null Transform” hacks (http://aerotwist.com/blog/on-translate3d-and-layer-creation-hacks/)
- Adding -webkit-transform: translate3d(0, 0, 0); (See http://davidwalsh.name/translate3d)
- Adding -webkit-backface-visibility: hidden; and -webkit-perspective: 1000; (See above link)
- Adding transform: translateZ(0); (See http://blog.teamtreehouse.com/increase-your-sites-performance-with-hardware-accelerated-css)
At this point and well over 6-hours of investigation and debugging, I’m submitting this to Apple to see what they say.
Update
I never did find out why this wasn’t working. Sometimes, you have to come to terms that you can’t know ‘em all. If there are other fires burning, and you don’t know the reason for the cause of the one fire you put out, you just have to tend to the fires!