ConfigureEvents may occur after a window has been deleted, an UnmapEvent
has already been sent (and thus xmonad already unmanaged the window),
but before a DestroyWindowEvent is caught by the eventHook. For
example, this is the case when one uses smartBorders with a single
window (such that smartBorders is "active"). The ConfigureEvents
sensibly already have an empty stack (because the UnmapEvent has already
been received), which we then copy to the history.
Whenever a parent window has been found, the sensible thing to do is to
always restore it. The fact that oldStack is Nothing simply encodes an
empty workspace and is thus something we definitely need to handle as
well.
[x] I've considered how to best test these changes (property, unit,
manually, ...) and concluded: I've tested them manually and @syunsuke (who was the original reporter) also confirmed that theses changes work for them.
Description
ConfigureEvents may occur after a window has been deleted, an UnmapEvent has already been sent (and thus xmonad already unmanaged the window), but before a DestroyWindowEvent is caught by the eventHook. For example, this is the case when one uses smartBorders with a single window (such that smartBorders is "active"). The ConfigureEvents sensibly already have an empty stack (because the UnmapEvent has already been received), which we then copy to the history.
Whenever a parent window has been found, the sensible thing to do is to always restore it. The fact that oldStack is Nothing simply encodes an empty workspace and is thus something we definitely need to handle as well.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/638
Checklist
[x] I've read CONTRIBUTING.md
[x] I've considered how to best test these changes (property, unit, manually, ...) and concluded: I've tested them manually and @syunsuke (who was the original reporter) also confirmed that theses changes work for them.
[x] I updated the
CHANGES.mdfile