Id: Bug: changing tag in "All tags" and selecting other element changes other element

[ghost]

When changing a tag in "All tags" and then selecting another OSM element, iD copies some tag from the first element to the second one:

In this example, i changed the restaurant's cuisine=* tag and then selected the road, which resulted in a change of the road's name=* tag.

This problem occurs both with Safari 12.0.3 and Firefox 65.0.1.

[bhousel]

well that sounds bad

[ghost]

PS: This bug must have been introduced only recently (v2.14?). I've never noticed this error before.

[brianhatchl]

I was able to reproduce this, and did not require an "actual" tag change. I was able to select a POI and just double-click it's name key for example. Then select a different POI and the name value of the first POI is applied.

It seems like the issue arises when a raw tag editor change event is dispatched on blur AND the blur event is triggered by a new feature being selected. At the point the changeTags event is handled in entity editor the selected entity id has already changed.

[BjornRasmussen]

I can also reproduce this easily.

[bhousel]

I've been trying to reproduce this in Firefox 65 with no luck.

@SelfishSeahorse / @brianhatchl - can you confirm that it still shows up in http://preview.ideditor.com/master/ ?

I do believe there is probably an actual issue with the change and blur events, but I'm having a hard time to see it.

[ghost]

I've been trying to reproduce this in Firefox 65 with no luck.

@SelfishSeahorse / @brianhatchl - can you confirm that it still shows up in http://preview.ideditor.com/master/ ?

Yes, the problem still exists, both with Safari 12.1 and Firefox 66.0.2 (macOS 10.13.6).

When changing a tag value, then pressing the tabulator key and selecting another element, the tag after/below the one that has been changed is copied to the other element (as in the screencast above).

[brianhatchl]

I was not able to reproduce the bug (as I've described it) on Firefox 66, but I'm still able to reproduce it on Chrome 73.

I go to this area, http://preview.ideditor.com/master/#background=Bing&disable_features=boundaries&map=19.99/18.51844/-72.41289

Select the hospital POI, open the raw tag editor and click the name key. Then select the church POI and see the hospital name overwrite it's name tag value and the edit history record a change tag event.

[bhousel]

Thanks @brianhatchl !

This is a super interesting one because @quincylvania can reproduce it every time, and I can never reproduce it. Brain dump follows..

I'm pretty sure this code is the problem:
https://github.com/openstreetmap/iD/blob/b52d8c1790d20fbb0abb3520f7d464ab43ce12ec/modules/ui/raw_tag_editor.js#L389-L395

What it's trying to do is delay the change dispatch by 10ms so that if the user does a few things, the change and blur get dispatched together. We're also trying to work around the issue that Firefox will lump timeouts together when they are very close together (so in Firefox a timeout <5ms can even actually end up running _synchronously_, undoing the whole point of deferring the dispatch).

So I can totally see how a faster computer than mine might process the click on the new feature and the events that switch modes and reselect the new entity before that 10ms delay happens.

[bibi6]

I think I've got another piece for that bug.
If you carefully respect the procedure, the bug occurs. However, if you (incidentally) hover another way (or, more generally, another element), then the bug doesn't appear.
That's just what I noticed right now on Firefox 66.0.2 running on Ubuntu 16.04.

[bhousel]

I added some changes in behaviorSelect to defer processing of clicks until after any blur events and tag updates have had a chance to happen.

To people who were able to reliably trigger this bug - can you test in http://preview.ideditor.com/master/ and let me know whether the fix works (and hopefully doesn't break anything else)?

@quincylvania @brianhatchl @SelfishSeahorse @BjornRasmussen @bibi6 etc..

[brianhatchl]

My test case is fixed in Chrome 74 and Firefox 66. :smiley:

[ghost]

To people who were able to reliably trigger this bug - can you test in http://preview.ideditor.com/master/ and let me know whether the fix works (and hopefully doesn't break anything else)?

The problem doesn't occur anymore (Safari 12.1 and Firefox 66.0.3 on macOS 10.13.6). Thank you!