Android does not have native gesture events.
It might make sense to keep sending MozSimpleGesture events from nsWindow, as long as they don't interfere with the MozTouch events. Or we can implement gestures in the frontend instead. We might want to do that anway, because things like pinch-zoom on a touchscreen can benefit from more information than MozSimpleGestureMagnify provides.

Created attachment 481975[details][diff][review]
mobile-browser patch (WIP)
This is a very stupid patch just to prove that the events are received correctly. It implements pinch zooming (no swipe gestures). It makes a lot of assumptions about the events based on the current Android implementation.

The main bug related to touch events on mobile (bug 544614) is currently blocking-fennec:2.0-, although it has gone back and forth in the past. We have some open design questions (see bug 531974 and bug 544614) to be resolved before this is exposed to web content. Because this is 2.0- no one is actively working on it, although I am planning to do some prototyping work if I have extra time available.

Created attachment 540074[details][diff][review]
WIP Patch
WIP. This works to fire off multi-touch events from the Android to the parent process, but isn't "done" yet. I still needs to finish up things like event targeting (both firing the touch events on multiple targets if necessary, and setting targetTouches correctly on touch events), and preventing mouse events when preventDefault is called. But I think I'm at the point where getting some feedback would be helpful.
I realise the spec isn't exactly clear on all of this, and we will likely need to compare more with Apple, Google, Opera, etc implementations in order to make these things correct, but wanted to keep moving here as well.
Main question I wanted feedback on relates to caching. Every touchevent has a touches, changedTouches, and targetTouches attribute. Changed reflects touches that are different in this event, and target is touches that were originally targetted at this target. In order to get things like changed and targetTouches correct, we need to cache information about the previous events somewhere. So I've added a gCaptureTouchList hashtable in presshell to do that.
I know this current implementation isn't perfect, but wanted feedback on the approach, plus any big hairy things you wanted to bring up.

(In reply to comment #12)
> I realise the spec isn't exactly clear on all of this, and we will likely
> need to compare more with Apple, Google, Opera, etc implementations in order
> to make these things correct, but wanted to keep moving here as well.
yeah, handling of various touch lists needs testing.
Looking at the patch now. Sorry for the delay.

Created attachment 543521[details][diff][review]
WIP v2
This doesn't compile if I remember right, but has some targetting fixed. Namely, I think touchdown events were originally only targetted at the document. I fixed that, and then after we call EventDispatcher->DispatchEvent I am trying to take the event->target and store it. When touchmove's happen I iterate through the array of target's we have seen and fire touchmove on all of them (this isn't working right) yet. On touchup, I find the original touchdown target for this touch and fire the events on that.
Last thing to do after that is just some checks I wanted to put it in case we have nsITouch's in our hash table that aren't being cleaned up. And most of the cleanup mentioned by Olli above.
I'm out next week, but will try to get back on this when I get back. Wanted to put this up in case someone else has time to work on it.

Marking dev-doc-needed so that MDC can track when this is finally done.
On the progress front, still digging through targeting. Apparently we target mouseevents by using the coordinates of the event itself. For multitouch, on touchstart I think I need to determine which is the new touch and use its coordinates for targeting.
I've already modified this so that on touchend, the widget code only sends us the touch that ended and we append (for the queue of active touches) everything else. I think I may do the same thing for touchdown so that I don't have to dig through the queue on every touchdown and figure out what is new.

Created attachment 548658[details][diff][review]
Patch part 1/4
Everythings starting to come up milhouse here. This implements the platform backend for touchevents. Mostly done. Need to address the feedback comments and just do all around cleanup/testing. Happy to get more feedback if there is any!

Created attachment 548661[details][diff][review]
Patch part 3/4 - Mobile frontend
This attaches to the mobile front to (currently) take touchevents and redispatch GestureEvents. Its directly copied from the old platform code, but needs a few fixes to deal with cancelling mouseevents fired by the initial mousedown.
This is still not forwarding these events to content. That would be Part 4/4... or we can put that in a separate bug.

Adding depends on bug 676275 (support newer sdks) since there are newer multitouch apis (off the top of my head i remember orientation of touches, as well as separate x and y radius stuff) in new sdks that would be useful.

Comment on attachment 550873[details][diff][review]
Patch v1 - 1/4 -> Platform changes
Could you investigate if just having nsDOMTouch could be possible.
It is a bit ugly to copy all the data from nsTouch to nsDOMTouch.

Created attachment 569731[details][diff][review]
Unbitrotted WIP platform and widget stuff
Sorry. Have been busy and haven't had time to put into this. Sounds like someone from B2G may be able to grab this?
I had removed all of my nsTouch stuff and had this compiling. Was then crashing whenever you touched the screen (it looked like when I tried to get the id of the touch).
This is very very very quickly unbitrotted and checked to make sure it compiled. Not installed and tested at all, but wanted to put it up if someone else was going to grab this. It includes both platform and widget stuff because i accidentally intermixed the two and haven't had a chance to pull them apart again.

Created attachment 571790[details][diff][review]
Patch v2
So this seems to work fairly well (for me) passes the single and multi-touch tests up for the charter (although they're very simple, and we do fail one for not having a relatedTarget attribute on these?), works with a few simple demos I found around the web that aren't to webkit specific to be useless (including jquery mobile ones).
Unfortunately, it doesn't pan Google Maps. (lots of "JavaScript Error: "a.target is null" {file: "http://maps.gstatic.com/cat_js/intl/en_us/mapfiles/378b/maps2/%7Bmain,mod_util,mod_mmh,mod_mmpc,mod_mobpnl,mod_rst%7D.js" line: 1948}" errors). So I'm going to plug away at it for another day. Get rid of some of the useless logging I have scattered around. Try to add some more comments so its all not too mysterious, and write some more tests to make sure mouse events are being prevented correctly, etc. Hopefully not have to dig into the maps source to hard.
Olli, if you want to start glancing at this, I'm hoping to have it up for review... soon.
For anyone who wants to play with it, Native UI build is at http://people.mozilla.com/~wjohnston/fennec_touch.apk

Created attachment 572107[details][diff][review]
Patch 1/2 Platform stuff
So my problem with GoogleMaps turned out to be that I wasn't setting the target of each touch correctly. Now fixed (here and in the touchevents spec) along with a few other little quirks. Google Maps pans well. Bing supports two finger pinch zoom and works well (except requiring a UA tweak to even get to it...). All the other demos and tests I've managed to fine seem to work.
I moved mTarget to be a WeakReference, so that if the page removes the node while the touch is in progress we just start returning nothing? We'll also maybe hit problems dispatching I expect... Not sure that's right there. Also not sure what to do with the NS_IMPL_CYCLE_COLLECTION stuff at the top of nsDOMTouchEvent.cpp.

Sorry for the bug spam, but also though I'd note that this removes our support for MozGesture (for now). The frontend patch I have up reimplements that in JS. I figured we can do that if we want it back, but happy to hear better ideas.

Created attachment 572138[details][diff][review]
Patch 1/2 Platform stuff v2
Removed the weakptrs. Quickly. Feel free to tell me I did all of this horribly wrong. I have a test page for that I'll put up here for fun too!

(In reply to Wesley Johnston (:wesj) from comment #31)
> Sorry for the bug spam, but also though I'd note that this removes our
> support for MozGesture (for now).
On Mobile? I hope this doesn't remove support for gesture events on OSX/Win7.

(In reply to Olli Pettay [:smaug] from comment #35)
> (In reply to Wesley Johnston (:wesj) from comment #31)
> > Sorry for the bug spam, but also though I'd note that this removes our
> > support for MozGesture (for now).
> On Mobile? I hope this doesn't remove support for gesture events on OSX/Win7.
Oh yeah. Didn't mean to scare anyone. Removes gesture events on Android only (and only for now, we'll probably have to re add them for things like pinch zoom).

Created attachment 573972[details][diff][review]
WIP Widget
This is a WIP updated to build against the new birch stuff and address blassey's comments. Sorta works to prevent panning. I added a timeout on the first action_move event. If the content process doesn't answer in time, we'll allow panning. Timeout is pretty fast (100ms) right now, and in the mean time we still allow events to go the the PanZoomController. It just doesn't do anything. I think that means that when those 100ms are up we move as if you had never prevented anything to begin with. Seems to work well here.
Needs cleanup. Probably broke some important things like clicking. I will probably prioritize the platform side over this for now though because it involves changes to Gecko we will need in for the platform freeze.

Created attachment 574498[details][diff][review]
WIP
Putting this up because I promised mwu I'd get him something. This applies cleanly on birch and mozilla-central for me.
Fixed most of the nits. Still trying to decide/figure out what to do about the memory issues. And writing some tests.
I'm not sure that this will help with panning in B2G. Certainly you can use touchevents for panning, and being able to detect multitouch will let you determine whether to pan or pinch zoom. But Fennec did the same thing formerly using mouse events + a filter in widget/src/android/nsWindow.cpp to NOT send mouse events when multitouch was happening.

Created attachment 575343[details][diff][review]
WIP
No idea why, but I have some obsession with uploading these WIP Patches. This implements a whole lot of the changes requested from mwu and smaug. Need to make another few passes through to make sure I've gotten everything. Maybe look at using nsTArray<nsDOMTouch> rather than the super awesome nsTArray<nsCOMPtr<nsIDOMTouch>> I've got now. It also adds a bunch of tests. I'll probably pull those into their own file for review. Still rebasing the widget code to test this with.
One thing I realized writing the tests is that the way I am preventing mouse events on preventDefault is a bit funny. If you call preventDefault, presShell will start eating all mouse events until the next touchstart fires. That means, if for some reason another touchstart never fires (maybe you switch to kbm mode on a desktop?) we won't fire any mouse events. I'd like to just eat them until touchend, but we also need to fire the final mouseup (which can also cause a click to fire) after we've fired touchend.
I think the right solution is to move the prevent logic into widget? We can return a status on the touch events that says basically, "Don't fire anything else related to this event." I'll have to preserve that state in presShell so that calling preventDefault on just touchstart (or first touchmove) will continue to return that status flag for all touchevents until (the last?) touchend.
I don't like depending on a correct widget implementation to match the spec, but I'm not sure if there's a better way?

(In reply to Wesley Johnston (:wesj) from comment #42)
> I don't like depending on a correct widget implementation to match the spec,
> but I'm not sure if there's a better way?
It's already a problem, so you wouldn't be making it any worse. We already require preventDefault to be explicitly handled to determine whether a keypress should be fired after a keydown.
Of course, it would be nice if widgets didn't need to have to work so hard.

Created attachment 578211[details][diff][review]
Patch v2
I think this has all the changes requested by smaug and mwu as well as the new tests.
I removed the yelling when we get to many touches. Instead, if widget sends a touchstart event with a touch point in it, but there are still touch points in our queue, I'm firing touchend events for all the points in the queue (maybe that should be touchcancel?), and sending an NS_WARNING.
I also removed the code the prevents mouse events and instead I'm just sending a status of nsEventStatus_eConsumeNoDefault to widget iff preventDefault was called on touchstart/first touchmove for all subsequent touches until the final touchend in this set.
Still working on a revised version of our widget code.

Created attachment 579330[details][diff][review]
WIP Widget
Saving my place.
This works fairly well though. I noticed that at times I am not getting touch events in nsWindow.cpp until several seconds after they are dispatched. Some digging shows that's because we aren't "coalescing" paint events any more, which also means we aren't coalescing most touchmove events (since we usually have move-draw-move-draw-move-draw and we had special code in place to coalesce the two). Not getting the events means we can't tell if the page called prevent default, and we'll occasionally allow panning for a few seconds before suddenly stopping it (I'm not sure if the page should snap back at that point or what). Rummer is someone has a patch to return the coalescing behavior.
I also started putting in a notification to be fired when a page registers touch event listeners. Hopefully we can use it and only introduce this (potential) panning delay on pages that need it.

Created attachment 579712[details][diff][review]
Widget Part 1/3
Splitting this out into pieces for review. Works well except that I've killed both clicking and doubletap zoom. Hopefully I can clear those up and put this up tomorrow.

Created attachment 579715[details][diff][review]
Widget Part 3/3 - Look for touch listeners
This part creates a notification if the page has touch listeners, and uses it to decide whether or not to wait for touch events before panning.

Created attachment 580134[details][diff][review]
Widget Patch 1/3 - Dispatching touch events
These patches together work well for me, but I'm seeing crashes in XUL Fennec, with not much useful info in the logcat. Need to build debug.

Created attachment 580135[details][diff][review]
Widget Patch 2/3 - Prevent Default stuff
Prevent default stuff. Was planning to get a review from you katz. Before I do, maybe you can give me any feedback you have on the general idea? This is a bit racy...

Created attachment 580141[details][diff][review]
Platform Patch
Whoops. Did I accidentally remove my last patch here? This is the platform bit. Has a few fixes for some little glitches I found writing widget stuff, but mostly intact.

Comment on attachment 580135[details][diff][review]
Widget Patch 2/3 - Prevent Default stuff
In general this approach seems kind of brittle to me. I'd prefer doing it the other way. In LayerController, intercept touch events coming from LayerView, and when you see a touch-down, send it to gecko and start queuing up additional touch events coming in from the LayerView until either (a) the timeout expires or (b) you get a preventPanning() call from nsWindow. If (a) happens, then continue with the normal processing of the touch events, and if (b) happens, then only send the events to gecko.
The way you're doing it now seems more brittle because it slices into PanZoomController and allows partial execution of that code, which is likely going to break hidden assumptions in the PZC code and lead to hard-to-find bugs.
The approach I'm suggesting is (I think) cleaner, although it might require some rearranging of the onTouchEvent functions in LayerController and LayerView to make sure that queuing/resuming of events is possible there. What do you think?

Created attachment 580362[details][diff][review]
Widget Patch 2/3 - Prevent Default stuff
I like the idea kats, and so I implemented it!
We have to copy the motion events in order to keep android from overwriting them each time around. Otherwise this seems to work fine.

Created attachment 580363[details][diff][review]
Widget Patch 3/3 - Touch Listeners
This keeps us from doing any of this stuff on pages that have no registerd touch listeners. Asking for review from mfinkle for the fennec-ish stuff, and smaug for the touch event listener notification.

Comment on attachment 580383[details][diff][review]
Widget Patch 2/3 - Prevent Default stuff
Overall pretty good, but r- for the threading issue below.
>+++ b/mobile/android/base/gfx/LayerController.java>+import org.mozilla.gecko.GeckoAppShell;
>+import org.mozilla.gecko.GeckoEvent;
>+import java.util.Timer;
>+import java.util.TimerTask;
>+import java.util.Date;
GeckoAppShell and Date imports not needed.
>- if (mPanZoomController.onTouchEvent(event))
>- return true;
>+ int action = event.getAction();
>+ switch (action & MotionEvent.ACTION_MASK) {
>+ case MotionEvent.ACTION_DOWN: {
>+ preventPanning(true);
>+ }
>+ }
You could use an if instead of a switch here, unless you anticipate needing to add more cases (which I don't think will happen because this is based on the touch events spec).
>+ case MotionEvent.ACTION_MOVE: {
>+ if (!inTouchSession && allowDefaultTimer == null) {
>+ inTouchSession = true;
>+ allowDefaultTimer = new Timer();
>+ allowDefaultTimer.schedule(new TimerTask() {
>+ public void run() {
>+ preventPanning(false);
>+ }
>+ }, PREVENT_DEFAULT_TIMEOUT);
The preventPanning call should always happen on the UI thread or you're gonna end up with races/unsynchronized access. The timer will operate on another background thread, so you should post another runnable back to the UI thread to do the preventPanning call, or use something like the GeckoAsyncTask with a Thread.sleep() in the doInBackground(), or something else.
>+ case MotionEvent.ACTION_UP: {
>+ inTouchSession = false;
>+ }
This should also happen on a touch cancel event for robustness. Also, I'm not sure what the spec says about multitouch, but you probably need a check here for getPointerCount() == 1 to avoid terminating the session too early. Actually the same applies for the ACTION_DOWN case above, I think you want to not do anything with that if getPointerCount() > 1.
>+ }
>+ return !allowDefaultActions;
>+ }
>+
>+ private boolean allowDefaultActions = true;
>+ private Timer allowDefaultTimer = null;
>+ private boolean inTouchSession = false;
I'd prefer if these were moved up with the other declarations at the top of the file, for consistency with Java style.
>+++ b/mobile/android/base/gfx/LayerView.java>+ private LinkedList<MotionEvent> mEventQueue = new LinkedList<MotionEvent>();
Please move declaration up. Also add a comment that it should only be touched from the UI thread.
> nsEventStatus status;
> DispatchEvent(&event, status);
>+ if (status == nsEventStatus_eConsumeNoDefault) {
>+ AndroidBridge::Bridge()->PreventPanning();
>+ return true;
>+ }
> return false;
Does this only happen for down events? We shouldn't call preventPanning if the page does preventDefault on a motion or up event.

Created attachment 580419[details][diff][review]
Widget Patch 2/3 - Prevent Default stuff
> The preventPanning call should always happen on the UI thread or you're
> gonna end up with races/unsynchronized access.
I just posted to the mController.
> not sure what the spec says about multitouch, but you probably need a check
> here for getPointerCount() == 1 to avoid terminating the session too early.
> Actually the same applies for the ACTION_DOWN case above, I think you want
> to not do anything with that if getPointerCount() > 1.
Little known fact, but ACTION_DOWN and ACTION_UP are actually only set where there's one touch. Multiple touches will have ACTION_POINTER_DOWN/UP set. I left this for now, but we can add the extra check if you want.
> Does this only happen for down events? We shouldn't call preventPanning if
> the page does preventDefault on a motion or up event.
So pages can only prevent panning on touchdown or the first touchmove. If they do, Gecko will return ConsumeNoDefault for that touch and all subsequent touches that happens. If the page calls preventDefault on a touchmove after the first (or on touchend) Gecko will still just return Ignore.
That means this currently sends a whole lot of preventPanning calls to Gecko, which usually just clears the queue. We could try and clean that up, but I wasn't in the hurry to optimize there right now. Maybe we need to though?

Created attachment 582444[details][diff][review]
Platform Patch
> Why this change? You aren't removing the older Win7 touch event handling
> elsewhere.
Just a mistake. Thanks.
> So this is same as what nsDOMUIEvent::GetPagePoint() does. Could you move
> the code to some helper method? Maybe to nsDOMEvent
> Also, could you please handle mPrivateDataDuplicated case, so that after the
> event has been dispatched, pageX/Y etc have still the right values.
I moved all three getPagePoint, getClientPoint, and getScreenPoint to be static methods in nsDOMEvent. I was attempting to pass mPrivateDataDuplicated to it so that it could return if necessary, but I gave up and just moved the checks back into nsDOMUIEvent.
> This crashes if mTargetTouches and mEvent are null.
> Call* methods aren't null-safe, do_* methods are
> mEvent shouldn't be ever null, so you could add NS_ENSURE_STATE(mEvent);
I don't think I needed this? Just switched to NS_ENSURE_STATE(mEvent).
> Could this be a (C++) helper method in nsIDOMTouch object?
Done.
> I wish I had an Android device which can run Fennec-trunk, but tablets
> aren't supported atm :(
Tablet support isn't great, but its not bad atm. Good enough to run tests on these if you want (and since tablets typically support more touches, you can test a bit more too). Portrait mode works better than landscape. I can provide a build if you want (or I just sent off a try run):
https://tbpl.mozilla.org/?tree=Try&rev=675c29c4d7a3

Created attachment 583033[details][diff][review]
Platform Patch
> Why you move this here? Do this when you have if (!aFrame)
I'm not exactly sure what you meant here, but I moved this earlier in the function?
> This needs documentation. How is the new method different from the old one.
> What is aPoint?
I added some documentation comment, but I'm not sure what more to write beyond this is a point that you want to get its coordinates relative to a frame and the widget associated with this event? I don't have a strong idea of what either of those even are (and no one I talk to does either).
> I think you should use EvictOldTouchPoints (call it perhaps
> GetOldTouchPoints) to collect touch objects to a list
> (nsCOMArray<nsIDOMTouch> for example)
> and then iterate through the list and dispatch events.
> Dispatching events at somewhat random time, like here during hashtable
> enumeration, is scary. Keep in mind that dispatching an event
> may destroy worlds (i.e. close windows)
Done. We actually already have an enumerator that adds everything in the hash table to another array, so I used it.

The pref makes development harder for pages that try to work across both touch and mouse interfaces. Gaia (b2g UI), for example, normalizes all mouse events to touch events in order to simplify input-processing code. With this pref disabled though, |document.createEvent('touchevent')| throws NS_ERROR_DOM_NOT_SUPPORTED_ERR, which doesn't really make sense to me. We still can support *creating* touch events everywhere, even if Gecko would never deliver them to pages.
addEventListener("touchstart", ...) still succeeds, which is odd to me. It seems better for authors to have that call fail if we didn't support touch events. But DOM event semantics are not my specialty :).
Can we find a happy solution to this problem, or is this behavior in the spec?

(In reply to Chris Jones [:cjones] [:warhammer] from comment #88)
> The pref makes development harder for pages that try to work across both
> touch and mouse interfaces. Gaia (b2g UI), for example, normalizes all
> mouse events to touch events in order to simplify input-processing code.
> With this pref disabled though, |document.createEvent('touchevent')| throws
> NS_ERROR_DOM_NOT_SUPPORTED_ERR, which doesn't really make sense to me. We
> still can support *creating* touch events everywhere, even if Gecko would
> never deliver them to pages.
No. "TouchEvent" in window or document.createEvent("TouchEvent") etc
are used as a feature detection whether the browser supports touch events.
If gaia sends Touch events to web content, then it of course needs to enable that pref.
> addEventListener("touchstart", ...) still succeeds, which is odd to me.
"touchstart" is just event type. The event you get in the listener could be for example
a key event named "touchstart"
> It
> seems better for authors to have that call fail if we didn't support touch
> events.
No. That is not how DOM events work. You can always add a listener for any event type.
event.type doesn't say anything about the interface event implements.
> Can we find a happy solution to this problem, or is this behavior in the
> spec?
Not exposing TouchEvent and other relevant APIs when it isn't actually supported is a web compatibility requirement.

Created attachment 588700[details][diff][review]
Platform patch fixes
Found some problems in the platform patch. This fixes them. Tests pass locally, and mostly on try (waiting for more results). Also adds a few tests I meant to add but forgot about.

Created attachment 588702[details][diff][review]
IFDEF platform pieces
This ifdefs (with ifdef ANDROID) all of the platform changes so that we can potentially move this forward to Aurora. I made no changes to the underlying patches. I'm not sure what I need to do for review with this.
In addition, I can put up a patch that has all of this qfolded if that makes it easier to verify that there are no changes to the non-Android platform. Not sure what people will want...? Happy to have extra eyes looking for mistakes.

Comment on attachment 582446[details][diff][review]
Widget Patch 3/3 - Touch Listeners
This patch has much of the same code in it as the other "Widget 3/3" patch and my comments are the same as well.
Which is the one you intend to use?

Comment on attachment 588702[details][diff][review]
IFDEF platform pieces
I really can't review any of this code. The idea is good: use #ifdef to make this code safer for landing on aurora. I think smaug need to review this.

Comment on attachment 588702[details][diff][review]
IFDEF platform pieces
>-[scriptable, builtinclass, uuid(98bc0f7d-5bff-4387-9c42-58af54b48dd5)]
>+[scriptable, uuid(98bc0f7d-5bff-4387-9c42-58af54b48dd5)]
You should keep builtinclass.
So, touch interfaces are currently enabled, AFAIK, only on Android, and while running mochitests.
So most the ifdefs are not needed. Only the cases when mouseevent or uievent handling is changed
might need ifdef

Created attachment 588819[details][diff][review]
IFDEF platform pieces
This should just ifdef the pieces where I've changed our Screen/Client/Page coordinate calculations, nsLayoutUtils, and the changes in nsPresShell::DispatchEvent. Also turns off the tests on non-Android platforms since the touch events will not pass through nsPresShell correctly.
I also cleaned up a stray function declaration left behind from an old version.

Created attachment 589648[details][diff][review]
Folded platform patches
Awesome. All set up to check this in. I switched to #ifdef MOZ_TOUCH, but only enabled it for ANDROID (I don't want to mess up something in B2G if you guys aren't ready?). mbrubeck (and anyone else who wants) is going to give a build a once over tonight to give feedback. Build is at:
http://people.mozilla.org/~wjohnston/fennec-touch.apk
(or with this and the following he can build himself).

Created attachment 591118[details][diff][review]
Fixes for widget
Included a pointerIndex field. I added the preventPanning function because it is implemented in Native Fennec and XUL Fennec fails when try to attach it via JNI. This seemed like the simplest fix. I added a comment explaining that its only used in Native Fennec. We can do something fancier if you want?

Comment on attachment 589648[details][diff][review]
Folded platform patches
Requesting Aurora Approval for this patch
User impact if declined: No way to interact gesturally with pages. Currently that behavior is preffed off, so right now the impact is minimal.
Testing completed (on m-c, etc.): This has been on mc since 1-18. AFAIK, no regressions have been found on Desktop or Mobile.
Risk to taking this patch (and alternatives if risky): We took care to #ifdef the parts of this patch that affected things outside mobile so that there would be no impact to the desktop product. The things that aren't ifdef'd are paths that desktop should not hit, especially since the pref for touch events is off there, making it impossible to dispatch them. The risk is low, but higher than some of our other mobile-only patches.
Just two days ago I landed a series of widget patches that depend on this on m-c. We need to be able to uplift those patches to aurora, if for no other reason that to minimize differences between aurora and mc for people landing patches on both. Doing that would be easiest if we uplift this patch as well.
Alternatively, we could modify the widget patches in order to minimize the differences between mc and aurora (but there would still need to be some minor ones, likely in nsWindow.cpp::DispatchMotionEvent() and land them that way.

In an Aurora build of 2012-01, I see currently in about:config:
dom.w3c_touch_events.enabled true
dom.w3c_touch_events.safetyX 5
dom.w3c_touch_events.safetyY 20
Is that expected? Or is that cruft from the XUL version of Fennec?

(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #121)
> In an Aurora build of 2012-01, I see currently in about:config:
> dom.w3c_touch_events.enabled true
> dom.w3c_touch_events.safetyX 5
> dom.w3c_touch_events.safetyY 20
>
> Is that expected? Or is that cruft from the XUL version of Fennec?
That's cruft copied from XUL Fennec. Those prefs have no effect on Aurora right now.

Is there a reason that nsLayoutUtils::GetEventCoordinatesRelativeTo(const nsEvent* aEvent, nsIFrame* aFrame) can't just be a wrapper for nsLayoutUtils::GetEventCoordinatesRelativeTo(const nsEvent* aEvent, const nsIntPoint aPoint, nsIFrame* aFrame) instead of duplicating it almost exactly? The code is a little bit delicate and I'd really prefer not to have two copies sitting around waiting to get out of sync.

Nope. I need to remove all the #ifdef MOZ_TOUCH pieces entirely. We should be fine. They are only there so we could safely move this forward to Aurora and Beta if necessary. I'll push a patch with that change to try tomorrow (but 722965) and if its good put it up for review.
Slipped my mind. Sorry :(

I've filed bug 745071 for win8 metro, but based on a comment from mbrubeck in bug 508906, I'm not sure which event system to go with. What was our reasoning for implementing the w3c events? Are we feeling upbeat about the outcome of the patent issues?