One of the big heart sinking bummers when the new design launched was that the announcement blog post would cause Safari on some mobile devices to crash. It would crash my iPhone 4S, I heard reports of crashing other Android devices, but it wouldn’t crash my iPad 2. Debugging on mobile is already kinda hard but debugging a page that crashes the entire application is extra hard.
So of course, I made reduced test cases!
Here are some details about the two documents.
|DOES crash||Does NOT crash|
|Document Size (un-gzipped)||131K||123K|
|Document Size (gzipped)||20.21K||19.55K|
|# of Requests||98||92|
|Total Page Size||1.42MB||1.40MB|
Another important detail: if you hide the comments section on either one, it doesn’t crash.
That’s what I’ve done as a stopgap solution on the live site. There is a “View Comments” button that you can click to display the comment thread. If you click it on this post, it will crash.
Just because elements are hidden doesn’t mean they aren’t in the DOM, so we can probably rule out DOM size as a crashing factor.
Having all the comments visible does presumably use more memory (probably by a lot) and it also increases the page height extremely tall.
Another relevant fact: removing the CSS stops the crashing. The CSS is only 37K un-gzipped and 7.32K gzipped. It does have some CSS3 stuff like gradients and box-shadows though.
Why am I posting this?
Science! I want to get some more eyes on these reduced test cases to see if we can reduce them even more and discover some root causes to this. Kind of a bummer you can crash mobile WebKit with just some fairly simple HTML and CSS. Perhaps it’s something very simple and then we can spread the word. And for my own purposes, I can fix the dang crashing problem without having to resort to something like paginated comments which I really hope to avoid.