[PATCH] OAuth wizard windows have tendency to hide their own error messages

[ris]

When the token retrieval process fails and shows an error message ("The automatic process ... has failed ..." message) There appears to be a timer of some sort running that periodically moves the preferences dialogs back to on top of this message, hiding it. And since the error dialog is modal, the preference panels cannot be interacted with - for seemingly no reason. This is extremely confusing for new users and annoying for all users.

This is happening for me on linux r14206, but I've seen similar things happen on multiple platforms on multiple releases.

[gaben]

Ticket #16953 has been marked as a duplicate of this ticket.

[gaben]

Ticket #19435 has been marked as a duplicate of this ticket.

[taylor.smock]

Ticket #23195 has been marked as a duplicate of this ticket.

[taylor.smock]

A hint from ​Modality JavaDocs:

• keeps its Z-order below the modal dialog that blocks it

Warning! Some window managers allow users to change the window Z-order in an arbitrary way — in that case the last requirement may not be met.

This affects all blocking modal dialogs, although some are much worse than others. As a specific example, a toggle dialog will appear in front of the Add tags dialog on macOS, but will not under Windows or linux. The OAuth error window seems to appear on at least two platforms (macOS and Linux).

There is a workaround (edited for brevity):

src/org/openstreetmap/josm/gui/ConditionalOptionPaneUtil.java

@@ -283 +286 @@
                 add(cbShowImmediateDialog, GBC.eol());
             }
             add(cbStandard, GBC.eol());
+
+            this.addAncestorListener(new AncestorListener() {
+                @Override
+                public void ancestorAdded(AncestorEvent event) {
+                    if (event.getAncestor() instanceof Dialog) {
+                        Dialog dialog = (Dialog) event.getAncestor();
+                        if (dialog.isVisible() && dialog.isModal()) {
+                            dialog.setAlwaysOnTop(true);
+                        }
+                    }
+                }
+            });
         }
 
         NotShowAgain getNotShowAgain() {

src/org/openstreetmap/josm/gui/ExtendedDialog.java

@@ -459 +459 @@
                 rememberWindowGeometry(new WindowGeometry(this));
             }
         }
+        if (visible && isModal()) {
+            this.setAlwaysOnTop(true);
+        }
         super.setVisible(visible);
 
         if (!visible && disposeOnClose) {

src/org/openstreetmap/josm/gui/HelpAwareOptionPane.java

@@ -350 +350 @@
         if (helpTopic != null) {
             HelpUtil.setHelpContext(dialog.getRootPane(), helpTopic);
         }
+        if (dialog.isModal()) {
+            dialog.setAlwaysOnTop(true);
+        }
         dialog.setVisible(true);
     }
 

Potential upstream bugs:

• ​https://bugs.openjdk.org/browse/JDK-8190230 (theoretically fixed in Java 10)

Quite frankly, this is a hack; we should not have to set a blocking window as always on top. It should be done in the JRE.

[stoecker]

Don't display an error dialog, but rather display the error inline in red or something alike?

[taylor.smock]

Don't display an error dialog, but rather display the error inline in red or something alike?

This is technically an option for the oauth error. This isn't always the case -- a warning message from uploading to the server may appear behind an undocked toggle dialog, for example.

A similar problem does affect other parts of the application. As noted, some operating systems are worse than others. As a specific example, on macOS, if I undock any toggle dialog and then open an Add tags dialog, the Add tags dialog will be behind the toggle dialog (in z ordering -- this isn't usually a problem unless the add dialog appears behind the toggle dialog, in which case the user may think that the application is frozen).

The workaround I found should work for all modal dialogs we have in JOSM. I still don't like the workaround.

[taylor.smock]

Blocking server-side conflict dialog behind Tags/Memberships toggle dialog

[stoecker]

The workaround I found should work for all modal dialogs we have in JOSM. I still don't like the workaround.

Wouldn't be the only "I don't like" workaround in JOSM.

[taylor.smock]

No, it wouldn't be. It wouldn't even be the first "I don't like it" workaround I've added.

I'm probably going to try and get a reproducer for Java bugs and an upstream ticket before I apply the workaround. I don't expect them to actually fix it, since they don't seem interested in desktop Java anymore.

[taylor.smock]

In 18849/josm:

Fix #16485: Modal dialogs may occasionally be behind another dialog

From the ​Modality javadocs:

• keeps its Z-order below the modal dialog that blocks it

Warning! Some window managers allow users to change the window Z-order in an arbitrary way — in that case the last requirement may not be met.

The workaround is to set the blocking dialog as always on top.

[taylor.smock]

Ticket retargeted after milestone deleted

[gaben]

Could you please try to add a local validator/mappaint rule? I have issues with the focus on Windows.

[gaben]

I'm reopening due to issues on Windows.

[taylor.smock]

It would help if I knew what the issue with focus on Windows was. All I know is that it "worksforme" on mac.

[gaben]

I'll add more details soon, until then please check the scenario in comment:12 while switching tabs.

[gaben]

I've run into the issue on Ubuntu as well.

1. Run JOSM
2. Open or download some data that has a road with access tags
3. On the Tags/Memberships panel, click on the Access preset
4. Switch windows with Alt+Tab

At this point, the window switching "stops working" for me. Okay it works, but JOSM is above everything until I click on one of the dock icons. And even then, the preset editor will still be on top of other apps. Reproduces with r18853, while r18446 has no issues.

[taylor.smock]

Ticket retargeted after milestone closed

[taylor.smock]

I'm not able to reproduce the window switching issue on mac, but I was able to see the issue with the dialog staying on top of other windows. We can try adding a focus loss listener and remove the always on top flag, but that flag may only matter during dialog creation.

[taylor.smock]

@gaben: Can you check and see if attachment:16485.patch​ fixes the issues you've seen on Windows? It worked for me on linux (for the dialog staying on top of other windows).

[gaben]

Sure, just a bit later today.

[gaben]

Yes, it fixes the issue on both Ubuntu and Windows. Thank you for working on it. I could only test this as my Java GUI knowledge converges to zero.

[taylor.smock]

In 18923/josm:

Fix #16485: Ensure windows lose always-on-top status when JOSM loses focus

Also fix some spotbugs/sonarlint issues.

[GerdP]

See #23396 for a possible regression

[skyper]

Ticket #23396 has been marked as a duplicate of this ticket.