Sometimes sibling or child vertices are not draggable

[afmenez]

This seems to be similar to #3805, but now I cannot select nodes. It started today for me, but I haven't used the editor on the weekend.

[bhousel]

What happens when you click the node?

[afmenez]

The node seems to be selected, but I can't drag to move it, or see the pop up menu.
This problem seems to be intermittent, I just opened the editor again and it was working fine.

[afmenez]

Maybe this is related to #3739

[afmenez]

I see what the problem is now. This behavior changed, now I must select the node before I can move it. The problem is that when I try to move it directly, it changes color and seems to be selected, but it is not.
Maybe this is not an issue, but I found the new behavior confusing.

[bhousel]

I see what the problem is now. This behavior changed, now I must select the node before I can move it. The problem is that when I try to move it directly, it changes color and seems to be selected, but it is not.
Maybe this is not an issue, but I found the new behavior confusing.

Yes, this is definitely a change from before when it was easy to drag anything, and I'm still adjusting to it too. However it was a real problem that newish users would drag nodes around when they were just trying to pan the map.

I'm going to leave this open because there is still a bug in the vertex dragging code, where I've seen some sibling or child vertices that I would expect to be draggable but are not (until you actually click on the vertex).

The issue might be that the code to determine which vertices are draggable happens when they're drawn, and iD does partial redraws sometimes.

[bhousel]

I improved this a little bit with 919234d.. When some hovering of a vertex or a way was happening, the hovered vertices could end up selected instead of the persistent ones, and those hover vertices don't have the sibling class that enables drag.

[willemarcel]

Yes, this is definitely a change from before when it was easy to drag anything, and I'm still adjusting to it too. However it was a real problem that newish users would drag nodes around when they were just trying to pan the map.

@bhousel What do you think about to make it configurable? For me it's much less productive if I need to select an element before moving it. It would be perfect if we had a shortcut key or a setting to allow to drag nodes directly.

[bhousel]

@bhousel What do you think about to make it configurable? For me it's much less productive if I need to select an element before moving it. It would be perfect if we had a shortcut key or a setting to allow to drag nodes directly.

Yeah I'm definitely having some regrets about the current behavior. Before, accidental drags would happen sometimes, but now I struggle to get things to drag all the time.

I think we can revert to the old behavior that allowed all vertices to be dragged, but find a smarter way to differentiate between fast drags intended to pan the map, and slow drags intended to reposition the vertex.

[slhh]

I think we can revert to the old behavior that allowed all vertices to be dragged,

The old behavior was strange in mode select, because a node was dragable while a totally different feature was selected. I think we should limit node dragging to browse mode, or to nodes of the selected feature. Alternatetively we can select the dragged node like JOSM does.

but find a smarter way to differentiate between fast drags intended to pan the map, and slow drags intended to reposition the vertex.

JOSM is using left button drag to position the vertex, and right button drag to pan the map.

[bhousel]

This was done in
49c087d Rename delegate->selector, adjust formatting, drop userselect polyfill
e6da524 Allow all nodes and vertices to be dragged (revert of #3739)

I ended up reverting to the old behavior where all visible nodes are draggable.

re this:

I think we can revert to the old behavior that allowed all vertices to be dragged, but find a smarter way to differentiate between fast drags intended to pan the map, and slow drags intended to reposition the vertex.

I actually spent a lot of time today on trying to make this clever by detecting fast drags and slow drags, and redispatching the start event if the drag was too fast (so the map would pan). But it ended up being not very good, so I threw all that code out.

In order to detect the velocity of the drag, you need to delay the start of the drag and sample a few events. Delays of under around 125msec weren't enough to reliably detect the drag velocity (especially during slow frames), and delays longer just felt bad or even prevented me from making small node adjustments.

This is definitely a case where the "clever" solution ended up more confusing than the easy one. Oh well 🤷‍♂️

[davidearl]

Transferring my message from osm-talk to here (this issue was quoted by one of the respondents):

Is there something people can do too easily and inadvertently in iD which leads to a problem if they don't spot they've done it? Or maybe even a bug?

In the last month I've found edits by two different accounts, both editing in iD, where a node has ended up merged with another node, or possibly a way re-connected to a different incorrect node, some hundreds of metres away (in both cases the original location ended up eastwards, but that's probably just coincidence). The visual result is a road or building ends up with a long narrow spike in it.

In both cases, from the changeset comments, it doesn't look like either of them were even trying to edit the particular feature in question - they were doing something quite unrelated.

What I'm wondering is if there is perhaps some gesture, like panning the map, which can end up dragging a node which dropped onto another node connects them. If you're rapidly panning perhaps you may not notice you picked up a node? Is this possible? Is there some other scenario that could lead to this accidentally? I can understand one mistake, but two so very similar accidents by different people looks suspicious.

[bhousel]

What I'm wondering is if there is perhaps some gesture, like panning the map, which can end up dragging a node which dropped onto another node connects them. If you're rapidly panning perhaps you may not notice you picked up a node? Is this possible?

Yes, that's the issue that we had tried to address by making it so that users needed to select a node first to drag it. You can click on the links above in this ticket to see relevant discussion on the issue on other tickets.

We received a lot of complaints about this, and it made editing more confusing and harder for everyone, so we reverted to the original behavior that makes all the rendered nodes draggable. Yes this means that sometimes it's possible to drag a feature when you meant to pan the map.

Users should notice if they do this however, as it makes things look weird and the map doesn't actually pan. The user can always Undo to put an accidentally dragged feature back to where it was.

Is there some other scenario that could lead to this accidentally? I can understand one mistake, but two so very similar accidents by different people looks suspicious.

It's not suspicious at all. Many thousands of people use iD every day, so if you see a few accidentally dragged things, just make a polite comment on their changeset and move the thing back where it belongs.

[planemad]

move the thing back where it belongs.

This is the tricky part. Many times its not very simple to know what was the original state, especially if multiple nodes were merged, or if a node moved a large distance.

Braindumping some ideas that could assist in making it easier:

• Undoing/reverting the last change to the selected objects
• A reference layer that could show what the previous state looked like, so that one can manually undo the change. Maybe link to changeset-map?