518191 - use Neil's SimpleTest.waitForFocus to improve intermittent test failures

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[David Bolter [:davidb] (NeedInfo me for attention)]

Attachment: WIP - idea

http://enndeakin.wordpress.com/2009/09/08/how-to-fix-focus-related-problems-in-tests/

Comment 1

[David Bolter [:davidb] (NeedInfo me for attention)]

Comment on attachment 402161 [details] [diff] [review]
WIP - idea

I'm doing a tryserver run to see what blows up.

Comment 2

[Marco Zehe (:MarcoZ)]

Comment on attachment 402161 [details] [diff] [review]
WIP - idea

I like this change especially because screen readers usually start doing their thing only after docs get loaded and focused. Did anything bad show up? If not, r=me.

Comment 3

[David Bolter [:davidb] (NeedInfo me for attention)]

Pushed to mozilla-central: http://hg.mozilla.org/mozilla-central/rev/4fee16ce937e

Note: this means when running the harness locally, you must give the window focus of the tests will halt.

Comment 4

[alexander :surkov (:asurkov)]

This should be really good to not annoy mozilla developers by mochitests failures but it' might be not good for us because it can make us to think we are in good shape since mochitests pass. Any intermittent failure shows something is wrong and we should address this. This is a reason why I preferred addLoadEvent to addA11yLoadEvent. Ideally we should realize when we need a11y document load event, when we need some timeout after doc load event and when we need to wait for focus event.

Comment 5

[Marco Zehe (:MarcoZ)]

Alex, I think that this will give us a more accurate picture. For example bug 510128 was still failing after this was checked in, so we do have a real problem there.

Moreover, screen readers usually do their magic once the document has finished loading and the browser sets focus to the document (when coming from the location bar, for example).

Comment 6

[David Bolter [:davidb] (NeedInfo me for attention)]

Yes I thought about just this issue, and after some discussion with Marco we thought this was the better option. That said, I think we can more carefully consider the right approach for each test.

Can you think of cases where we shouldn't wait for the browser to be focused? (Maybe file a bug for discussion)

Comment 7

[alexander :surkov (:asurkov)]

On the quick glance I can keep in mind only one case where we need to wait for document accessible load event is when we want to listen selection changes. Another cases can require neither accessible load event nor focus event. It's good screen readers tend to start the work after focus event is fired. However if we assume our code should work before focus then it should do or we should understand why it doesn't and to document this somewhere. I mean situations like these are always trick and it's hard to catch them in real life and file bug with steps to reproduce since all of this is random. I think we could file bug as David suggests to make our tests working after DOM document load if they allow this.

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

OK cool, I spun off bug 519969 :)