+nzolghadr@  My guess is that native events in chrome can be generated (for example a mouse move is sent when a render widget is first created). We likely should filter native window events when in testing mode.

Don't we get no windows or native events when running with run-webkit-tests?

No I don't believe anything like that exists. On linux you typically run it as xvfb-run but there are synthetic events that the browser does generate as well. And I wonder if those cause issues for current hover values.

dgrogan@ regarding the repro can you elaborate a little more on the parallel vs sequential. Do you mean when you use only one content shell to run all the tests it doesn't happen and when you use multiple then it might? How many did you use that could potentially trigger the failure? I wonder if there is a state in the code that gets leaked from the previous tests as this might usually be the reason that sequential runs pass and parallel ones don't.

I'll give the repro a try but atotic might be able to answer faster.

sequential, everything happens in one shell:
run-webkit-tests html/tabular_data/

parallel, each test gets separate shell:
run-webkit-tests -f html/tabular_data/

You can also easily reproduce the failure by running just a single test:
run-webkit-tests html/tabular_data/col_width_resizing_table.html

I got a failure on the first try with multiple content_shells:

$ ./third_party/WebKit/Tools/Scripts/run-webkit-tests --disable-breakpad --debug --clobber-old-results --no-retry-failures -f html/tabular_data

Running 24 content_shells in parallel.                                     

[24/24] html/tabular_data/col_width_resizing_table.html failed unexpectedly (image diff)


And I got a failure on the first try running just this one test in one content_shell:

$ ./third_party/WebKit/Tools/Scripts/run-webkit-tests --disable-breakpad --debug --clobber-old-results --no-retry-failures html/tabular_data/col_width_resizing_table.html

Running 1 content_shell.                                                   

[1/1] html/tabular_data/col_width_resizing_table.html failed unexpectedly (image diff)


But I can't get a failure in running the whole directory with one content_shell:

$ ./third_party/WebKit/Tools/Scripts/run-webkit-tests --disable-breakpad --debug --clobber-old-results --no-retry-failures html/tabular_data

Running 1 content_shell.                                                   

All 24 tests ran as expected.


This is odd, but it is identical to atotic's experience.

I don't seem to see this failure. All the commands above pass for me all the time . Do yo also run them on a Linux machine in case that is any factor.

Yes, on linux.

These are my args.gn

enable_nacl = false
enable_pdf = false
enable_print_preview = false
google_api_key = "..."
google_default_client_id = "..."
google_default_client_secret = "..."
is_component_build = true
use_goma = true

I managed to reproduce this. This is not happening at all often on my computer. I have to run about 10 times every time to be able to reproduce it once. Regardless, it is reproducible. From what I gathered (commenting the down/up in the test) we get two events form the browser and one from the event_sender (the mouse move in that test). In the failing case we get the events from the browser after the event_sender event and in the passing case we get them before the event_sender event. Those browser events are the ones causing the mouse leave to the page). I assume that would be normal since the browser events should go through ipc and mojo channel to get to the renderer which is not the case for event_sender. At the same time I believe if gpu_benchmarking is used the event automatically gets queued and will be in sync.

We might be able to do what Dave suggested regarding ignoring the browser events but I'm afraid it might fail bunch of other tests that kind of rely on those browser events to essentially reset their states. At the same time with using gpu benchmarking the test instruction events are also coming through mojo. So we need also another flag of some sort to distinguish those.

As we are moving off the event sender in general, I suggest to just transfer this test to gpu benchmarking as well. But I'll keep this in mind if anything else comes up in the future.

Thanks for trying again.

I don't understand a lot of your findings, starting from "In the failing case we get the events from the browser after the event_sender event and in the passing case we get them before the event_sender event." (who is "we"?)

But is the non-determinism you found specific to this test or can it appear in any test that uses eventSender? If the second, it's probably a contributor to test flakiness which, you've probably seen on chromium-dev, has significantly reared its ugly head again.