@alitaheri feel free to make necessary changes before merging and let me know if anything else I can help with 😄

@Cansn0w Thank you very much for the contribution. I only have one concern. Won't this break older versions of chrome? until everyone upgrades this will break stuff, also, if this bug gets fixed after a future update, that will also break it. However, if it works in a way that doesn't break when this bug is fixed or for older versions then it's good. It's just that I've wrote this code a long time ago and don't remember much. I will have to take a deeper look. Either confirm that this change won't break other cases or wait for me to look into it. Thank you 🙏

Thank you for your response and continuous maintenance of the library!

To my knowledge this should not break in browsers without this bug, e.g. older or future version of Chrome. The change proposed in this PR is similar to how we used to solve the problem, that is, assigning a positive value to scrollLeft and see if the browser changes it, since only negative scrollLeft strategy would change it. In this PR we work around the off-by-1 bug by assigning dummy.scrollLeft = 2; so we're now testing if scrollLeft is in the range of [-scrollWidth, 1] instead of [-scrollWidth, 0].

but please do take a look in case there could be other problems 😄

@Cansn0w uh, right. you're on point. Thanks for looking into this issue. I will publish a new version asap after I test it out myself 👍

@Cansn0w published as v0.2.1

Thank you!