This plugin is having no effect on iOS for me. I've installed the plugin and successfully called scrollLock.hide(), but on iOS there's no effect at all.

My app is a Cordova app + Vue.js. When I run in the browser, body scrolling IS prevented, which is what I'd expect, but not on iOS.

Are you aware of any issues with running under Cordova or Vue.js?

Thanks for the great library! It's a lifesaver and I've used it for multiple projects!

I ran into an issue and was wondering if we could make a change to fix it.

The Problem

I'm building out a complex interface where the small screen and large screen experiences are very different. On large screens an element should have a fill gap selector. On small screens it should not. I had a function that looked roughly like this:

updateScrollLock() {
   if(isLargeScreen) {
      scrollLock.addFillGapSelector('.foo');
   } else {
      scrollLock.removeFillGapSelector('.foo');
   }

   if(lockScrolling) { 
      scrollLock.disableScrolling();
   } else {
      scrollLock.enableScrolling();
   }
}

This function would be called whenever a user opened or closed a menu. This action could happen a number of times. At first the menu opening and closing was snappy, but over time I noticed that the performance degraded on large screen lower-power machines (and in low performing browsers).

I dug into it and realized that every time the menu was toggled the fill gap selector was being re-added so that state.fillGapSelectors looked like this: ['.foo', '.foo', '.foo', ...]. I think this was slowing down performance, since when scroll locking was toggled it had to iterate over all those duplicate selectors and make changes.

A Quick Fix

I was able to work around it by doing something like this:

      scrollLock.addFillGapSelector('.foo');

-->

      scrollLock.removeFillGapSelector('.foo');      
      scrollLock.addFillGapSelector('.foo');

This works fine but it would be nice if it was impossible to get into this situation in the first place.

A Fix in the Library

We could avoid this by doing something like this:

export const addFillGapSelector = (selector) => {
    if (selector) {
        const selectors = argumentAsArray(selector);
        selectors.map((selector) => {
            if(state.fillGapSelectors.indexOf(selector) !== -1) {
                state.fillGapSelectors.push(selector);
                if (!state.scroll) {
                    fillGapSelector(selector);
                }
            }
        });
    }
};

I'd be happy to put up a PR if this makes sense to you.

If a scroll-enabled container contains a range-slider <input type="range">, this slider is hard to use on a touch-device (because of the touch-event handling?)

For an example see this demo page, that contains a regular slider and a slider in a scroll-enabled container (make sure you open it on a touch-device).

Found a bug while using. When (for example, a menu) is scrolled to the maximum, but the user continues to drag his finger, then a large number of errors of the form start to appear in the console: "[Intervention] Ignored attempt to cancel a touchmove event with cancelable = false, for example because scrolling is in progress and cannot be interrupted." The solution is very simple by adding one condition before e.PreventDefault()

if (e.cancelable) { e.preventDefault(); }

In some cases trying to cancel an event will fail with following error message: [Intervention] Ignored attempt to cancel a touchmove event with cancelable=false, for example because scrolling is in progress and cannot be interrupted.

It happens because the event is not cancelable. To fix this, check for e.cancelable before e.preventDefault(); in the following two locations: https://github.com/FL3NKEY/scroll-lock/blob/master/src/scroll-lock.js#L440 https://github.com/FL3NKEY/scroll-lock/blob/master/src/scroll-lock.js#L447

if(e.cancelable) {
    e.preventDefault();
}

It's possible to add the same selector multiple times. This can lead to perf slowdowns as DOM operations run on each selector By preventing duplicate selectors we can avoid this

This commit also adds a test to confirm this works.

Fixes #13

Could you add a method, eg. AddLockableTarget() ? That way in addition to locking body, we could also lock scrollable divs.

eg.

<body {{LOCKHERE}}>
   <div {{LOCKHERE}}>
      <div {{SCROLLHERE}}>

      </div>
   <div>
<body>

• Fix bug of fills gap when overflow is hidden
• Fix bug with queue state (could be less than 0)
• Add lockable feature
• More advanced getPageScrollBarWidth method
• Add demo with Modal
• Add demo with Sidebar

Is this library supposed to work when being invoked on elements running in shadowed components?

Seems as though the whole screen gets locked if the element being made scrollable is inside of a shadowed component...?

As the title says, body lock works everywhere just fine but safari on ios. How to deal with safari on ios devices? The only thing i found could work is to set additionaly body to position fixed but it breaks scroll position after.

I'm sorry for the way I'm going to phrase things, but my knowledge is a bit limited in this area still (regarding JS events).

All of this is done on an iPad with an Apple Pencil.

I have a URL with a custom onclick event. The thing is, when I call disablePageScroll(), then the click event doesn't fire anymore (I am pretty sure it's the click event, I didn't check though, but my anonymous function in onclick does not get called). However, the link does change color, so clearly some events are still getting through.

When the page scroll is enabled, not only does the URL change color, but also the whole rectangular area briefly flashes to a black. I made a GIF of it.

I first click on "share", which flashes red (page scroll is disabled by default), then I enable page scroll by clicking on "on" (an alert shows that page scroll is enabled). I then click on "share" again and then you see a red flash and a black rectangular flash, indicating that disablePageScroll() is blocking some event.

Finding the culprit was simple, but I don't have any clue on what unintended side effects I get when I comment it out, but for my purposes, I did for now.

https://www.chromestatus.com/feature/5162094739587072 This update is causing displacement of modals with input fields when the field becomes focused. I tested it with this example https://fl3nkey.github.io/scroll-lock/demos/sidebar/sidebar.html on android chrome 75. Steps to reproduce:

• open modal
• click on the name field
• modal scrolls to the bottom