id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
7951	"incorrect contents of combolists when clicking on a ""Recently added tags"":"	verdy_p	team	"When adding a new tag to an object, the dialog shows two comboboxes for entering or selecting a tag name and its value.

But now it also displays a list of ""Recently added tags"". The first displayed in that list is what fills initially the current selection of name/value in the two comboboxes.

However if we click on another name/value pair in that list, the two editable parts of the comboboxes are properly filled, but the list parts of the combos are still displaying alternate values from the initial selection.

So if the first choice was for example source=INSEE (from a previous tag edit), and we want to add another tag like population:date=2009 by clicking on it, and want to choose another year, by opening the combolist, that list displays ""INSEE"" or other existing values from the initial ""source=*"" tag, but not ""2009"" and other years.

In summary, the lists of comoboboxes are not refreshed and synchronized according to the current state of the edit fields of other combos when they have been changed by clicking on a recently added tag.

-----

Additional RFE: filling the content of the combolist takes too much time when editing. In my opinion, computing that list it should be done in a background thread that will update the list asynchronously (you need synchronization only when that list will be displayed by opening it explicitly, or when that list is ready, to offer an autofill feature when typing in the editable fields).

This is notably a problem when adding tags like ""name=*"" because it has a lot of possible values and the list of values is enormous. May be, if you have too many items in that list above some threshold, the list should be cancelled, forcing us to enter enough characters to match some substring.

Or only to fill the list with items that are defined for objects in the geographic neighborhood (first those that have a common node or way or relation, or parent objects and their children in hierarchical relations) of the current edited objects in the selection: once the threshold is reached, start eliminating values that are less likely to be entered.

Something should be done in JOSM to perform parallel search queries (using thread pools) and alwauys outside of the main GUI thread. The GUI must remain responsive, allowing to even interrupt those long searches running in background threads (this is not just a problem for this tag edit dialog but more generally for every kind of filters used to fill a selection). This problem still means that JOSM is not easy to work with big datasets.

Note (for memory): there's still problems with displaying long lists in those comboboxes (see my other related bug request, because that list is too high and is still displayed partly out of screen). This other problem is not a RFE but really another GUI BUG.
"	defect	closed	normal		Core	tested	fixed	GUI combobox recently added tags