New issue
Advanced search Search tips

Issue 612852 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: May 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

Race when touchend listener is added inside a passive touchstart listener?

Project Member Reported by rbyers@chromium.org, May 18 2016

Issue description

- It's sometimes a good idea (eg. if the DOM may change) to add your touchmove/touchend listeners from inside a touchstart listener.
- Touchstart listeners should generally be passive
- It's often reasonable for touchend listeners to call preventDefault to prevent generation of mouse/click events.

I was worried the combined scenario may be broken due to a race condition in passive touch event handling.  If the impl thread decides whether or not touchend should be cancelable before it knows about the EventHandlerRegistry change, it may dispatch an uncancelable touchend in this case.

However I'm unable to repro this.  Why?
Test page: http://output.jsbin.com/mivojo
Hope to see only touchstart/touchend, but expected to see a "click" (which would be bad).
Tested Chrome Linux 52.0.2723.2 and Android 52.0.2739.2
 
This is because the TouchEnd is always dispatched to main thread.

https://code.google.com/p/chromium/codesearch#chromium/src/ui/events/blink/input_handler_proxy.cc&sq=package:chromium&l=871&rcl=1463555947

It is never mutated so it will always be cancelable. We don't preemptively prevent ack the touch end.
Status: WontFix (was: Untriaged)
Closing issue; I think adding a test case to test a race here can be a little problematic.

Sign in to add a comment