Min-browser window still on top of other windows when i select a window

[ahmeteid7]

the window of that browser app is very odd, i don't know why it is still of top when i switch bw windows using skippy-xd. that is the props of the window of the app, i think it my be electron app:

xprop
_NET_WM_ICON_GEOMETRY(CARDINAL) = 362, 737, 31, 31
WM_STATE(WM_STATE):
        window state: Normal
        icon window: 0x5768bc00
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MOVE, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_STICK
_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 26, 0
_NET_WM_DESKTOP(CARDINAL) = 0
_NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_HORZ, _NET_WM_STATE_MAXIMIZED_VERT
_NET_WM_USER_TIME(CARDINAL) = 7400600
_NET_WM_ICON(CARDINAL) = 
WM_NORMAL_HINTS(WM_SIZE_HINTS):
        program specified location: 0, 26
        program specified minimum size: 320 by 350
        program specified maximum size: 2147483647 by 2147483647
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x1, 0x0, 0x0
XdndAware(ATOM) = BITMAP
_NET_WM_BYPASS_COMPOSITOR(CARDINAL) = 2
WM_NAME(UTF8_STRING) = "Min"
_NET_WM_NAME(UTF8_STRING) = "Min"
WM_WINDOW_ROLE(STRING) = "browser-window"
WM_CLASS(STRING) = "min", "Min"
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_PID(CARDINAL) = 2550
WM_CLIENT_MACHINE(STRING) = "eid-HP-Compaq-6005-Pro-SFF-PC"
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, _NET_WM_PING, _NET_WM_SYNC_REQUEST

[felixfung]

I installed min-browser just for you :)

I can reproduce the behaviour. When min-browser is NOT in focus to begin with, skippy-xd works fine. When min-browser IS in focus, skippy-xd will always focus back to min-browser, including paging mode; the only exception is quick alt-tab without window overviews appearing.

Most probably this is a bug in combination of min-browser and X11. I can tell you X11 is a *#^@ to work with...

I would recommend opening an issue with min-browser, looks like they are quite responsive?

[PalmerAL]

@felixfung Is there anything "special" about how skippy is focusing windows?

From https://github.com/minbrowser/min/issues/2419#issuecomment-2041796257, the issue only happens when a webpage is open in a tab. The page is loaded in a separate view; when the window gets focus, we delegate focus to that view: https://github.com/minbrowser/min/blob/master/js/webviews.js#L525-L529

Is that likely to cause any problems that you know of?

[felixfung]

I polished the code around focusing, but was not the original author.

The focus starts with raising the window: https://github.com/felixfung/skippy-xd/blob/a585ab2b6eb2e9d6b5ddf11eb6f634d1c87f4b90/src/clientwin.c#L642

and then sends _NET_ACTIVE_WINDOW https://github.com/felixfung/skippy-xd/blob/a585ab2b6eb2e9d6b5ddf11eb6f634d1c87f4b90/src/wm.h#L143

This looks like completely normal behaviour to me: https://specifications.freedesktop.org/wm-spec/1.3/ar01s03.html

I am suspecting that X11 is being &#@*, and this weird behaviour is due to complex timing issue with multiple focus events, and X in this scenario always finalizes focus on min-browser tab:

Skippy-xd creates/maps a fullscreen window which contains all the live preview windows. Upon window selection, the fullscreen window unmaps, and then sets _NET_ACTIVE_WINDOW to the selected window.

https://github.com/felixfung/skippy-xd/blob/a585ab2b6eb2e9d6b5ddf11eb6f634d1c87f4b90/src/skippy.c#L1042

I am suspecting that in between the unmapping of the fullscreen window, and the focusing of the new window, min-browser first obtains focus, which triggers the transferal of focus to the tab, which overrides the focusing according to skippy-xd.

This would explain why quick alt-tab would work in this scenario, because the fullscreen window is never triggered in this case.

We can test this hypothesis by commenting out the code that puts focus on the tab?

[felixfung]

I can partially confirm the hypothesis.

When I comment out this line, https://github.com/felixfung/skippy-xd/blob/a585ab2b6eb2e9d6b5ddf11eb6f634d1c87f4b90/src/skippy.c#L1035

After window selection, the fullscreen window would not unmap, but the focus will switch to the selected window. This holds true even when a min-browser tab was focused to begin with.

Let me know about your side of diagnosis and experimentation, and then we can come up with a solution?

[PalmerAL]

Are you able to comment out the lines I linked above, and run Min with the local development instructions: https://github.com/minbrowser/min?tab=readme-ov-file#developing ? I don't have a linux machine ATM, so I suspect that's easier than for me to set up a VM with skippy on it.

Assuming the lines above are the issue, I'm not sure what a solution would be. I assume the problem is that the focusing of the webcontents happens asynchronously after the window is focused, but I think we do need the check in those lines (document.activeElement.tagName !== 'INPUT'), which is necessarily going to involve a roundtrip from main content > UI subprocess > back to main process. We could probaby make that whole roundtrip synchronous, but I imagine that's going to be suboptimal in terms of performance.

[felixfung]

I have not yet tried compiling min-browser, but it looks like if I do not maximize min-browser, then skippy-xd works perfectly. @ahmeteid7 worth trying it out?

[felixfung]

...just tried again, and this trick stops working...

[felixfung]

Simply doing a sleep between fullscreen window unmapping and focusing selected window fixes the bug... but when min-browser is maximized, switching virtual desktop still does not work. Probably X specific focus quirk specific to maximized state. Any how, this is pretty much a confirmation of the race condition hypothesis.

[felixfung]

@ahmeteid7 you can try #91? For me it works, with the exception of when min-browser is maximized and paging is attempted

[felixfung]

@PalmerAL I thought about this a little bit: perhaps arguably the root cause of this issue is asynchrony? Arguably logically it should be synchronous, and asynchrony is only an optimization? And hopefully synchronicity wouldn't make an observable performance difference?

[felixfung]

Is anyone still interested in this issue?

[PalmerAL]

Oh, sorry for not replying. I think you're probably right that it would be better synchronous. Fixing it isn't really a priority for me though, since it's such an uncommon configuration. If someone wants to make a PR in Min and test it they're welcome to.

[felixfung]

I guess you can leave a note on https://github.com/minbrowser/min/issues/2419, meanwhile we can close this issue?