You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Select a feature and enter “123ABC” into the Address field’s addr:housenumber text field.
Select a different feature.
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?
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.
URL
No response
How to reproduce the issue?
addr:housenumber
text field.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
The text was updated successfully, but these errors were encountered: