Yeah, that was intentional. There are some tests that look at the hover state, for example, and they get messed up if the mouse is over the web content. Ideally we would make those tests not be flaky like that, but for now this gets rid of that interference.

In the case of run-web-tests, though, no window is even displayed, so I don't understand how the mouse could be over anything at all.

I agree that it's weird, but that's what I saw happening. I'm guessing something is querying the cursor position directly rather than listening for events.

Were you trying to fix something Windows-specific, by any chance? Maybe you could enable the fix for Windows only, if that's the case? I'm on Linux, FWIW.

It was a Linux failure, actually ( bug 828591  if you're interested). I managed to reproduce it locally too, unsure why it didn't show up on the Windows bots at the time.

Now that I remember the context, it shows up even when the window isn't displayed because it's not a real mouse event that's causing the problem. When the window is activated, Chrome synthesizes a mouse move event to resync all the UI elements that might have gotten out of sync while it was deactivated. The bug I fixed was that it was sometimes using a stale mouse location. Updating it with the real mouse location revealed that the tests were relying on the stale location to give a consistent beginning state.

At the layer where all these problems are happening we have no idea whether we're in a real browser or a headless content_shell so we can't create a test mode. And the web content needs to react to synthesized events, otherwise the rest of the test won't work at all. So I'm not sure what else we would do.

Thanks for explaining.

So, ideally, we should rather fix the tests, I suppose. I.e. the tests that need to should move the cursor to a suitable location before carrying on with the actual test.

I can consistently repro this with running content_unittests

Mass UI Triage.