I work on touch support in Chrome desktop (and the touch events and pointer events standards). Most of the mozilla implementation details in this thread are over my head, but I wanted to add a couple comments in case it's helpful. Inline.
On Thursday, April 18, 2013 10:06:57 PM UTC-4, Tim Abraldes wrote: > >> The metro/WinRT widget backend can take advantage of native gesture > > >> recognition, so maybe in the future we would want to implement the > > >> ability to opt-out of front-end gesture recognition. I don't think we > > >> should do this in the immediate term, but as backends get better and > > >> better native support for things like gestures, we may want to allow > > >> ourselves the opportunity to take advantage of that native support. > > > > > > > > > Maybe, if we need to. Currently the metro front end doesn't use most > > > of the simple gestures widget sends so might as well disable processing > > > and delivery for now. From what I remember we aren't planning on using > > > the native cross slide gesture recognizer either. > > > > That's correct; we're implementing detection of the cross slide gesture > > in js in bug 829056 [1]. > I think this is analogous to what we do in Chrome - always use RegisterTouchWindow and do our own gesture recognition (for scrolling, flinging, long press, etc.). IE10 appears not to do this, instead relying on the pointer event support in Windows 8 and so a very limited touch input model on Windows 7. > >>> ** If both of these events do not return eConsumeNoDefault: > > >>> *** Abandon sending W3C touch events. > > >> > > >> I'm not sure that we should stop sending W3C pointer/touch events. It's > > >> conceivable that a page exists that is not scrollable, uses touch input, > > >> and does not bother to call `preventDefault` on the pointer/touch events > > >> it receives (which means we won't get eConsumeNoDefault returned). If a > > >> page is ignoring W3C pointer/touch events anyway, I don't think it is > > >> harmful to keep sending them. > > > > > > > > > I think we want to enforce the W3C spec. > > > > The spec doesn't say anything about not sending touch events if > > preventDefault wasn't called on the first touchstart/touchmove. > > > So for example, say a page is > > > listening to touch events and drawing something in response, but fails > > > to call preventDefault. Widget on desktop would generate pixel scroll > > > events and send touch events. You would have a web page reacting to > > > touch events while the browser scrolls. > > > > Page A > > Responds to touch input by drawing > > Does not call preventDefault > > Is scrollable > > > > Page B > > Responds to touch input by drawing > > Does not call preventDefault > > Is not scrollable > > > > If we stop sending touch events when preventDefault isn't called on the > > first touchstart/touchmove: > > Page A fails to draw but scrolls correctly > > Page B fails to draw > > > > If we send touch events regardless of preventDefault: > > Page A scrolls correctly but draws while scrolling > > Page B draws correctly > > > > Neither situation is ideal (the page really should call preventDefault > > on its touch events) but I think the latter behavior is preferable. > Yeah the spec is woefully under specified here - in part because the major implementations at the time differed. There are legitimate scenarios where pages will listen for touch events but not call preventDefault (eg. they might want to respond to pan or pinch gestures without supressing click behavior for the simple case of a touch not moving much). Mobile safari and Chrome desktop generally handle this as you've described as preferable. You can experiment with this easily using www.rbyers.net/eventTest.html (the alternate prevent-default on touchmove every second option is particularly useful for seeing how partial consumption of moves during scrolling behaves). This behavior can be a problem for threaded scrolling though (see https://plus.google.com/115788095648461403871/posts/cmzrtyBYPQc). For this reason, Chrome for Android (and in some cases mobile safari) will send a touchcancel event (and then stop sending touch events) after scrolling has started. > > This is a corner case I think, we could do either and see what bugs > > > crop up. > > > > I agree; any page that actually listens for touch events should be > > calling preventDefault on those events. > > That's what we'd like to encourage for the common scenarios (eg. see this article: http://www.html5rocks.com/en/mobile/touchandmouse/), but as I said above there are some special cases where it makes sense to do something else. > >>> *** Generate pixel scroll events in the appropriate direction based on > > >>> DecideGestureEvent, or simple mouse events if DecideGestureEvent > > > indicates > > >>> scrolling isn't possible. > > >> > > >> We should definitely send scroll events. If scrolling isn't possible, I > > >> don't think we should do anything special; certain mouse events will > > >> already be sent when the user performs non-scroll touches (as per the > > >> W3C specs) and we don't want to start sending a bunch of extra mouse > > >> events all of a sudden. > Yeah, this is a tough trade-off. It's tempting to try to better emulate mouse - more mouse-based sites would certainly work better if it were possible. But relying on whether scrolling is possible to decide when to send mouse events is pretty brittle (should resizing a window really change the behavior so fundamentally)? Despite the pain, all implementations of touch events that I'm aware of punt on this and say that mouse events are generated only in response to (and after the end of) specific gestures - in particular a tap (touchstart, touchmove*, touchend, mousemove, mousedown, mouseup, click). > > > > > > If we implement sending synth mouse events up in the DOM, great. If not, > > > we'll need to deal with it down in widget. > > > > In the metro/WinRT widget backend we handle sending > > mousedown/mousemove/mouseup in response to touch input. It sounds like > > we'll want to additionally send scroll events for certain touch input. > > I'm not sure how things are handled in the desktop widget backend. > > > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=829056 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
