>> 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]. >>> ** 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. > 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. >>> *** 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. > > > 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
