[Patch] ‘Copy tags from previous selection’ uses tags from the wrong (older) selection when changing layers

[huftis]

When switching between two layers, the ‘Copy tags from previous selection’ doesn’t work properly. For every selection except the first, it uses the tags from ‘one before the previous’ selection. To workaround this, one have to do an extra layer switch. Details and example below.

How to reproduce:

Open JOSM. Download the following area (or open attachment:lakes.osm​).

min.lat 59.2577648
max.lat 59.2687317
min.lon 5.2319813
max.lon 5.2682877

It should contain three lakes.

Save the following text as a file named test.csv:

latitude, longitude, natural, name
59.262, 5.238, water, foo
59.261, 5.254, water, bar
59.263, 5.260, water, baz

Open ‘test.csv’ in JOSM (using opendata plugin) – or open attachment:names.osm​. Press OK to import it. You will now have two layers, the OSM data layer and the ‘test.csv’ layer. The latter contains names (not real names) of three lakes in the OSM data. The goal is to copy these names to the lakes, so we do the following:

Select the leftmost point, named ‘foo’. Change the active (editing) layer to the OSM layer (by clicking on the empty space to the left of ‘Data Layer 1’ in ‘Layers’ panel). Select the leftmost lake. Press ‘Shift + R’. The tags are correctly copied, and the lake is now named ‘foo’.

Now try to repeat this type of operation. Change the layer to ‘test.csv’. Click the ‘bar’ point. Change the layer back. Click the second lake. Press ‘Shift + R’. Note that the tags of the ‘foo’ object, not the the ’bar’ object, is copied. This is a bug. Now change the layer to ‘test.csv’ and then back again (without doing anything else). Try ‘Shift + R’ again. Now the tags from ‘bar’ object is correctly copied.

To summarise:

1. For the first object, everything works OK.
2. For any later object, the following operations uses data for the second to last selected object, instead of from the last selected object.

a) Change layer.
b) Select source object.
c) Change layer back.
d) Select target object.
e) Press ‘Shift + R’.
f) Observe that the wrong tags have been copied.

3. If one after step d) changes the layer and immediately change it back again, the correct tags are copied in step e).

[simon04]

(Simplify instructions)

[simon04]

I can reproduce. By changing the layer, you are virtually changing the selection as well. So in step 2c) you "click" on the first layer. And in step 2e) you obtain its tags.

To avoid this, you'd have to unselect the first lake before performing 2a).

[simon04]

attachment:10350.core.patch​ and attachment:10350.plugin.patch​ should address this by determining whether the selection change is due to a change of the active layer.

@Don-vip: Is there a nicer way to figure that out? Should #isCalledFromLayerChange better be placed in the plugin action (after making LayerChangeAdapter a protected class)?

[Don-vip]

This is kind of a hack, I would prefer to see it in the plugin... I'm not sure how we can make it nicer. One risk remains if we rename the method. Maybe it would be better to use Class.getDeclaredMethod to have a valid reference to the method instead of just comparing its name. If we fail to find the method we can throw a proper exception instead of failing silently.

[simon04]

In 8957/josm:

see #10350 - Allow subclasses of JosmAction access its inner classes

[Don-vip]

@Simon in r15404 I added the possibility for subclasses of JosmAction to define their own ActiveLayerChangeAdapter. This should allow to fix this issue without accessing the stacktrace.