Comment 44 for bug 38753

No, windows works completely different. The "clients" have far more control about "window management", ie. when you click into explorer it of course knows where you click and then in doubt doesn't trigger a raise.

To do this on X11 and probably wayland, you'd *have* to activate & pass the click on mouse press and raise the window on mouse release (if there's not not been an interim DnD) - you cannot rely on "the toolkit" since there's not "/the/ toolkit".

*Theoretically* this *could* be done on X11, BUT (big, fat: BUT) it would require a permanent passive mouse grab on active clients (just as kwin atm. passively grabs inactive clients and releases that grab when they fall active) so kwin would also receive mouse release events for the activated client (and all others)

Since one probably had to monitor only the first[1] mouse release after the activation (assuming that an already activated client is also always risen in this activation model, true about 99% of the time) this should actually not be "too" harmfull (but mess the code a bit ;-) and if it wasn't for "KWin" (but some tiny WM with 3 users) i'd perhaps just write a patch, but freaking around with mouse grabs is about the worst thing one can do on X11 (otherwise kwin could resize borderless windows by now w/o stupid overlay corners) so i'd never really guarantee for such a patch.

[1] FTR: it's not that trivial, DnDs might likely actively grab the pointer and then you receive the wrong or no mouse release