Dot navigation fails in Chrome and Edge on small screens

Please screenshot your forms. Most basic issues are due to unfamiliarity. Others are likely bugs. Not this module's for such specific internal functionality I am 100% sure.

I would recommend you report it to github project instead.

Also in case useful:
1. Chrome did have "issues" with the outline of the slides, accessibility concerns, it appears to calculate it as layout properties causing extra pixel additions which appear to be likely the root cause of this problem, and a few others like shifted thumbnails last time.

But the module has provided the solution internally as long as you stick to the design. Please install Slick samples, and report back if any reproduction?

2. Try switching Mobile first option, and adjust 640 to either 639 or 641 of the breakpoints. Not the exact number of 640.

Likely other things get in the way.

Many basic issues were taken care of by this module, unless you disable some of them consciously by the provided options, like emptying Skin, Aspect ratio, etc. When you did, many basic issues you have to deal with on your own.

We appreciate advanced users at the cost of making regular users getting lost when not sticking to the design, or at least the samples.

When you get lost, be sure to compare it to Slick samples.

Please see attached video which shows the number of dots changing from 4 to 3 as the screen narrows to less than 640px.

You mentioned a calculation issue in Chrome, but this can't be a calculation issue because there are no circumstances in which a carousel with five slides should have three dots.

I tried switching on Mobile First and also experimented with setting the breakpoint to 639 and 641. However, that didn't help, and as the video will hopefully make clear, this is not behavior that should occur regardless of settings.

I don't think Slick Samples provides a use case like mine, where one slide should show at a narrow screen width. Also, I just don't think it should ever be possible, under any circumstances, to break the dot navigation in the way shown in the screencast.

In what is likely a related issue, clicking on the last dot in Firefox properly focuses the carousel on the last slide, while clicking the last dot in Chrome focuses the carousel on the second to last slide.

Please note: We can be certain this is not a CSS issue because the HTML shows only three dots below the 640px breakpoint. It appears the javascript is just not printing enough list items (dots).

It's possible this is a bug in the library, though initially it seems more likely a bug in the module. After reviewing the attached files, please let me know if you think this is more likely a bug in the library.

Changing this back to Bug Report since there are likely no circumstances when a carousel with five slides should present three dots in the HTML.

Adding a screenshot to show three dots in the HTML.

Thanks for details.

Most likely a bug of the library, I doubt this is module's, unless you can point us to the exact line of problem codes, of course.

The dots markups are internal library's.

However I am fine to see it narrowed down here before you report it at github:

• Try creating an isolated test at codepen, etc., without using module JS and CSS. If re-produceable, it is bug with the library, otherwise this module's. You can copy it from the library samples.
• Infinite option is not consistent, tried using the same value?
• Try Respond to option other than window.

No other idea yet, but Variable width might also cause miscalculation.

I'm changing this back to a bug, because I am not able to reproduce it using the library only.

Here is a jsfiddle showing an example that works fine in Chrome/Edge:
http://jsfiddle.net/e01Lzyoc/

If you can reproduce the issue in a jsfiddle with the library only, please let me know. I have found the library to be unbreakable. The library works fine in all browsers I have tested.

If I could point you to the exact line of code where the problem exists, as you requested, this would be a better bug report. However, at the moment I only know I can't reproduce the issue with the library itself. The library does not appear to have any bug in this area.

Changing this back to support request for the moment, because I'm no longer seeing different behavior in FF vs Chrome. Previously, FF was working well in my component, but it wasn't working in Chrome. Now, neither works well.

Changing this back to bug as I am still finding it breakable in Chrome/Edge, and totally unbreakable in FF. In my present configuration, at the lowest breakpoint, in Chrome/Edge, the wrong number of dots is displayed and it is impossible to navigate to the last dot. The HTML itself is wrong at my 640px breakpoint -- it has elements for three dots when there should definitely be five, as there is in FF.

To be clear, I am totally unable to break the library in any browser, and am unable to break this module in FF. However, the module is breakable in Chrome/Edge.

I found a configuration that works. If I turn on "center mode" for my smallest breakpoint, the number of dots is correct and it is possible to navigate to the last slide.

Leaving this issue set to "bug," because "center mode" should probably never affect whether or not the correct number of dot elements are provided in the HTML output.

Ok, I haven't verified it, yet, nor compare those different options if any.

Likely mistmatched options?

Mind pasting two things for easier reproduction:

• the export of your Slick optionset config
• inspect element (F12), and select the root .slick element, and find and copy data-slick attribute content

Then we can compare them against your fiddle if any options mismatched?

I am still 100% sure such dots mechanism is nothing related to the module's unless I were plain wrong, of course :)

Not sure if you knew this:

1. chrome, IE, opera has stubborn cache. Try disabling their cache via their settings, and also keep pressing F5, or better CTRL/CMD + R to refresh it each time you debug codes.
2. And of course, Drupal cache and aggregation must be disabled and also cleared just as well during changing the options, moreso if under production mode. All configs are permanently cached even under non-strict dev mode. Dev mode require you to touch sensitive settings.php and other related config files just as well to reduce headaches. Please find more info on dev mode in Drupal docs.

They likely trick you.

Also screenshots of your Slick formatter or Slick Views forms as requested at my first comment above.

Friendly housekeeping before a new release.

I hope you can make it one way or another.
Feel free to re-open if still an issue, or share your solutions to benefit others.

Thanks.