Maximus causes windows to stop painting

This behaviour is common to both the maximus package as installed via Synaptic and the Maximus Gnome shell extension (having installed via Zip and modified the metadata.json in the package to support 3.8).

Selecting a window and choosing 'Unmaximise' suddenly makes it visible (painted) again, so it's directly attributable to the maximisation behaviour.

I have made some progress following the instructions provided by Tjaart van der Walt in the thread at https://bitbucket.org/mathematicalcoffee/maximus-gnome-shell-extension/issue/23/please-upgrade-to-38 which indicates how to get the latest extension direct from the author's mercurial repository. It's certainly more functional and still figuring out whether it's entirely stable - good news so far.

Status changed to 'Confirmed' because the bug affects multiple users.

What I suspect is the same issue is happening to me (I'm using a fairly different configuration from the reporter, Cinnamon on Ubuntu Artful, so it's fairly unlikely that the desktop configuration is to blame). I've also confirmed that the theme used doesn't matter, via testing with multiple different themes for window borders and window controls.

The symptoms are that with Maximus running (I normally use «maximus -s -m» for testing), maximising a window sometimes causes it to become entirely invisible/transparent; it still reacts to keypresses and mouse clicks normally, and things like drop-down menus render when they should, it's just that the window doesn't render, instead showing what's "behind" it.

Unlike the initial reporter, the bug acts unreliably for me (maybe there's a race condition or the like involved?). I've done most of my tests using Seahorse (a generic GTK program), and discovered that maximising the window with Alt-F10, Alt-Space X or with the "maximise" button on the title bar nearly always causes it to render correctly, whereas double-clicking the title bar normally reproduces the bug, although only the first time that that I do it for any given Seahorse window. However, I've had periods of time where I couldn't reproduce the bug with Seahorse at all, although that seems to be rare. I've also had periods of time where double-clicking the Seahorse title bar makes it turn invisible every time I do that (with the other forms of maximising working correctly), even with the same window; and one of those periods ended spontaneously after maximising with double-click and unmaximising with Alt-F10 about 3 times.

Meanwhile, results with some other programs: Firefox nearly always reproduces the bug (i.e. no matter how I maximise the Firefox window, it turns transparent); the only times I've managed to successfully (i.e. without causing the bug) undecorate Firefox using Maximus have been when it's maximised as a consequence of Maximus (without -m) loading. Evolution tends to reproduce the bug if maximised via any means but the maximise button in the title bar or the maximise button on the taskbar context menu (although occasionally the bug will occur even if the maximise button is used; there seems to be no pattern here, you can do the same thing twice in a row and get different results). Kate (a KDE application, unlike the GTK applications mentioned earlier) seems to have similar results to Firefox, but with the added weird side effect (that doesn't occur with the other programs I mentioned, nor with Maximus not running) that it appears to lose window focus when unmaximised (with some other window getting it instead).

Use of «xwininfo» seems to imply that the invisible maximised windows are undecorated (as they should be when using Maximus) and in the expected place on the screen, just not rendering (or rendering invisibly) for some reason.

I've been unable to get at Maximus' version number from the program itself; running «maximus -v», which should report it, simply starts Maximus instead. dpkg claims that the package from which it's installed is version 0.4.14-4.

Confirmed that this still happens on Bionic. Given that Maximus is still on version 0.4.14-4, I guess that wasn't particularly surprising, but I decided to test anyway.