Follow line bug when holding F

[Cartographer10]

I found a bug where the follow line command closes to soon.

Reproduction steps

1. Create a circle like the grey line below
2. Create a new line, place the first node on the 1 below
3. Click on the second node as marked below
4. Press F and keep holding it

Actual behavior
The line snaps back to the beginning after only a few nodes. It consistently snaps back after 2 or 3 nodes. It happens the most when making a sharp left turn as can be seen on the images.

Expected behavior
The new line should follow the entire line instead of snapping back after a few nodes

System information
OS: Linux mint: 21.3
Java: Openjdk-21-jre
JOSM: v18940

[Taya]

This also happens to me. It happens more frequently to me if JOSM is running slow. It also seems to happen a lot more if I press F as soon as possible after clicking the second node.

[Woazboat]

I added some debug output and it looks like the source of the problem is that the follow action is triggered twice for the same node when it's activated in quick succession.

2024-01-27 19:37:18.283 FINE: FollowLineAction, base node: {Node id=-25598 version=0 MV lat=53.56452634464472,lon=9.974486742835618}, new node: {Node id=-25599 version=0 MV lat=53.5645413500275,lon=9.974497445420058}
2024-01-27 19:37:18.306 FINE: Selection changed. 2 primitives are selected.
2024-01-27 19:37:18.841 FINE: FollowLineAction, base node: {Node id=-25599 version=0 MV lat=53.5645413500275,lon=9.974497445420058}, new node: {Node id=-25600 version=0 MV lat=53.5645523956531,lon=9.97447797022542}
2024-01-27 19:37:18.884 FINE: Selection changed. 2 primitives are selected.
2024-01-27 19:37:18.914 FINE: FollowLineAction, base node: {Node id=-25599 version=0 MV lat=53.5645413500275,lon=9.974497445420058}, new node: {Node id=-25600 version=0 MV lat=53.5645523956531,lon=9.97447797022542}
2024-01-27 19:37:18.927 FINE: Selection changed. 1 primitives are selected.

The base node that the follow action uses is taken from DrawAction. The DrawAction base node is updated in a selection change listener.

key event -> follow line action -> execute change way nodes command + change selection command -> selection change event -> DrawAction selection change listener -> update draw base node

I assume this is a race condition between the follow line action and the base node update in the draw action selection change listener.

[anonymous]

Reported this problem a year or so ago, exactly as pictured in the OP 1st screencut, set a first node, start the line to the second node and hit F. Reaching the 4th node jumps/connects back the line to the starting node, closing the way. The more data is in the active layer the sooner it happens
. Only a new line. Drawing a line along and edge, interrupting to do something else, resume A, then F has never caused this.

Having become used to it, always working in larger sets, most always simple polygon mapping of landuse/landcover, do a Ctrl+Z which reverses the loop back step and continue with F as the function was not terminated.

[SekeRob]

Errata: Subjectively the occurrences have greatly diminished since the performance work was done v.v. the NSI plugin caused slowing and related. The datasets have to be big, 50-75MB saved, the present one grew to 116MB.

[GerdP]

different geometry, same problem

[GerdP]

Note also the strange numbering of the segments in my example. Whenever I was able to reproduce I see the same numbering. The first segment gets the 2, the last (wrong) segment the is rendered as 1st. To reproduce it seems to help to zoom out and press 8 to zoom back in so that GC is active.

[GerdP]

OK, I think I can always reproduce like this:
1) enter draw mode
2) select a node of a closed way with 6 or more nodes (doesn't matter which node)
3) press and hold F
4) move cursor close to next node in way until the snap-to cursor is rendered
5) left click

When I do this I see the problem more often then not. There is no need to have lots of data or change the zoom and nothing else keeps my CPU busy. Problem disappears with the attached patch but I am not yet sure where to reset oldLast.

[GerdP]

The patch doesn't work when you undo one of the follow actions and try to use follow again, so it's too simple.

[GerdP]

23442-2.patch looks like a good and simple solution. If nobody complains I'll commit it tomorrow.

[Woazboat]

It doesn't solve the underlying problem but I guess it does mitigate it.

[GerdP]

Right, it just doesn't rely on the idea that the returned value is either the first or the last node of the new way. In fact this happens very often but only in this special situation the problem was not detected.

[GerdP]

I meant I think it solves this problem in the FollowLineAction for good, but we may find other actions which are not handling such a case properly.

[GerdP]

Replying to anonym:

Reported this problem a year or so ago, exactly as pictured in the OP 1st screencut, set a first node, start the line to the second node and hit F. Reaching the 4th node jumps/connects back the line to the starting node, closing the way. The more data is in the active layer the sooner it happens
. Only a new line. Drawing a line along and edge, interrupting to do something else, resume A, then F has never caused this.

Having become used to it, always working in larger sets, most always simple polygon mapping of landuse/landcover, do a Ctrl+Z which reverses the loop back step and continue with F as the function was not terminated.

Do you have a ticket number for us?

[GerdP]

In 18959/josm:

fix #23442: Follow line bug when holding F

• make sure that the node returned by DrawAction.getCurrentBaseNode() is either first or last node of the selected way.

[SekeRob]

Replying to GerdP:

Replying to anonym:

Reported this problem a year or so ago, exactly as pictured in the OP 1st screencut, set a first node, start the line to the second node and hit F. Reaching the 4th node jumps/connects back the line to the starting node, closing the way. The more data is in the active layer the sooner it happens
. Only a new line. Drawing a line along and edge, interrupting to do something else, resume A, then F has never caused this.

Having become used to it, always working in larger sets, most always simple polygon mapping of landuse/landcover, do a Ctrl+Z which reverses the loop back step and continue with F as the function was not terminated.

Do you have a ticket number for us?

Here you go: https://josm.openstreetmap.de/ticket/22850

[GerdP]

Ticket #22850 has been marked as a duplicate of this ticket.

[GerdP]

Thanks, I wonder why I couldn't find it searching for "Follow"