exwm
exwm copied to clipboard
ch11ng
exwm-workspace-switch: Wrong type argument: frame-live-p, #<dead frame
I always use multiple screens with exwm, and 95% of the time there's no issue. However, sometimes when applications that had used "full screen mode" (Zoom, browsers with F11 used) end, I am left with a blank screen and no amount of adding extra frames with C-x 5 2 helps; attempting to kill the frame doesn't do anything, and trying to switch to it tells me something like exwm-workspace-switch: Wrong type argument: frame-live-p, #<dead frame F : Photos - Google Phot 0x9a42e40> (that was after closing a window with full-screen Google Photos in Firefox). I'm sure others have encountered this; how can I get my other monitor back to displaying stuff, other than restarting my emacs EXWM session?
I wonder how that frame was deleted. Closing fullscreen X window could cause an issue but that was fixed in Release 0.20. Could you provide a way to reproduce this? I doubt it has anything to do with multiple-screen setup BTW.
- Make Firefox full-screen with
M v f - End full screen by switching to char mode (for me
M-k) -
(kill-buffer)withC-x k RET
The screen is now black except for my (working) cursor. and I receive exwm-workspace-switch: Wrong type argument: frame-live-p, #<dead frame F : Photo - Google Photo 0x8ea2720> if I try to switch to that screen.
What do M v f, M-k and C-x C-k RET bind respectively? Your keys are quite different from the standard it appears.
M v f in Firefox is Menu -> View -> Full Screen
M-k in exwm windows is the default to toggle between input-mode and char-mode (not sure the name of the command)
C-x k RET is what I meant; (kill-buffer)
I often (3+ times weekly) have problems with this related to Zoom video conference software. The termination of a Zoom window (especially when done by one of the other participants) can leave one of my screens effectively "dead" (black with the above error) and no combination of making new frames, (exwm-restart), etc will bring that screen back into use. Switching to a terminal (C-M f6 on most Linux flavors) uses both monitors still, though.
Please try C-h k M-h and that would reveal the name of the command it binds. There should be no such problem if it's exwm-reset.
Hmm... you lost me. M-h is mark-paragraph, which is useful to know because I've never used it before. I did look into M-k, though and found it to be exwm-input-toggle-keyboard, if that's what you meant.
Sorry it was a typo. I tried exwm-input-toggle-keyboard and it seems to work as Firefox restored from fullscreen mode. What happened after you pressed M-k?
On my machine it triggers me to leave full-screen mode in Firefox when I use exwm-input-toggle-keyboard .
Another, more common vector than the Firefox issue: when in Zoom the meeting ends while one of hte views was in "full screen mode" (often while screen sharing), it can leave me with a "dead" monitor that I can't get back without restarting my exwm session. Same errors we've been talking about here.
I'm seeing this sometimes too 🙋🏾 For some applications it also seems to matter how I've fullscreened them: MPV, for instance, seems fine if I use f (which is MPV's built-in fullscreen key binding), but if I use C-c C-f (exwm-layout-set-fullscreen), then it'll fail to work when a video file ends.
However, I'm also seeing something related (but I'm not sure it's the same issue). I wanted to see if you thought it was related before I opened another one.
Sometimes, usually when there's been a floating X window that has disappeared (such as a Slack call pop-up), I'll get an error message saying "wrong type argument: frame-live-p #<dead-frame [...]", but in my case Emacs freezes completely. Nothing I do seems to work (including C-g). If I switch to a different tty, and kill -12 the process, then that seems to take me one step further (the minibuffer message changes), but I'm still unable to do anything. If I repeat the kill -12 step, then I'll get a debug window popup, but anything I do seems to freeze it. Repeated freezes appears to take me into a recursive edite. The only way I've found out of it is to force kill Emacs and start again.
Do you think this is the same issue or a different one?
Thanks!
Thomas Heartman @.***> writes:
I'm seeing this sometimes too 🙋🏾 For some applications it also seems to matter how I've fullscreened them: MPV, for instance, seems fine if I use f (which is MPV's built-in fullscreen key binding), but if I use C-c C-f (exwm-layout-set-fullscreen), then it'll fail to work when a video file ends. I have actually never used the EXWM fullscreen before, just using each apps built-in fullstreen, but yes, I've seen issues there (especially if I kill the EXWM buffer while it's full-screened).
However, I'm also seeing something related (but I'm not sure it's the same issue). I wanted to see if you thought it was related before I opened another one.
Sometimes, usually when there's been a floating X window that has disappeared (such as a Slack call pop-up), I'll get an error message saying "wrong type argument: frame-live-p #<dead-frame [...]", but in my case Emacs freezes completely. Nothing I do seems to work (including C-g). If I switch to a different tty, and kill -12 the process, then that seems to take me one step further (the minibuffer message changes), but I'm still unable to do anything. If I repeat the kill -12 step, then I'll get a debug window popup, but anything I do seems to freeze it. Repeated freezes appears to take me into a recursive edite. The only way I've found out of it is to force kill Emacs and start again.
Do you think this is the same issue or a different one?
I have never had it cripple my system like that but I also don't often encounter floating windows except Save File prompts in Firefox and Gimp. I daresay they are related. Perhaps the same thread here will lead to a common solution.
Thanks!
You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.*
I have never had it cripple my system like that but I also don't often encounter floating windows except Save File prompts in Firefox and Gimp.
Yeah, I don't see many floating windows myself, but there are some, such as certain Zoom windows, some Slack windows, etc. I've also had similar issues with zoom where the system locks up completely. Interestingly, though, the X window keeps working. So I've had the system stop reacting to any input, but the meeting kept going and I was able to hear and see the host, and they could see me (but my mic was muted).
I daresay they are related. Perhaps the same thread here will lead to a common solution.
Yeah, they do sound related. Let's see what @ch11ng thinks about it and take it from there ☺️
I don't think @ch11ng comes here much anymore...
Regarding Zoom, that's one of the reasons that I've been doing Zoom strictly through my browser for the last year. That said, I have had that everything else freezes experience during video calls in my browser. It may be a sign of a more common error state in EXWM.
I just want to add that I very rarely had that problem before but after my latest system update (where I updated zoom and Emacs to the latest master branch) this happens almost every other zoom session. I assume it's the zoom update that triggeres the exwm bug somehow.
I don't think @ch11ng comes here much anymore...
@WorldsEndless Don't they? That's a shame. What's the path forward for this issue, then? Or for EXWM in general, I suppose?
I assume it's the zoom update that triggeres the exwm bug somehow.
@dakra Interesting. That may indeed contribute. I wonder what causes it. When things freeze it's really hard to debug too and you don't exactly want to put yourself in that situation 😅
I'm also experiencing this problem with zoom. I can reproduce it with the following steps
- I'm watching the meeting on an external screen
- the meeting is in full screen mode (say by double clicking the zoom window)
- the meeting ends by the host
Yes, in general EXWM does some weird stuff when any program has a full screen and that is abruptly closed, I think. Full screen meaning "full screen mode" as opposed to the natural screen occupation for a program.
Any way we could make the full-screened programs better contained in EXWM? If not, is there any way to make it go back to the normal/buffered window before it quits so that it doesn't quit in full-screen?
I think those would indeed be the solutions. I haven't made it to a point where I can read the code and understand the workings of XELB yet, though.
Chen Sun @.***> writes:
Any way we could make the full-screened programs better contained in EXWM? If not, is there any way to make it go back to the normal/ buffered window before it quits so that it doesn't quit in full-screen?
You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. *
I have had many of these dead frame problems - with Zoom and with the Open File dialog from various X applications. This week I tracked these down to winner-mode. If winner-mode is off, boom - the problems disappear. Today I added advice to one specific function - and so far not only have those issues vanished - but when I start a web browser in a new EXWM session, it comes up instantly with its 20 windows, and I no longer have a slew of messages regarding dead windows!
;; Add advice to stop hangs on EXWM
;; The problem happens with floating windows that disappear - like open file dialog or a Zoom dialog when starting a meeting
;; The solution is to assure all frames in winner-modified-list pass the frame-live-p test
(defun gjg/winner-clean-up-modified-list ()
"Remove dead frames from `winner-modified-list`"
(dolist (frame winner-modified-list)
(unless (frame-live-p frame)
(delete frame winner-modified-list))))
(advice-add 'winner-save-old-configurations :before #'gjg/winner-clean-up-modified-list)
Keep in mind that this has not been tested very extensively yet - but I wanted to get this out because it was very hard to track down.
@gregoryg Thanks for tracking this down, I disabled winner-mode now because I don't actually use it. Lets see if it helps.
For what it's worth, I was seeing this issue pop up with transient dialogues like the floating window that prompts for touching a Yubikey when authenticating via SSH. Some combination of switching screens while dismissing that window caused these errors for me.
@tazjin you're welcome. It has not completely resolved all these issues, but it has made the problems so rare that I can measure the occurrences in weeks rather than days or hours.