Notes description does not fit in box (sometimes)

[mnalis]

What steps will reproduce the problem?

1. download area and Notes
2. click on note either on main screen od right-side screen
3. note description will (sometimes) open in window which is too small to display Notes description

What is the expected result?

Notes description will fit in box containing it, so it could be readable

What happens instead?

Notes description opens in box which is too small, so last line of text is unreadable. In attached "bad" image, last word "peaku" after "metal mash na" is lost. (sometimes, the whole text of the note gets lost)

Please provide any additional information below. Attach a screenshot if possible.

When I click elsewhere to remove notes box, resize right window (tools), and click on the note again, it (sometimes, depending on the size) gets fixed

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2019-11-01 23:59:01 +0100 (Fri, 01 Nov 2019)
Build-Date:2019-11-01 22:59:57
Revision:15492
Relative:URL: ^/trunk

Identification: JOSM/1.5 (15492 en) Linux Debian GNU/Linux 9.11 (stretch)
Memory Usage: 276 MB / 1820 MB (96 MB allocated, but free)
Java version: 1.8.0_232-8u232-b09-1~deb9u1-b09, Oracle Corporation, OpenJDK 64-Bit Server VM
Screen: :0.0 1024x768
Maximum Screen Size: 1024x768
Java package: openjdk-8-jre:amd64-8u232-b09-1~deb9u1
WebStart package: icedtea-netx:amd64-1.6.2-3.1+deb9u1
Java ATK Wrapper package: libatk-wrapper-java:all-0.33.3-13+deb9u1
libcommons-logging-java: libcommons-logging-java:all-1.2-1
fonts-noto: fonts-noto:-
VM arguments: [-Dicedtea-web.bin.name=javaws, -Dicedtea-web.bin.location=/usr/bin/javaws, -Djava.security.manager, -Djava.security.policy=/etc/icedtea-web/javaws.policy]
Dataset consistency test: No problems found

Plugins:
+ DirectDownload (34977)
+ DirectUpload (35041)
+ Mapillary (1.5.20)
+ OpeningHoursEditor (34977)
+ PicLayer (35104)
+ SeaMapEditor (34908)
+ apache-commons (35092)
+ apache-http (34908)
+ colorscheme (34908)
+ gson (35158)
+ imagery_offset_db (34908)
+ jna (34908)
+ log4j (34908)
+ mapdust (35039)
+ pbf (35033)
+ photo_geotagging (34908)
+ reverter (35084)
+ turnrestrictions (34977)
+ waydownloader (34977)
+ waypoint_search (34977)

Tagging presets:
+ http://<user.name>.com/prezentacije/OpenStreetMap/josm-preset.xml
+ https://josm.openstreetmap.de/josmfile?page=Presets/Crafts&zip=1
+ https://josm.openstreetmap.de/josmfile?page=Presets/contact(socialnetworks_IMs)&zip=1

Validator rules:
+ https://josm.openstreetmap.de/josmfile?page=Rules/KeepRight&zip=1
+ https://josm.openstreetmap.de/josmfile?page=Rules/OsmoseValidations&zip=1

Last errors/warnings:
- E: Failed to locate image 'presets/empty.png'
- W:  fotograf: Could not get presets icon presets/empty.png
- E: Failed to locate image 'presets/empty.png'
- W:  recycle: Could not get presets icon presets/empty.png
- E: Failed to locate image 'presets/empty.png'
- W:  pametna klupa: Could not get presets icon presets/empty.png
- W: No configuration settings found.  Using hardcoded default values for all pools.
- W: java.io.IOException: The requested URL https://josm.openstreetmap.de/josmfile?page=Rules/OsmoseValidations&zip=1 was not found
- W: Failed to add https://josm.openstreetmap.de/josmfile?page=Rules/OsmoseValidations&zip=1 to tag checker
- W: java.io.IOException: No file found for: https://josm.openstreetmap.de/josmfile?page=Rules/OsmoseValidations&zip=1

[mnalis]

broken Notes display

[mnalis]

OK after resize

[mnalis]

note display is still sometimes truncated in current tested (17084)

[mnalis]

just to note it is still broken in current tested (17084):

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2020-10-03 13:42:38 +0200 (Sat, 03 Oct 2020)
Revision:17084
Build-Date:2020-10-04 01:30:47
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (17084 en) Linux Debian GNU/Linux 10 (buster)
Memory Usage: 467 MB / 2048 MB (168 MB allocated, but free)
Java version: 11.0.9+11-post-Debian-1deb10u1, Debian, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: :0.0 1920x1080 (scaling 1.0x1.0)
Maximum Screen Size: 1920x1080
Best cursor sizes: 16x16 -> 16x16, 32x32 -> 32x32
Desktop environment: ICEWM
VM arguments: [--patch-module=java.desktop=/usr/share/icedtea-web/netx.jar:, --add-reads=java.base=ALL-UNNAMED,java.desktop, --add-reads=java.desktop=ALL-UNNAMED,java.naming, --add-reads=java.naming=ALL-UNNAMED,java.desktop, --add-exports=java.desktop/sun.awt=ALL-UNNAMED,java.desktop, --add-exports=java.desktop/javax.jnlp=ALL-UNNAMED,java.desktop, --add-exports=java.base/com.sun.net.ssl.internal.ssl=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.net.www.protocol.jar=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.security.action=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.security.provider=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.security.util=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.security.validator=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.security.x509=ALL-UNNAMED,java.desktop, --add-exports=java.base/jdk.internal.util.jar=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.net.www.protocol.http=ALL-UNNAMED,java.desktop, --add-exports=java.desktop/sun.awt.X11=ALL-UNNAMED,java.desktop, --add-exports=java.desktop/sun.applet=ALL-UNNAMED,java.desktop, --add-exports=java.desktop/sun.applet=ALL-UNNAMED,jdk.jsobject, --add-exports=java.naming/com.sun.jndi.toolkit.url=ALL-UNNAMED,java.desktop, -Dicedtea-web.bin.name=javaws, -Dicedtea-web.bin.location=/usr/share/icedtea-web/bin/javaws.sh, -Djava.security.manager, -Djava.security.policy=/etc/icedtea-web/javaws.policy]
Dataset consistency test: No problems found

Plugins:
+ DirectDownload (35552)
+ DirectUpload (35583)
+ FixAddresses (35583)
+ PicLayer (2a9aa7a)
+ apache-commons (35524)
+ apache-http (35092)
+ buildings_tools (35579)
+ conflation (0.6.6)
+ geochat (35405)
+ imagery_offset_db (35405)
+ jna (35092)
+ jts (35122)
+ measurement (35579)
+ pt_assistant (2.1.10-80-g7d9bba3)
+ reverter (35638)
+ turnlanes (35405)
+ turnrestrictions (35583)
+ utilsplugin2 (35624)

Tagging presets:
+ https://<user.name>.com/prezentacije/OpenStreetMap/josm-preset.xml

Map paint styles:
- /tmp/elemstyles.mapcss
- https://www.dropbox.com/s/qo3ai47fpv241jf/Styles_Fixme_and_Notes.zip?raw=1
- https://raw.githubusercontent.com/OpenSeaMap/josm/master/CEVNI_MapCSS.mapcss
+ http://bezdomni.net/Styles_HighlightedCapesBays-style.mapcss 

Last errors/warnings:
- 05079.096 E: Region [TMS_BLOCK_v2] : Failure getting from disk, key = osm-hr_ Zagreb 2018 Aerial imagery:https://tms.osm-hr.org/zagreb-2018/{zoom}/{x}/{-y}.png/14/8917/5839
- 05079.300 E: Region [TMS_BLOCK_v2] : Failure getting from disk, key = osm-hr_ Zagreb 2018 Aerial imagery:https://tms.osm-hr.org/zagreb-2018/{zoom}/{x}/{-y}.png/13/4458/2919
- 05079.343 E: Region [TMS_BLOCK_v2] : Failure getting from disk, key = osm-hr_ Zagreb 2018 Aerial imagery:https://tms.osm-hr.org/zagreb-2018/{zoom}/{x}/{-y}.png/12/2229/1459
- 05079.346 E: Region [TMS_BLOCK_v2] : Failure getting from disk, key = osm-hr_ Zagreb 2018 Aerial imagery:https://tms.osm-hr.org/zagreb-2018/{zoom}/{x}/{-y}.png/17/71333/46718
- 05079.367 E: Region [TMS_BLOCK_v2] : Failure getting from disk, key = osm-hr_ Zagreb 2018 Aerial imagery:https://tms.osm-hr.org/zagreb-2018/{zoom}/{x}/{-y}.png/17/71333/46719
- 05079.369 E: Region [TMS_BLOCK_v2] : Failure getting from disk, key = osm-hr_ Zagreb 2018 Aerial imagery:https://tms.osm-hr.org/zagreb-2018/{zoom}/{x}/{-y}.png/17/71333/46720
- 05079.507 E: Region [TMS_BLOCK_v2] : Failure getting from disk, key = osm-hr_ Zagreb 2018 Aerial imagery:https://tms.osm-hr.org/zagreb-2018/{zoom}/{x}/{-y}.png/17/71333/46721
- 05079.512 E: Region [TMS_BLOCK_v2] : Failure getting from disk, key = osm-hr_ Zagreb 2018 Aerial imagery:https://tms.osm-hr.org/zagreb-2018/{zoom}/{x}/{-y}.png/17/71333/46722
- 05079.531 E: Region [TMS_BLOCK_v2] : Failure getting from disk, key = osm-hr_ Zagreb 2018 Aerial imagery:https://tms.osm-hr.org/zagreb-2018/{zoom}/{x}/{-y}.png/17/71333/46723
- 05079.532 E: Region [TMS_BLOCK_v2] : Failure getting from disk, key = osm-hr_ Zagreb 2018 Aerial imagery:https://tms.osm-hr.org/zagreb-2018/{zoom}/{x}/{-y}.png/17/71333/46724

[mnalis]

Nimbus - wrong Notes window size

[mnalis]

Nimbus - Notes window size corrects after panning the map

[mnalis]

I can reproduce this bug not only with Metal look and feel (as in original report) but also with Nimbus (attached screenshots from 17084, with bug present, and with Notes details window size automagically fixed after panning the map with right mouse button)

[GerdP]

I was not able to reproduce this on Windows, but the note in your screenshot was closed. I tried several others and none of them changed while panning.

[mnalis]

Thanks for trying GerdP! The bug happens only sometimes, and does not seem to depend on the note in question. I cannot determine what exactly triggers the bug - the same note is sometimes shown ok, sometimes not. (and as indicating earlier, simple act of panning the map or resizing the JOSM window fixes it). It might be that in only happens when pixel position is exactly something when clicking on the note, or panel is exactly some size or something else.

It is still hugely annoying, as it easily happens to me a dozen times on different notes in longer editing session, and has been there for more than a year (surviving through dozens of JOSM versions, look&feel changes, and at least 3 openJDK versions and 2 Debian upgrades). It is very hard to reproduce at will, though.

I'm open for suggestions for what I could try to see it helps, or which might provide more debug info when it happens, in order to help debug this.

[mnalis]

Also, I've never seen the note display break when I pan or zoom the map - panning/zooming only ever corrected it for me. Breakage only seems to occur (and then only sometimes) when initially displaying the note (by clicking on it on the map, or clicking on it on the Notes pane on the right).

[GerdP]

please try

[mnalis]

Thanks GerdP; I'll look into setting up build environment to learn to build and test the patch in next few days!

I've since nuked and setup again JOSM preferences. Bug is still there, and I've found I can pretty reliably (say in about 80% of cases) reproduce it on Note 243490. When screen is on same position, I can click on Note to get the bug, and click off to remove screen, and then click on Note again to reproduce it 100% of the time. But if I pan a map a little, the bug may disappear (or not). Here is how it looks:

[mnalis]

display bug shows initially

[mnalis]

bug still there after removing note display, moving screen a little, and clicking on the bug again

[mnalis]

same action as before (removing note display, moving screen a little, and clicking on the bug again) but this time, the bug is not present!

[mnalis]

That is with webstart JOSM on Debian Buster, with icewm window manager on X11, and maximized (but not fullscreen) JOSM, reproducible after fresh start. (I'll go look to setup build environment to test your patch!).

Please provide any additional information below. Attach a screenshot if possible.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2020-11-21 14:56:29 +0100 (Sat, 21 Nov 2020)
Revision:17329
Build-Date:2020-11-22 02:30:52
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (17329 en) Linux Debian GNU/Linux 10 (buster)
Memory Usage: 497 MB / 2048 MB (190 MB allocated, but free)
Java version: 11.0.9+11-post-Debian-1deb10u1, Debian, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: :0.0 1920x1080 (scaling 1.0x1.0)
Maximum Screen Size: 1920x1080
Best cursor sizes: 16x16 -> 16x16, 32x32 -> 32x32
Desktop environment: ICEWM
Environment variable LANG: C.UTF-8
VM arguments: [--patch-module=java.desktop=/usr/share/icedtea-web/netx.jar:, --add-reads=java.base=ALL-UNNAMED,java.desktop, --add-reads=java.desktop=ALL-UNNAMED,java.naming, --add-reads=java.naming=ALL-UNNAMED,java.desktop, --add-exports=java.desktop/sun.awt=ALL-UNNAMED,java.desktop, --add-exports=java.desktop/javax.jnlp=ALL-UNNAMED,java.desktop, --add-exports=java.base/com.sun.net.ssl.internal.ssl=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.net.www.protocol.jar=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.security.action=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.security.provider=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.security.util=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.security.validator=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.security.x509=ALL-UNNAMED,java.desktop, --add-exports=java.base/jdk.internal.util.jar=ALL-UNNAMED,java.desktop, --add-exports=java.base/sun.net.www.protocol.http=ALL-UNNAMED,java.desktop, --add-exports=java.desktop/sun.awt.X11=ALL-UNNAMED,java.desktop, --add-exports=java.desktop/sun.applet=ALL-UNNAMED,java.desktop, --add-exports=java.desktop/sun.applet=ALL-UNNAMED,jdk.jsobject, --add-exports=java.naming/com.sun.jndi.toolkit.url=ALL-UNNAMED,java.desktop, -Dicedtea-web.bin.name=javaws, -Dicedtea-web.bin.location=/usr/share/icedtea-web/bin/javaws.sh, -Djava.security.manager, -Djava.security.policy=/etc/icedtea-web/javaws.policy]
Dataset consistency test: No problems found

Plugins:
+ DirectUpload (35640)
+ buildings_tools (35640)
+ conflation (0.6.6)
+ imagery_offset_db (35640)
+ jts (35458)
+ pt_assistant (2.1.10-80-g7d9bba3)
+ turnrestrictions (35640)
+ utilsplugin2 (35640)

Tagging presets:
+ https://<user.name>.com/prezentacije/OpenStreetMap/josm-preset.xml

Map paint styles:
- https://josm.openstreetmap.de/josmfile?page=Styles/PublicTransport&zip=1
+ http://bezdomni.net/Styles_HighlightedCapesBays-style.mapcss

Validator rules:
+ https://josm.openstreetmap.de/josmfile?page=Rules/KeepRight&zip=1
+ https://josm.openstreetmap.de/josmfile?page=Rules/QAToolInspiredValidations&zip=1
+ https://josm.openstreetmap.de/josmfile?page=Rules/OSMLint&zip=1
+ https://josm.openstreetmap.de/josmfile?page=Rules/MissingWeekdays&zip=1
+ https://josm.openstreetmap.de/josmfile?page=Rules/SourceObjectTag&zip=1
+ https://josm.openstreetmap.de/josmfile?page=Rules/IndoorRules&zip=1

[GerdP]

It would be great to have an instruction like

• change zoom to ...
• use Ctrl+J to jump to position ...
• download notes

This should allow others to reproduce it. It might well be related to the OS components.

[skyper]

This is a really old bug. Wonder why it was not reported earlier. I remember to have seen it on Debian with X11 and several Desktops flavors (Gnome, XFCE, LXDE).

I can reproduce it with both notes from this ticket and also the example in #17211. I tried "Metal" and "Flatlaf Dark" themes without a big difference in behavior. Just make the mapview small and zoom and/or pan around. It is easier to reproduce with more context in the note.

Notes can be downloaded with "Open Location". I gonna attach the three example nodes as example file​.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2020-11-25 00:09:36 +0100 (Wed, 25 Nov 2020)
Revision:17355
Build-Date:2020-11-25 02:30:51
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (17355 en) Linux Debian GNU/Linux 10 (buster)
Java version: 11.0.9+11-post-Debian-1deb10u1, Debian, OpenJDK 64-Bit Server VM

[skyper]

example with three notes

[GerdP]

OK, I see nothing special, so it seems this doesn't happen on Windows.

[mnalis]

start JOSM 17329 by using java -jar /home/mnalis/.cache/icedtea-web/cache/31/https/josm.openstreetmap.de/download/josm-tested.jar 'https://www.openstreetmap.org/note/2434904#map=19/45.82651/15.80774&layers=N', click OK to confirm all 3 downloads, then click on the red note icon in the middle of the map.

[mnalis]

And the bugs looks the same when I instead use JOSM from Debian Buster-backports 0.0.svn17084+dfsg-1~bpo10+1 (recompiled by myself in preparation to try your patch) by using java -jar /usr/share/josm/josm.jar 'https://www.openstreetmap.org/note/2434904#map=19/45.82651/15.80774&layers=N'

[mnalis]

bug still there after building version with patch https://josm.openstreetmap.de/raw-attachment/ticket/18372/18372.patch applied :(

[mnalis]

Update:

One important thing to note is that is seems dependent on the size of right sidebar. By selecting a note so the note details text is shown, and resizing the right sidebar little by little, I can make note subwindow fix itself or break itself again (but moving right sidebar back to previous position won't always undo what initial resizing did).

I can also reproduce problem with skyper https://josm.openstreetmap.de/attachment/ticket/18372/josm_18372_examples.osn and with freshly created preferences: rm -rf /tmp/testhome; mkdir /tmp/testhome; java -Djosm.home=/tmp/testhome -jar josm-tested.jar ~/Downloads/josm_18372_examples.osn, then clicking on the resolved note 118835 in lower left corner note looks normal.

Then dragging side of the right sidebar to the left (to enlarge right sidebar) cases the note subwindow to redraw and breaks the last line, manifesting this bug.

[mnalis]

@GerdP, if it is still unreproducable in MS-windows, I've tried to do some debugging via Logging.info()...

It only happens in src/org/openstreetmap/josm/gui/layer/NoteLayer.java in code path starting with:

if (v != null) {
      v.setSize(maxWidth, 0);

I've nailed it down to "magic height" constant of 10 in line:

int w = (int) Math.ceil(v.getPreferredSpan(View.X_AXIS));
int h = (int) Math.ceil(v.getPreferredSpan(View.Y_AXIS)) + 10;

and again when returning to calculate starting position of Note subwindow:

return new Point(
        screenloc.x + (d.width > rightMaxWidth && d.width <= leftMaxWidth ? xl - d.width : xr),
        screenloc.y + (d.height > bottomMaxHeight && d.height <= topMaxHeight ? yt - d.height - 10 : yb));

I'm no java programmer, but as I understand it there is View v which contains formatted HTML text, and that v is inside JEditorPane pane which is the box for the note that gets drawn on the screen.

So to uninitiated like myself it looks like sizes width/height of the pane should be like that of v plus perhaps few pixels on ALL sides for margins... However, above calculated width w does not have any such magic constant for margins, but height h does have 10, which looks suspicious to me. Maybe original programmer has tried using same width/height for v and pane and run into this problem, and then worked around it by adding extra 10 pixels.

To test the theory, I've changed 10 to 20 in those two places, and fixed the bug -- text doesn't get cut off in the middle anymore (although sometimes of course there is then visible free space of extra 10 pixels at the bottom).

So I would guess that correct way would be programmatically finding out by how many pixels exactly need to be added from View v height to calculate JEditorPane pane height (which probably differs on MS-Windows and on X11, if you can't reproduce problem on MS-Windows). But as I don't program in Java I don't have a slightest idea how to find out that, or even if there should be any such offset.

If nobody know why this happens and how to calculate correct offset, perhaps it would be easiest to just increase that hardcoded offset to 20 so Notes never break for anyone (at the expense of having few extra blank pixels at the bottom sometimes for some users). Or make it a advanced preferences or magic variable which gets assigned 10 or 20 depending on the OS used). With comment in the code why it is set to that value, of course, so next one who comes along can find some helpful reference...

[GerdP]

In 17361/josm:

Fix #18372: Notes description does not fit in box (sometimes)

• increase magic number to 20 as proposed by mnalis

[GerdP]

Thanks for the hints! See also #15550 which mentions more problem cases.

I've nailed it down to "magic height" constant of 10

Yes, that's the line which calculates the initial "wrong" display. I can now reproduce your results when I set the value to 0: Sometimes the last line is not displayed. It depends on the position of the note and the size of the edit panel.

Also, I've never seen the note display break when I pan or zoom the map - panning/zooming only ever corrected it for me.

When I play with value 0, sometimes the error is introduced with panning or resizing the edit window, so it probably doesn't help to force a redraw.

[GerdP]

With the change in r17361 this is the "worst" case of empty space that I see in MS Windows:

No problem for me.

[mnalis]

Works on my example Notes with offset 20, but on the note 1188355 I can still trigger the bug (much rarer, though). It seems that the "magic offset" on X11 is needs to be about 10 bigger than on MS-windows to completely work around the bug..

[skyper]

Does not happen that often but I still get it with all three notes:

1. Start JOSM with empty preferences (java -Xmx256M -Djosm.home=/tmp/JOSM/josm_test_$(date +%s) -jar /usr/share/josm-latest/josm-latest.jar)
2. Make the main window small (140x100)
3. Open attached file​
4. Click on a note in mapview
5. (Pan or/and Zoom around)

I have managed to get notes been not displayed completely right after opening the tooltip. If not right away, panning or/and zooming will at some point cut of lines at the bottom.

With #17211 in my mind, I am not sure if tooltips will work here as the context of the note might need more space than the screen size and we do not get around a scrollbar.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2020-11-26 22:24:27 +0100 (Thu, 26 Nov 2020)
Revision:17364
Build-Date:2020-11-27 02:30:53
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (17364 en) Linux Debian GNU/Linux 10 (buster)
Java version: 11.0.9+11-post-Debian-1deb10u1, Debian, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
VM arguments: [-Djosm.home=<josm.pref>]

[GerdP]

I also wondered what would happen when the dialog contains too many lines. Please can you check if the changeset manager dialog works fine for you. Tree e.g. ​https://openstreetmap.org/changeset/85329869 which has a long discussion.

[skyper]

No problem with the changeset manager, but this is an separate window and tables. I see minor issues there as urls are not clickable and selecting text to copy into buffer does not work.

[GerdP]

OK. BTW: On my MS Windows system Eclipse shows the same problem with tooltips. Sometimes the last line is truncated. They probably also don't know the magic number ;)
No idea if tooltips allow scrollbars, if not, we have to use a normal panel, right?

[GerdP]

Ah, stop. In Eclipse it works like this: First the tooltip is shown without scrollbar, if you hover over the tooltip it changes to a normal window with scrollbar and other buttons. But problem is the same. User doesn't see that there's more text unless they press F2 or use the mouse.

[skyper]

Replying to skyper:

No problem with the changeset manager, but this is an separate window and tables.

Wait a minute, sorry, I have also problems with this table. It works with the last comment but it does not work with all above as the scrolling is tied to one row column and context of other rows columns is invisible and skipped if the cell is too small. Sorting by rows columns does not work, either, at least for "date".

Edit: Sorry mixed up rows and columns.

[GerdP]

@Skyper: Yes, can reproduce both problems :( I guess I never tried to sort this data.

[skyper]

Replying to GerdP:

@Skyper: Yes, can reproduce both problems :( I guess I never tried to sort this data.

See #20164 and #20165.

[GerdP]

Thanks!

[stoecker]

Milestone renamed

[daganzdaanda]

I have managed to get notes been not displayed completely right after opening the tooltip. If not right away, panning or/and zooming will at some point cut of lines at the bottom.

I tried the testfile using current tested JOSM version and was able to get the last line cut off by either making the sidebar larger or panning the map view. In both cases the tooltip width was changing and some lines had to be broken differently. This can happen also when the tooltip gets wider. Maybe this (re-)breaking of lines is not always taken into account correctly when the height of the tooltip box is calculated?

With #17211 in my mind, I am not sure if tooltips will work here as the context of the note might need more space than the screen size and we do not get around a scrollbar.

True, if I make the whole JOSM window smaller and move it to the bottom of my screen, the tooltip will continue outside of the window, with no way to scroll it. This is likely a problem if you use JOSM on a device with a small screen.