macos: erratic extra window behaviour

[richlv]

On MacOS, some additional JOSM windows do not appear in front when they have focus.
It seems like the windows are in two or more categories.

For example, the following nicely come forward of one another when they get focus:

• Mapillary image
• Geotagged Images
• Correlate images with GPX track

On the other hand, these windows always appear below the ones listed above, even when they have focus:

• Add tag
• Download

This is very inconvenient - for example, the "Download" window cannot be used until the image windows have been moved somewhere else. "Add tag" window often pops up below the image windows and gives an impression of JOSM having hung.

[Don-vip]

Can you please share your status report?

[richlv]

Sure, here it is:

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2019-06-03 00:05:30 +0200 (Mon, 03 Jun 2019)
Build-Date:2019-06-02 22:10:24
Revision:15155
Relative:URL: ^/trunk

Identification: JOSM/1.5 (15155 en_GB) Mac OS X 10.14.5
OS Build number: Mac OS X 10.14.5 (18F132)
Memory Usage: 779 MB / 1820 MB (502 MB allocated, but free)
Java version: 1.8.0_211-b12, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: Display 1127230987 1920x1080, Display 69733382 1680x1050
Maximum Screen Size: 1920x1080
VM arguments: [-Djava.security.policy=file:<java.home>/lib/security/javaws.policy, -DtrustProxy=true, -Djnlpx.home=<java.home>/bin, -Djava.security.manager, -Djnlpx.origFilenameArg=${HOME}/Library/Application Support/Oracle/Java/Deployment/cache/6.0/56/1ee8cfb8-3463dc3d, -Djnlpx.remove=false, -Dsun.awt.warmup=true, -Djava.util.Arrays.useLegacyMergeSort=true, -Djnlpx.heapsize=NULL,2048m, -Dmacosx.jnlpx.dock.name=JOSM, -Dmacosx.jnlpx.dock.icon=${HOME}/Library/Application Support/Oracle/Java/Deployment/cache/6.0/25/4c122699-75b5ae18.icns, -Djnlp.application.href=https://josm.openstreetmap.de/download/josm.jnlp , -Djnlpx.jvm="<java.home>/bin/java"]

Plugins:
+ Mapillary (1.5.18)
+ PicLayer (34908)
+ apache-commons (34908)
+ apache-http (34908)
+ ejml (34908)
+ geotools (34908)
+ jaxb (35014)
+ jna (34908)
+ jts (34908)
+ measurement (34977)
+ opendata (34997)
+ photo_geotagging (34908)
+ reverter (34999)
+ utilsplugin2 (34977)

Last errors/warnings:
- W: No configuration settings found.  Using hardcoded default values for all pools.

[richlv]

This behaviour contributed to my own silly mistake and a loss of several hours of edits.
JOSM seemed to be stuck, thus I tried to close it an save the data layer through the "Unsaved changes" dialog. I misunderstood that dialog and lost all the edits (#17868 created about a possible confusion in that dialog).

After while I figured out that I had deleted a way that was in a relation, and the confirmation dialog to remove it from the relation had appeared below Mapillary / geotagged photo window...

[Stereo]

I've had this too, but I haven't found a way of reliably reproducing this. Have you?

[richlv]

Yeah, have a data layer and a Mapillary or Geotagged image window visible.
Select an object, open "Add tag" dialog. Position that dialog away from the main window, then position one of the image windows on top of the "Add tag" dialog. Hit esc.
Now start adding tags so some object. JOSM seems to hang, even though it's just window layering being wrong.

[Stereo]

Can you try the most recent pre-release at ​https://github.com/thomersch/josm/releases and see if you can still reproduce this?

[Stereo]

This might be a duplicate of #16076

[richlv]

Mapillary image + "add tag" scenario still there with the latest build.

[richlv]

Mapillary image + "add tag" scenario still there.

[taylor.smock]

This isn't just a image viewer dialog problem. It occurs with all other toggle dialogs, so long as the Tags/Memberships dialog is docked.

The toggle dialogs are part of that same tree (GuiHelper.getFrameForComponent(MainApplication.getMainFrame()) === MainApplication.getMainFrame()).

Oddly enough, when I set a break point at source:trunk/src/org/openstreetmap/josm/gui/dialogs/properties/TagEditHelper.java@18814:788#L788​, it "just works".

Possible JDK bugs:

• ​https://bugs.openjdk.org/browse/JDK-8306001 ("Modal dialog can go behind another modal dialog")
• ​https://bugs.openjdk.org/browse/JDK-8158473 ("[macosx] Modal dialog is shown behind non-modal dialog if invoked from frame in a full screen mode")
• ​https://bugs.openjdk.org/browse/JDK-4255200 ("modal dialog should come to the front")
• ​https://bugs.openjdk.org/browse/JDK-7124246 ("[macosx] Modal z-order issue")

I think this might be a JDK issue.