The touch-action CSS property (bug 795567) and the Pointer Events DOM API (bug 822898) are currently "experimental" and disabled by default, via the prefs dom.w3c_pointer_events.enabled and layout.css.touch_action.enabled. This bug is to track the process required for enabling them by default. The DOM events depend on the touch-action CSS property for most common use cases, so we should either enable them at the same time, or enable touch-action first. Both features are specified in W3C Pointer Events, currently a Candidate Recommendation [1]. IE11 supports them unprefixed [2]. (IE10 supported a vendor-prefixed version.) Chrome has an "experimental" implementation that is disabled by default and can be enabled with a flag [3]. Currently Gecko supports touch-action in WinRT widget. We will also need to implement it for at least Gonk (bug 960209) and Android (bug #?), and eventually probably Win32. Widget support for the DOM events is similarly being implemented on WinRT (bug 956644), to be followed by other platforms. Should we require parity across some set of platforms before enabling these features on any platform? [1]: http://www.w3.org/TR/pointerevents/#the-touch-action-css-property [2]: http://msdn.microsoft.com/en-us/library/ie/hh772044%28v=vs.85%29.aspx [3]: http://crbug.com/241964

A few thoughts about enabling touch-action by default: 1. Code implemented in the bug 795567 uses c++'s APZC, so if we have in foreseeable future android and win32 platforms moved to use such APZC then it maybe worth to wait for it. 2. Code implemented in the bug 795567 has "not the most efficient" hit testing logic and it would be improved after touch-sensitive regions are landed (https://bugzilla.mozilla.org/show_bug.cgi?id=928833, in progress by Roc). So if we would like to deliver the better performance it's worth to enable touch-action after regions are done. Given this we might need to add bug 928833 and bugs of moving android/win32 to C++'s apzc as blockers. (Or do not add and switch to the decision of enabling by default only for metro).

(In reply to Nick Lebedev (MS) from comment #1) > 1. Code implemented in the bug 795567 uses c++'s APZC, so if we have in > foreseeable future android and win32 platforms moved to use such APZC then > it maybe worth to wait for it. I agree with respect to android, since it's on our to-do list to move it over to the C++ apzc. I'm not sure about win32 or the other desktop platforms that might support touch.

Note that we're having some trouble enabling touch-action in Chromium by default: https://code.google.com/p/chromium/issues/detail?id=372357. There's a flaw in a popular library (Hammer.js) that means many websites are broken by touch-action being supported: https://github.com/EightMedia/hammer.js/wiki/How-to-fix-Chrome-35--and-IE10--scrolling-(touch-action).

Thanks for the heads up!

Any update on when you're thinking you might enable touch-action support by default? We're still having trouble getting sites updated - might be a good idea to co-ordinate on the timing here.

touch-action should be enabled along with pointer events... Hard to say time atm. Metro backend is pretty much ready, but that isn't something for release builds, so some tweaking for Android etc need to be done.

This bug is also blocking bug 913153. Sebastian

I'm not sure if that's not the right place to raise this. I found an issue with pointer events relating to Windows 8 touch screen devices. According to the w3c pointer events spec: "3.2.2 The pointerdown event A user agent must dispatch this event when a pointer enters the active buttons state. For mouse, this is when the the device transitions from no buttons depressed to at least one button depressed. For touch, this is when physical contact is made with the digitizer. " However, nothing happens when I "touchstart" the screen. The first event is dispatched only when I remove or move the pointer (finger). The sequence of events is: pointerover > pointermove > mousemove > pointerdown > mousedown > pointerup > mouseup > pointerover I have tested FF Nightly v. 41.0a2.

This is not the right place - please file a new bug with a test case that demonstrates the problem. Thanks!

Any updates on the plan / an ETA?

Please update on status? FWIW Firefox is now lagging behind all other browsers on this feature: http://caniuse.com/#feat=css-touch-action The current HammerJs polyfill for touch-action has its own problems. It would be great to get to native support across the board. Is it possible that touch-action for touch events can be brought out from behind the flag, separate from the ongoing work on pointer-events?

Alex, Are you referring to our Hammer-Time touch-action polyfill? Or Actual HammerJS? HammerJS uses touch-action but is not a polyfill for it.

Sorry, the MS Open Tech people that were working on this are not anymore, and work on it has stalled somewhat. It also dropped off my radar the last few months. I'd like to pick it back up soon because there's not that much work left here, but it probably won't happen until after we are shipping APZ on Fennec (bug 1206874) which is what I'm focusing on at the moment. The good news is that once we have APZ on Fennec finishing the touch-action support will mean we will get it on all our platforms at once. However I wouldn't expect it in release before Firefox 48 at the soonest. Sorry about that.

Note that you may want to consider (as blink has done) separating touch-action and pointer events support. There are a number of reasons why touch-action support should be considered more urgent than the rest of pointer events (fast click library elimination, passive touch event listeners: https://github.com/RByers/EventListenerOptions/blob/gh-pages/explainer.md). At a minimum, with mobile Safari now supporting touch-action: manipulation for click-delay removal (eg. selectively on non-mobile viewport sites), Firefox is the only browser missing that support. It may be reasonable for sites to start depending on this, dropping their use of fastclick libraries entirely (and just living with the click delay on the small fraction of mobile browsers which don't support touch-action:manipulation).

Yes, I definitely would like to get touch-action in as soon as I can, with or without the rest of pointer events support.

Hello, which version of the FF this is fixed in? We are still seeing this issue.

(In reply to Vijay from comment #17) > Hello, which version of the FF this is fixed in? Good question. It's not obvious from this bug, as no patches actually landed here, but after some digging it looks like: * touch-action was enabled by default in Firefox 52 (bug 1244402) * pointer events were enabled by default on all platforms other than Android in Firefox 59 (bug 1411467) > We are still seeing this issue. Please be specific about what's not working for you (and probably file a new bug for it).