1091889 - Touch events on B2G get retargeted to the nearest clickable element

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Kartikaya Gupta (email:[e-mail])]

Currently on B2G touch and mouse input event targets are shifted to be a nearby clickable element (or an element with touch listeners or whatever). However, the coordinates of the events are not changed. Therefore it is possible for listeners to receive input events where the coordinates of the event are outside the bounds of the target of the event.

Furthermore, the touch events are fuzzed the same as the mouse events, whereas other browsers don't shift touch events around at all (only mouse events). Fennec's code changed recently and ended up doing the same thing B2G is doing, but I'm changing it back to the previous behaviour for compatibility in bug 1078029. I recommend that B2G also change how it does this so that we are compatible with other browsers and with Fennec.

There is additional backstory at https://bugzilla.mozilla.org/show_bug.cgi?id=1078029#c10

Changing the platform behaviour in B2G should be relatively straightforward (just fiddling with some prefs after bug 1078029 lands) but there might be fallout on the Gaia side. In particular it means that the touchstart event target may be different from the click event target, so using touchstart for highlighting/activating/clicking stuff may be wrong. Something to think about.

Comment 1

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #0)
> In particular it means that the touchstart event
> target may be different from the click event target, so using touchstart for
> highlighting/activating/clicking stuff may be wrong. Something to think
> about.

We're using the target element from a `touchstart' event in the dialer's keypad to establish which key was tapped by the user. I suppose this shouldn't affect us as we're not relying on the event's target coordinates. We use `touchmove' coordinates together with elementFromPoint() to figure out if the user is moving out of the button, I suppose this shouldn't be affected either. BTW this is something I've been wanting to change for a while but it's been in the long list of dialer refactorings we didn't have a chance to do yet.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

(In reply to Gabriele Svelto [:gsvelto] from comment #1)
> We're using the target element from a `touchstart' event in the dialer's
> keypad to establish which key was tapped by the user. I suppose this
> shouldn't affect us as we're not relying on the event's target coordinates.

What I'm proposing here is for the touch events to reflect the "raw" input event and target. So what I'm suggesting will in fact change the target element of a touchstart in the cases where the users taps near but not directly on a button in the dialer keypad. I'm not sure how often that scenario gets hit though. If you used the target from the mousedown or click event that would be the same as what it is now (and the same as what the touch events have now).

Comment 3

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #2)
> What I'm proposing here is for the touch events to reflect the "raw" input
> event and target. So what I'm suggesting will in fact change the target
> element of a touchstart in the cases where the users taps near but not
> directly on a button in the dialer keypad.

This will actually be beneficial for us then. We had a bug we were forced to close as WONTFIX where tapping on the disabled call button close to the adjacent enabled button was registered as a tap on the latter. This was not a common situation but mildly annoying since the user had obviously tapped on a disabled button yet the one next to it would be activated just because the target was close to the tap. With your change I assume this won't happen anymore.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

Assuming you're listening for touch events, yes, this change would fix that problem.

Comment 5

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #4)
> Assuming you're listening for touch events, yes, this change would fix that
> problem.

Yes, we're explicitly using touch events and not click/mouse ones.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

Attachment: Patch

Try push for platforms that use b2g.js: https://treeherder.mozilla.org/#/jobs?repo=try&revision=bf8492ddb90a

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Updated try push since there were general infra issues during the previous one: https://treeherder.mozilla.org/#/jobs?repo=try&revision=698451d6a6f3 - looks like there are a couple of b2gdesktop things that break with this change. I don't have cycles to look into it now so unassigning.

Comment 8

[Julien Wajsberg [:julienw]]

I think we should actually be consistent accross all our products here...

Comment 9

[BMO Automation]

Firefox OS is not being worked on