Ed. No, wait, it's most days. Guess that's why I don't bother trying to be helpful here, far too much crazy for my taste.

Note that Featherpad also had developed similar artefacts, turned off also with F11:  Featherpad could not be dragged or resized with the default mouse bindings;  the default 'lower window' binding had since been modified by choice to 'maximize window', and that wouldn't respond either.

These artefacts had persisted even when blackbox, a different window manager, was installed, including (a) with Mousepad when it was reinstalled;  and (b) more recently, with xfce4-terminal.

That 'full screen' suspicion and F11 solution were proposed in 2013 for a similar situation with some LXDE application(s).  One argument brought up for applications possibly starting in full screen mode was that it might be related somehow to some new theme(s) being applied.  In my case, some themes from Devuan's official repos had indeed been installed earlier and, for what it's worth, later applied with an excellent LXDE theme manager:  lxappearance.

Therefore, I could not identify any vulnerability, and this thread has been closed although, in case it could be 'remotely' relevant, a 'dlm' error was also noted on logout, but I can't find it in any current /var/log file. Why would there be need for a 'distributed lock manager' on my standalone pc?  How could a lone dlm package - libdlm3, a 'Distributed Lock Manager library' - have appeared on my system? After a bit of research, I decided to remove it without any noticeable knock-on effect, except the error occasionally was noted to persist on logout.

See the reason given in a link there:  "Python2 becomes end-of-live upstream, and Debian aims to remove Python2 from the distribution [...]".

It is not maintained upstream:  https://github.com/aanatoly/fbpanel .

I suspected fbpanel to be compromised more recently, as its menu icons stopped displaying, even after restarting it or firejailing it, etc.  Fbpanel has now been purged and replaced with tint2. Mousepad and the Calligra suite may be again retried at a later date:  perhaps they might not be culprits, although mousepad and calligrasheets were not launched from fbpanel when their artefacts manifested:  they were launched from .xinitrc.

/usr/bin/firejail  --net=none /usr/bin/calligrasheets '/home/someusername/Documents/Somefile.ods' &

Note that mousepad had also been launched from .xinitrc, but with a check for the latest version of three files, each having slightly different suffixes before the .txt extension:

/usr/bin/mousepad -- "$(ls -t /home/$USER/Documents/SomeFolder/SomeFileVersion*.txt | head -n 1)" "$(ls -t /home/$USER/Downloads/SomeFolder/SomeOtherFileVersion*.txt | head -n 1)" "$(ls -t /home/$USER/Downloads//SomeFolder/SomeOtherFileVersion*.txt | head -n 1)" &

calligra* packages have been now been purged accordingly for now, to be on the safe side, although it is a great suite.  I do not see a way to update the thread title to include this suite.

$ man cwm
[...]
          The default mouse bindings are:

           M-M1            Move current window.
           CM-M1           Toggle group membership of current window.
           M-M2            Resize current window
           M-M3            Lower current window.
           CMS-M3          Hide current window.
[...]

Background:  My Devuan system (on a Raspberry pi 400 arm64 architecture, in case it is relevant) was recently updated with bash instructions from Chimaera to Daedalus, and the display manager was purged to replace it with the system's interactive text login using an .xinitrc file (plus .bash_profile, .profile, and a soft link from .xsession to .xinitrc).  It then automatically launches a cwm window manager and ungoogled-chromium browser among other applications in Xorg.  Full disclosure:  There may still be some unresolved error messages (see earlier messages), and I am still unsure whether one of Daedalus' offered improvements was automatically implemented - whether Xorg now runs as a user instead, or as root.  Hopefully this was not botched in my upgrade, and no security risk as it stands!  The system is up-to-date and, though I uninstalled mousepad last night, the current version, according to apt search mousepad, is "mousepad/stable 0.5.10-2 arm64".

I thought it strange when I was not able to drag Mousepad quite a while ago but didn't get concerned enough until last night.  Other windows responded well to all three bindings;  windows included xfce4-terminal, calligrasheets, librewolf and ungoogled-chromium. I wonder whether someone remotely was able to commandeer my Mousepad to launch inside some kind of vm, with its window borders not visible, and disabling the dragging/resizing of that windows hides any vm(?)'s window borders, so as to eavesdrop.  I had been setting some changes in my .cwmrc file that I figured might be interfering. 

Mousepad (c.3Mb with dependencies) was therefore purged;  featherpad, a "Lightweight Qt5 plain-text editor" was installed instead at c.500kb (with any dependencies), and it appears to offer roughly the same main functions.

Perhaps as a related issue, on a previous Devuan (Chimaera) installation, Mousepad wouldn't launch visibly when right-clicking on various .txt files one at a time in spacefm and when selecting the default 'Mousepad';  it would only launch from a right-click menu when selecting the 'Editor' choice, if my memory is correct.

Note that I don't bother with window grouping or tiling, so no such settings are knowingly amended in .cwmrc.

The only somewhat relevant .cwmrc custom bindings might be:-

# "Sometimes it's necessary to unbind keys first [...]", acc. to https://www.reddit.com/r/openbsd/comments/fo7fou/cwm_default_terminal_cwmrc_applications/fldqiw8/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button
unbind-key all

# Window-maximize seems to toggle windows
# BUT THIS SETTING HAS SINCE BEEN COMMENTED OUT, AS DECIDED IT WAS UNNEEDED
bind-mouse M-3		window-maximize

# TO PREVENT POINTER FROM WARPING ON THE fbpanel LAUNCHER/SYSTEMS BAR/TASK BAR - 
# THE WINDOWNAME FROM xprop FOR fbpanel IS panel SO "ignore fbpanel" DOES NOT WORK
ignore panel

If it could be of use, I could reinstall Mousepad temporarily to, say, give you its xprop description or terminal output when launched from a terminal in case the artefacts would present again or in case the reports are relevant.  The only somewhat relevant .config object perhaps was a Mousepad folder, but I decided not to keep it, sorry (there was no .config/mousepad folder before purging Mousepad, if i recall correctly).  I may have synced the Mousepad folder from lingering previous installation backups.  I am tired of signing up to different websites so, sorry, but I am not inclined to register to file this as a bug report.  If it is of interest or can be replicated, and if this sounds like something worse than a .cwmrc misconfiguration, perhaps an interested Devuan party could take this up.