> 1) abandon generating nsIDOMSimpleGestureEvents on Windows for both backends > when processing touch input from touch input displays.* > > This would mean that if the desktop front end wants to do something with > pinch or zoom, it would have to process W3C touch events instead. Note that > we could still fire simple gestures from devices like track pads. But for > touch input displays, we would not support these events.
If I understand the proposal correctly, widget would be responsible for sending only pointer/touch events (with the one exception you mentioned), and we would implement "simple gesture recognition" in a js module. This would give us a single implementation of gesture recognition that could be shared and used with multiple widget backends, and would simplify the widget backends because they no longer have to do gesture recognition. For those reasons, I think this is a great idea. 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. > 2) Rework how we process touch events in Windows widget such that: > * Both backends respect RegisterTouchWindow and only fire W3C events when it > is set. > * If RegisterTouchWindow has been called: This is the first I've heard of RegisterTouchWindow, so I can't speak to whether we should send touch events if it hasn't been called. > ** Send touchstart and the first touchmove and look at the return results. > ** If either of these returns eConsumeNoDefault, continue sending W3C events > only. No mouse or pixel scroll events would be sent. Sounds reasonable. > ** 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. > *** 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. > There is also the open issue of future support for other touch specs which > I'm not taking into consideration. If anyone has any input on W3C support > vs. MS Pointer support I'd love to hear it. I'd hate to get this all cleaned > up only to find that we have to change our touch input processing again for > the nth time. Maybe now might be a good time to abandon W3C completely. As I > understand it MS Pointer events solve some of the problems we have with > mixed touch/mouse input. As I understand it, W3C touch events (touchstart/touchmove/touchend) are the current state of the art, but are being abandoned in favor of W3C pointer events. I believe that we should definitely implement W3C pointer events. I'm not sure how widespread the usage of W3C touch events is, but it may be necessary for us to implement those as well for compatibility. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
