Selecting objects using a graphics tablet is difficult (requires zero movement)

[danstowell]

Selecting objects in iD appears to require exactly zero movement of the cursor at the moment of clicking. This becomes evident when you try it with a graphics tablet plugged in, when it becomes very difficult to select anything!

This lack of tolerance for clicking is different to the behaviour of everything else within the web browser. For example I can click normal links (like the "History" link) in a fluid pass without ever stopping still.

(My system, btw: Ubuntu 13.04, Firefox 25.0, Wacom Bamboo.)

I presume that you're not using the standard web browser's "onClick" behaviour, but some kind of internal "onMouseDown/onMouseUp" logic? If so, please could you add a small tolerance for slight movement during clicking?

(I'd like to remark that this is not just an issue of convenience, but of interface consistency and accessibility.)

[tmcw]

Yes, iD uses a different system for clicking (see #530 ). Since a click in iD can immediately be followed by a drag motion, it's a higher priority to make sure accidental displacement doesn't occur than to detect every possible click.

[danstowell]

OK - so, does this mean that my issue could be fixed simply by upping tolerance = 8 (in js/id/behavior/draw.js)? If so, hooray :) - and I think that's all I have in mind, I don't think it's a clash with the specialist needs you mention.

(In firefox I know how to use the inspector to live-hack CSS; if I could see a way of doing this with the JS I'd try it right now. If you happen to know a simple way I can test such tweaks without major setup that'd be handy...)

[jfirebaugh]

Hmm, I'm not sure this can be accounted for by the filtering that Draw does. That should be active only when actually drawing.

I thought it might be due to the click-canceling behavior of drag but that seems to actually be dead code.

In my tests I simply don't see any click events dispatched by the browser when dragging vertices or points.

[jfirebaugh]

Does this happen equally for all feature types (points, vertices, lines, areas)?

[danstowell]

Trying this out again, I realise that I don't think wiggle-tolerance is actually what's causing my issue:

• I'm pretty confident I can execute a graphics-tablet "click" and keep the pen still enough that it only moves by one or two pixels. That's definitely under the "threshold=8" (it's a pixel threshold I assume). Yet still cannot select for the life of me.
• If I click-and-hold an object in ID (using the tablet) for a few seconds, without moving it, when I let go, it's still not selected. YET if I do exactly the same thing but use my laptop's touchpad mousebutton to click-and-hold, when I let go it is in fact selected. (This is on exactly the same system, in exactly the same editing session.)

This suggests to me that clicks originating from the graphics-tablet lead to a different series of events received, than clicks from the touchpad. Other clicks (such as clicking the zoom + or -) work perfectly fluidly with my graphics-tablet. I would be inclined to blame the graphics-tablet driver, but it's the most common brand (Wacom Bamboo, mine is CTL-470) and it works fine in absolutely everything else. (I use it with josm often.)

If anyone is able to test with a graphics tablet and see if there's a clear difference in the events received, that would help. Or if there's a way I can dump such events during my session.

[danstowell]

@jfirebaugh yes, it occurs for all 4 feature types.

[quincylvania]

A lot's changed in six and a half years!

We now have pointer events (#5505) and can thus treat stylus and mouse interaction differently. I don't have a graphics tablet but selecting nodes without dragging them using an Apple Pencil on iPad was near-impossible, as described. I added a higher pixel tolerance for styluses which solved the issue. Selecting ways and areas appears to be unproblematic, so whatever changed about that behavior in the long interim must have already fixed the issue.