Touch 1 isn't updating if Touch 0 hasn't moved

Problem Description

Touch 1 doesn't update position if Touch 0 hasn't moved.

Happens on Firefox for Android and the default Android browser, but not on Chrome for Android.

Edit: After testing some more, it seems Touch 0 also doesn't update its position until it's moved a certain amount after the initial touch. Actually, I guess that's the real problem.

Still only affects Firefox on Android and Android's default browser. Also tested this particular behavior on Firefox, IE, Chrome, and Chrome for Android.

Attach a Capx

dl.dropboxusercontent.com/u/102867918/Multi-Touch%20Dragging%20Issue.capx

Description of Capx

Keeps track of up to one Touch on each half of the screen (maximum 2), and positions a marker for each. Ideally, you should be able to drag on both sides of the screen at the same time, independent of one another.

Steps to Reproduce Bug

• Step 1 - Touch once on either half of the screen but don't move it from that position.
• Step 2 - Touch once on the other half of the screen and attempt to drag around.
• Step 3 - Notice how the second marker isn't updating its position and pull your hair out.

Observed Result

The second marker simply stays at the position it was first created at.

Expected Result

Second marker should be updating its position to wherever Touch 1 (the second touch) is.

Affected Browsers

• Chrome for Android: NO
• FireFox for Android: YES
• Internet Explorer: Is there a version for Android?
• Default internet browser on Android: YES

Operating System and Service Pack

Android 4.4.2

Construct 2 Version ID

221

Bump. No one has encountered the same problem?

Closing as won't fix: it works correctly in Chrome for Android and Safari on iOS, which suggests the code in Construct 2 is correct. (Besides, it just forwards the information that the browser tells it about touches.) The Android stock browser is crap and not worth the trouble of trying to support and is rapidly falling out of use anyway as everyone switches to Chrome. As for Firefox, I can reproduce it there, but since I believe our code is correct since it works in more modern browsers, I think it's a Firefox bug that you should report to Mozilla.