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

VERIFIED FIXED in mozilla1.9.3a2

Status

defect
--
major
VERIFIED FIXED
10 years ago
7 years ago

People

(Reporter: ted, Assigned: sgautherie)

Tracking

(Blocks 2 bugs, {autotest-issue})

Trunk
mozilla1.9.3a2
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixed1.9.2.1 fixed1.9.1.9], )

Attachments

(2 attachments, 3 obsolete attachments)

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.
Assignee

Comment 1

10 years ago
(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 :-|
Blocks: 451287
OS: Windows XP → Linux
Version: unspecified → Trunk
Assignee

Updated

10 years ago
Summary: mochitest a11y failed, mochitest reports huge numbers for pass/fail → mochitest-a11y failed, summary reports unexpected huge numbers for pass/fail
Assignee

Comment 2

10 years ago
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'.
Blocks: 438871
OS: Linux → All
Whiteboard: [orange]
Assignee

Comment 3

10 years ago
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.
No longer blocks: 438871
Severity: normal → major
Depends on: 486899
Hardware: x86 → All
Whiteboard: [orange]
Assignee

Updated

10 years ago
Blocks: 486899
Depends on: 462338
No longer depends on: 486899
Assignee

Comment 4

10 years ago
I filed bug 494397: I don't know if it explains it all or not (yet).
Depends on: 494397
No longer depends on: 462338
Assignee

Comment 5

10 years ago
(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 :-/
Assignee

Comment 6

10 years ago
(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.
Assignee

Comment 7

10 years ago
(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"?
Assignee

Comment 8

10 years ago
(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.
Assignee

Updated

10 years ago
Keywords: crash
Assignee

Comment 9

10 years ago
Per comment 7.
Assignee: nobody → sgautherie.bz
Status: NEW → ASSIGNED
Attachment #379287 - Flags: review?(rcampbell)
Assignee

Comment 10

10 years ago
Ping for review.
Assignee

Comment 11

10 years ago
rcampbell, ping for review ?
Attachment #379287 - Flags: review?(rcampbell) → review-
Comment on attachment 379287 [details] [diff] [review]
(Av1) Report timeout value and threshold, and warn

this doesn't actually introduce any value.
Assignee

Updated

10 years ago
Blocks: 513605
Assignee

Comment 13

10 years ago
[
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
]
Assignee

Updated

10 years ago
Blocks: 525175
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.
Assignee

Updated

10 years ago
Blocks: 535891
Assignee

Updated

9 years ago
Blocks: a11ytestdev
Assignee

Updated

9 years ago
Blocks: 542726
Assignee

Comment 15

9 years ago
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.
Assignee: sgautherie.bz → nobody
Status: ASSIGNED → NEW
(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.
Assignee

Comment 17

9 years ago
Not causing this bug,
but improves/fixes somewhat-related code from bug 469985.
Attachment #425106 - Flags: review?(surkov.alexander)
Assignee

Updated

9 years ago
Depends on: 469985
Assignee

Comment 18

9 years ago
[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).
Attachment #425128 - Flags: review?(surkov.alexander)
Assignee

Updated

9 years ago
Depends on: 452710
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
Attachment #425106 - Flags: review?(surkov.alexander)
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.
Attachment #425128 - Flags: review?(surkov.alexander)
Assignee

Comment 21

9 years ago
(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.
(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.
Assignee

Comment 23

9 years ago
(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|!?
(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 on attachment 425106 [details] [diff] [review]
(Bv1) Fix potential edge case in listenA11yEvents()

Ok, I think it's nice code clean up. Thanks.
Attachment #425106 - Flags: review+
Assignee

Comment 26

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

Moving 'crash' keyword to that bug.
Assignee: nobody → sgautherie.bz
Status: NEW → ASSIGNED
Flags: in-testsuite-
Keywords: crashautotest-issue
Target Milestone: --- → mozilla1.9.3a1
Assignee

Comment 27

9 years ago
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.
Attachment #425128 - Attachment is obsolete: true
Attachment #425224 - Flags: review?(surkov.alexander)
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!
Attachment #425224 - Flags: review?(surkov.alexander) → review+
(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 :)
Assignee

Updated

9 years ago
Attachment #425224 - Attachment description: (Cv2) Remove leftover observer → (Cv2) Remove leftover observer [Checkin: Comment 30]
Assignee

Comment 31

9 years ago
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 :->
Attachment #425106 - Attachment is obsolete: true
Attachment #425250 - Flags: review?(surkov.alexander)
Assignee

Comment 32

9 years ago
(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
(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 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.
Attachment #425250 - Flags: review?(surkov.alexander) → review+
Assignee

Comment 35

9 years ago
(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.
Keywords: checkin-needed
Whiteboard: [c-n: m-c after 1.9.3a1 freeze]
Assignee

Comment 36

9 years ago
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
Attachment #425224 - Attachment description: (Cv2) Remove leftover observer [Checkin: Comment 30] → (Cv2) Remove leftover observer [Checkin: Comment 30 & 36]
Assignee

Comment 37

9 years ago
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
Attachment #425250 - Attachment description: (Bv2) Fix potential edge cases in listenA11yEvents() → (Bv2) Fix potential edge cases in listenA11yEvents() [Checkin: Comment 37]
Assignee

Comment 38

9 years ago
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...
Attachment #379287 - Attachment is obsolete: true
Assignee

Updated

9 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Assignee

Updated

9 years ago
Status: RESOLVED → VERIFIED
Assignee

Updated

9 years ago
Blocks: 482261
Assignee

Comment 39

9 years ago
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
Attachment #425250 - Attachment description: (Bv2) Fix potential edge cases in listenA11yEvents() [Checkin: Comment 37] → (Bv2) Fix potential edge cases in listenA11yEvents() [Checkin: Comment 39 & 37]
Assignee

Updated

9 years ago
Keywords: checkin-needed
Whiteboard: [c-n: m-c after 1.9.3a1 freeze] → [fixed1.9.2.1 fixed1.9.1.9]
Assignee

Comment 40

9 years ago
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
Attachment #425250 - Attachment description: (Bv2) Fix potential edge cases in listenA11yEvents() [Checkin: Comment 39 & 37] → (Bv2) Fix potential edge cases in listenA11yEvents() [Checkin: Comment 39 & 37 & 40]
Assignee

Updated

9 years ago
Whiteboard: [fixed1.9.2.1 fixed1.9.1.9] → [fixed1.9.3a2; fixed1.9.2.1 fixed1.9.1.9]
Assignee

Updated

9 years ago
Whiteboard: [fixed1.9.3a2; fixed1.9.2.1 fixed1.9.1.9] → [fixed1.9.3a2 in fact; fixed1.9.2.1 fixed1.9.1.9]
Assignee

Updated

9 years ago
Whiteboard: [fixed1.9.3a2 in fact; fixed1.9.2.1 fixed1.9.1.9] → [fixed1.9.2.1 fixed1.9.1.9]
Target Milestone: mozilla1.9.3a1 → mozilla1.9.3a2
Assignee

Updated

7 years ago
Summary: mochitest-a11y failed, summary reports unexpected huge numbers for pass/fail → mochitest-a11y failed, summary reports unexpected huge numbers for pass/fail. ("nsIAccessibleEvent is not defined")
Assignee

Updated

7 years ago
Blocks: 718239
You need to log in before you can comment on or make changes to this bug.