"Tim Abraldes" <tabral...@mozilla.com> wrote in message news:<aamdndrkq8yrr-3mnz2dnuvz_hwdn...@mozilla.org>... > > 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.
Agreed, that's the best place for it. If we run into platform specific settings we can expose constants as needed. > 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. > > 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. It's called on the widget when something in front end registers a touch event handler - http://mxr.mozilla.org/mozilla-central/source/dom/base/nsGlobalWindow.cpp#82 95 So if it hasn't been called, nobody is listening for touch events, and so we can skip sending them. > > ** 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. 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. This is a corner case I think, we could do either and see what bugs crop up. > > > *** 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. Jim _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
