Having a sendNativeTouchEvent function (like sendNativeMouseEvent) available to nsIDOMWindowUtils would be very helpful for test automation as we go forward with mobile projects like FFOS. Synthesizing our own using sendTouchEvent or initTouchEvent from chrome-level javascript only generate untrusted touch events, but we want to be able to generate trusted events so we can simulate user gestures.

Why not using something like sythesizeTouch from testing/mochitest/tests/SimpleTest/EventUtils.js ?

EventUtils.js uses sendTouchEvent, which doesn't create the trusted events we need. We need trusted events because we'd be able to interact with UI elements that require these events (any button that triggers a pop up window, like the Sign In button in marketplace, for example, requires trusted events).

AFAIK, EventUtils creates trusted events. It is used for every "user interaction simulation" in the mochitests.

Actually, I never used synthesizeTouch so maybe that one behaves differently? What makes you think it is not trusted? Did you use a specific test case?

The code for opening a Persona (browserid) card on B2G requires that trusted events be fired otherwise the button depresses and never actually does anything. see bug 847655 In working on that bug I can't see to get trusted touch events but can get trusted click events I used utils.synthesizeTouch(el, rect.left + 1, rect.top+1 ,{},el.ownerDocument.defaultView) and it doesnt work. The Persona card doesnt launch

Did you try setting this pref on device: dom.identity.syntheticEventsOk ? It may be a temporary workaround we can use. However, I can't actually find that setting in mxr. Jed, is this back door still available?

(In reply to Kumar McMillan [:kumar] from comment #6) > Did you try setting this pref on device: dom.identity.syntheticEventsOk ? It > may be a temporary workaround we can use. > > However, I can't actually find that setting in mxr. Jed, is this back door > still available? Hi, Kumar, yes, it's here: http://mxr.mozilla.org/mozilla-b2g18/source/dom/identity/nsDOMIdentity.js#130 It uses this getter: http://mxr.mozilla.org/mozilla-b2g18/source/dom/identity/nsDOMIdentity.js#55

jwatt, aren't you using synthesizeTouch for <input type='range'> tests? Though, maybe the code isn't expecting trusted events?

I am using synthesizeTouch for <input type='range'> tests, but the nsHTMLInputElement code for "range" doesn't check whether the events are trusted. Are you saying I should?

(In reply to Jonathan Watt [:jwatt] from comment #9) > I am using synthesizeTouch for <input type='range'> tests, but the > nsHTMLInputElement code for "range" doesn't check whether the events are > trusted. Are you saying I should? Not really but that means the method might likely be buggy and doesn't create trusted events while it should.

This has begun to be an issue with our automation. We've been simulating what a manual tap would do by dispatching touchstart/touchend/mousemove/mousedown/mouseup/click events from our automation framework (marionette), which has been working for most case. This approach is problematic now because our chain of event dispatching can be paused, leading to unintended problems. For example, if I simulate a tap on a button that causes a modal dialog to appear on touchend, then as a result of the modal dialog, the app frame is paused, and so our dispatching of the subsequent mouse events gets paused as well. This means that the dispatching of mouse events will occur *after* the modal dialog disappears and the app frame resumes, which is unintended. If instead, we were using something like sendNativeTouchEvent, this would not occur, since the dispatching of events is handled outside of the app frame. Who or what team would be responsible for adding such a method? Can we bump the priority of this bug?

@wesj Is this something that you can help us with?

Sorry for the delay. As to the trustedness of the events, I'm not sure what's up. EventUtils just calls DOMWindowUtils.sendTouchEvent() which sends a DOMTouch through widget code. i.e. you can't get much closer to simulating actual real touch events. I'm a bit busy, but we could look at extending DOMWindowUtils to allow passing an array of event types. i.e. DOMWindowUtils.sendEvents(["touchdown", "touchup", "mousemove", "mousedown", "mouseup"],...); But this sounds more like a problem with the test harness to me.

(In reply to Malini Das [:mdas] from comment #2) > EventUtils.js uses sendTouchEvent, which doesn't create the trusted events > we need. EventUtils.synthesizeTouch et. al. do indeed call nsDOMWindowUtils::SendTouchEvent, but actually that _does_ dispatch a trusted event due to the 'true' argument at this line: https://mxr.mozilla.org/mozilla-central/source/dom/base/nsDOMWindowUtils.cpp?rev=dde4dcd6fa46&mark=874#874 I wrote a test and caught the dispatched event in HTMLButtonElement::PostHandleEvent and can confirm that the event that reaches this method is indeed trusted. The thing is, HTMLButtonElement::PostHandleEvent doesn't handle touch events: https://mxr.mozilla.org/mozilla-central/source/content/html/content/src/HTMLButtonElement.cpp?rev=dde4dcd6fa46#221 (In reply to Wesley Johnston (:wesj) from comment #13) > But this sounds more like a problem with the test harness to me. The problem may be that the test harness is not carrying out the default action for the touchend event of dispatching a mousemove, mousedown, mouseup and click event as defined in the table here: http://www.w3.org/TR/touch-events/#list-of-touchevent-types (Assuming that's the relevant spec.)

(In reply to Jonathan Watt [:jwatt] from comment #14) > The problem may be that the test harness is not carrying out the default > action for the touchend event of dispatching a mousemove, mousedown, mouseup > and click event as defined in the table here: > > http://www.w3.org/TR/touch-events/#list-of-touchevent-types > > (Assuming that's the relevant spec.) Ah, so there was a bit of a misunderstanding when this bug was filed. Our goal is to get sendNativeTouchEvent triggering the expected event chain that you'd get if you physically interacted with teh screen. That is, if you tap on a screen in B2G, you will dispatch touchstart/touchend/mousemove/mousedown/mouseup/click. We understood it to be the case that if you dispatched trusted touch events, and if you sent touchstart then touchend, then you'd automatically get the mouse event generation for free. It seems that sendTouchEvent does indeed dispatch trusted touch events, but it doesn't send the mouse event chain we expect. http://mxr.mozilla.org/mozilla-central/source/dom/ipc/TabChild.cpp#1704 is the file that figures out if the touch events that are coming in are a tap or not, but somehow, when I test a chain of touchstart/touchend, it doesn't generate the mouse event chain when in B2G. The goal of this bug would be to have sendNativeTouchEvent generate what we expect according to the platform. Can we have something like this added?

FYI, we compensate for this in our harness by detecting if the user wants to send a tap, and then we dispatch our own mouse events, but it would be better (and would help us fix the issue in Comment #11) if the platform sees the touch events and does the right thing

closing and we can create a new bug if this is an issue in the future.