#15558 closed defect (fixed)
Previous changeset comment stays in old state
Reported by: | anonymous | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | 19.04 |
Component: | Core | Version: | |
Keywords: | upload changeset comment | Cc: |
Description
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
Attachments (3)
Change History (16)
comment:1 Changed 22 months ago by
Keywords: | upload changeset comment added |
---|
comment:2 Changed 22 months ago by
Owner: | changed from team to Don-vip |
---|---|
Status: | new → assigned |
comment:3 Changed 22 months ago by
Owner: | changed from Don-vip to team |
---|---|
Status: | assigned → new |
Changed 22 months ago by
Attachment: | 15558.patch added |
---|
Changed 22 months ago by
Attachment: | 15558-v2.patch added |
---|
comment:4 Changed 22 months ago by
Ah, yes, very annoying. I think it's a regression from r5483
I think the problem is solved by patch 15558-v2.patch
comment:6 Changed 22 months ago by
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.
Changed 22 months ago by
Attachment: | 15558-v3.patch added |
---|
comment:7 Changed 22 months ago by
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.
comment:8 Changed 22 months ago by
I guess we can give it a try. This long-standing bug is annoying.
comment:9 Changed 22 months ago by
Milestone: | → 19.04 |
---|
comment:11 follow-up: 12 Changed 22 months ago by
Thanks for the reminder. I don't know how to find other tickets which might be fixed as well.
comment:12 Changed 21 months ago by
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"
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.