mapbox / mapbox/mapbox-gl-js

`touchmove` event should preserve Touch.identifier for multitouch.

Open
#6,222 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

api :memo:
Dominant language
TypeScript
Stars
12.4k
Forks
2.4k
PR merge metrics
No merged PRs in 30d

Description

Mapbox's touch events are quite useful because have projection already computed as `lngLats[]`. Not only are they already projected, _they're already offset to the container's bounds_, so if you have a `margin: 20vmin` on your map so it suspends delicately like a picture in the Louvre, all of your lat lngs are already computed with the offset taken into account! Very nice work!

However, the current implementation of `touchmove` doesn't support multiple touches (fingers) continuously. This is because the `lngLats` does not preserve the original touch event's `identifier` property. What is so important about the `identifier` property? The `identifier` property allows the consumer of the event to create continuous multi-touch lines without jumps or breaks when a single finger leaves the canvas.

### Steps to Trigger Behavior

1. attach a `touchmove` event to your map.
2. Change Google's sensors to Force Enabled to simulate touch events.
3. Observe a `touchmove` event, specifically the `lngLats` array.

### Expected Behavior
Each `lngLat` object preserves the touchmove identifier
https://developer.mozilla.org/en-US/docs/Web/API/Touch/identifier

### Actual Behavior
Each `lngLat` object is missing the touchmove identifier.

**mapbox-gl-js version**: 0.44.1 and prior

Imagine you placed four of your fingers on a touch surface, and you begin to wipe from left to right, as if you were clearing dew off your window. Four fingers create four distinct lines on your canvas. (Obviously, blood and treasure has been invested into turning our touch events into `MultiPoint` and `MultiPolygon` GeoJSON objects, but please ignore that technical detail). As your fingers track across the surface, you _lift one finger_ off the canvas. The raised finger should no longer track, and the remaining fingers should draw as normal. While still tracking, you drop your raised finger onto the canvas AGAIN. The finger should draw naturally along with its siblings.

Here is the desired behavior:
![2018-02-23_10-33-34](https://user-images.githubusercontent.com/1424223/36602389-86050978-187d-11e8-9c96-40b71c89fc7a.gif)

From my understanding, this is only made possible by `Touch.identifier`.
https://developer.mozilla.org/en-US/docs/Web/API/Touch/identifier

Here is the current behavior, if we use as the `identifier` the index position of the array in `lngLats`.
![2018-02-23_10-37-09](https://user-images.githubusercontent.com/1424223/36602437-ad1c53f4-187d-11e8-803e-a83aea7592ab.gif)

Yes, this bug is a bit complex, and I'll provide you with some code, but only if this bug is viewed to be possibly valid, rather than covered outright. Remember, we're talking about multiple fingers of contact, effectively drawing on a surface with multiple points coming in and out of the `originalEvents`'s `changedTouches` property.

Let me know if you would like to investigate this further.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the touchmove event handling that builds lngLats from originalEvents.changedTouches; no source file or test is named in the issue. Reproduce the four-finger sequence described, including lifting and re-adding one finger, and trace how Touch.identifier is handled. Done means each lngLat preserves its identifier and remaining contacts continue without jumps or breaks.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
frontend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
28/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.