Steam menus disappear when the mouse is hovered over

[cysp74]

See the title of the bug (impacted menu entries are placed into window's title (?), i.e. "Steam", "View", "Friends", etc.).
When you click on a menu entry, try to hover over the menu and the menu disappears.

Under different wms steam works fine (pekwm, icewm, openbox).
As I recon this was bug intro'd this year (2023), however, I haven't put any effort into identifying which commit causes this yet

The issue also exists with the default config file.

Version:
fvwm3 1.0.9 (1.0.8-21-gd47b2ba9)

Distro:
Arch Linux

Log entries:
[1699898174.621710]  log opened (because of SIGUSR2)
[1699898185.029678] setup_window_placement: Expanding screen from 'null' -> ''
[1699898185.138140] setup_window_placement: Expanding screen from 'null' -> ''
[1699898321.173708] setup_window_placement: Expanding screen from 'null' -> ''

FVWM doesn't crash during this issue

[somiaj]

My guess is this is related to #761 (I think steam uses electron). Fvwm has currently chosen to not create work around for this behavior, even though other wms have. I don't know the details well enough to know what workaround fvwm would need to deal with these behaviors of menus from chromium/electron apps.

[cysp74]

My guess is this is related to #761 (I think steam uses electron). Fvwm has currently chosen to not create work around for this behavior, even though other wms have. I don't know the details well enough to know what workaround fvwm would need to deal with these behaviors of menus from chromium/electron apps.

Of course, if I switch steam to unmanaged (Style steam Unmanaged) the issue is gone.

So, by common sense, if

1. Other wms can handle this (I have to stress, openbox can handle also, however it's not actively developed for years),
2. Steam with unmanaged option (at fvwm side takes steam out of fvwm control) can receive proper events,

Then fvwm can have a solution eg. a reworked logic, not a quasi workaround.
-- Alas, I quite unfamiliar with fvwm code yet.

[xuzhen]

I noticed that when the menu disappears, the output of the xev command contains a strange pair of FocusIn/FocusOut events after the EnterNotify event. This is not seen when Steam is running with openbox.

EnterNotify event, serial 18, synthetic NO, window 0x3a00010,
    root 0x6cb, subw 0x0, time 14989009, (60,32), root:(1070,233),
    mode NotifyNormal, detail NotifyInferior, same_screen YES,
    focus NO, state 0

KeymapNotify event, serial 18, synthetic NO, window 0x0,
    keys:  4294967243 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

FocusIn event, serial 18, synthetic NO, window 0x3a00010,
    mode NotifyNormal, detail NotifyNonlinear

KeymapNotify event, serial 18, synthetic NO, window 0x0,
    keys:  4294967243 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

FocusOut event, serial 18, synthetic NO, window 0x3a00010,
    mode NotifyNormal, detail NotifyInferior

After doing some debugging, I found that removing these two lines stopped the menu from disappearing

fvwm3/fvwm/events.c

Line 2401 in 1d1c257

focus_force_refresh_focus(fw);

fvwm3/fvwm/events.c

Line 2413 in 1d1c257

_refocus_stolen_focus_win(ea);

[cybersphinx]

fvwm 2.6.x seems to behave the same, so it might be an old problem.

[petergthatsme]

this is definitely an issue in 2.6x. I've had this for a long time now; menus are broken in steam, and on some websites in various browsers. Possibly also related: there is a problem in getting the 'cast' menu to show up in chrome/chromium (i think i put in an issue about it before at some stage).
The update (to what i think is) equivalent to what @xuzhen shown above, but in 2.6x, does not seem to work for me - but perhaps there are more things that need to be commented out - i just haven't had a chance to experiment enough. If anyone finds a fix the 2.6x, please share.

edit: here is a (potentially-related) issue with getting the 'cast' menu to show up in chrome/chromium:
https://www.mail-archive.com/fvwm-workers@fvwm.org/msg04873.html

[Athanasius]

So, given a 'fix' was identified above for fvwm3, has anyone checked into side effects of that ? If there are such then would this be amenable to an extra user configuration option?

It's affecting me with fvwm3 v1.1.0 and latest Steam client -> ValveSoftware/steam-for-linux#11075

[Athanasius]

After doing some debugging, I found that removing these two lines stopped the menu from disappearing

fvwm3/fvwm/events.c

Line 2401 in 1d1c257

focus_force_refresh_focus(fw);

fvwm3/fvwm/events.c

Line 2413 in 1d1c257

_refocus_stolen_focus_win(ea);

Unfortunately this doesn't appear to address the issue for me when using Style * SloppyFocus. If I change to Style * ClickToFocus the fix does work. I added some fvwm_debug() calls as well and see:

[1720872371.089072] HandleEnterNotify: [fvwm][events] Would call focus_force_refresh_focus(fw);
[1720872371.089100] HandleEnterNotify: [fvwm][events] Would call _refocus_stolen_focus_win(ea);

just as my mouse pointer moves off Help (no longer highlighted) and to the space between that text and the popup menu. So those calls do indeed seem to be implicated.

Now to see if any of the similar calls affect the SloppyFocus scenario.

[Athanasius]

Oh, I and I should note that I can have my focus configuration in total be:

# Use SloppyFocus by default
Style * SloppyFocus
# But ClickToFocus for Steam
Style Steam ClickToFocus
Style steam ClickToFocus
Style steamwebhelper ClickToFocus

and this code tweak continues to allow the Steam menus to work. The second line (Store etc) menus also continue to work, as does the top-right profile dropdown menu.

[Athanasius]

I instrumented all of the calls to _refocus_stolen_focus_win() or focus_force_refresh_focus() with a line like:

fvwm_debug(__func__, "[fvwm][events][%d] Would call _refocus_stolen_focus_win(ea);\n", __LINE__);

(with focus_force_refresh_focus instead of _refocus_stolen_focus_win where applicable).

events.c:3741 called during Firefox startup (multiple windows). This is https://github.com/fvwmorg/fvwm3/blob/1.1.0/fvwm/events.c#L3731

No such call for any of the instrumented code sections with SloppyFocus (all windows) when the Help menu disappears before the pointer can enter it. So, for SloppyFocus the issue lies elsewhere.

[Athanasius]

OK, I've found a call that affects the SloppyFocus scenario at https://github.com/fvwmorg/fvwm3/blob/1.1.0/fvwm/events.c#L2399

If I comment this out than the Steam menus work properly even with SloppyFocus active.

Edit: No, snd.gui-pulse continues to work fine. I'd misremembered the name of the directory I was trying to get into, and there's no feedback if you attempt this with a non-existent one.

Ignore what follows:

---

However this does appear to adversely affect some Motif application functionality. Specifically I installed the Debian package snd-gui-pulse which provides a snd.gui-pulse executable for examining and editing sound files (supports at least .wav files). In its File > Open dialogue focus appears to not work properly for the top line where you can edit the current file system location. You can edit, but pressing return afterwards has no effect, when it does with that SetFocusWindow() call in effect.

Using FVWM's Identify it looks like this 'Open' dialogue is wholly its own top-level window. This from clicking in the affected "file system location" text box:

Name: Open
Icon Name: Open
Class: Snd
Resource: Open_popup
...
NoTitle: Yes
Iconified: No
Transient: Yes
WindowListSkip: No
...
Focus Policy: Passive
- Input Field: True
- WM_TAKE_FOCUS: Absent

Hmmm, let me try with this line commented out, but the "original two" still in effect, given at least one comment around those mentions Motif (which is why I was checking this at all).

[Athanasius]

So, with ClickToFocus the two lines identified in #924 (comment) being remove are sufficient to have Steam menus work.

But with SloppyFocus you also need to remove https://github.com/fvwmorg/fvwm3/blob/1.1.0/fvwm/events.c?rgh-link-date=2024-07-13T12%3A58%3A25Z#L2399

The single Motif application I tested appears to work properly despite this functionality being removed.

Looking at the code and comments, a lot of this stuff is very old. How sure is anyone that much of this code is still needed, especially when marked as a workaround for specific decades old issues ?

[ch-f]

@Athanasius thank you for debugging. I encountered similar issues with some Java programs and SloppyFocus. Removing that old Motif hack finally resolved the problem.

@ThomasAdam could we consider removing that old Motif hack or at least making it optional?

[ThomasAdam]

It's on my list to look at.

[Athanasius]

I was just going to submit a PR with my changes, and thought to check one last time if this was still actually an issue with main. It's not. I just built using fd67bc261b22094321830fe4e31a55dc101ee39e, and without my changes, and it's simply working.

Either other changes in fvwm3 since have fixed it, or something Steam has changed has addressed this.

[ch-f]

I'm still experiencing this issue with some Java applications like Maple. On fvwm2 I can also fix this with your changes.

[ThomasAdam]

@ch-f Do you see it with Libreoffice?

[ch-f]

I don't use Libreoffice often and haven't seen an issue there.

[ThomasAdam]

OK,

Well, the original patch is not correct and I'm not applying it.

What I need is an application which isn't Steam, to be able to debug this myself.

[Athanasius]

@ch-f Do you see it with Libreoffice?

LibreOffice 7.4.7.2 (as packaged in Debian bookworm) doesn't show any menu issues for me. Main menus work, including their popouts, and the popouts on things like text styling or colour also work without issues.

At this stage, with Steam no longer exhibiting the issue, I don't know of an app that does exhibit the issue. I have to assume that, despite initially dismissing this as a WM issue, Steam developers did change something their end.

But, separately, perhaps it's still true that some of the very old hacks related to Motif and the like are no longer necessary ? i.e. if any Motif app continues to work without those hacks perhaps they should be removed.