adding hammer to the body tag in ie10 disables scrolling via touch

[klundberg]

...specifcially with the -ms-touch-action: none style being set. when I set stop_browser_behavior to false this fixes that issue, but then drag hammer events don't properly work since the page wants to scroll.

I'm not really sure what the best solution here is; ideally one could conditionally disable and re-enable default browser behavior when convenient. Our use case is that we want a hold event to trigger an element to become draggable. The browser behavior would be stopped once the hold gesture triggers, and it would then be restarted when the drag event is finished.

[ghost]

Please confirm the following:
• The IE10 quirks-mode setting (if any modes are set)
• The appropriate HTML5 doctype is being used
• If the issue occurs on either, or both, of html and body: Some IE versions (and Firefox) treat the tags differently

[jtangelder]

This is a problem that exists in Hammer with ie10 yes... i would suggest you dont add it to the full document, but to the specific elements. You could experiment with the value of the touchAction property. maybe you will find a setting that works for you.

Available options are;
auto
Initial value. Indicates the Windows Store app using JavaScript will determine the permitted touch behaviors for the element.

none
The element permits no default touch behaviors.

pan-x
The element permits touch-driven panning on the horizontal axis. The touch pan is performed on the nearest ancestor with horizontally scrollable content.

pan-y
The element permits touch-driven panning on the vertical axis. The touch pan is performed on the nearest ancestor with vertically scrollable content.

pinch-zoom
The element permits pinch-zooming. The pinch-zoom is performed on the nearest ancestor with zoomable content. For more information about specifying content as zoomable, see the -ms-content-zooming property.

manipulation
The element permits touch-driven panning and pinch-zooming. This is the shorthand equivalent of "pan-x pan-y pinch-zoom".

double-tap-zoom
The element permits double-tap-zooming. The double-tap-zoom is performed on the full page. Double-tap-zoom is not available in Windows Store apps using JavaScript.

[jtangelder]

Issuebot:
This issue is auto-closed because it's last activity was too long ago.
If you think the issue is still active, please re-open it!

[lilililil]

This issue is still present in Nokia IE10.1, adding any hammerjs related code breaks scroll.

• hammerjs 1.0.10

[jtangelder]

Yes, you should change the touchAction property then :-)

[lilililil]

Changing line 35 to the following did the trick for me!

touchAction      : 'manipulation',

[trullock]

I have this issue and any value for touchAction does not solve it :(

Any clues on where to start debugging this? or an ETA on a fix?

[RByers]

Note that Chrome 35 now supports touch-action, and as a result we're now seeing complaints from people that sites that used to scroll with touch no longer do as a result of this code (eg. http://crbug.com).

Why is touch-action: none the default when you're not going to call preventDefault on all touch events? That seems inconsistent. If you're not sure that you're going to want to disable scrolling etc. then you should leave touch-action set to auto I think, right? Specific gestures that override scrolling behavior could then set the appropriate touch-action.

[jtangelder]

The default value became 'none' when i found out this let IE10 detect gestures. Looking back, it wasn't the one that should be the default, pan-y seems way better in most cases. Most pages don't have horizontal scrolling, and most people use the drag/swipe/left/right gestures.

To change the default setting you can set it in the code, but you can also do this before creating an instance by changing the touchAction value.

For Hammer 1.0.x this would be
Hammer.options.stop_browser_behavior.touchAction = 'pan-y';

And Hammer 1.1.x:
Hammer.options.behavior.touchAction = 'pan-y';

[jacobrossi]

Thanks, Jorik, for jumping in and working on a fix! The pan-y default seems like a reasonable stop gap solution.

Longer term, have you considered trying to set the appropriate value per element based on the gestures registered for? For example:

Hammer(el).on("swipeleft", function() {
    //In this case, touch-action: pan-y; is probably best
});

Hammer(el).on("swiperight", function() {
    //In this case, touch-action: pan-x; is probably best
});

Looking through your supported events, my guess is the following mapping:

Gesture Event	Least restrictive touch-action value
hold	auto
tap	auto
doubletap	manipulation
drag, dragstart, dragend	none
dragup, dragdown	pan-x
dragleft, dragright	pan-y
swipe	none ?
swipeup, swipedown	pan-x
swipeleft, swiperight	pan-y
transform, transformstart, transformend	none ?
rotate	pan-x pan-y
pinch, pinchin, pinchout	pan-x pan-y
touch	auto ?
release	auto ?
gesture	none

This might be a little tricky when multiple gestures are combined on the same element (you need to determine the configuration that allows all the gestures listened to). But that should be doable and I can help work through it with you if you like.

[jtangelder]

I love the table you made, thanks! About the automagic touch-action value, I guess this would be a cool feature for the next Hammer version that i'm planning a bit (secretly). I'm planning to make the touch-action property as the main 'prevent-default' function, and add support for non-touch-action browsers by creating some kind of polyfill...

[jtangelder]

I'm busy on creating a wiki page about this, to inform all users how to fix this.
https://github.com/EightMedia/hammer.js/wiki/How-to-fix-Chrome-35--and-IE10--scrolling-(touch-action)

Any improvements/suggestions?

[RByers]

Thanks Jorik! Making the default pan-y and adding this wiki page is a great short term fix - thank you for the very quick turn around! Note that people can also use Chrome 36 on a laptop with "emulate touch screen" to experiment with the different choices.

Bigger picture I agree with Jacob that ideally the developer wouldn't have to manually choose the right tough-action. Conceptually they should tell you once what sort of gestures they want hammer to handle (instead of the browser). Then it's Hammer's job to make sure it's use of touch-action and preventDefault are consistent.

The difference between IE and Chrome here makes things a little tricky - in IE touch-action is the only way to disable a browser behavior so for Hammer to work you need to err on the side of being aggressive (as you were doing by defaulting to 'none'). But in Chrome preventDefault still works to disable things that are otherwise allowed by touch-action, so you really want to err on the side of being conservative (in fact, you could argue there's little value in Hammer setting touch-action at all for Chrome). Eg. for 'swipeup' (on it's own) you'd presumably like scrolling in the opposite direction to work and so ideally on Chrome you'd use 'touch-action: auto' and rely on preventDefault, but on IE you have no choice but to use 'touch-action: pan-x' to disable both scrolling up and down.

Perhaps the best solution is to always be conservative in setting touch-action and document the fact that certain gestures won't work in IE on their own. Eg. if you enable just 'swipeup' then it'll work in other browsers but never get invoked for IE, but to make it work in IE you also need to enable 'swipedown'. This is basically implementing Jacob's table, and taking the intersection whenever more than one gesture is active.

I think this matches what we're seeing in practice on some sites - for most websites scrolling is more important than the gesture hammer provides and so on IE they just disable Hammer entirely.

[jtangelder]

Hm, it will need some research when i'll get there. I just ordered a Nokia Lumia so I can experiment with this myself soon and find out the differences and tricks. Hope i can make it all work with as less configuration/per browser hacks as possible.
It's a gonna be a though job!

[RByers]

Great! You should also be able to get a reasonably accurate idea of how it
works in IE by using Chrome with all calls to 'preventDefault' disabled
(eg. do 'TouchEvent.prototype.preventDefault = function(){}').

On Tue, May 20, 2014 at 4:08 PM, Jorik Tangelder
notifications@git.luolix.topwrote:

Hm, it will need some research when i'll get there. I just ordered a Nokia
Lumia so I can experiment with this myself soon and find out the
differences and tricks. Hope i can make it all work with as less
configuration/per browser hacks as possible.
It's a gonna be a though job!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/241#issuecomment-43630018
.

[jacobrossi]

Good to hear you're getting a device to test with. If you want something in the short term, Visual Studio 2013 (Express edition is free) includes a Simulator that can emulate touch (sorry, we don't offer this in the browser's F12 tools yet).

[jtangelder]

The Windows Phone emulator only runs on Windows 8.1, i'm on win7/ubuntu at home, on OSX at my office. So that's not an option unfortunately! The tablet emulator works, but it noticed some differences between the phone and desktop windows..

[trullock]

I have all iOS devices, WP8, android 2.3, 4.3 and 4.4 to test on, I'll do this ASAP

[arschmitz]

Where do we stand on this now?

[RByers]

This was fixed in Hammer a year ago, guess the issue was accidentally left open?
Details: https://github.com/EightMedia/hammer.js/wiki/How-to-fix-Chrome-35--and-IE10--scrolling-(touch-action)

[arschmitz]

@RByers Thanks looks like it was also a V1 issue. Just taking over leading this project and trying to wade through some of these really old issues that are still open.

[prashon]

Somehow I managed to overcome this issue.. I just commented out a line in the library and it fixed the whole crap. Find the below function call in the touchemulator.js library and just comment the same line i.e,. preventMouseEvents(ev); . Thats it.. Yor are done.. Check it on browser and celebrate...