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!
My process was to copy the page that was crashing and then slowly remove stuff until it got the point it wouldn’t crash anymore. I got to the point where I removed one comment from the comment thread and it stopped crashing. Those two documents represent as close to the tipping point that I could get. They both have all JavaScript removed. They both use the exact same CSS.
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.
Chris, just to let you know, on iOS 6 (beta) Safari &/or Chrome it doesn’t crash when loading the comments.
One thing of note though and it caused some distortion is that if the commenters name is too long it screws with the layout of the page. Don’t know if that might cause trouble as it would effectively be resizing everything centered around a singular comment?
Image: http://d.pr/i/NOLJ
{
word-wrap: break-word;
}
FYI: There is something different about each version. Load up both pages in Chrome, and keep your eye on the scroll-bar. Tab between them. There is some content in one that is not in the other, by the looks of things.
I’d try debugging further, but that’s a LOT of page to scroll through to play spot-the-difference.
Yep that’s exactly the difference. In the non-crashing version I removed one additional comment from the page.
Quicker to use WinMerge to compare – files are identical except for the yes-crash has an additional block of code between lines 1359-1475. So the problem is most likely going to be in those 110-odd lines.
It also includes the use of gravatars, like andyunleashed mentions in a later post.
First thing I’d try is removing the comment section entirely and re-testing to see if it still crashes. My bet is there’s some funky stuff going on in there.
It does not crash if you remove the comment section. That’s the heart of the issue here. One additional little comment can create the tipping point between not crashing and crashing.
It might be worth trying a factory reset and reload of your iPhone too. I was beta testing a product a few months ago and it used to crash without warning on my iPad. After some hunting, I found that mobile Safari would also do this, but reseting and reloading apps seemed to fix it. It might not fix all cases but fixed mine.
As best we could work out, installing and deleting apps without an occasional reset essentially leaves the memory fragmented (just like hard drives used to) and you get crashes without proper exits and safeguards.
I’m totally down for solutions like that, but in this case, it wasn’t isolated to just my phone, it was lots of people reporting the problem on a variety of devices.
By the way – Chris if it’s happening to you on your iPhone, go to Settings > About > Diagnostics & Usage (down the bottom) > Diagnostics & Usage Data. Look for the Safari crash reports in here it should have details in there about exactly what might be causing it.
Verrrry interesting.
This looks to be the relevant crash report: https://gist.github.com/3691938
Screenshot of errors: http://cl.ly/JLo2
“Jettisoned” in the crash report means it was terminated by iOS – basically, most likely to free up memory.
“Count” is the number of memory pages so in this case 12131*4(kb)/1024 = 47.38MB of memory was being used.
Now why it’s using 47.38MB of memory to load the page – that I don’t know!
Just found this, might be relevant – http://stackoverflow.com/questions/11462691/rapidly-setting-image-srcs-with-dataurl-causes-memory-leak
You doing anything with dataurls for images loading in comments?
Have you tried disabling gravatar just to see if any effect?
It works just fine in both Chrome 18 for Android and the Android stock browser (on a Galaxy Note, 4.0.4).
The page is very long, maybe too much for mobile browsing standards, but it loads just fine.
(On a side note, the text of the “Submit Comment” button looks awful on Chrome 23 dev on Windows XP.)
Hi Chris,
If I had to guess, I would agree with @andyunleash. When I first came to the redesign from my iPhone 4S, it did crash my browser. Could you maybe try force crash the browser by adding elements to the working version (preferably not to the comments section as you have isolated that as the area causing the issue). Now if it is a memory issue, surely increasing the document size will cause it to crash? If increasing the dom size outside of the comments section does not cause the browser to crash, then your problem lies in your comments.
Could the way you are caching your site be effecting mobile browsers? I know they handle these things different.
Just a note, The menu also craps out in Windows (My mac is at home) Safari 5.1.7 (cuts off the last two as you shrink)
I know this is not in any way associated with this issue, but I figured since you were attempting to debug…
Also crashes Chrome 21 on window drag & resize on my Windows 7 machine. Just thought you might like to know.
Weird I have not been able to get this to happen on my win7 box in chrome 21?
Chrome 21.0.1180.89 m hangs the tab, though its closeable, when re-sizing quickly/violently.
I also don’t really like how the whole page resizes/zooms when resizing the browser window.
Hey Chris,
On mobile Chrome on my Samsung Galaxy S 2 the page does not crash
Browsing the site on my iPhone 4s with iOS5.1 and have no issues, currently still have 120mb/s of memory free
Ho! On my Nexus 7 running Android Jelly Beam, it does not crash using Chrome. However, when typing this comment it runs – all of a sudden – very very slow ! Maybe some script is screwing it ? Which I think is the comment preview
Did you try to reduce your CSS instead of removing it entirely? For example, start with removing transitions, then remove gradients, then Media Queries, then half of stylesheet, then another half, etc. Well, you should know that well. ;-)
I’m noticing a pretty significant performance boost on my 17″ macbook pro by removing the box-shadow on .page-wrap::before, .page-wrap::after
I was seeing choppy scrolling and delayed typing that all goes away when you remove it.
excessive use of box-shadow has been known to cause problems with rendering. Especially when tied to transitions & animations.
Actually I just found this: cubiq that says box-shadow effects Retina displays particularly worse.
Without checking out the pages, and TBH only skimming the article I am willing to bet $1 that it is an inset box-shadow issue. Do you use inset box-shadows anywhere?
On my Windows Phone 7.5/IE9 it did not crash. But the comments section loads kinda slow. When scrolling down, bits of the ads will overlap comments briefly, for 1-2 secs, before getting adjusted. After maybe 20-30 secs this stops happening (once everything is loaded into memory, i suspect).
Unrelated observation: the icon font for the navigation is not loading. What I see in place of icons, are large letters (almost touching the top & bottom of the buttons) set in Segoe UI Light, the symbols being: k, 9, Q, p, q, ó, w, 6. Also occasionally, tapping on “Navigation ‘n’ search” would jump directly to one of the links (twice to gallery, once to forums). Perhaps I just unwittingly tapped twice-ish, can not reproduce reliably.
I had a similar problem with iPad and long forum threads. Still have some problem, but not as much. But I did find out that fading in a single button with -webkit-transform made the site crash.
Still don’t know why that would only crash the browser when I had 100+ comments.
If there is a solution, it would be nice to twitter that oder make a new blogpost.
The site is working fine on my iPhone 4S (Safari), and I also checked out iOS Chrome and it’s working great there too!
did you play around with backface-visibility?
Just read & follow the Article :)
Got my mobile safaris (iphone 4s/ipad3 latest ios) crashing today as well with long page that used border-radius on one element. After removing that one css-definition, everything works perfectly.
I’m posting this from my iPhone 4 with iOS 6, only issue is that one of the commenters has their email as name, it is so long that the main column is reduced to taking up about 2/3 of the width, the rightmost 1/3 is dark gray.