Modify

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#12617 closed defect (fixed)

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

Reported by: verdy_p Owned by: team
Priority: major Milestone: 16.04
Component: Core Version:
Keywords: relation member drag-and-drop Cc: simon04

Description

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).

Attachments (0)

Change History (8)

comment:1 Changed 4 years ago by Klumbumbus

Cc: simon04 added

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

comment:2 Changed 4 years ago by 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.

comment:3 Changed 4 years ago by simon04

Resolution: fixed
Status: newclosed

In 9993/josm:

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

comment:4 Changed 4 years ago by Klumbumbus

Milestone: 16.03

comment:5 Changed 4 years ago by 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).

comment:6 Changed 4 years ago by 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.

comment:7 Changed 4 years ago by 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).

comment:8 Changed 4 years ago by Don-vip

Milestone: 16.0316.04

Milestone renamed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.