Previous changeset comment stays in old state

[anonymous]

I have found closed ticket #15290 with the same defect without resolution.

Two different PCs, different Win versions, different java versions

1) Win 7, JOSM version 13122, language English, Look and Feel Metal, Expert mode, java 1.8.0_151
2) Win 10, JOSM version 13123, language English, Look and Feel Metal, Expert mode, newest java - the problem was there in several previous JOSM versions as well, and before upgrading java from 1.8

With mouse, it is necessary to select the previous changeset comment twice. First clicks leaves the comment in the old state.

The same problem is with keyboard: {DOWN} - the history opens, the previous comment is selected but after {ENTER} the original /empty or prefilled state/ stays. It is necessary to go {DOWN} {DOWN} {UP} {ENTER} to get the previous comment in.

The problem is not constant. I suspect the remote control could be the reason, as I notice this every time I work on hotosm tasks.

the Win 7 info:
URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2017-11-14 01:41:49 +0100 (Tue, 14 Nov 2017)
Build-Date:2017-11-14 02:40:51
Revision:13122
Relative:URL: ^/trunk

Identification: JOSM/1.5 (13122 en) Windows 7 64-Bit
OS Build number: Windows 7 Home Premium (7601)
Memory Usage: 595 MB / 910 MB (158 MB allocated, but free)
Java version: 1.8.0_151-b12, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: \Display0 1920x1080
Maximum Screen Size: 1920x1080
VM arguments: [-Djosm.home=./, -Djosm.pref=./HOT]
Dataset consistency test: No problems found

[Don-vip]

Problem not specific to changeset comment. The bug is probably in AutoCompletionComboBox as I can see this problem everywhere. There are probably several duplicates of this bug.

[GerdP]

Ah, yes, very annoying. I think it's a regression from r5483

I think the problem is solved by patch 15558-v2.patch

[Don-vip]

did you check it doesn't reintroduce #8013?

[GerdP]

Sure, I've tested the patch with the search dialog.
After start of JOSM the darch field is empty, from then on the last entered value is presented (works also for empty search value)
In both cases the first Cursor Down opens the drop down list and the 2nd hit selects the first entry.

[GerdP]

With v3 I've also reduced the code duplication involved with the reversing of the lists.
I've only changed those places where the list is only used to create the dialog. The remaining calls of method setPossibleItems()
need more care as they use other ways to work around this problem.
Please let me know if I should continue in this direction, else I'll commit this patch tomorrow.

[Don-vip]

I guess we can give it a try. This long-standing bug is annoying.

[GerdP]

In 15011/josm:

fix #15558: apply 15558-v3.patch

[GerdP]

Thanks for the reminder. I don't know how to find other tickets which might be fixed as well.

[Don-vip]

Replying to GerdP:

I don't know how to find other tickets which might be fixed as well.

Couldn't find others in "open core defects"

[GerdP]

In 15108/josm:

simplify code (see #15558):
also removes side-effect: The order of the list searchExpressionHistory is no longer reversed.