Combo field allows editing localized value as raw value

[SomeoneElseOSM]

URL

https://taginfo.openstreetmap.org/keys/denotation#values

How to reproduce the issue?

No idea. I've just spotted the problem in the data.
A DWG correspondent mentioned the odd value added in v1 of https://www.openstreetmap.org/node/13674177470/history (and also commented on the changeset, which prompted the original editor to fix it). However, a look at https://taginfo.openstreetmap.org/keys/denotation#values suggests that something is amiss - lots of people have done the same thing; the common factor seems to be common values of "denotation" (try searching taginfo for urban and avenue).

I fixed a few https://www.openstreetmap.org/changeset/181647912 , https://www.openstreetmap.org/changeset/181648102 and https://www.openstreetmap.org/changeset/181648132 but there are lots more.

Any ideas what might be going on?

Screenshot(s) or anything else?

n/a

Which deployed environments do you see the issue in?

Released version at openstreetmap.org/edit

What version numbers does this issue effect?

At least iD 2.37.3

Which browsers are you seeing this problem on?

No response

[matkoniecz]

sadly, bad value is popular enough to get autosuggested

making it possibly subsissue of openstreetmap/id-tagging-schema#1829

Is it viable and desirable to limit values here to some predefined list of denotation= values without allowing any entries beyond it (at least in the standard iD GUI)?
Or maybe list some selectable entries and cease showing suggestion from taginfo?

If yes, which values it would include?

[SomeoneElseOSM]

No, "iD autosuggests a popular but not feasible value" is not what I am reporting here.

Lots of people are for some reason adding tree denotations like "urban" followed by some other text, perhaps from a paste buffer. This does not happen with e.g. "barrier=hedge" (try searching https://taginfo.openstreetmap.org/keys/barrier#values ) . Clearly iD is doing something wrong in the former case, but what?

[matkoniecz]

Clearly iD is doing something wrong in the former case, but what?

I would not assume it quite quickly, it may be for example a single confused user that managed to create some values popular enough to autosuggest start wreaking havoc

Or just coincidence of some kind.

I guess that maybe denotation field may be specifically broken, unlike other dropdown fields but it sounds like a quite bizarre bug

[SomeoneElseOSM]

it may be for example a single confused user

No Please look at what I have already written before commenting like that. To not do so just wastes everyone's time.

The fixes I did last night that I mentioned were for 3 separate users. The remaining ones (look at taginfo and drill through) are different users. A common factor is iD, and it definitely is more common with some values ("denotation") rather than others ("hedge").

[tyrasd]

This is indeed very peculiar.

It is also found the same bug on other tags, e.g. building, highway, surface even layer…

At the moment I cannot think of many plausible ways this could happen. It must be something in the clipboard buffer of the user's OS, and then they copy-pasted a feature. Perhaps the users forgot to deselect the feature they wanted to copy-paste, thus the following pressing of Ctrl C, Ctrl V only pasted the previous content of the copy-paste buffer into the field instead of copying/pasting the feature. Not sure what we could do to prevent this, though…

Any other ideas?

[SomeoneElseOSM]

I've had a go, but can't figure out how to reproduce it. I'm guessing that it's not iD's built-in "copy a feature", since that copies entire features not just parts of values.

[FloEdelmann]

I think I found out how to reproduce this:

1. Select a value in a combo field → its value is written to tags correctly but the cursor stays inside the field
2. Paste (CLIPBOARD_CONTENT in the video below) via Ctrl+V → tags are not updated right away
3. Click outside the field → Display value + appended clipboard content is converted to snake_case and written to tags

simplescreenrecorder-2026-05-22_12.51.44.mp4

[tordans]

Should we maybe listen to the paste event and then, when field empty update it but when field non-empty, show a JS-confirm "replace A with B - ok, cancel"?

[FloEdelmann]

The same thing can actually happen when instead of pressing Ctrl+V, you press another key (there seem to be many values ending with q, maybe because they wanted to quit that particular object). So I think a more general solution is needed, not only a fix for unintentional clipboard pasting.

[SomeoneElseOSM]

Thanks for reproducing this! I had no idea that editing tags as a text box was allowed (and have no idea why!).

On the "q" thing, I think that that's often people trying to square something such as a building after adding it. People (including me) do occasionally attack the list in taginfo (search https://taginfo.openstreetmap.org/keys/building#values for values containing "q") by removing the "q" and squaring the object.

[matkoniecz]

Thanks for reproducing it! Bug affecting entire class of input fields makes more sense (maybe title can be changed)

[1ec5]

For clarity, the general issue is that you can click anywhere in the localized (blue) value to edit it as if it’s a raw value. Pasting at the end is just a special case of that, but a pretty plausible one. The field should behave more like the multicombo field, which treats the whole localized value as an atomic unit.

Ironically, the multicombo field does not allow editing an existing token, but that would be pretty convenient sometimes, as long as it avoids this confusion between localized and raw values: #4521.