Modify

Opened 6 years ago

Closed 6 months ago

Last modified 5 months ago

#16485 closed defect (fixed)

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

Reported by: ris Owned by: team
Priority: normal Milestone: 23.12
Component: Core Version: tested
Keywords: oauth error dialog focus Cc:

Description

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.

Attachments (2)

Screenshot 2023-09-26 at 8.18.10 AM.png (1.2 MB ) - added by taylor.smock 9 months ago.
Blocking server-side conflict dialog behind Tags/Memberships toggle dialog
16485.patch (9.0 KB ) - added by taylor.smock 6 months ago.

Download all attachments as: .zip

Change History (27)

comment:1 by gaben, 2 years ago

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

comment:2 by gaben, 23 months ago

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

comment:3 by taylor.smock, 9 months ago

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

comment:4 by taylor.smock, 9 months ago

Milestone: 23.10

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

    diff --git a/src/org/openstreetmap/josm/gui/ConditionalOptionPaneUtil.java b/src/org/openstreetmap/josm/gui/ConditionalOptionPaneUtil.java
    a b  
    283286                add(cbShowImmediateDialog, GBC.eol());
    284287            }
    285288            add(cbStandard, GBC.eol());
     289
     290            this.addAncestorListener(new AncestorListener() {
     291                @Override
     292                public void ancestorAdded(AncestorEvent event) {
     293                    if (event.getAncestor() instanceof Dialog) {
     294                        Dialog dialog = (Dialog) event.getAncestor();
     295                        if (dialog.isVisible() && dialog.isModal()) {
     296                            dialog.setAlwaysOnTop(true);
     297                        }
     298                    }
     299                }
     300            });
    286301        }
    287302
    288303        NotShowAgain getNotShowAgain() {
  • src/org/openstreetmap/josm/gui/ExtendedDialog.java

    diff --git a/src/org/openstreetmap/josm/gui/ExtendedDialog.java b/src/org/openstreetmap/josm/gui/ExtendedDialog.java
    a b  
    459459                rememberWindowGeometry(new WindowGeometry(this));
    460460            }
    461461        }
     462        if (visible && isModal()) {
     463            this.setAlwaysOnTop(true);
     464        }
    462465        super.setVisible(visible);
    463466
    464467        if (!visible && disposeOnClose) {
  • src/org/openstreetmap/josm/gui/HelpAwareOptionPane.java

    diff --git a/src/org/openstreetmap/josm/gui/HelpAwareOptionPane.java b/src/org/openstreetmap/josm/gui/HelpAwareOptionPane.java
    a b  
    350350        if (helpTopic != null) {
    351351            HelpUtil.setHelpContext(dialog.getRootPane(), helpTopic);
    352352        }
     353        if (dialog.isModal()) {
     354            dialog.setAlwaysOnTop(true);
     355        }
    353356        dialog.setVisible(true);
    354357    }
    355358

Potential upstream bugs:

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.

comment:5 by taylor.smock, 9 months ago

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

comment:6 by stoecker, 9 months ago

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

comment:7 by taylor.smock, 9 months ago

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.

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

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.

Last edited 9 months ago by taylor.smock (previous) (diff)

by taylor.smock, 9 months ago

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

in reply to:  7 comment:8 by stoecker, 9 months ago

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.

comment:9 by taylor.smock, 9 months ago

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.

comment:10 by taylor.smock, 8 months ago

Resolution: fixed
Status: newclosed

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.

comment:11 by taylor.smock, 7 months ago

Milestone: 23.1023.11

Ticket retargeted after milestone deleted

comment:12 by gaben, 7 months ago

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

comment:13 by gaben, 7 months ago

Resolution: fixed
Status: closedreopened

I'm reopening due to issues on Windows.

comment:14 by taylor.smock, 7 months ago

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

comment:15 by gaben, 7 months ago

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

comment:16 by gaben, 6 months ago

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.

comment:17 by taylor.smock, 6 months ago

Milestone: 23.11

Ticket retargeted after milestone closed

comment:18 by taylor.smock, 6 months ago

Milestone: 23.12

comment:19 by taylor.smock, 6 months ago

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.

by taylor.smock, 6 months ago

Attachment: 16485.patch added

comment:20 by taylor.smock, 6 months ago

@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).

comment:21 by gaben, 6 months ago

Sure, just a bit later today.

in reply to:  20 comment:22 by gaben, 6 months ago

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.

comment:23 by taylor.smock, 6 months ago

Resolution: fixed
Status: reopenedclosed

In 18923/josm:

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

Also fix some spotbugs/sonarlint issues.

comment:24 by GerdP, 5 months ago

See #23396 for a possible regression

comment:25 by skyper, 5 months ago

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.