1000985 - [B2G] 'click' events are not triggered if there is an existing touch on-screen

Status: RESOLVED WONTFIX

(Core :: DOM: Events, defect, P3)

Description

[Justin D'Arcangelo [:justindarc]]

If a finger is held down anywhere on-screen, a second finger cannot be used to trigger 'click' events on any other elements.

Comment 1

[Diego Marcos [:dmarcos]]

This affects to all gaia apps. I would expect click events to be delivered on two finger taps. There are two scenarios:

1. Double finger tap when one finger is over an element with onClick callback attached and the second finger is over an element with no onClick listener. The element with the onClick should get the click event.
2. Double finger tap when both fingers are on elements with onClick listeners attached. Gecko should resolve the conflict and deliver the click event to one and only one of the elements.

iOS and Android handle these scenarios gracefully. I recorded a couple of videos illustrating the issue in the camera and clock apps (attached to this bug)

Comment 2

[Diego Marcos [:dmarcos]]

Attachment: twoFingerTapClock.MOV

Comment 3

[Diego Marcos [:dmarcos]]

Attachment: twoFingerTapCamera.MOV

Comment 4

[Diego Marcos [:dmarcos]]

It's very important to have this fixed. Hema can you escalate this to someone on the gecko side?

Comment 5

[Mike Habicher [:mikeh] (high bugzilla latency)]

Fabrice, Hema is OoO at the moment--do you know who can help out with this?

Comment 6

[Diego Marcos [:dmarcos]]

I attached videos showing how android and ios behave in the same situation.

Comment 7

[Diego Marcos [:dmarcos]]

Attachment: settingsIOS.3gp

two finger tap on iOS

Comment 8

[Diego Marcos [:dmarcos]]

Attachment: settingsAndroid.MOV

two finger tap in gaia

Comment 9

[Diego Marcos [:dmarcos]]

Attachment: settingsGaia.MOV

two finger tap on settings ffos

Comment 10

[Jason Smith [:jsmith]]

Can someone get a reduced test case here to demonstrate the bug? We can do a regression window if we have that.

Comment 11

[Diego Marcos [:dmarcos]]

I'm not sure if this is a regression. It's the way that gecko behaves that it's not well optimized for touch screens. Below two test cases. The videos also illustrate well the problem and the behavior of android and iOS for the same scenario

Test case 1:

1. Open clock app.
2. With two fingers and tapping simultaneously. One finger taps one of the tabs on the bottom and the other one taps anywhere on the screen.

Expected result: The tab gets the click event and the app transitions to a different section
Actual Result: The tab button doesn't get the click event.

Test case 2:

1. Open the settings app.
2. Tap simultaneously with two fingers in two different options of the settings list.

Expected result: I would expect the conflict to be resolved and one of the options to be triggered by the tap
Actual result: Nothing happens. There's no option triggered by any tap.

Comment 12

[Jason Smith [:jsmith]]

Ok - let me double check just to be sure.

QA Wanted to see if we can reproduce the test cases on comment 11 on 1.3.

Comment 13

[[:fabrice] Fabrice Desré]

(In reply to Mike Habicher [:mikeh] from comment #5)
> Fabrice, Hema is OoO at the moment--do you know who can help out with this?

Olly, can you check this?

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

So this stuff is underspecified in touch events spec.
https://dvcs.w3.org/hg/webevents/raw-file/v1/touchevents.html#mouse-events

Do we have the same behavior on Android?
Also, we explicitly don't dispatch legacy mouse events if any of the touch event listeners for
touchstart or first touchmove called preventDefault(). Is that perhaps happening here?

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

So, testcase needed.

Comment 16

[Olli Pettay [:smaug][[e-mail]]]

*minimal* testcase, please

Comment 17

[Justin D'Arcangelo [:justindarc]]

Test case: http://jsbin.com/goxec

Comment 18

[Olli Pettay [:smaug][[e-mail]]]

(when I say minimal testcase, I mean a minimal html page attached to the bug ;) )

Comment 19

[Justin D'Arcangelo [:justindarc]]

Attachment: bug1000985-testcase.html

Copy/paste testcase from http://jsbin.com/goxec into single .html file.

Comment 20

[Jason Smith [:jsmith]]

Ok - now we've got a testcase. Let's check to see if that testcase reproduces on 1.3.

Comment 21

[Matt Brubeck (:mbrubeck)]

(In reply to Olli Pettay [:smaug] from comment #14)
> So this stuff is underspecified in touch events spec.
> https://dvcs.w3.org/hg/webevents/raw-file/v1/touchevents.html#mouse-events
> 
> Do we have the same behavior on Android?

Yes, I can reproduce this bug in Firefox for Android using attachment 8412722 [details].  Chrome and Opera Mobile on Android also seem to behave the same.

Comment 22

[Justin D'Arcangelo [:justindarc]]

Attachment: camera pull-request (master)

Camera branch demonstrating how use of FastClick.js (instead of regular `click` events) eliminates the issue of having multiple touches on-screen.

Comment 23

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

I want to investigate what desktop browsers/OSs do in this scenario, marking this bug as blocking 1244402 so I don't forget.

Comment 24

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

On Windows touch two-finger taps don't do anything as far as I can tell. Edge and Chrome both support pinch-zoom with two fingers, and Chrome also interprets a two-finger tap as contextmenu (this is true even if one finger goes down and there is a delay before the second finger taps).

Firefox for desktop basically matches Edge/Windows here, so I'll remove this dependency as I don't think anything needs to change there. We might still want to change the behaviour on Android.

Comment 25

[Sylvestre Ledru [:Sylvestre]]

Closing as we are not working on Firefox OS anymore.