Spec should be explicit on whether the order of elements in TouchLists is relevant

[RByers]

I believe the order of TouchList entries is supposed to be irrelevant. However some sites (eg. this one) make assumptions about a given touch ID remaining at the same index in the TouchList from event to event. There was a special case in blink where we weren't preserving order, and we're going to fix this.

In what cases is the ordering preserved in existing browsers? Should we just make that part of the spec so that sites can depend on it? It can certainly simplify some coding patterns.

[patrickhlauke]

My gut feeling is that no, the spec should clarify that the order/index may change and that authors should rely only on the id.

I've not had a chance to test it, but: if i put 3 fingers on the screen in sequence, and then remove the second one, is the expectation from devs that you'd still see a touch point on 0 and 2 in the touchlist? what would index 1 contain, then? null?

[scottgonzalez]

I also don't think we should specify an order for existing touches.

On Fri, May 8, 2015 at 1:19 PM, Patrick H. Lauke [email protected]
wrote:

My gut feeling is that no, the spec should clarify that the order/index
may change and that authors should rely only on the id.

I've not had a chance to test it, but: if i put 3 fingers on the screen in
sequence, and then remove the second one, is the expectation from devs that
you'd still see a touch point on 0 and 2 in the touchlist? what would index
1 contain, then? null?

p

Patrick H. Lauke

On 8 May 2015, at 16:59, Rick Byers [email protected] wrote:

I believe the order of TouchList entries is supposed to be irrelevant.
However some sites (eg. this one) make assumptions about a given touch ID
remaining at the same index in the TouchList from event to event. There was
a special case in blink where we weren't preserving order, and we're going
to fix this.

In what cases is the ordering preserved in existing browsers? Should we
just make that part of the spec so that sites can depend on it? It can
certainly simplify some coding patterns.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#13 (comment).

[RByers]

I don't think we'd ever want to leave gaps no. We should test to see if
all existing implementations maintain order in the simple case of no
touchstart/touchend. If so, that might at least be worth a note - with a
warning saying you shouldn't rely on it. The fact that a site was relying
on this caught us by surprise (though it's of course not surprising in
retrospect) - seems like the sort of thing worth documenting somewhere
unless at least one major implementation wants to take the hit of
intentionally shuffling the ordering.

On Fri, May 8, 2015 at 1:22 PM, Scott González [email protected]
wrote:

I also don't think we should specify an order for existing touches.

On Fri, May 8, 2015 at 1:19 PM, Patrick H. Lauke <[email protected]

wrote:

My gut feeling is that no, the spec should clarify that the order/index
may change and that authors should rely only on the id.

I've not had a chance to test it, but: if i put 3 fingers on the screen
in
sequence, and then remove the second one, is the expectation from devs
that
you'd still see a touch point on 0 and 2 in the touchlist? what would
index
1 contain, then? null?

p

Patrick H. Lauke

On 8 May 2015, at 16:59, Rick Byers [email protected] wrote:

I believe the order of TouchList entries is supposed to be irrelevant.
However some sites (eg. this one) make assumptions about a given touch ID
remaining at the same index in the TouchList from event to event. There
was
a special case in blink where we weren't preserving order, and we're
going
to fix this.

In what cases is the ordering preserved in existing browsers? Should we
just make that part of the spec so that sites can depend on it? It can
certainly simplify some coding patterns.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#13 (comment).

—
Reply to this email directly or view it on GitHub
#13 (comment).

[patrickhlauke]

On 11/05/2015 20:07, Rick Byers wrote:

I don't think we'd ever want to leave gaps no. We should test to see if
all existing implementations maintain order in the simple case of no
touchstart/touchend. If so, that might at least be worth a note - with a
warning saying you shouldn't rely on it. The fact that a site was relying
on this caught us by surprise (though it's of course not surprising in
retrospect) - seems like the sort of thing worth documenting somewhere
unless at least one major implementation wants to take the hit of
intentionally shuffling the ordering.

Ah, so the site was relying on the order/index remaining the same
during, say, a touchmove when no fingers were added/removed? Ok, that
kind of makes sense, though conceptually, you would then still need to
include handling code that DOES look at the actual unique IDs as soon as
a touch is added/removed, which then begs the question why they don't do
that in all situations anyway...

If I were hardline (and well, I don't have a browser/compat issues to
worry about personally), I'd say that the devs are relying on an
undocumented "feature" which is conceptually wrong, and - if the number
of sites that do this is small - it could be addressed with
evangelism/outreach? Do we have an idea of how many sites, roughly, use
similar assumptions in their code?

[RByers]

It looks like hammer.js has this issue in their rotation gesture recognizer (rotation will flip 180 degrees if the two touch points swap position in the touches list). Even if they fix this, we know tons of sites use hammer.js (though I'm not sure how common rotation gesture recognition is).

[patrickhlauke]

Just doing a gentle ping here...still think it's worth a general note about the order of the individual touches in the touches/targetTouches/changedTouches arrays/collections/whatever-they're-actually-called being potentially arbitrary, and that scripts should not rely on the order but on the identifier when tracking specific touches in a multi-touch interaction. Happy to draft something up, if we feel it would be beneficial?

[patrickhlauke]

Did some very rough and ready testing with this http://patrickhlauke.github.io/touch/tracker/multi-touch-tracker-index.html (which only uses touch events and visually shows each touch in targetTouches, complete with its "index" and the unique identifier) and current behavior seems to vary already across implementations.

While during a touch interaction (once all touches have been placed on the screen) the order of touches in the TouchList object doesn't seem to change (the index remains consistent, at least in the tested browsers) in most cases, there are some tricky variations when touches are added/removed:

• Edge (with touch events enabled in about:flags): when a touch is removed, order is preserved (touches with an index greater than the removed touch are "bumped to the left" in the same order to fill the gap); new touches are always added at the end of the TouchList object. This is the most consistent behavior I've encountered.
• Chrome/Win10: order is not always preserved when a touch is removed (the index can flip/flop temporarily, until it settles); new touches are always added at the end of the TouchList object.
• Chrome/Android 6: order preserved when touch removed; however, new touches are not always added at the end (e.g. if a touch was removed during gesture, and then a new touch added, this new touch receives the same index as the touch that was previously removed).
• Firefox/Android 6: order is not consistently preserved (can flip randomly) when touch removed; new touches are not always added at the end (e.g. if a touch was removed during gesture, and then a new touch added, this new touch receives the same index as the touch that was previously removed).
• Safari/iOS: consistent like Edge - order is always preserved when a touch is removed; new touches always added at the end of the TouchList object.

Personally, I feel it would be better to write a generic note explaining that the order in which Touch objects can be found in the various TouchList objects can change arbitrarily (particularly in situations when a touch is added or removed), and that authors should not rely on it - instead, to explicitly track a touch in a multi-touch case, they should refer to the unique identifier associated with a touch. Happy to draft/PR something.

Thoughts?

[patrickhlauke]

(just edited the previous comment, as further testing reveals there's some reason behind the strange behavior of Chrome and Firefox on Android - it's not that a new touch is added to index 0, but rather it seems that if a touch is removed and then a new touch is added, this new touch is given the index of the previously removed one...like it has some sort of "memory")

[patrickhlauke]

Personally, I feel it would be better to write a generic note explaining that the order in which Touch objects can be found in the various TouchList objects can change arbitrarily (particularly in situations when a touch is added or removed), and that authors should not rely on it - instead, to explicitly track a touch in a multi-touch case, they should refer to the unique identifier associated with a touch. Happy to draft/PR something.

having said that, if we see that there are scripts in the wild which rely on the (fairly rock solid, from my testing) Safari/iOS behavior (order always preserved during gesture, order preserved when a touch is removed, new touches always added at the end), then perhaps we could document that "generally" that's the behavior, but that authors should nonetheless not rely on it? or can we even mandate that browsers should/must do it this way (and file relevant bugs against those that don't)?

[RByers]

Thanks for doing the research Patrick, that's excellent!

Given that Safari and Edge seem consistent on a behavior that is generally useful to developers, I'd lean towards just specifying it that way (developers WILL depend on it, regardless of what the spec says) and fix Chrome to match. +NavidZ WDYT?

[patrickhlauke]

For completeness of test results: just tried Vivaldi Browser 1.0 on Surface 3/Windows 10:

• order is not always preserved when a touch is removed (the index can flip/flop temporarily, until it settles); new touches are always added at the end of the TouchList object.

[patrickhlauke]

revisiting this, as it's been bugging me...before i go off an propose a PR, here's what i plan to add. due to the fact that it does indeed seem that there's some inconsistency in existing implementations, like in Firefox, i'd propose adding these as normative statements (but i'll work on some cleaner wording, this is just to get the concepts down):

• the touches in the touchlist SHOULD be in the order in which touches were added
• once a touch is on the screen, its position/index in the touchlists, as well as its identifier, SHOULD remain the same, as long as no further touches are added/removed (in which case all bets are off, since even just to make sure there's no gaps things may need to be reshuffled); additionally, add a non-normative note that says that authors are advised to rely on identifier
• the touchlists MUST not be "sparse arrays" (can we call these "arrays"? is there an equivalent/better way, like "sparse collection" or similar?) - when a touch is removed, subsequent touches in the touchlist are "bumped" to fill the gap. however, there's no guarantee that after a touch has been removed that the relative order of the touches is the same
• when a touch is added, it SHOULD be added at the end of the touchlist (but from testing, this is where on Android things get funky, as it seems to somehow "remember" the previous position of a touch that was removed and then re-added?)

in short, the only MUST is that there be no gaps in touchlists. the SHOULDs reflect most sane current behavior. non-normative note reinforces that authors should rely on identifier.

thoughts?

[scottgonzalez]

Those all sound reasonable, but I think the note that authors should rely on identifier is the most important piece.