Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scrolling trough slides causes page refresh and complete crash on newer iPhones (both Safari and Chrome) #4548

Open
kovinet opened this issue May 15, 2023 · 24 comments

Comments

@kovinet
Copy link

kovinet commented May 15, 2023

Description

We have been having HUGE problems with these script on latest iPhones. While everything works fine on desktop and on Android devices, as well as on some older iPhones (tested on iPhone 7, iPhone 11, IPhone SE) the site completely breaks on iPhone 14 after trying to scroll. What happens is that when trying to go to slide next slide browser tries to refresh the page instead and then it completely crashes.

We have tried removing some content like images, in this case it is possible to scroll like 3 or 4 slides and then the problem repeats, making the page completely unusable on these devices.

I have been trying to isolate the problem for hours and it is hard, because I don't own new iPhone and it works on all devices I own. But the problem has been reproduced on at least 4 iPhones, where page completely crashes when trying to scroll.

Versions

iPhone 14 (Safari and Chrome), reproduced also on some other iPhones, while working on most older ones

@kovinet
Copy link
Author

kovinet commented May 15, 2023

After doing more extensive testing I am starting to notice that the problem lies somewhere in CSS.
When I remove all of my own CSS and just leave fullpage.css it seems to work.

@alvarotrigo
Copy link
Owner

Interesting 🤔
It'd be nice to know exactly which styles are the ones interfering with it.

Perhaps removing part of them multiple times until you figure out which can be the one creating the issue?

@kovinet
Copy link
Author

kovinet commented May 15, 2023

It must be some really weird bug and it only happens on some iPhones, while working perfectly on iPad, Desktop Chrome, Android phones.

Here is video screencast of broken experience on iPhone 14: https://www.screencast.com/t/2kwzeR0JwR4q

And how it is working perfectly on Android: https://www.screencast.com/t/v4EooCbjJ

By now I have deleted most of dependencies, so it's just fullPage.js + 300 lines of css, still breaking on iPhone, sometimes I can scroll few slides then it tries to refresh the page when trying to swipe and then showing Can't open this page error...

@alvarotrigo
Copy link
Owner

If you remove those extra 300 lines of CSS, it works just fine, right?

Probably the easiest way to find out what's the cause of the problem is by reducing those 300 lines bit by bit until you find what it can be :)

@kovinet
Copy link
Author

kovinet commented May 15, 2023

I found that if I delete these lines:

.text {
    padding: 80px;
    width: 100%;
    max-width: 1000px;
    margin: 0 auto;
}
.text h1 {
    font-size: 2.5rem;
    font-weight: 300;
    line-height: 1.2;
    margin-top: 0;
    margin-bottom: 50px;
}

.text h2 {
    font-size: 2rem;
    font-weight: 300;
    line-height: 1.2;
    margin-top: 0;
    margin-bottom: 50px;
}

.text h3 {
    font-size: 20px;
    font-weight: 300;
    line-height: 1.2;
    text-transform: uppercase;
    margin-top: 50px;
    margin-bottom: 30px;
}

Then it works better, it still crashes, but after 3 or 4 sections instead after first attempt to slide.
But this is very basic CSS and it doens't make any sense why it is causing it :)

I will continue tomorrow when I have access to someone with affected phone ...

@kovinet
Copy link
Author

kovinet commented May 16, 2023

I have been debugging more and this is really weird.

I have been deleting chunks of html out and when I removed some html from one of slides it started working fine. So i assumed that chunk is the problem, so I removed other slides and just kept the problematic slide but it then works on its own!

It seems like that when size of total html exceeds certain limit there is some kind of memory leak and it starts crashing on new iPhones.

So even if I keep all the CSS and keep html that is crashing the site, but isolate it, it then works. But when I put it together with other content then it starts crashing. 😞

@kovinet
Copy link
Author

kovinet commented May 16, 2023

I have come to the point where I have in one of the slides the code:

<h1>Jane Dough</h1>

and everything work, now if I just duplicate this div couple of time:

<h1>Jane Dough</h1>
<h1>Jane Dough</h1>
<h1>Jane Dough</h1>
<h1>Jane Dough</h1>
<h1>Jane Dough</h1>

I breaks (crashes the browser).

But if I just keep this slide and remove some other slide then this works. Like some stack overflow happens or something, crazy really....

@kovinet
Copy link
Author

kovinet commented May 16, 2023

After changing some paddings etc. I have finally got some different error message from Safari:

image

Sorry for spamming here, I hope this also helps you to improve the script in the future, because there seems to be some issue. I suspect there is a memory leak regarding scroll events...

@kovinet
Copy link
Author

kovinet commented May 16, 2023

I have come to the conclusion that if there is X number of slides that have content overflowing the section, so that inner scrollbar appears in too many sections / slides, then it starts to crash. So there is no specific CSS that is at fault, but for example if I add some padding-top so that content doesn't fit in many of the sections it is reason enough for it to crash the browser...

Like there is too many processes manipulating the scroll or something in this direction.

As mentioned before, this only happens in iPhone 14, but it never happened to far on iPhone 11 or iPhone 7. Same for Chrome and Safari. There is also no issue on Android devices or desktop.

@alvarotrigo
Copy link
Owner

alvarotrigo commented May 16, 2023

Interesting findings!

It might be related to this issue:
https://stackoverflow.com/q/17824060/1081396

As a workaround, you can use scrollBar: true.
If you still prefer not to show the scrollbars, then you can use css3:false.

And if none of those solutions fit you well, then you can try reducing the number of vertical sections.

@kovinet
Copy link
Author

kovinet commented May 16, 2023

Thanks for the hints. I have now somehow managed to make it work, mostly by removing some paddings from elements inside slides so they fit without scrollbar. No crashes for now on few tested phones, I hope it won't randomly crash on others - then I will try with the tips provided.

@VoHoTv
Copy link

VoHoTv commented Sep 24, 2023

Experiencing the same issue for this website. iPhone 12 pro with iOS 16.6.1

@alvarotrigo
Copy link
Owner

Experiencing the same issue for this website. iPhone 12 pro with iOS 16.6.1

Did you try removing sections? See if that's related?
Or using anchors: []?

@joelstein
Copy link

We have a similar problem with a page with 63 slides powered by fullPage.js, all with background images, a background overlay, animating text, etc.

And it only seems to crash on newer iPhones. I have an older iPhone 8, and it doesn't crash.

I also found this discussion, which makes me think the page is somehow using too much memory or GPU:

https://stackoverflow.com/a/77119170

@alvarotrigo
Copy link
Owner

alvarotrigo commented Oct 11, 2024

And it only seems to crash on newer iPhones. I have an older iPhone 8, and it doesn't crash.

@joelstein I assume you are using the lazyLoad option for the images and data-src for them?
You can also use lazyLoadThreshold.

For the background images, check out this article on how to lazy load them using fullPage.js

Let me know if that solves anything for you.

Otherwise, check out this answer. They relate it to opacity and keyframes?

@alvarotrigo
Copy link
Owner

@joelstein any update on this? Did my suggestions fixed it?

@Neophen
Copy link

Neophen commented Oct 16, 2024

I had this bug also, and it's nothing to do with fullpage.js
What is crashing is the fact that overflow-x eats up too much memory
I have a simple page with infinite vertical scroll and until i've added overflow-x-hidden and scroll-snap-x everything was working fine.
You can have a look at the safari > dev tools > layers and if that has much more than one it basically you'll crash from memory consumption

@alvarotrigo
Copy link
Owner

@Neophen that's interesting! Thanks for the insights! 👍
Do you happen to have a codepen where we can reproduce the issue?

@joelstein
Copy link

We fixed the issue with our implementation. The "Layers" tab in Safari helped us figure out that we used a crazy amount of memory when transitioning between slides. It would spike up to about 1 GB of memory because react-fullpage rendered all 63 sections for each transition (that, and each section has a background image, background overlay, animating text, animating fade for the background image, etc).

Our workaround was to track the current section index, compare it within each section's render function, and only render if the section was the previous, current, or next.

It would be awesome if the React implementation of fullPage.js had some mechanism for only rendering these three sections. Just a thought.

I hope this helps someone else struggling with Safari mobile crashing on section transitions!

@alvarotrigo
Copy link
Owner

alvarotrigo commented Oct 17, 2024

It would be awesome if the React implementation of fullPage.js had some mechanism for only rendering these three sections. Just a thought.

@joelstein If I do not misunderstand what you are saying, the problem is not just on the react component for fullPage.js, right?
We should be able to reproduce the issue on the Vanilla JS version, too, or even in an isolated reproduction without using fullPage.js and using a basic transition using translate3d on a wrapper with "slides".

So, if that's the case, I think the best approach here would be to implement "virtual sections/slides" in fullPage.js itself.

This way, we can potentially limit the number of sections and slides on the DOM to those near the current one and avoid reaching the memory limits on the web browser.

@joelstein
Copy link

Correct. I don't think the issue is strictly caused by fullPage.js, its React component, or the CSS tranlsate3d function.

The underlying issue is that the CPU/GPU is overwhelmed in scenarios that require the browser to consume large quantities of memory. (This is especially easy to see in Safari's Layers tab, which shows the number of layers and the total memory consumed.)

But, since fullPage.js wraps potentially large quantities of DOM elements in a single "view", I think it's sensible for it to offer a strategy that optimizes the hidden things. For example, if there was a way to define the sections (rather than render the HTML and ask fullPage.js to find all elements with the .section class), or even just the number of sections, then the implementation can render only what's needed based on the active section index. Just a thought.

As an aside for others struggling to understand how to optimize CSS animations and GPU, compositing, laters, etc, I found this article immensely helpful:

https://www.smashingmagazine.com/2016/12/gpu-animation-doing-it-right/

@alvarotrigo
Copy link
Owner

@joelstein thanks for the info!!
I'll take a look at this for a future release! 👍

@Neophen
Copy link

Neophen commented Oct 25, 2024

I don't but i can give you one if you want it's basically anything with lot's of items which have overflow on the x axis. Imagine Instagram feed:
image

Inspecting this in safari you will see a ton of layers
The way i've worked around it, was by having intersectionObserver and only allowing the visible items to have overflow-x
I can do a repro, but it's pretty simple

@alvarotrigo
Copy link
Owner

@Neophen thanks for that! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants