iOS safari crashing (a problem repeatedly occured)
Asked Answered
T

9

18

I'm developing a website and have recently run into a problem when testing on my iPhone X - the site wont load.

Safari tries to load it, then reports the error 'this web page was reloaded because a problem occured', and after a couple of tries it gives up and reports 'a problem repeatedly occured'. Chrome on my iPhone also doesn't load the site.

At this time I can't share the website publicly, but there are no errors reported in the chrome desktop console. In fact, the website runs perfectly fine on my desktop, my laptop, my old iPhone 6 and 5s, my friends Samsung android, and 15 other random computers and phones I've tested it on. It also loads fine in xCode simulator. But it doesn't work on my iPhone X.

My research across SO and the internet in general has led me to believe this error is usually due to excessive memory usage, but desktop Chrome reports the memory usage peaks at 20mb only. Also the site loads just fine on my inferior iPhone 5s.

I have cleared the safari and chrome caches on my iPhone X, toggled block cookies on/off, reset network settings, and restarted the phone.

My worry is that if my iPhone X doesn't load the site, no doubt other users will have problems, even if the 20 miscellaneous devices I have also tested work just fine.

Does anyone have any idea what is going on here?

Tickle answered 1/10, 2018 at 16:50 Comment(6)
Did you have any progress on this? I'd be very curious to hear... I'm having a similar issue, at the difference that the site loads but any interaction causes the site to crash instantly. Website is working fine on older less performant devices etc.Prow
Yea that sounds like the same issue as me. I just posted my solution.Tickle
Finally got hands on a device - in my case it was because of a single transform: scale(0.5, -0.05); filter: brightness(0.2) blur(50px); declaration. Funny because there was a lot more heavy going on on the page.Prow
I can support the idea that this is due to CSS rendering somehow - I was experiencing this issue but was able to resolving it by removing the keyframe animations on background-position on an element that had altered opacity and scale.Dominate
For me it was an asynchronous api call getting caught in an endless loop, which goes to confirm it's a memory issue most likely. I add "check any API calls" to the checklist. This bug is so weird but that totally solved it for me.Arron
For anyone stumbling across this years after it was asked, see this more recent answer to a similar question https://mcmap.net/q/741622/-debugging-a-ios-safari-crash-quot-a-problem-repeatedly-occurred-quotChowchow
F
6

I ran into this issue today and wanted to see the MRE that would cause this to happen. It does seem to be the case that both Safari and Chrome on iOS 14 crash when the autofocus attribute is set on at least two <input> controls, and focus is then requested on either control using JavaScript. I was able to confirm that the crash doesn't occur on iOS <= 13. Chrome 87 and Safari 13.1 on macOS are also unaffected.

Whether the crash occurs depends on when focus is requested. In the 'window load' event, things keep running. When requested in the 'document ready' handler, or at the end of the document, things go bad.

Setting the autofocus on more than one element doesn't make much sense, but the browser shouldn't crash. The JavaScript fallback may be used to provide a consistent UX for browsers that lack support for the autofocus attribute. The obvious fix for this is to remove all conflicting autofocus attributes.

/*
// Load event on window object: NO CRASH
window.addEventListener('load', (e) => document.querySelector('input[name="field_1"]').focus());

// DOMContentLoaded event on document object: CRASH
document.addEventListener('DOMContentLoaded', (e) => document.querySelector('input[name="field_1"]').focus());
*/

// End of document script: CRASH
document.querySelector('input[name="field_1"]').focus();
<!DOCTYPE html>
<html>
<body>
<form>
<p><label>First field<br><input type="text" name="field_1" autofocus></label></p>
<p><label>Second field<br><input type="text" name="field_2" autofocus></label></p>
</form>
</body>
</html>
Fourposter answered 6/12, 2020 at 15:47 Comment(1)
Ran into this issue and changing focus away from an input with the autofocus attribute via JavaScript was the cause. Our fix was to remove the attribute on the element and handle it through scripting only.Success
V
5

I saw this same error message in Safari when I tried to access a webgl context in "high-performance" mode (using the powerPreference attribute on the renderer in a three.js scene).

Removing the high-performance mode allowed my webpage to load.

Vair answered 21/11, 2019 at 16:46 Comment(0)
T
4

I have “solved” this by assuming this is indeed a memory problem and setting display:none to elements not visible in the viewport (by using a window on-scroll event).

https://medium.com/talk-like/detecting-if-an-element-is-in-the-viewport-jquery-a6a4405a3ea2

This fixed the crashing in safari on my iPhone X. However it does not explain why this was occurring in the first place on a powerful device when the web app consumes under 20mb of memory and it ran fine on any other less powerful device I could find.

Tickle answered 18/10, 2018 at 0:43 Comment(2)
Sounds like a rather radical solution. I'm getting improvements by removing transforms and filters but haven't been able to narrow it down to one single problem. Main issue is that I don't have access to an iPhone X directly so testing is extremely tedious.Prow
as stated in my comment above I feel this is the right answer - to remove or limit excessive animation or CSS rendering seems to resolve the crashing issue. My webpage was also very small (~21MB) and after removing an animation of background-position it no longer crashes. Why? Ask Apple I guess... this did not happen on any other device I tried. ¯_(ツ)_/¯Dominate
F
1

I faced a similar issue:

on my website (only on a specific page) iOS safari shows error message "a problem repeatedly occurred on my-page-url" without any errors in the console. On all desktop browsers this page works fine, on all Android mobile phones also, but on iOS Safari page shows error...

After many hours of investigation, I have found that the problem was with the CSS property

height: intrinsic;

it was really strange, because this property works fine only on desktop Safari, on other browsers it was just ignored. But mobile Safari dies...

So I changed this CSS property and everything was fixed :)

Hope this will help someone to save few hours of debugging :)

Funk answered 2/6, 2020 at 10:17 Comment(2)
I find myself in this exact situation. To what did you change the CSS property too?Mutant
just any common property, like inherit or 100%Funk
T
1

Spent my fair share of debugging a similar issue.

For me it was due to the fact that I was using Vuetify, and had 2 text-fields that both had autofocus property set. Removing that extra autofocus from an element fixed it for me.

Taliped answered 31/10, 2020 at 13:33 Comment(1)
To expand a little on this, I was unable to reproduce this problem without the JavaScript .focus() call. Just setting the autofocus attribute on more than one control on the same page did not trigger the crash for me. If you have more information, then I'd love to know.Fourposter
C
1

High GPU consumption caused by too many composited layers.

Had recent iOS Safari throwing this. Ended up being CSS related. We had too many composited layers. Resolved by hiding them where possible (display:none) until they were needed.

It was this SO that gave me the clues I needed to track down the issue.

Chowchow answered 24/1 at 17:11 Comment(1)
R
0

I ran into a similar issue with a page rendering a list of SVGs. Replacing the SVGs with PNGs resolved the issue.

Rodenhouse answered 14/6, 2022 at 16:35 Comment(0)
D
0

Safari was crashing due to firestore hogging all of the memory, the issue is here: https://github.com/firebase/firebase-js-sdk/issues/6118 and fixed by initializing firestore like so:

export const db = initializeFirestore(app, {
  experimentalForceLongPolling: true,
})
Democracy answered 31/8, 2022 at 21:50 Comment(0)
B
0

For posterity and future searches, I was pulling my hair out trying to debug this same issue in a NextJS app.

I was able to resolve this issue by removing a complicated CSS box shadow assigned to a container that can rapidly change size. The container changes its height vertically, and therefore can stretch the viewport. As soon as I disabled the shadow, smooth as butter.

Here's the shadow I was using if anyone was curious. I got it from one of those online box shadow generators. Didn't even think about the performance issues that could happen.

:root {
  --shadow--lg: 25px 50px 62px -3px rgba(9, 9, 12, 0.34),
    17px 34px 43px -2px rgba(9, 9, 12, 0.34),
    11px 22px 28px -2px rgba(9, 9, 12, 0.34),
    7px 14px 18px -1px rgba(9, 9, 12, 0.34),
    4px 9px 11px -1px rgba(9, 9, 12, 0.34),
    3px 4px 7px -1px rgba(9, 9, 12, 0.34), 2px 3px 4px rgba(9, 9, 12, 0.34),
    0px 1px 1px rgba(9, 9, 12, 0.34);
}
Biodynamics answered 7/10, 2022 at 17:20 Comment(1)
How did you know it was this shadow?Magma

© 2022 - 2024 — McMap. All rights reserved.