fix rare flakiness in domado-events testRepeatedHandlers

This addresses https://code.google.com/p/google-caja/issues/detail?id=1779

Symptom is we expect
 mousedown,1,mousedown,3,mouseup,1,mouseup,3
but we get
 mouseup,1,mouseup,3

I haven't been able to reproduce it, but I think what's happening is
that the webdriver click() puts a small delay between mousedown and
mouseup events, and in that interval we happen to run the testcase,
which installs mousedown and mouseup handlers, and then sees
results from just the mouseup events firing.

This fix just reduces the test to mouseup handlers, since it's
intended to test that repeated calls to addEventListener do
the expected thing, and there's nothing special about testing
both mouseup and mousedown.

[kpreid2, 2013-08-29 23:39:49]

I agree that there's nothing special about the mousedown/mouseup pairing, but
this test is exercising several different ordering cases for the internal
algorithm to detect duplicates, so I don't want to reduce the number of event
listeners involved.

Suggestion 1: Instead of removing the mouseup listeners, make them into
mousedown listeners using a separate instantiation of the record() function
(which writes a different string into 'events').

Suggestion 2: Keep the test the way it is, except that the handlers are all
installed in response to a mouseup event from a separate, earlier handler. This
would prevent the registering-in-the-middle you hypothesize.

Suggestion 3: Install the handlers at the top level (thus before the clicking
starts) rather than inside the jsunit test function.

I'm being a little overcautious here, but event dispatch is tricky and I don't
want to cut down on our test coverage.

[felix8a, 2013-08-30 00:13:32]

This addresses https://code.google.com/p/google-caja/issues/detail?id=1779

Symptom is we expect
 mousedown,1,mousedown,3,mouseup,1,mouseup,3
but we get
 mouseup,1,mouseup,3

I haven't been able to reproduce it, but I think what's happening is
that the webdriver click() puts a small delay between mousedown and
mouseup events, and in that interval we happen to run the testcase,
which installs mousedown and mouseup handlers, and then sees
results from just the mouseup events firing.

This fix just reduces the test to mouseup handlers, since it's
intended to test that repeated calls to addEventListener do
the expected thing, and there's nothing special about testing
both mouseup and mousedown.

[felix8a, 2013-08-30 00:14:11]

On 2013/08/29 23:39:49, kpreid2 wrote:
> I agree that there's nothing special about the mousedown/mouseup pairing, but
> this test is exercising several different ordering cases for the internal
> algorithm to detect duplicates, so I don't want to reduce the number of event
> listeners involved.
> 
> Suggestion 1: Instead of removing the mouseup listeners, make them into
> mousedown listeners using a separate instantiation of the record() function
> (which writes a different string into 'events').
> 
> Suggestion 2: Keep the test the way it is, except that the handlers are all
> installed in response to a mouseup event from a separate, earlier handler.
This
> would prevent the registering-in-the-middle you hypothesize.
> 
> Suggestion 3: Install the handlers at the top level (thus before the clicking
> starts) rather than inside the jsunit test function.
> 
> I'm being a little overcautious here, but event dispatch is tricky and I don't
> want to cut down on our test coverage.

heh, I did consider all those options before doing this.

option 3 is way complicated because we'll get a lot of clicks before calling
jsunitRegister.

option 2 is somewhat complicated because I'm not sure that adding a mouseup
handler during a mousedown handler will always receive the mouseup pending.

option 1 seemed unnecessary because the test of multiple orderings was something
I added recently for no reason, historically we just tested one ordering. but I
can keep that fairly easily.  new snapshot.

[kpreid2, 2013-08-30 18:25:38]

LGTM

[felix8a, 2013-08-30 18:56:10]

@r5587