Scrolling horizontally using gestures causes browser to navigate through history instead of scrolling the table.

[josh08h]

Expected Behavior

The table should scroll to the left and right. If scrolling to the left and reach the beginning of the table, then the browser should navigate backwards in history.
If scrolling to the right and reach the end of the columns, the browser should navigate forward in history.

Current Behavior

The page history navigation seems to take over the scrolling of the table.

Possible Solution

Steps to Reproduce (for bugs)

Go to http://schrodinger.github.io/fixed-data-table-2/example-object-data.html
Resize the browser so that not all columns are visible.
Scroll horizontally using gestures on touchpad or magic mouse whilst mouse is over the table.
The browser will try to navigate back in history however we should see the table columns scroll.

Context

Our staff use gestures to navigate around the screen and this constantly makes them navigate back in their browser history.

Your Environment

Chrome 58.0.3029.96 (64-bit)
10.11.6 OS X El Capitan

[josh08h]

So I have narrowed it down - This bug is NOT due to chrome.. it is in fact due to the OS version I am on.

[quixotically]

Hi @josh08h ! It looks like the bug is indeed tied to 10.11.6 OS X El Capitan. Trying on 10.12 Sierra and even 10.11.3 El Capitan did not reproduce the bug.

But, it also seems the bug is only showing up on Chrome - maybe even just Chrome 58 - at least when compared to just Firefox and Chrome 57.

Also, to clarify your repro steps: are you able to scroll to the right, but not left? What I'm seeing is that any attempt to scroll left will take me back a step in history, but I'm still able to scroll right as long as there is space left to scroll. Another interesting thing is that if I switch tabs and then go back to the FDT tab, I am able to scroll left once. Then, I can't again.

There is also a bit of inconsistency involved. Overall the issue is very reproducible on 10.11.6 with Chrome 58, but sometimes the left scroll does work. Usually it's only very briefly when it does though.

Can you please confirm that both 10.11.6 and Chrome 58 are necessary to repro, and that specifically scrolling left only does not work? Can you also please confirm that magic mouse behaves the same way under the same conditions as the trackpad? Was not able to test with magic mouse, but we should have one available tomorrow to try out, so I would like to first clarify expectations.

[quixotically]

Hey @josh08h - it looks like it's OSX and Chrome in general, not just 10.11.6 and Chrome 58. We were just able to reproduce on OSX Sierra 10.12.4, using Chrome 57. I also found a bunch of articles about mac trackpads not working properly with Chrome.

The workarounds are about the same for magic mouse and trackpad. Here they are:

Magic mouse workaround (worked for me):

• Go to System Preferences -> Mouse -> More Gestures and either:
• Uncheck the Swipe between pages option.
• Keep it checked, but select the Swipe left or right with two fingers option
• Found this via comment 13 here https://bugs.chromium.org/p/chromium/issues/detail?id=252895

Trackpad workaround (worked for me):

• Go to System Preferences -> Trackpad -> More Gestures and either:
• Uncheck the Swipe between pages option.
• Keep it checked, but select the Swipe with three fingers option
• Figured this out from the magic mouse workaround above

Other possible workarounds:

• Reboot (this actually seemed to fix the issue too! Worked on all three macbooks I tested on. But I can’t be sure about this one since reproducing the bug is still a bit inconsistent)
• Use another browser (Firefox worked fine for me)
• Use the scrollbar instead of trackpad/magic mouse

Unfortunately I’m not sure we can do much on the FDT side since this seems like an OSX and Chrome issue. Please get back to me about the workarounds! Hope this helps.

Sources:

• https://apple.stackexchange.com/questions/21942/chrome-mac-gesture-conflict-with-horizontal-scrolling
• https://bugs.chromium.org/p/chromium/issues/detail?id=252895
• https://discussions.apple.com/thread/5695084?tstart=0
• https://discussions.apple.com/thread/7679256?start=0&tstart=0

[maksis]

It's probably caused by https://developers.google.com/web/updates/2017/01/scrolling-intervention (you should also see a warning in the browser console). Adding the following CSS should fix the issue:

.fixedDataTableLayout_rowsContainer {
    touch-action: none;
}

[wcjordan]

That seems like a reasonable cause. @josh08h could you test out that change and submit a PR if it solves the issue you're having?

[wcjordan]

Given maksis's feedback. I'm going to make a few changes to better support this behavior.

On master, don't bind the touch listeners unless touchScrollEnabled is true.
On v1.0+ add the touch-action: none css to our rowsContainer (as suggested above).

I'm also going to subscribe to facebook/react#6436
and when React has first class support for passive events configs, I'll switch these listeners to not be passive and remove the touch-action:none css.

@KamranAsif @quixotically any thoughts or concerns?

[quixotically]

sgtm. Can you make sure to test that things work as expected before merging the change @wcjordan ? Thank you @maksis and @wcjordan !

[wcjordan]

Ya I plan to try the touch example out to ensure things work as expected. And also do my best to ensure I can't reproduce the issue referenced here. Although I had trouble reproducing and we haven't fixed it yet, so I don't think it will get worse.

Do you have any other suggestions for testing?

[quixotically]

Cool. And ah yeah, reproing this is hard, especially if the issue is still gone after we rebooted your machine.

Sorry, I don't have any other suggestions for testing. So, I think it's fine if you can just make sure there is no obvious break.

[josh08h]

Apologies for the absence recently.

I can confirm

.fixedDataTableLayout_rowsContainer {
    touch-action: none;
}

does not fix the issue for me.

[wcjordan]

That's unfortunate. Would it be possible for you to fork FDT and remove the touch listeners to see if that addresses the issue?

[aschwan]

In the Terminal, enter:

defaults write com.google.Chrome.plist AppleEnableSwipeNavigateWithScrolls -bool FALSE

Restart Chrome and the swipe navigation should be disabled.

To change the setting back to default enter:

defaults write com.google.Chrome.plist AppleEnableSwipeNavigateWithScrolls -bool TRUE

[KevinYaoooooo]

Any progress on this issue

I get this issue a lot, it's really annoying, it occured on many computers of my colleagues, here are the env infos:

could you guys take a look at this bug?

BTW, I had already tried you solution which is removed all touch listeners on my forked version, but this but still exist, please help

[wcjordan]

No update beyond the solutions in this thread. We'd be happy to accept a PR if you make any progress in your investigation.

It may be worth looking at why macs propagate the touch swipe even though preventDefault is called in ReactTouchHandler and ReactWheelHandler. It may be worth moving that around / ensuring it's called as expected.

[pradeepnschrodinger]

I believe this should be fixed with the v1.0.0 release, since we use native event handlers. Feel free to respond and reopen otherwise.