#18179 closed defect (worksforme)
Text fields act weirdly
Reported by: | gaben | Owned by: | team |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | Core | Version: | latest |
Keywords: | Cc: |
Description
What steps will reproduce the problem?
- Open the tag editor
- Write something in one of the fields
- Select what you wrote (Ctrl+A), then copy (Ctrl+C)
- Press Home to put the cursor to the beginning of the text field
- Try pressing Ctrl+V
What is the expected result?
The paste should work in step 5.
What happens instead?
It doesn't :( I can't decide if it's a feature or a bug.
I also noticed, that after paste the selection remains on the pasted text.
URL:https://josm.openstreetmap.de/svn/trunk Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Last:Changed Date: 2019-09-27 18:30:18 +0200 (Fri, 27 Sep 2019) Build-Date:2019-09-28 01:30:52 Revision:15382 Relative:URL: ^/trunk Identification: JOSM/1.5 (15382 hu) Windows 10 64-Bit OS Build number: Windows 10 Pro 1903 (18362) Memory Usage: 699 MB / 1820 MB (482 MB allocated, but free) Java version: 1.8.0_221-b11, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM Screen: \Display0 1920x1200 Maximum Screen Size: 1920x1200 VM arguments: [-Djava.security.manager, -Djnlp.application.href=https://josm.openstreetmap.de/download/josm-latest.jnlp, -Djava.util.Arrays.useLegacyMergeSort=true, -Djnlp.tk=awt, -Djnlpx.jvm=<java.home>\bin\javaw.exe, -Djnlpx.splashport=55585, -Djnlpx.home=<java.home>\bin, -Djnlpx.remove=false, -Djnlpx.offline=false, -Djnlpx.relaunch=true, -Djnlpx.session.data=%UserProfile%\AppData\Local\Temp\session6419869405489899767, -Djnlpx.heapsize=-1,2147483648, -Djava.security.policy=file:<java.home>\lib\security\javaws.policy, -DtrustProxy=true, -Djnlpx.origFilenameArg=%UserProfile%\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\31\583aa85f-25d43383] Dataset consistency test: No problems found Plugins: + FixAddresses (34977) + OpeningHoursEditor (34977) + apache-commons (35092) + buildings_tools (34982) + continuosDownload (82) + ejml (35122) + geojson (124) + geotools (35137) + jaxb (35014) + jts (35122) + junctionchecking (34977) + opendata (35139) + reverter (35084) + tag2link (35149) + tageditor (34977) + turnlanes-tagging (281) + utilsplugin2 (35098) + wikipedia (v1.1.1) Tagging presets: + https://josm.openstreetmap.de/josmfile?page=Presets/Healthcare&zip=1 Map paint styles: - https://josm.openstreetmap.de/josmfile?page=Styles/Maxspeed&zip=1 - https://josm.openstreetmap.de/josmfile?page=Styles/Lane_and_Road_Attributes&zip=1 - https://josm.openstreetmap.de/josmfile?page=Styles/Surface-DataEntry&zip=1 - https://josm.openstreetmap.de/josmfile?page=Styles/Surface&zip=1 + https://josm.openstreetmap.de/josmfile?page=Styles/RecyclingMaterials&zip=1 Validator rules: + https://josm.openstreetmap.de/josmfile?page=Rules/OsmoseValidations&zip=1 Last errors/warnings: - W: No configuration settings found. Using hardcoded default values for all pools. - W: java.io.IOException: A kért URL https://josm.openstreetmap.de/josmfile?page=Rules/OsmoseValidations&zip=1 nem található - W: Nem sikerült https://josm.openstreetmap.de/josmfile?page=Rules/OsmoseValidations&zip=1 hozzáadása a címke ellenőrzőhöz - W: java.io.IOException: No file found for: https://josm.openstreetmap.de/josmfile?page=Rules/OsmoseValidations&zip=1
Attachments (0)
Change History (3)
follow-up: 3 comment:1 by , 5 years ago
comment:2 by , 5 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
Ah no, that's a side effect of AutoCompletingComboBox
implementation, see #2729 / r3214:
I can't really change this without causing a lot of trouble in other use cases.
@Override public void insertString(int offs, String str, AttributeSet a) throws BadLocationException { if (selecting || (offs == 0 && str.equals(getText(0, getLength())))) return; // ... }
comment:3 by , 5 years ago
Replying to Don-vip:
Not sure, but I think we have an intended mechanism that detects if the string you are trying to paste is the exact same as the current one, to avoid strange duplicate copy-paste in case you press on ctrl-v too long.
I had similar idea, that maybe it is intended behaviour.
Nevertheless, thanks for checking.
Not sure, but I think we have an intended mechanism that detects if the string you are trying to paste is the exact same as the current one, to avoid strange duplicate copy-paste in case you press on ctrl-v too long.