Mobile Safari on iOS crashes on big pages

Asked 6/8, 2012 at 15:37 Answered 14/7, 2023 at 2:5

Solved javascript css debugging mobile-safari

I have a problem where Mobile Safari crashes when loading and manipulating the DOM with jQuery when the pages get too big.

I get the same problem on both iPhone and iPad.

What are the best way to troubleshoot mobile pages to find the error? Are there any known problems that might crash Mobile Safari?

Subtype answered 6/8, 2012 at 15:37 Comment(4)

What is too big? Is it reproduceable? Do you have a working example to shows the crash? Did or can you test on other browsers (Chrome, FF)? Same issue? – Grantor 6/8, 2012 at 15:42

It's a forum site and it always happens when a thread gets more than about 100 comments. I don't get this on any desktop browser I've tested, but always on mobile safari when the user is authenticated. – Subtype 6/8, 2012 at 15:56

I think I've narrowed it down to a chunk of JavaScript code, but I still dont really understand what's causes this. I'll guess I have to remove everything and then enable bit by bit and see when it breaks. – Subtype 6/8, 2012 at 15:59

A repeatable example is the home page of obviously.com and it happens regardless of the amount of free memory in the iOS device. – Lazy 26/12, 2013 at 7:34

I actually found the problem. It wasn't with JS as I thought, but with the CSS. I added class to make a CSS transition to fade in some elements. For anonymous users these elements had display: none; and probably never ran the opacity transition.

The strange thing is that the transitions was on exactly two elements. So why would this only crash on long threads with 100+ comments?

So the bottom line is: -webkit-transition crashed the page on mobile safari.

Subtype answered 6/8, 2012 at 17:46 Comment(0)

Had the same issue, for me it was -webkit-transform: translateZ(0); that caused the crash of Safari.

Tonsorial answered 29/11, 2012 at 10:24 Comment(0)

I know this question has been successfully answered but I just wanted to put my five cents in too as I have been banging my head against the wall over this one quite a few times:

As most answers have pointed out already it usually comes down to memory issues. Almost anything can be the last bit that finally tips over the "memory pile" much like a translateZ or anything else.

However in my experience it has nothing to do with the actual CSS (or JS) command in specific. It just happens to be that the last transition was one too much.

What tends to help me a lot is to keep anything that is not visible at this time under display: none. This might sound primitive but actually does the trick. It's a simple way to tell the renderer of the browser that you don't need this element at this time and therefore releases memory. This allows you to create mile long vertical scrollers with all sorts of 3d effects as long as you hide elements that you are not using at this time.

Francophile answered 14/2, 2013 at 1:45 Comment(2)

how do you hide anything that is not visible at the time? Is there some JS way to do this? – Toupee 28/1, 2016 at 23:56

@bphilipnyc there is, but you have to manage it manually. There is no super straight forward way to simply hide all none visible objects. Essentially you have to write the logic that keeps track of what is on the screen and what isn't. Without knowing your general site structure, it's hard to tell what the quickest way to do that is. – Francophile 30/1, 2016 at 20:5

The main issue with any iOS app is memory usage. So, it is likely that your pages are using too much memory.

Mobile Safari use some clever technique so that not the whole page has to reside in memory at any given time, only a portion of it. Maybe you could check if anything in your page defeats this mechanism or makes it less effective.

In any case, to give more up to the point suggestions, more information about your page would be really great.

By the way, you could have some hints from the crash log that the device store. Check to see if you can find it under Settings:

General
About
Diagnostics & Usage
Diagnostics & Usage Data

If it's a memory problem, you should find something like "signal (0)"; not sure if this can only mean "killed due to memory usage", but I usually take this for granted when I found a signal (0).

Otherwise, it might tell you what is wrong...

Hope this helps.

Soulless answered 6/8, 2012 at 15:41 Comment(1)

How could you, as you say, "could check if anything in your page defeats [Mobile Safari's clever memory-saving mechanism] or makes it less effective"? – Security 10/1, 2014 at 23:28

There are both memory limits and Javascript execution time limits, though it's a little fuzzy as to how you may actually hit those. Common reports come in that a page with a size greater than 10MB will have issues, and Javascript execution is limited to 10 seconds.

See Apple's documentation for more info.

Pancho answered 6/8, 2012 at 15:42 Comment(4)

This is an inevitable consequence of an embedded platform without swap. Once main memory is full, out-of-memory errors are going to start occurring. If 10MB sounds quite small, remember that Safari can have quite a few open in tabs at any one time - although it quietly discards page contents of hidden tabs in response to memory pressure. – Illuminometer 6/8, 2012 at 15:50

@Marko This is an obvious Safari bug and a potential security issue. Applications are required to free as much memory as possible when the system notifies them and not crash. Safari should maybe take snapshots and display them when it's out of memory, or even disable images or truncate pages when it's just too much. (Off-topic note: Swapping is horror under SSD. That's why I bought the largest RAM for my SSD-equipped MBP. So I can prevent swapping as much as possible. Good for Apple never enabling it on our mobile devices.) – Talich 6/8, 2012 at 16:10

The memory and time limits seem to apply only to JavaScript. There are also a few limits on canvases and JPEG. Hitting a limit stops the webpage, not Safari. Clearly, Apple should've put more limits to prevent crashes. – Talich 6/8, 2012 at 16:14

This is only a security bug if it is crash rather than the operating system terminating the process due to resource limits being hit. This latter conditions is a very common fate for iOS applications. I can assure you swapping isn't a lot of fun with the regular kind of hard-drive either! – Illuminometer 6/8, 2012 at 17:13

I recently had an issue with mobile safari crashing on web-app pages containing a lot of images (30+ were enough) and a few transformations for the menu. After a lot of trial and error, I settled with a solution similar to what LinkedIn does, but for infinite scrolling using angularjs. I used requestAnimFrame and two expanding/shrinking divs (with js style attributes) on the top and bottom of the list to remove all image containers (with other stuff overlayed on top) except for a few ones which are close to the viewport. Scrolling performance (native, no js) is fine and memory consumption is in check.

Baby answered 27/3, 2014 at 21:38 Comment(0)

I had a similar problem, the web page worked like a charm on android devices and crashed on IOS (iphone and simulator).

After a lot of research (using also the ios_webkit_debug_proxy) I found that the problem was connected to the jQuery ready event.

Adding a little timeout solved the problem. My application was also using iframes.

$(document).ready(function () {
    window.setTimeout(function () { ready(); }, 10);
});

Ancient answered 4/3, 2014 at 17:12 Comment(2)

if ready is a function that takes no arguments, then you can just do: window.setTimeout(ready, 10); – Lavernalaverne 18/3, 2015 at 1:25

Thanks for mentioning ios_webkit_debug_proxy, that's a cool project! – Mcgurn 21/9, 2015 at 21:59

Contributing a bit: This happened to me when I used CSS filter: grayscale. Interestingly, I didn't have a problem with filter: brightness. Go figure.

Inappreciable answered 14/7, 2023 at 2:5 Comment(0)

Recommended topics

Hot tags