492956 - mochitest-a11y failed, summary reports unexpected huge numbers for pass/fail. ("nsIAccessibleEvent is not defined")

Status: VERIFIED FIXED

(Testing :: Mochitest, defect)

Description

[(not currently active) Ted Mielczarek]

There was a mochitest-a11y failure on Linux and the result printed was: mochitest-a11y: 20349/161044/1
Sure enough, in the log it says:
*** 723 INFO Passed: 20349
*** 724 INFO Failed: 161044
*** 725 INFO Todo:   1
*** 726 INFO SimpleTest FINISHED

Clearly there weren't this many tests run. I'm not sure how the test harness failed this way.

Comment 1

[Serge Gautherie (:sgautherie)]

(In reply to comment #0)

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242296338.1242303502.9342.gz&fulltext=1
Linux mozilla-central unit test on 2009/05/14 03:18:58

This log summary should have been: 369 / 242 / 1.
(Or the log simply misses that huge number of lines...)

> I'm not sure how the test harness failed this way.

Impossible to tell unless it would be reproducible :-|

Comment 2

[Serge Gautherie (:sgautherie)]

m-1.9.1 had this bug today for a while:

{
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.5/1242975494.1242979635.1802.gz
Linux mozilla-1.9.1 unit test on 2009/05/21 23:58:14
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.5/1242975494.1242980636.3420.gz
WINNT 5.2 mozilla-1.9.1 unit test on 2009/05/21 23:58:14
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.5/1242982693.1242987423.15260.gz
Linux mozilla-1.9.1 unit test on 2009/05/22 01:58:13
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.5/1242983451.1242988175.16386.gz
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.5/1242982692.1242989834.19008.gz
WINNT 5.2 mozilla-1.9.1 unit test on 2009/05/22 01:58:12
Linux mozilla-1.9.1 unit test on 2009/05/22 02:10:51
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.5/1242983451.1242988545.17064.gz
WINNT 5.2 mozilla-1.9.1 unit test on 2009/05/22 02:10:51
+
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1242976485.1242986054.12798.gz
WINNT 5.2 comm-central unit test on 2009/05/22 00:14:45
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1242977308.1242982092.5888.gz
Linux comm-central unit test on 2009/05/22 00:28:28
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1242982690.1242985612.11967.gz
Linux comm-central unit test on 2009/05/22 01:58:10
+
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey-Ports/1242977229.1242981923.5703.gz
Linux comm-1.9.1 unit test on 2009/05/22 00:27:09
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey-Ports/1242983451.1242988528.17053.gz
Linux comm-1.9.1 unit test on 2009/05/22 02:10:51

mochitest-a11y 3002/4496/0 CRASH L-FAIL

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey-Ports/1242979501.1242989052.17927.gz
WINNT 5.2 comm-1.9.1 unit test on 2009/05/22 01:05:01

mochitest-a11y 3001/4496/1 CRASH L-FAIL
}
instead of the usual value, +/- like "1222/0/77".

NB: 1.9.1 MacOSX does not run 'mochitest-a11y'.

Comment 3

[Serge Gautherie (:sgautherie)]

m-central had it too:

{
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242975357.1242983370.7928.gz
Linux mozilla-central unit test on 2009/05/21 23:55:57
3440/5809/1 L-FAIL
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242982557.1242989319.18202.gz
Linux mozilla-central unit test on 2009/05/22 01:55:57
3440/5743/1
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242982935.1242989799.18960.gz
Linux mozilla-central unit test on 2009/05/22 02:02:15
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242983439.1242989376.18260.gz
Linux mozilla-central unit test on 2009/05/22 02:10:39
3440/5743/1 L-FAIL
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242975357.1242982461.6430.gz
OS X 10.5.2 mozilla-central unit test on 2009/05/21 23:55:57
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242982557.1242989973.19270.gz
OS X 10.5.2 mozilla-central unit test on 2009/05/22 01:55:57
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242982935.1242988936.17564.gz
OS X 10.5.2 mozilla-central unit test on 2009/05/22 02:02:15
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242983439.1242988836.17364.gz
OS X 10.5.2 mozilla-central unit test on 2009/05/22 02:10:39
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242975357.1242982382.6187.gz
WINNT 5.2 mozilla-central unit test on 2009/05/21 23:55:57
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242982557.1242988885.17499.gz
WINNT 5.2 mozilla-central unit test on 2009/05/22 01:55:57
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242982935.1242987423.15259.gz
WINNT 5.2 mozilla-central unit test on 2009/05/22 02:02:15
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242983439.1242990674.20877.gz
WINNT 5.2 mozilla-central unit test on 2009/05/22 02:10:39
299/13245/0 L-FAIL
}

***

Today's case trigger is obviously bug 486899 comment 78.

Comment 4

[Serge Gautherie (:sgautherie)]

I filed bug 494397: I don't know if it explains it all or not (yet).

Comment 5

[Serge Gautherie (:sgautherie)]

(In reply to comment #3)

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242975357.1242982382.6187.gz
> WINNT 5.2 mozilla-central unit test on 2009/05/21 23:55:57

I can reproduce with this build:
http://stage.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32-unittest/1242975545/


(In reply to comment #4)

> I filed bug 494397

The patch there seems to prevent from crashing :-)

> I don't know if it explains it all or not (yet).

Yet, from the UI, it looks like there is a "thread" which keeps running and increasing the Failed count (until the browser is closed),
so both Passed+Failed counts are off and don't match log :-/

Comment 6

[Serge Gautherie (:sgautherie)]

(In reply to comment #3)

Ftr, the log is
{
*** 321 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/a11y/accessible/test_elm_media.html | Test timed out.
}
and "Error thrown during test: nsIAccessibleEvent is not defined - got 0, expected 1" on "all" following tests.

(In reply to comment #5)

> Yet, from the UI, it looks like there is a "thread" which keeps running and
> increasing the Failed count (until the browser is closed),

All runs fine with s/testActions(actions);/SimpleTest.finish();/ in test_elm_media.html.

Ftr, the code actually reads:
{
      testActions(actions); // Will call SimpleTest.finish();
}

> so both Passed+Failed counts are off and don't match log :-/

'Passed' is wrong without '--close-when-done' only.

***

With bug 494397 patch applied, I try to add some try+catch here and there but without much success: I get errors like
{
nsIAccessibleEvent is not defined

SimpleTest is not defined

MozillaFileLogger._foStream is null(!?) in MozillaFileLogger._foStream.write(data, data.length);
}

I don't know what is actually going on,
but it looks like calling |SimpleTest.finish()| when the timeout fires does switch to the next test, but is not enough to fully stop what test_elm_media.html was doing :-(

I don't know whether the test or the harness is to blame, nor what we could do about it.

Comment 7

[Serge Gautherie (:sgautherie)]

(In reply to comment #6)
> but it looks like calling |SimpleTest.finish()| when the timeout fires does

I would guess this is fine for a test which has stopped running: probably waiting on some event which is not occurring or something,

> switch to the next test, but is not enough to fully stop what
> test_elm_media.html was doing :-(

but helpless to stop an (background) endless loop or the like.

> I don't know whether the test or the harness is to blame, nor what we could do
> about it.

If I'm right,
can we do more than update the error message to something like
"timed out, expect failures/etc if test was not actually stalled"?

Comment 8

[Serge Gautherie (:sgautherie)]

(In reply to comment #1)
> http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242296338.1242303502.9342.gz&fulltext=1
> Linux mozilla-central unit test on 2009/05/14 03:18:58

It looks like |make upload| was not (yet) run for this build,
at least, it's not available (anymore).

> Impossible to tell unless it would be reproducible :-|

Difference with current case:
test_events_tree.xul failed but was not timed out by the harness.

Similarities with current case:
"All" following tests had
"Error thrown during test: this.mEventSeq is null - got 0, expected 1"
so, afaik currently, I would assume this was very bug 494397.

Comment 9

[Serge Gautherie (:sgautherie)]

Attachment: (Av1) Report timeout value and threshold, and warn

Per comment 7.

Comment 10

[Serge Gautherie (:sgautherie)]

Ping for review.

Comment 11

[Serge Gautherie (:sgautherie)]

rcampbell, ping for review ?

Comment 12

[Rob Campbell [:rc] (:robcee)]

Comment on attachment 379287 [details] [diff] [review]
(Av1) Report timeout value and threshold, and warn

this doesn't actually introduce any value.

Comment 13

[Serge Gautherie (:sgautherie)]

[
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1256785900.1256791549.21285.gz
Linux mozilla-central test debug everythingelse on 2009/10/28 20:11:40

1889 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/a11y/accessible/test_name_nsRootAcc.xul | Test timed out.
1896 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/a11y/accessible/test_nsIAccessNode_utils.html | [SimpleTest/SimpleTest.js, window.onerror] An error occurred - nsIAccessibleEvent is not defined at chrome://mochikit/content/a11y/accessible/events.js:766
1900 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/a11y/accessible/test_nsIAccessibleDocument.html | [SimpleTest/SimpleTest.js, window.onerror] An error occurred - nsIAccessibleEvent is not defined at chrome://mochikit/content/a11y/accessible/events.js:766
[...]

mochitest-a11y: 6146/51897/5
]

Comment 14

[Phil Ringnalda (:philor)]

Not that I know how to fix it, but, it would be lovely if someone did - because we suck, we hardly ever actually report new intermittent failures, but we're much, much worse about not reporting a11y failures because they seem so ridiculous and rather than look at the one that started the cascade, we just look at the entirety of the spew and then ignore it completely.

Comment 15

[Serge Gautherie (:sgautherie)]

From recently filed bugs (on reproducible failures), I get the feeling that the accessible harness does have a flaw in handling failing tests.
Work has been done on other test suites to separate as much as possible each test from "leaking" to the next one: I would assume the a11y test suite needs something (more) like that too.

Comment 16

[alexander :surkov (:asurkov)]

(In reply to comment #15)
> From recently filed bugs (on reproducible failures), I get the feeling that the
> accessible harness does have a flaw in handling failing tests.
> Work has been done on other test suites to separate as much as possible each
> test from "leaking" to the next one: I would assume the a11y test suite needs
> something (more) like that too.

Right. It might be because we observe the a11y events (via observer service) and when something bad happens we don't stop the observation.

Comment 17

[Serge Gautherie (:sgautherie)]

Attachment: (Bv1) Fix potential edge case in listenA11yEvents()

Not causing this bug,
but improves/fixes somewhat-related code from bug 469985.

Comment 18

[Serge Gautherie (:sgautherie)]

Attachment: (Cv1) Catch the exception in gA11yEventObserver.observe()

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.3a1pre) Gecko/20100203 SeaMonkey/2.1a1pre] (home, optim default) (W2Ksp4)

With this "fix", failure count drops from 200+k to the "expected" 5 :->

I'm not sure how the a11y harness works in details.
I would have liked a solution with some kind of proper cleanup of the observer (etc) but I don't know if/how that would be possible.
I would also have liked to report this "failure", but it looks like the implicit context is +/- empty: listenA11yEvents(), Components, ok(), ..., are all undefined :-/

In short, there might be (or not) room for improvement (in a follow-up bug), but I suggest to take this (at least ftb).

Comment 19

[alexander :surkov (:asurkov)]

Comment on attachment 425106 [details] [diff] [review]
(Bv1) Fix potential edge case in listenA11yEvents()


> function listenA11yEvents(aStartToListen)
> {
>-  if (aStartToListen && !gObserverService) {
>-    gObserverService = Components.classes["@mozilla.org/observer-service;1"].
>-      getService(nsIObserverService);
>-    
>-    gObserverService.addObserver(gA11yEventObserver, "accessible-event",
>-                                 false);
>-  } else if (!gA11yEventApplicantsCount) {
>-    gObserverService.removeObserver(gA11yEventObserver,
>-                                    "accessible-event");
>+  if (aStartToListen) {
>+    // Add observer once only.

Could you describe what you want to address here?. Why do we not want to remove observer if aStartToListen is true but there is no registered listeners? I think this case is kind of error and we should report an error or something.

please reask review when comments are addressed

Comment 20

[alexander :surkov (:asurkov)]

Comment on attachment 425128 [details] [diff] [review]
(Cv1) Catch the exception in gA11yEventObserver.observe()


>-    var event = aSubject.QueryInterface(nsIAccessibleEvent);
>+    var event;
>+    try {
>+      event = aSubject.QueryInterface(nsIAccessibleEvent);
>+    } catch (ex) {
>+      // When a test is aborted (i.e. timed out by the harness), it then gets here.
>+      // We need to catch this exception, otherwise it leaks to all the following tests.
>+      return;

I think we want to throw an exception because we can't use ok(false) here because the test was unloaded but we really want to see an error in the error console, of course exception should be more sensible than nsIAccessibleEvent is undefined. So you need something like

try { } 
catch (e) { throw "blabla"; }

Also we must stop the observer.

I expect to see new patch, canceling review.

Comment 21

[Serge Gautherie (:sgautherie)]

(In reply to comment #20)
> catch (e) { throw "blabla"; }
> 
> Also we must stop the observer.

As I tried to say, I fully agree with the idea, but I don't know how to achieve the latter, hence I can't do the former yet either:
helpwanted.

Comment 22

[alexander :surkov (:asurkov)]

(In reply to comment #21)
> (In reply to comment #20)
> > catch (e) { throw "blabla"; }
> > 
> > Also we must stop the observer.
> 
> As I tried to say, I fully agree with the idea, but I don't know how to achieve
> the latter, hence I can't do the former yet either:
> helpwanted.

Probably I missed but can you access gObserverService inside of gA11yEventObserver? If gA11yEventObserver is alive then the object pointed by gObserverService should live too. We could put gObserverService into members of gA11yEventObserver if this variable is destroyed due to some reasons.

Comment 23

[Serge Gautherie (:sgautherie)]

(In reply to comment #19)

> Could you describe what you want to address here?. Why do we not want to remove

|if (aStartToListen && !gObserverService)| is what triggered my attention:
in this patch, I am assuming (but I may be wrong at that) that |!gObserverService| is only meant to protect |addObserver()| and should not change |aStartToListen|-related behavior.

> observer if aStartToListen is true but there is no registered listeners? I

As I said, I don't know the details of how all this works,
I'm just assuming (again) that specifying |aStartToListen = true| and executing |removeObserver()| is unexpected: either the param is misnamed or the caller has a logic flaw, no?

> think this case is kind of error and we should report an error or something.

Probably: using |throw|!?

Comment 24

[alexander :surkov (:asurkov)]

(In reply to comment #23)
> (In reply to comment #19)
> 
> > Could you describe what you want to address here?. Why do we not want to remove
> 
> |if (aStartToListen && !gObserverService)| is what triggered my attention:
> in this patch, I am assuming (but I may be wrong at that) that
> |!gObserverService| is only meant to protect |addObserver()| and should not
> change |aStartToListen|-related behavior.
> 
> > observer if aStartToListen is true but there is no registered listeners? I
> 
> As I said, I don't know the details of how all this works,
> I'm just assuming (again) that specifying |aStartToListen = true| and executing
> |removeObserver()| is unexpected: either the param is misnamed or the caller
> has a logic flaw, no?

Yes, it makes sense.

> > think this case is kind of error and we should report an error or something.
> 
> Probably: using |throw|!?

Yes, I meant the throw statement.

Comment 25

[alexander :surkov (:asurkov)]

Comment on attachment 425106 [details] [diff] [review]
(Bv1) Fix potential edge case in listenA11yEvents()

Ok, I think it's nice code clean up. Thanks.

Comment 26

[Serge Gautherie (:sgautherie)]

(In reply to comment #5)
> > I filed bug 494397
> 
> The patch there seems to prevent from crashing :-)

Moving 'crash' keyword to that bug.

Comment 27

[Serge Gautherie (:sgautherie)]

Attachment: (Cv2) Remove leftover observer [Checkin: Comment 30 & 36]

Cv1, with comment 22 suggestion(s).

With this patch I get (only):
{
2941 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/a11y/accessible/test_name_nsRootAcc.xul | Test timed out.
[...]
2951 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/a11y/accessible/test_nsIAccessNode_utils.html | [SimpleTest/SimpleTest.js, window.onerror] An error occurred - uncaught exception: [accessible/events.js, gA11yEventObserver.observe] This is expected if a previous test has been aborted... Initial exception was: [ ReferenceError: nsIAccessibleEvent is not defined ] at :0
}
;-)

NB: I'll work on a new patch B after this one, as they touch the same code.

Comment 28

[alexander :surkov (:asurkov)]

Comment on attachment 425224 [details] [diff] [review]
(Cv2) Remove leftover observer
[Checkin: Comment 30 & 36]


>-    var event = aSubject.QueryInterface(nsIAccessibleEvent);
>+    var event;
>+    try {
>+      event = aSubject.QueryInterface(nsIAccessibleEvent);
>+    } catch (ex) {
>+      // After a test is aborted (i.e. timed out by the harness), this exception is soon triggered.
>+      // Remove the leftover observer, otherwise it "leaks" to all the following tests.
>+      this.observerService.removeObserver(this, "accessible-event");

it makes sense to null it I think.

> function listenA11yEvents(aStartToListen)
> {
>-  if (aStartToListen && !gObserverService) {
>-    gObserverService = Components.classes["@mozilla.org/observer-service;1"].
>-      getService(nsIObserverService);
>+  if (aStartToListen && !gA11yEventObserver.observerService) {

I would be more happy if you move registration events logic into gA11yEventObserver completely (at least the observer service creation). But it's up to you, just please file following up bug for this if you don't have time for this.

Thanks you work on this!

Comment 29

[alexander :surkov (:asurkov)]

(In reply to comment #27)

> NB: I'll work on a new patch B after this one, as they touch the same code.

mercurial queue is your friend :)

Comment 30

[Serge Gautherie (:sgautherie)]

Comment on attachment 425224 [details] [diff] [review]
(Cv2) Remove leftover observer
[Checkin: Comment 30 & 36]


http://hg.mozilla.org/mozilla-central/rev/094a2d7f3a6b

Comment 31

[Serge Gautherie (:sgautherie)]

Attachment: (Bv2) Fix potential edge cases in listenA11yEvents() [Checkin: Comment 39 & 37 & 40]

Bv1, with comment 24 and comment 28 suggestion(s).

That's all I had intended to fix actually ;-)

(In reply to comment #24)
> > Probably: using |throw|!?
> 
> Yes, I meant the throw statement.

Done.
NB: Coding this one explicitly would be bloat, I think.

(In reply to comment #28)

> it makes sense to null it I think.

No need (anymore): garbage collector should be enough.

> I would be more happy if you move registration events logic into
> gA11yEventObserver completely (at least the observer service creation). But
> it's up to you, just please file following up bug for this if you don't have
> time for this.

This patch moves the observer service creation.
I let you file the other bug about code rewrite.

(In reply to comment #29)
> mercurial queue is your friend :)

Indeed, but it doesn't help much when modifying the very same lines :->

Comment 32

[Serge Gautherie (:sgautherie)]

(In reply to comment #30)
> http://hg.mozilla.org/mozilla-central/rev/094a2d7f3a6b

V.Fixed, per
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1265319973.1265321945.10606.gz
Linux comm-central-trunk debug test mochitest-other on 2010/02/04 13:46:13

Comment 33

[alexander :surkov (:asurkov)]

(In reply to comment #31)

> > it makes sense to null it I think.
> 
> No need (anymore): garbage collector should be enough.

Yep, but the garbage collector mostly is a protection from author mistakes. I prefer to null the reference when it's possible. Why do we need to assign the work to garbage collector when we can do it on own side.

> > I would be more happy if you move registration events logic into
> > gA11yEventObserver completely (at least the observer service creation). But
> > it's up to you, just please file following up bug for this if you don't have
> > time for this.
> 
> This patch moves the observer service creation.
> I let you file the other bug about code rewrite.

You move forward to keep me happy so possibly it's not needed to file a bug :)

> 
> (In reply to comment #29)
> > mercurial queue is your friend :)
> 
> Indeed, but it doesn't help much when modifying the very same lines :->

I wouldn't agree. This is what mq is about. Just put patches in stack. I'm fine to review patches based on other patches. At least if taken approach is correct then it don't require big merging.

Comment 34

[alexander :surkov (:asurkov)]

Comment on attachment 425250 [details] [diff] [review]
(Bv2) Fix potential edge cases in listenA11yEvents()
[Checkin: Comment 39 & 37 & 40]

r=me

but I would move global variables and listenA11yEvents/addA11yEventListener/removeA11yEventListener into gA11yEventObserver.

gA11yEventObserver might make sense to rename gA11yEventManager and rename methods to listenEvents(), addListener(), removeListener().

I think, something like.

Comment 35

[Serge Gautherie (:sgautherie)]

(In reply to comment #33)

> Yep, but the garbage collector mostly is a protection from author mistakes. I
> prefer to null the reference when it's possible. Why do we need to assign the
> work to garbage collector when we can do it on own side.

(It's more a different paradigm: code less (hopefully making less mistakes!), let the tool do its (optimized) job.)
In this case, manually nulling the service would mean to explicitly maintain code to get it again if need be.
I do prefer to let you look into this in a follow-up patch if you do want it that way.

> You move forward to keep me happy so possibly it's not needed to file a bug :)

Thanks :-)
But I really meant to fix actual issues only and I'm looking forward to eventually close this bug: a new bug with a new assignee is best in this case.

> I wouldn't agree. This is what mq is about. Just put patches in stack. I'm fine
> to review patches based on other patches. At least if taken approach is correct
> then it don't require big merging.

(I known. I was speaking on my side: the less merging I do the better.)

(In reply to comment #34)

As I suggested, please move all code style improvements to a follow-up bug.

Comment 36

[Serge Gautherie (:sgautherie)]

Comment on attachment 425224 [details] [diff] [review]
(Cv2) Remove leftover observer
[Checkin: Comment 30 & 36]


http://hg.mozilla.org/releases/mozilla-1.9.2/rev/80b973df6483
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/578153e09de4

Comment 37

[Serge Gautherie (:sgautherie)]

Comment on attachment 425250 [details] [diff] [review]
(Bv2) Fix potential edge cases in listenA11yEvents()
[Checkin: Comment 39 & 37 & 40]


http://hg.mozilla.org/releases/mozilla-1.9.2/rev/0997309eb779

Comment 38

[Serge Gautherie (:sgautherie)]

Comment on attachment 379287 [details] [diff] [review]
(Av1) Report timeout value and threshold, and warn


(In reply to comment #12)
> this doesn't actually introduce any value.

Well...

Comment 39

[Serge Gautherie (:sgautherie)]

Comment on attachment 425250 [details] [diff] [review]
(Bv2) Fix potential edge cases in listenA11yEvents()
[Checkin: Comment 39 & 37 & 40]


http://hg.mozilla.org/mozilla-central/rev/3aceac092202

Comment 40

[Serge Gautherie (:sgautherie)]

Comment on attachment 425250 [details] [diff] [review]
(Bv2) Fix potential edge cases in listenA11yEvents()
[Checkin: Comment 39 & 37 & 40]


http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d217f3c28332