Opening a dialog does not always give it focus

[peparsons]

This might be related to issue #358 but I'm not sure so I hope you don't mind my raising it as a new issue.

Since I've started using a more recent version of icewm, I've found that there are problems with focus when a dialog is opened.

Version 1.3.12 works fine.
Version 1.4.2 exhibits this fault.
I've also tried version 1.6.2 which exhibits the same fault.

This is the problem:
When I do something in my application to open a new dialog, the dialog does not get focus as it should. If I click in a text box in it, the text box does not get focus, so I can't type in it.

Some more information:

1. When a dialog is not in focus, clicking the dialog's title bar give it focus correctly, so it then works as expected.
2. Most dialogs in my application exhibit this behaviour, but some don't. There's no apparent common factor to those which work correctly. There's even 1 dialog which can be opened from a menu (faulty) or from a button (not faulty).
3. It doesn't go wrong if there's another dialog open already, in addition to the main one.

Any help would be greatly appreciated.

[gijsbers]

Thank you for opening this issue! Maybe it is related, maybe not. That is not so important.
The main thing is to get it reproducable for us to work on.
So basically we need to configure a setup which is similar to yours
and repeat the steps you do to reproduce the problem.

1. So could you tell use your focus_mode ?
2. Do you succeed in repeating it for a Sloppy focus model?
3. Can you give us details which dialogs of which applications?
4. Maybe some preferences settings?
   You can get the default settings by:
   icewm -c /dev/null --postpreferences > /tmp/1
   and your own by:
   icewm --postpreferences > /tmp/2
   and compare them with:
   diff -U 1 /tmp/1 /tmp/2
   and then tell us those which are relevant for focusing and application appearance.
   This may be empty actually.

[peparsons]

Thanks for the responding so quickly.

I've used the default focus options, so it's click to focus.
When I changed it to sloppy focus, the problem went away.
I can see why reproducing the problem is important, but the Motif application I'm using is a complex engineering tool which I can't share with you.
I did what you asked me to do, but I don't think the results are much help. Sorry the formatting is a bit wacky below. (I'm not sure what is being interpreted in a weird way.)

diff /tmp/1 /tmp/2
87c87
< TaskBarShowMailboxStatus=1

TaskBarShowMailboxStatus=0
102c102
< TaskBarShowCPUStatus=1

---

TaskBarShowCPUStatus=0
108,109c108,109
< TaskBarShowMEMStatus=1
< TaskBarShowNetStatus=1

---

TaskBarShowMEMStatus=0
TaskBarShowNetStatus=0

[gijsbers]

Okay, this is useful. It seems dependent on Click-to-focus.

So one hint might be that it requires Motif (or some older GUI-library?).

If you run xprop on the dialog, does it give you properties for:
WM_CLIENT_LEADER, WM_TRANSIENT_FOR, WM_HINTS, WM_NORMAL_HINTS, WM_STATE, _WIN_LAYER, and any MOTIF hints, but not the raw data ones.

What does icesh motif on the dialog give?

All other applications which have dialogs have no such problem?

[bbidulock]

Icewm does not properly handle ICCCM 2.0 modality: neither global nor application-wide modality. Motif often uses modality for application dialogs and expects proper behaviour from the window manager (because both MWM and DTWM support ICCCM 2.0 modality properly). Recent (and by recent, I mean around the time that Icewm was originally written) applications avoid the use of modality altogether.

When an application-wide modal dialog window is opened, and the keyboard focus is on another application window, focus must be changed to the dialog window to observe modality, regardless of click-to-focus. These are the rules of application-wide modality. Icewm is not following them. When you set sloppy focus, and the dialog window happens to be under the pointer, it gets focus, but not because Icewm is properly observing modality in this case. It is not. In this case still you may observe a difference between dialogs launched by mouse clicks and those launched by accelerator key strokes, simply because of the location of the pointer.

Some Motif dialogs in your application are likely not modal; some are. Some may be application-wide modal and other globally modal. For those that are not modal, the application is likely transferring focus on its own to the dialog window from the previous application window.

I'm sorry, but I think that the only way to fix your problem would be to make Icewm ICCCM 2.0 compliant with regard to modality. This effort would likely only benefit a Motif application.

[bbidulock]

Icewm ICCCM 2.0 focus model handling has been, at best, heuristic. The 1.3.12 release was similar to earlier 1.3 branch releases, but also included corrections for full ICCCM 2.0 focus model handling. It appears that various tweaks have broken that too. Even with 1.3.12, the focus behaviour was hokey and annoying in specific situations and cases, especially when compared to other light-weight window managers: blackbox, fluxbox, and ultra-compliant openbox. So, I will call this a bug, but I don't know if it can be fixed.

[bbidulock]

Ice look through a window's transients to determine whether the window can be focused. If one of its transients is modal (even through settings in _MOTIF_WM_HINTS), it considers the window unfocusable. However, only ModalPrimary applies to dialogs that are transient for another toplevel window. The two other modalities: ModalGroup and ModalSystem have a transient of None or Root (for ModalGroup) but do have a group leader, or has no transient for at all (for ModalSystem). ModalGroup has a group leader for which it is modal and a transient for set to None or Root. Ice is not checking this. hasModal() should check the type of modality when searching transients, and should also search windows that share the same groups leader for ModalGroup modality. It should also check if any visible window has ModalSystem set. There is a note at line 2406 in wmframe.cc stating that application modality is not handled (ModalGroup). But then, ModalSystem is not handled either. 1.3.12 largely focused all new windows, so that lack of modality handling is masked when the window first appears; however, it would not stop clicking another window in the group (or any other window) and transferring focus when the ModalGroup (or ModalSystem) dialog is still visible.

So, maybe this is both a bug and an enhancement.

[peparsons]

I appreciate the time you've taken to explain all this to me. The application which has this issue has nearly 400 dialogs and was written over 20 years ago - but is, nevertheless, important to the clients.

I know that some dialogs are application modal, but most are not modal.

If it's OK with you, I'll leave this issue open in case there's a time in the future when something changes?

[gijsbers]

OK. It would be interesting to see the output of icesh motif on the dialogs that need improvement.

[peparsons]

OK. It would be interesting to see the output of icesh motif on the dialogs that need improvement.

icesh is new to me. I'm going to need some guidance to get this right, please. I've tried this:
icesh motif
The mouse cursor changes to a cross and I can click in a rogue dialog (one which should have focus but doesn't) and the output is below:

0xc00318 motif: input
input: modeless

[gijsbers]

Thank you. That is interesting, since it shows that modality is not at heart of this problem.

[lersek]

(coming from ice-wm/icewm#110)

In my case, icesh motif reports, on the xnedit Find dialog:

0x18001c2 motif: input
          input: modeless

[lersek]

I don't know if I've just found a new (very reproducible) symptom for the same root cause, or a new issue (please advise -- in the latter case I'm going to file a new ticket).

• have Thunderbird open on workspace#1
• have Firefox open on workspace#2 (and no other workspace)
• click a link in an email in Thunderbird

With IceWM 1.3.7 and 1.3.8, a new tab would open in Firefox (loading the just-clicked link) and the active workspace would switch from workspace#1 to workspace#2, and the Firefox window on workspace#2 would get focus. With 3.2.3, the new tab is opened in Firefox alright, but the active workspace remains workspace#1, so clicking the link has no visible results (beyond the link changing color in Thunderbird, perhaps).

If this is intentional behavior, then apologies for the noise -- does a new preference exist that can restore the earlier behavior? Thank you.

[gijsbers]

This issue is about dialogs: temporary windows of an application which support the main window(s). It looks like this issue has been fixed by commit 83c0c4c. @peparsons Could you confirm?
@lersek Because you report about the communication between two different applications, it cannot be about dialogs. I tried to reproduce your new problem as follows. Install the latest firefox and thunderbird. Have thunderbird on W 1 and firefox on W 2 as the only applications. Move my ~/.icewm out of the way. Restart icewm 3.3.0 and click on a link in thunderbird. It always opens in firefox. Hence it seems to work as expected.

[lersek]

IceWM 3.3.0 fixes the original focus problem reported in this ticket for me. Thank you.

[lersek]

With thunderbird 102.6.0, firefox 102.6.0, and icewm 3.3.0, my "link opening" problem is gone as well.