I'm kind of unhappy about these windowing patches. I know that this is blocking us from turning on d3d tests in the CI, and I agree that's a bad thing. On the other hand, I don't like the way these are working around the failures, because they're *not* working around them—they're crippling the tests.
Contrary to what Alexandre said a few weeks ago, our d3d windowing tests aren't failing because they're testing things too zealously—they're failing because, by all appearances, the *core assumptions that are being tested* are being violated by fvwm2. That means that the applications that depend on this behaviour are going to be broken on fvwm2. So what I would really like to see is that this bug just gets fixed upstream.
A first step towards that, as Henri mentioned, is testing with fvwm3 instead, because it may already be fixed upstream. I don't know how stable fvwm3 is in general, but the fact that fvwm2's README says "All users are hereforth encouraged to use fvwm3, and to report any bugs" suggests that it's what we should be targeting at this point *anyway*.
I'm sure this is not what you want to spend your time doing, and if necessary I can put my time where my mouth is and try to push this upstream myself.
d3d8 is not affected in this way because it does not call flush_events() between focus loss and re-gain.
That seems undesirable. I don't think we want the same test to differ between d3d8 and d3d9 without a reason. In this case, if the flush_events() call is catching something, we should probably add it to d3d8.