Changing the selection after editing a field sometimes applies the tag to the wrong feature

[1ec5]

URL

No response

How to reproduce the issue?

1. Select a feature and enter “123ABC” into the Address field’s addr:housenumber text field.
2. Select a different feature.
3. Observe that both features are tagged addr:housenumber=123ABC.

Screenshot(s) or anything else?

addresses_2.mov

I reproduced this issue inconsistently when working on a large changeset in which iD takes a while to respond to any click events. I could not reproduce this issue when working on a very small changeset.

When iD is in this state, the issue still reproduces if you tab before changing the selection or deselect before selecting a different feature. The problem is a race condition where the field applies the tag on a delay to the current selection, even if the selection has already changed.

Which deployed environments do you see the issue in?

Released version at openstreetmap.org/edit

What version numbers does this issue effect?

2.27.

Which browsers are you seeing this problem on?

Firefox

/ref #7973

[maro-21]

I suppose 97d1aa5 fixes this?

[1ec5]

Unlikely. This general class of bug has cropped up many times in the past. It’s been a game of whack-a-mole. 97d1aa5 seems to be specific to the street/place subfield, whereas I reproduced this issue in the housenumber subfield, and I seem to recall reproducing it in other non-address fields too.

This issue only happened once the changeset got over a certain size, causing a race condition due to poorer selection performance. I’d have to retest with a similarly large changeset to know for sure if that commit or something else has improved the situation, but the fundamental root cause of asynchronous event handling is probably still there.