Max call stack exceeded (infinite loop) on mobile

[patrickhulce]

https://jsbin.com/nedubarado/edit?html

Steps to reproduce the problem

1. Visit https://output.jsbin.com/nedubarado in Chrome
2. Open DevTools and Enable device emulation
3. Select Galaxy S5 from the dropdown (any sufficiently small resolution screen should do)
4. Reload the page

What is the expected behaviour?

The page loads with the carousel

What is observed behaviour?

The page enters an infinite loop before reaching max call stack exceeded (and crashing outright on low-powered devices)

More Details

• Which browsers/versions does it happen on? Tested on Chrome stable (66) and Canary (68)
• Slick version? Tested and confirmed on 1.6 and 1.9
• Did this work before? Unknown

@paulirish and I dug into this, it looks like the loop is in the init/refresh/checkResponsive loop https://github.com/kenwheeler/slick/blob/a2aa3fec335c50aceb58f6ef6d22df8e5f3238e1/slick/slick.js#L595-L608

The issue is that .init (which calls .setPosition) mutates the window.innerWidth which causes respondToWidth to change between checkResponsive calls. As a result, checkResponsive flips back and forth between activeBreakpoint = null and targetBreakpoint = null forever.

Originally reported in https://github.com/GoogleChrome/lighthouse/issues/5208

[davimug]

Any update on this?

[tourniquet7]

I am also getting this issue on android.

It is breaking on my development site, but not when I copied and pasted it into jsfiddle. http://jsfiddle.net/CraigNewland/fmo50w7n/3262/

I have tried with slick 1.6.0 and 1.9.0 and I tried jQuery 2.1.1 and jQuery 2.2.4

I am running on an Android galaxy using Chrome version 66.0.3359.158

Operating System - Android 8.0.0; SM-G950U Build/R16NW

[tourniquet7]

I was async loading my css. If I turn that off, it seems to work. Here is how I was doing it.

[willbroderick]

This seems to occur when the slideshow directly affects the page width - so when it's the widest thing on the page. In our case, it was because we took overflow:hidden off the "slick-list" div. Using Slick's styles unmodified, or making sure the slideshow is inside another container with overflow:hidden and width:100%, avoids this error (for us).

[rondog]

Interesting...maybe a resize loop is happening. The arrows on the slider made it the widest thing on my page and removing the arrows (to make it not the widest) indeed fixed it. I'm sure moving the arrows inside the container will also work

[jc99ta]

I'm not sure how active this project is (many open pull requests and issues). For anyone coming across this particular problem, I solved this by adding a width parameter to the checkResponsive function.

First pass, in response to a change in window size kicks off the process, but instead of recalculating the width upon second initialization it uses the width that was passed from the first call. This breaks the infinite loop.

Attached is a patch of the changes that worked for me, no guarantees.

Issue_3447.zip

[hellojebus]

@willbroderick you are a god amongst mortals

[thedavidthomas]

Just ran into this issue myself... is there a PR that fixes this? if so can it be merged and released?

[darriuk]

In our case, it was because we took overflow:hidden off the "slick-list" div. Use Slick's styles unmodified, or making sure the slideshow is inside another container with overflow:hidden and width:100%, avoids this error (for us).

@willbroderick This fix works perfectly : )

[touson]

This seems to occur when the slideshow directly affects the page width - so when it's the widest thing on the page. In our case, it was because we took overflow:hidden off the "slick-list" div. Using Slick's styles unmodified, or making sure the slideshow is inside another container with overflow:hidden and width:100%, avoids this error (for us).

This solution by @willbroderick worked for me

[codernik]

This seems to occur when the slideshow directly affects the page width - so when it's the widest thing on the page. In our case, it was because we took overflow:hidden off the "slick-list" div. Using Slick's styles unmodified, or making sure the slideshow is inside another container with overflow:hidden and width:100%, avoids this error (for us).

This worked for me for v 1.8.1

[irtaza9]

@willbroderick the div with className 'slick-list' have the overflow:hidden property but it is still show the no passive event warring in my console.

PFA

Config

const settings = {
    arrows: false,
    infinite: true,
    autoplay: true,
    dots: false,
    vertical: true,
    verticalSwiping: true,
    speed: 5000,
    autoplaySpeed: 0,
    centerMode: true,
    cssEase: 'linear',
    initialSlide: 1,
    slidesToShow: 1,
    slidesToScroll: 1,
    variableWidth: true,
};

Usage

<div style={{ backgroundColor: 'white' }}>
                    <Slider {...settings} >
                        {images.map((image, index) => (
                            <div key={index}>
                                <div className="row flex-column justify-content-center p-5" >
                                    <div className="col fs-1">
                                        title {index}
                                    </div>
                                    <div className="col">
                                        description {index}
                                    </div>
                                </div>
                            </div>
                        ))}
                    </Slider>
                </div>

Tech Stack : React

Can you please tell me what should i do the make this warring resolvable? I will be very thankful to you.

[mehedihsajib]

This seems to occur when the slideshow directly affects the page width - so when it's the widest thing on the page. In our case, it was because we took overflow:hidden off the "slick-list" div. Using Slick's styles unmodified, or making sure the slideshow is inside another container with overflow:hidden and width:100%, avoids this error (for us).

This worked for me. Thanks <3