hkjels
commented
1 year ago This is extremely annoying and in my case slightly worse, as there's nothing in the taskbar, so there's no way to get back to the application although it is running.
Open krzysz00 opened 1 year ago
hkjels
commented
1 year ago This is extremely annoying and in my case slightly worse, as there's nothing in the taskbar, so there's no way to get back to the application although it is running.
krzysz00
commented
1 year ago I can collect more logs if folks think that'd be helpful
hideyukn88
commented
1 year ago @krzysz00, would you please share the log from /mnt/wslg with extended logging enabled with below wslg configuration? You will need to restart WSL after below file is placed. Also, would you please try 1: double click title bar and 2) press Windows key + Up arrow key, does maximize work with this method? thanks!
c:\Users\[your Windows's user name]\.wslgconfig
[system-distro-env]
WESTON_RDP_DEBUG_LEVEL=5Sorry for the late reply, here's weston.log with the debug level at 5. Both maximization methods had the same result, and the first window is the [win]+Up version.
reuben-tonna-ixaris
commented
1 year ago We are seeing a similar issue on Windows 11 with wsl2 on a multiple monitor setup
At this point clicking on the task bar icon does not re-open the window even though chrome is still running. Double clicking, Ctrl+upKey does not open it either.
This happens on any UI.
Any pointers how we can work around this problem please.
melvinmicallef
commented
1 year ago I am also encountering this issue with Windows 11 using wsl2. I have 3 monitors in total (laptop screen + another 2).
Opening any GUI window (such as chrome) and minimizing it and maximizing without changing its monitor location works fine. The issue occurs when you move it to a different monitor, maximize the window and then minimize it.
markhc
commented
1 year ago Same issue here. Don't even need to move to another monitor. Strangely, this happens to me with terminator but not with Wireshark (the only 2 GUI apps I use from WSL).
If I maximize and then minimize window, I cannot get back into it no matter what. Only solution is to close it from the taskbar or Ctrl+C the application from the command line.
$ wsl --version
WSL version: 1.2.5.0
Kernel version: 5.15.90.1
WSLg version: 1.0.51
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22621.1848Here are the log files
heartnheart
commented
12 months ago I encountered the same issue when I updated to WSL 1.2.5.0 using the command wsl --update. Every time I maximize Emacs (either by pressing the Win-Up key or clicking the maximize button), it disappears.
Previously, I was using WSL 1.1.3.0, which didn't have this problem. As a temporary workaround, I downgraded to version 1.1.3.0 by installing the file Microsoft.WSL_1.1.3.0_x64_ARM64.msixbundle.
hideyukn88
commented
12 months ago @heartnheart, does it repro consistently on your end? If you don't mind, would you please share /mnt/wslg/weston.log after the window disappeared? I did same at my end with emacs-gtk (both in X11 and Wayland native), I couldn't observe the issue, thanks!
hideyukn88
commented
12 months ago @markhc, thanks for reporting the issue,
Strangely, this happens to me with terminator
Do you mean https://github.com/gnome-terminator/terminator ? thanks!
markhc
commented
11 months ago Do you mean https://github.com/gnome-terminator/terminator ? thanks!
Yes, that's the one.
hideyukn88
commented
11 months ago @markhc, thanks, at my environment, Win+Up to maximizing window, then Win+Down to restore to the original size, both works fine. Just for reference, does it occur in both X11 and Wayland mode? thanks!
markhc
commented
11 months ago does it occur in both X11 and Wayland mode?
@hideyukn88 How would I switch between X11 and Wayland? Sorry, i am not very familiar with Linux display servers.
hideyukn88
commented
11 months ago @markhc, you can use GDK_BACKEND=x11 or Wayland, thanks!
heartnheart
commented
11 months ago @heartnheart, does it repro consistently on your end? If you don't mind, would you please share /mnt/wslg/weston.log after the window disappeared? I did same at my end with emacs-gtk (both in X11 and Wayland native), I couldn't observe the issue, thanks!
Sorry for the late reply.
The content of /mnt/wslg/weston.log does not change (with tail -f /mnt/wslg/weston.log) when I use Win+UP key to maximize Emacs (so it disappears), and then use Win+Down to restore (so it appears again).
BTW, I have two monitors configured as
Emacs is built from source code
(emacs-version)
"GNU Emacs 30.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, cairo version 1.16.0)
of 2023-06-07"
emacs-repository-branch
"master"
emacs-repository-version
"f68d962ede0cc3d7758d3304e7411a10694acce8"
system-configuration
"x86_64-pc-linux-gnu"
system-configuration-options
"'--program-transform=s/^ctags$/ctags.emacs/'"
system-configuration-features
"CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LIBOTF LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB"
@heartnheart, thanks for info. I configured my local environment as close as yours, but still not enable to reproduce the issue. I have a few additional questions.
1: Do you run Windows 10 or 11?
2: I see you have secondary monitor at negative coordinate (toward upper left of primary monitor), if this monitor is disabled, does it help? If it helps, if the monitor is moved to positive coordinate space, does it help?
3: I imagine the emacs at your end is running as Wayland mode (you can double check by xwininfo -root -tree, if emacs doesn't show up here, it's running in Wayland mode), if it's changed to X11 mode, does it help?
4: at last, if you can update WSL to pre-release version by wsl --update --pre-release, does it help?
Thanks!
krzysz00
commented
11 months ago For what it's worth, I have a secondary monitor in a negative position (off to the left).
heartnheart
commented
11 months ago @heartnheart, thanks for info. I configured my local environment as close as yours, but still not enable to reproduce the issue. I have a few additional questions.
1: Do you run Windows 10 or 11? 2: I see you have secondary monitor at negative coordinate (toward upper left of primary monitor), if this monitor is disabled, does it help? If it helps, if the monitor is moved to positive coordinate space, does it help? 3: I imagine the emacs at your end is running as Wayland mode (you can double check by
xwininfo -root -tree, if emacs doesn't show up here, it's running in Wayland mode), if it's changed to X11 mode, does it help? 4: at last, if you can update WSL to pre-release version bywsl --update --pre-release, does it help?Thanks!
@hideyukn88
Updating to prelease version with 1.3.14.0_x64_ARM64.msixbundle does not help
xwininfo: Window id: 0x22e (the root window) (has no name)
Root window id: 0x22e (the root window) (has no name)
Parent window id: 0x0 (none)
7 children:
0x200033 (has no name): () 828x811+858+1823 +858+1823
1 child:
0x600140 "*scratch* - GNU Emacs at monday": ("emacs" "Emacs") 752x714+38+59 +896+1882
2 children:
0x600144 (has no name): () 752x648+0+66 +896+1948
2 children:
0x600195 (has no name): () 1x1+-1+-1 +895+1947
0x600193 (has no name): () 16x612+736+0 +1632+1948
0x600141 (has no name): () 1x1+-1+-1 +895+1881
0x60014d (has no name): () 1x1+-1+-1 +-1+-1
0x600015 (has no name): () 1x1+-1+-1 +-1+-1
0x600001 "emacs": ("emacs" "Emacs") 10x10+10+10 +10+10
0x200027 "Weston WM": () 10x10+0+0 +0+0
0x200002 (has no name): () 8192x8192+0+0 +0+0
0x200001 (has no name): () 10x10+0+0 +0+0For what it's worth, I have a secondary monitor in a negative position (off to the left).
I finally got it to work correctly by changing my secondary monitor to be the one to the right. If I set it off to the left the issue starts again.
Tried the other potential solutions but none helped, including updating WSL to pre-release.
hideyukn88
commented
11 months ago @markhc, @krzysz00, do you happen to have access to Spy++ utility came with Visual Studio? If so, please run the tool and locate the "disappeared" WSL window in the tool, and capture the screenshot of Windows Properties dialog box"? Since this case, the window in question is not visible, so I think it's not possible to locate it by using its finder tool, but the window should be in the window tree view, so it still should be able locate it by window title. I have analyzed the detail log provided by @krzysz00, but it looks doing right, so I would like to see the state of the window at Windows's side, thank you very much for helping us!
https://learn.microsoft.com/en-us/visualstudio/debugger/using-spy-increment?view=vs-2022 https://learn.microsoft.com/en-us/visualstudio/debugger/window-properties-dialog-box?view=vs-2022
markhc
commented
11 months ago @hideyukn88 Sure thing, here you go. The images are after I minimize it and try to maximize it again (when it disappears). But the properties, as far as I can tell, are the same as when the Window is maximized and working correctly.
hideyukn88
commented
11 months ago @markhc, thanks for screenshot, it looks the window should be visible. Please allow me to verify what "disappear" means here. For example, how its "input" works, say mouse? Let's say the window is maximized and at foreground, but not visually visible, then mouse click still should be captured by the invisible maximized window, not by the other window behind. Is this the case? Or actually the window behind gets the mouse click? thanks!
markhc
commented
11 months ago Let's say the window is maximized and at foreground, but not visually visible, then mouse click still should be captured by the invisible maximized window, not by the other window behind. Is this the case?
This is NOT the case. The input goes to the window that should be "behind" it.
I made a quick video displaying the behavior https://www.youtube.com/watch?v=LURBXBIuKGs
Incidentally, I just now realized that I can get the window back to being visible with Win + Arrow Down. Seems to be the only way that works.
To state the behavior again:
kshartman
commented
11 months ago I can confirm the same behavior. And THANKS for noting that Win+Down brings it back. A pain but at least I can get it back. The only way I have found to safely maximize/minimize the emacs editor since this bug started is to use the F11 key.
hideyukn88
commented
11 months ago @markhc, thanks for detail analysis and videos.
Maximizing the window (through any means) and then minimizing it -> window disappears and cannot be brought back using the tarkbar or alt tab
For minimize, there is several ways to minimize, such as title bar button, Win+Down, or taskbar icon, do all method still end up same results? thanks!
hideyukn88
commented
11 months ago @markhc, have you had a chance to run some app in Wayland mode? easy example would be gedit. In most distro under WSL, gedit run as Wayland mode by default. While 'gedit' in Wayland mode doesn't have minimize and maximize button on title bar (it has only close button, refer below screenshot comparison), but it can be maximized by Win+Up or double-clicking title bar area, thanks!
With Ubuntu 20.04,
[Wayland mode]
[X11 mode - $ GDK_BACKEND=x11 gedit]
kshartman
commented
10 months ago Any news on this? It is really annoying. Also I can tell you that gedit running in wayland mode does the same thing. If I double click the title bar to maximize the window "disappears" and you cannot get back to it with alt-tab. The only thing that works is to click the icon in the windows task bar and then use Win+Down. There is no difference in behavior between
gedit
and
GDK_BACKEND=x11 gedit
other than in the latter case I do get the min and max button. Using the max button has the same behavior as double clicking the title bar (window "disappears").
kshartman
commented
10 months ago A little more info. I downloaded the emacs 29.1 tarball and configured and compiled it to use the old athena x toolkit (xaw) instead of gtk. Ugly but it works. The maximize/minimize buttons mostly work as expected as does title bar click and F11 key. If I configure and compile it with gtk3 support it still exhibits the behavior described above (as does gedit) regardless of wayland or X backend. So it must be something in wslg handling of gtk3 apps is my bet (and multiple monitors appears to be a factor, see below).
One wierdness for non-GTK build (xaw): the win-up key always makes the emacs window disappear. win-down is the only way to get it back as described above. This happens ONLY when I have two monitors side by side. If I disable the second monitor then win-up does NOT make the window disappear - it maximizes as expected.
MamiyaOtaru
commented
10 months ago konsole (kde) window: maximise using titlebar button. Minimize with titlebar button. Konsole window restores, and can't be interacted with. If another WSL app is open, mousing over the Konsole window changes the cursor as though I am resizing the other WSL app. Can't interact with the Konsole window until I click it in the taskbar (twice, to minimise then restore), then it is fine.
BUT if I maximise Konsole (titlebar button) then minimize it by clicking it in the taskbar, it goes away and can only be brought back with win+down
Termit window (gtk): after maximising (titlebar button), minimising works both by clicking the taskbar and by clicking minimise in the titlebar (the latter unlike Konsole). But then it too is gone until I press win+down.
This happens on my main (laptop, a Surface) window. The external monitors to either side do not exhibit the disappearing behavior, though maximised Konsole still has the same bug where pressing minimise (titlebar) restores the window but leaves itg unable to be interacted with until minimising/restoring it with the taskbar.
edit Konsole's additional weirdness with restoring from a maximised state when pressing (titlebar) minimize is with wayland. With x11 it does minimize properly (and can't be brought back without win+down). So the KDE+Wayland Konsole but with restoring when using the titlebar minimise button while maximised seems a separate issue
hideyukn88
commented
10 months ago Thanks for everyone who provided valuable information and especially @markhc for YouTube video! I think I figured out, at least, one scenario can end up window to be disappeared. Below is privately build system-distro VHD and you can apply this using .wslconfig, refer this link. This will not mess any your current configuration; you can simply go back your original configuration by removing system-distro override setting in .wslconfig. Please try out this private VHD, and let me know if it helps or not, thanks all for helping us!
MamiyaOtaru
commented
10 months ago that fixes it for me. Both the disappearing bug and the semi-related one where Konsole bugged out when pressing minimize
sorend
commented
9 months ago I also have the problem with Emacs. If I start another Emacs up, then the first Emacs window re-appears in the windows taskbar. (and I can just close the extra Emacs and continue to work with the one that was missing)
deadcombo
commented
8 months ago This issue persists on WSLg 1.0.58. I experience this with Emacs as well, in the same manner as the poster above me.
EDIT: A reliable way to bring back the window is to run wslg emacs -q. The new window will bring the old one with it, then you can close the -q window. -q is used for speed as it does not load configuration.
hideyukn88
commented
8 months ago @sorend, @deadcombo, is the behavior specific to emacs? is the emacs running in X11 mode or Wayland mode? And do you have multiple monitors? If so, what is the monitor layout configuration? I have emacs running on Ubuntu 20.04 installed by emacs-gtk package, and I could not reproduce the issue, thanks!
deadcombo
commented
8 months ago @hideyukn88 Emacs is the sole graphical program I use, I cannot say.
Show only on 2toggle-frame-fullscreen to be rid of the white frame decoration. I then use Win+Arrows to snap the fullscreen frame as needed. However, I've confirmed that a non-maximized window will also disappear eventually.
dslinger-a2
commented
8 months ago @heartnheart, thanks for info. I configured my local environment as close as yours, but still not enable to reproduce the issue. I have a few additional questions.
1: Do you run Windows 10 or 11? 2: I see you have secondary monitor at negative coordinate (toward upper left of primary monitor), if this monitor is disabled, does it help? If it helps, if the monitor is moved to positive coordinate space, does it help? 3: I imagine the emacs at your end is running as Wayland mode (you can double check by
xwininfo -root -tree, if emacs doesn't show up here, it's running in Wayland mode), if it's changed to X11 mode, does it help? 4: at last, if you can update WSL to pre-release version bywsl --update --pre-release, does it help?Thanks!
Using the pre-release fixed this issue for me!
sorend
commented
7 months ago @sorend, @deadcombo, is the behavior specific to emacs? is the emacs running in X11 mode or Wayland mode? And do you have multiple monitors? If so, what is the monitor layout configuration? I have emacs running on Ubuntu 20.04 installed by
emacs-gtkpackage, and I could not reproduce the issue, thanks!
@hideyukn88 It happens on Emacs and IntelliJ (so far the only graphical programs I use on wsl).
mohanr
commented
7 months ago Mine is a laptop with Windows 11/ Wsl. Emacs windows vanishes randomly.
jpmartin1
commented
7 months ago I'm seeing this behavior with intellij on wsl (Ubuntu 22.04.2 LTS) on Windows 11 Pro 22H2. Generally mostly notice windows sometimes disappear if I leave and come back, but I've had it happen while I'm actively using the machine but the wsl windows are in the background as I'm doing other things.
@sorend As a workaround for intellij at least I have found that I can get it to reappear by getting intellij to open a new window. E.g. if I run intellij-idea-ultimate . on the command line, I get intellij's "would you like to open this in this window or a new window" popup and the main window reappears as well (and I can just cancel on the dialog).
sorend
commented
7 months ago @jpmartin1 yes it's easy to get them back. You can also start any lightweight graphical program, e.g. starting xterm brings all the missing back. Still annoying that they disappear :-)
dants
commented
6 months ago @sorend
If I start another Emacs up, then the first Emacs window re-appears in the windows taskbar.
Thanks for the workaround, it does the job for me as well.
xianbang2021
commented
6 months ago Hi, all, I am not sure if anybody here meet the same problem as below. After I brought back the first Emacs window after start another emacs up, I can't interact with the first Emacs with cursor or keyboard.
xianbang2021
commented
6 months ago additional information: other GUI app has same behaviour. e.g. Tilix
kierke-gaard
commented
6 months ago Same here. The windows of my wsl2 emacs disappears after my laptop has gone to energy saving mode.
The application is still running, but the windows is gone (also not on the taskbar).
When I start a new emacs instance, then I'll see the old one all of a sudden. Really annoying.
Windows 11 emacs 28.1
WSL-Version: 2.0.9.0 Kernelversion: 5.15.133.1-1 WSLg-Version: 1.0.59 MSRDC-Version: 1.2.4677 Direct3D-Version: 1.611.1-81528511 DXCore-Version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows-Version: 10.0.22621.1848
hideyukn88
commented
6 months ago @kierke-gaard and all, thanks for updating us, the disappearing window issue when network configuration is changed is tracked by https://github.com/microsoft/wslg/issues/1092, and check my post at https://github.com/microsoft/wslg/issues/1092#issuecomment-1861445116 to see which case you might be hitting. If the first case in my that post, the fix is just submitted at https://github.com/microsoft/weston-mirror/pull/156.
This issue https://github.com/microsoft/wslg/issues/1058 is tracking the issue for window disappearing when window is maximized. Please let us know if this is still happening, thanks!
deadcombo
commented
5 months ago I've migrated from Windows 10 to Windows 11 23H2. I have not experienced Emacs' window disappearing since, it's been about 2 weeks.
deadcombo
commented
5 months ago I've migrated from Windows 10 to Windows 11 23H2. I have not experienced Emacs' window disappearing since, it's been about 2 weeks.
Take that back, it's resurfaced.
tmax22
commented
4 months ago any fix on this? this bug holds back the possibility to use linux as development environment on windows computer
hideyukn88
commented
4 months ago @deadcombo, @tmax22, thanks for reporting the issue, when this occurs,
1) does the application window still exist in xwininfo -root -tree?
2) does the task bar icon for application still there? what would happen if that's is clicked multiple times?
3) can that window be located using Windows's Spy++ tool? Please refer comments at https://github.com/microsoft/wslg/issues/1058#issuecomment-1640574370, and https://github.com/microsoft/wslg/issues/1058#issuecomment-1640821101.
Thanks!
deadcombo
commented
4 months ago 1 & 3 will try.
Putting the computer to sleep seems to trigger it reliably now.
On February 6, 2024 6:36:28 PM UTC, Hideyuki Nagase @.***> wrote:
@deadcombo, @tmax22, thanks for reporting the issue, when this occurs,
1) does the application window still exist in
xwininfo -root -tree? 2) does the task bar icon for application still there? what would happen if that's is clicked multiple times? 3) can that window be located using Windows's Spy++ tool? Please refer comments at https://github.com/microsoft/wslg/issues/1058#issuecomment-1640574370, and https://github.com/microsoft/wslg/issues/1058#issuecomment-1640821101.Thanks!
-- Reply to this email directly or view it on GitHub: https://github.com/microsoft/wslg/issues/1058#issuecomment-1930537429 You are receiving this because you were mentioned.
Message ID: @.***>
Windows Version
Microsoft Windows [Version 10.0.22621.1555]
WSL Version
1.2.5.0
Are you using WSL 1 or WSL 2?
Kernel Version
5.15.90.1-microsoft-standard-WSL2
Distro Version
Ubuntu 22.04
Other Software
No response
Repro Steps
xeyes)Alternatively, have an application that resizes itself to maximized (ex.
emacsafter loading a.emacs.desktopfile)Expected Behavior
The window is maximized
Actual Behavior
The window "disappears". It minimizes to the taskbar, and pressing the button on the taskbar causes a portion of the window - about half, horizontally - to flicker on to my second monitor (not where it was initially) before disappearing to the minimized state.
Such windows can only be removed by ^C-ing their process.
Diagnostic Logs
WslLogs-2023-05-03_23-38-18.zip
xev.txt (running
xev, maximizing the window)xeyes-strace.txt