fvwmorg / fvwm3

FVWM version 3 -- the successor to fvwm2
Other
495 stars 77 forks source link

Steam menus disappear when the mouse is hovered over #924

Open cysp74 opened 8 months ago

cysp74 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 7 months ago

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

https://github.com/fvwmorg/fvwm3/blob/1d1c2576384590ecc8ba88342127d8387ce01c7c/fvwm/events.c#L2401

https://github.com/fvwmorg/fvwm3/blob/1d1c2576384590ecc8ba88342127d8387ce01c7c/fvwm/events.c#L2413

cybersphinx commented 6 months ago

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

petergthatsme commented 5 months ago

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 commented 2 weeks ago

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 -> https://github.com/ValveSoftware/steam-for-linux/issues/11075

Athanasius commented 1 week ago

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

https://github.com/fvwmorg/fvwm3/blob/1d1c2576384590ecc8ba88342127d8387ce01c7c/fvwm/events.c#L2401

https://github.com/fvwmorg/fvwm3/blob/1d1c2576384590ecc8ba88342127d8387ce01c7c/fvwm/events.c#L2413

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 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

So, with ClickToFocus the two lines identified in https://github.com/fvwmorg/fvwm3/issues/924#issuecomment-1837409031 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 ?