the way we are currently testing snav doesn't allow any time between the firing of a keyboard event and verifying that focus has changed. This can causes test failures because events are processed more slowly than our test for a focus change. Recently the mac unit test tinderbox turned orange due to a snav failure most likely caused by this effect.

Comment on attachment 330307 [details] [diff] [review] patch v.1 (excuse the spacing in that makefile.)

Timeouts on the VMs are likely to cause as many if not more problems than they solve. Can you use a "focus" event listener instead?

> Timeouts on the VMs are likely to cause as many if not more problems than they solve. How so? Is this documented? > Can you use a "focus" event listener instead? I could. What happens if the focus event never happens? Do I create a timeout that kills the test if focus never switches?

(In reply to comment #3) > Timeouts on the VMs are likely to cause as many if not more problems than they > solve. Can you use a "focus" event listener instead? > If by "problem" you mean a "poorly written test should be made better, not band-aided with setTimeout" then I agree. A real listener would be a better choice. On the other hand, setTimeout itself isn't an indicator of a bad test. A quick scan of the "test" folders show setTimeout appearing over 700 times. One issue with setTimeout and VM's that I got stung by a few times is using too short of a timeout. It's possible the 10 millisecond timeout could be too short. (In reply to comment #4) > > Can you use a "focus" event listener instead? > > I could. What happens if the focus event never happens? Do I create a timeout > that kills the test if focus never switches? > The test framework already has that timeout in effect. But trying a "focus" listener is a good idea, before we punt to setTimeout.

from IRC: dougt: i am not sure if a element.focus() always triggers a focus event. [10:33pm] mfinkle: hmm, snav is programmatically setting focus, so no event may be fired [10:35pm] mfinkle: I see you just confirmed it worked in #developers [10:37pm] dougt: yeah. [10:37pm] dougt: well [10:37pm] dougt: it is a bit worse than that [10:38pm] dougt: it send events. [10:38pm] dougt: sometimes. [10:38pm] dougt: in one test case I am looking at [10:38pm] dougt: after the 4th programmatic focus, [10:38pm] dougt: we sit waiting for the focus event. [10:39pm] dougt: if i click in a different window, then i click back, everything works. [10:39pm] dougt: clearly suggesting that some focus events are being dropped. [10:40pm] dougt: i have tried both setting the event listener on the document and on the expected element (the one that i expect to be focused).

gavin, how about we: 1) file a bug w/ test case about the dropped events I am seeing. 2) file a bug to convert these test cases to use focus listeners dependent on (1). 3) move forward with these test cases as is.

Also another problem which prevents us from using focus listeners is that focus does not change in textarea or text input fields. I do plan on ensuring that spatial navigation works fine when navigating over text areas, and so our tests should also support this case.

fd1c0f6abf6d.