Unexpected deletion of members by drag-n-drop in relation editor

[verdy_p]

I discovered the drag-n-drop was implemented first because it created a serious bug when editing complex relations (notably those containing hundreds of members).

It frequently happens that we slighly drag the mouse while clicking, and in some case this causes an immediate move of items in the list (which is refreshed and repositioned, so we don't see what happened and which members are affected).

But more dramatically, some moves, when we already have multiple elements selected in the list, will cause them to be REMOVED unpexpectedly from the list of members, causing a dramatic change.

Please add a confirmation dialog if a drag-n-drop operation causes any members to be removed from the list (not just moved elsewhere in the list), and notably if the operation if on a selection of multiple members!

For now the new drag-n-drop feature in the relation editors is extremely dangerous! We may not even see that some members were effectively removed from the list, and if we apply the changes we won't see that there are less members than before

---

Note also that the pane showing the history of changes does not even indicate how many members were added or removed when applying changes and closing the relation editor.

We ONLY see that the relation was changed, without more details: we should have a "+" icon showing details, containing at least:

• the list of members added, and the list of members removed, and we should be able to select elements from these list, to help restoring elements that were unexpectedly removed from the list of members, without necessarily having to completely revert ALL edits made in the relation editor;
• it should also probably say if tags were modified, just like with other elements (nodes/ways) or when editing tags from the tags pane (outside the relation editor itself).

[Klumbumbus]

When you select one item in the list and move it above itself, it gets deleted.

[verdy_p]

yes, this is a severe defect. And this is even more dramatic if you have a current selection with multiple rows.

It is TOO MUCH easy to delete a row by a very *tiny* drag (a few pixels). It frequently happens by accident.

Dragging an element within the list itself should NEVER delete it (if you want deletion, make sure the target of the move is really OUTSIDE the list).

My opinion is that it is not even needed: for deleting an item, first select them, then click separately on the dustbin button.

So this is a severe design bug.

[simon04]

In 9993/josm:

fix #12617 - Unexpected deletion of members by drag-n-drop in relation editor

[anonymous]

"Fixed" should be really tested. Because there are still members being deleted. What you fixed in 9993/josm was just to restore the visiblity of the selection after the drag-n-drop operation... if they are still in the list of members.

RFE:
As explained above, please expand the "list of changes" by detailing what was changed when clicking "OK" to apply changes in the relation editor. We should have an expandable group (with a "+" icon) created instead of a single line, showing which members were added or removed (you may ignore their relative order). It's not even possible to see if the number of members changed because the history is completely refreshed even and all items *before* the change show only the new number of members (we still cannot know if members were changed by the edit and at which step, so it's hard to determine what needs to be undone).

And possibly add to the group of changes (less important) the list of tags changed (just like when we edit tags of selected relation(s) outside the relation editor).

[simon04]

Did you test r9993? The issue from comment:1 is fixed from my point of view. If not, please describe how to reproduce it.

I overlooked the "summarize changes". Please stick to one issue in one ticket. I created #12629 for the improvement.

Please also note that any development on JOSM is done voluntarily, so too many demands and "shoulds" are not appreciated.

[anonymous]

The two requests were effectively related to the same source problem, as reported in this bug #12617.

I had clearly separated the RFE (now cloned by "simon04" in bug #12629) in my initial bug report, using a very visible dash line. OK I could have filed another request, but I think that the RFE is equally important to implement (and necessary for coherency of the interface of changes: we should see these changes somewhere, whever they were expected or not, just like when editing simpler objects in the tags editor)

This bug #12617 was the main reason why I "noted" the RFE in the final note, as a good suggestion (also to make sure that this bug is effectively corrected: for now I have doubts, as I still see items deleted, without any question, by tiny drag-n-drops in the list of members, and they are still not reported in the changes when applying them in the relation editor: that's why this bug was considered "serious", it's not just the fact that the current selection in the list of members was lost, something still minor but that was apparently the only thing really corrected in r9993 but not part of my request here, and that was visibly not an effective correction for the unexpected deletions).

The way I see r9993, it's not a correction of a real bug, but an implementation of a separate improvement for the interface (i.e. only keeping the selection visible after only *moving* elements with drag-n-drop, but without effect after an effective deletion).

[Don-vip]

Milestone renamed

[taylor.smock]

In 18439/josm:

Fix #17906, #21889, see #12617 for the original issue

This fixes an issue where a relation member could be deleted accidentally
when a user moved the relation member to its current position. This also
affected multiple members when multiple members were selected. The user
just had to move the selected members to another selected member position.

This patch also improves relation move performance when large numbers of
relation members are moved.