Mousewheel does not work reliably, especially in unfocused windows; why; and how to fix it

Yes, I know this isn't the place for bug reports: I'm posting here because this also contains the solution, which needs to be integrated by the devs. Feel free to move it if you'd rather it be in Support.

So, as mentioned in the "GTK3 regressions" thread, wheel scrolling (of content, not tabs: that's a different issue) in caja, pluma, etc etc is broken, often seemingly at random, and has been ever since at least 18.04. It's 100% reliable in 16.04.

The mousewheel just randomly doesn't work at times, notably in caja windows (which I tend to scroll through that way a lot). Just now, I went through 4 clicks on the wheel in there and absolutely nothing happened at all. Then it suddenly "woke up" and started working.

If I switch to a different window (click to focus) but then hover over the caja window and scroll the wheel, it will almost always ignore the first event but then respond to subsequent ones. Give the caja window focus then switch away from it again and start over, and the first wheel movement gets ignored again.

Digging into the history of it, I found exactly what I expected to: the bug has existed since 2013 (!) and GTK3 is at fault. (Note that there is also the expected Blame Game in the GNOME bugzilla, originally attributing the bug to Compiz, then to libinput2. Both of those are provably innocent since MATE 16.04 with no compositor doesn't have the bug). Ultimately, the GNOME devs hacked at it a few times, failed to get it working, marked it as a duplicate of a different bug, then marked that one as RESOLVED FIXED, and left it at that. (https://bugzilla.gnome.org/show_bug.cgi?id=699574 et al).

The bug IS actually caused by libinput2 to some extent, but the bigger problem lies in GTK3's handling of mouse events because of its attempts to perform momentum / trackpad scrolling.
TL;DR, GTK3 fails to process wheel events properly.

The fix appears to be GDK_CORE_DEVICE_EVENTS=1. I'd have to dig through the code to see exactly what that does, but at a guess it'll be something like "don't try to filter certain mouse events out" (which, clearly, GTK3 fails to do correctly: I know why, and can bore you with the details if you'd like, but it's fairly academic since you can't patch GTK3 to fix it). The fix very clearly works for pluma, which is easy to test it on.

The problem with that, from a user perspective (other than knowing that it's needed in the first place) is that it has to be set before the application is run. That makes it non-functional (especially for anyone using session restore) or impractical unless they edit /etc/environment or something equally core that they shouldn't need to be touching.

I don't know what impact fixing it would have on trackpad users, and I don't have one to test the fix on. If it causes a problem there it would need a UI checkbox, though I'd argue that it should be the default even if so, unless the trackpad impact is even more hopelessly broken than the mouse impact is, which seems unlikely: I'd expect it to at most cause a slight inaccuracy in the distance response to swipes, which given the imprecision of trackpads wouldn't be humanly perceptible. But like I say, I'm not in a position to test that out.

If it needs UI, I'm not sure where the best place for it would be, but I'd probably suggest Mouse rather than e.g. MATE Tweak, if all else is equal between them.

Being able to use multiple WM's complicates things further, as having Marco take care of it would still leave it broken for Compiz users (unless Compiz already implements the same workaround, which it might: it would explain why GNOME treated it as "FIXED" when it isn't, since GNOME Shell would work properly thanks to Compiz if so). Someone (Wimpy?) who's much more knowledgable about Compiz than I am would know how to handle that side of things though.
(The WM aspect is only relevant if it does cause a noticeable issue with trackpads, as fixing it via /etc would carry over to all DEs, so it would have to be set as part of the MATE session startup rather than globally).

Anyway, hopefully that'll put the nail in this thing's coffin. I'll file a (much less wordy!) bug in LP tomorrow if you'd like one just for tracking etc: I need to get to bed now.

TIA