Problem with scrollable elements in the main section about brim

[gajus]

@blackmambahk is this in theory or are you having this issue in practise? Brim makes sure to not preventDefault scroll event if the originator is other than window, http://stackoverflow.com/questions/2890361/disable-scrolling-in-an-iphone-web-application/26853900#26853900. If you are having this issue in practise, then I need a test case to reproduce it.

[blackmambahk]

Hi there,
Its an issue in practise - not just in theory - iPhone 5 iOS8.11 - I am debugging this in DevTools on a MacBook with the phone connected via the USB port.

I have a very extensive UI in the Main content and somewhere inside it is a scrollable div.

So I am already in MinimalUI mode.

The relevant code in Brim is this:
// Disable window scrolling when in minimal view.
// @see http://stackoverflow.com/a/26853900/368691
(function () {
var firstMove;

        global.document.addEventListener('touchstart', function (e) {
            firstMove = true;
        });

        global.document.addEventListener('touchmove', function (e) {
            if (viewport.isMinimalView() && firstMove) {
                e.preventDefault();
            }

            firstMove = false;
        });
    } ());

I touch the the scrollable element - the TouchStart event bubbles up to the document, the target is some element inside the scrollable div, and triggers your code above and sets firstMove to true.

I then move triggering a TouchMove event which bubbles up again to the document, with the target an element inside the scrollable div, and since MinimalView is true and firstMove is true it calls e.preventDefault and as a result prevents the subsequent scroll.

I might be missing something but I didn't see anything in the above code that actually checks whether the element that is going to scroll would be the body.

I can't really give a test case as the app is too big, and anyway I already fixed the problem for myself by adding a test to see which element is the scroll parent.

FYI I also had a similar issue when not in MinimalUI mode where I Touch down on the 'Mask' at a point that is over the inner scrollable content inside 'Main' and instead of the 'Mask' scrolling and triggering the bars to hide, the content scrolls instead.

I fixed this by adding a div inside the 'Mask' and made that div larger than 'Mask' so forcing scrolling then set scrollTop in code on the initial load to force the Mask to scroll to its maximum, so then the user touch scroll will correctly trigger the body to scroll and hide the bars.

[gajus]

global.document.addEventListener('touchstart', function (e) {
    firstMove = true;
});

global.document.addEventListener('touchmove', function (e) {
    if (viewport.isMinimalView() && firstMove) {
        e.preventDefault();
    }

    firstMove = false;
});

In the very same snippet of code that you have pasted, notice that firstMove is set to false after the first move. Therefore, only literally the first move is prevented. All of the subsequent touchmove events will propagate.

[blackmambahk]

firstly when I was testing if you killed the first TouchMove there was no subsequent touch scrolling .... if you allow it then you get scrolling.

secondly it doesn't really seem to make sense to kill an event that actually you might want to allow ie TouchMove on a div that is native scrollable is fine so why block it.

I guess the one thing I didn't check is whether there is some conflict with the ftfastclick lib we are using and killing the first TouchMove then causes an issue.

[gajus]

Thats the whole point of killing the first touchmove: it kills the window scroll. It does not kill whatever descendant scrolling.

It is most likely that it is the implementation of the library that fails under these conditions. It is simple to test without it.

On Nov 19, 2014, at 13:31, robert.edgar [email protected] wrote:

firstly when I was testing if you killed the first TouchMove there was no subsequent touch scrolling .... if you allow it then you get scrolling.

secondly it doesn't really seem to make sense to kill an event that actually you might want to allow ie TouchMove on a div that is native scrollable is fine so why block it.

I guess the one thing I didn't check is whether there is some conflict with the ftfastclick lib we are using and killing the first TouchMove then causes an issue.

—
Reply to this email directly or view it on GitHub.

[blackmambahk]

"Thats the whole point of killing the first touchmove: it kills the window scroll. It does not kill whatever descendant scrolling. "

But there is no window scroll if you are over a native scrollable panel (using overflow touch) so it doesn't actually do that.

The only time a native scrollable div triggers a window scroll is when you scroll down to the bottom of the descendant panel or up to the top of the descendant panel, thats why normally we check where the scroll parent is.

I would normally test this out some more but I have less than 48hrs left before a 10 day holiday and the 'fix' I made works so I need to move on just at the moment.....

I will try and have a look at it if I get some time on my hols :)