623962 - Timeout exceeded for 'subject.manager.getDownloadState(subject.download) == subject.state' in testDownloadStates.js

Status: VERIFIED FIXED

(Mozilla QA Graveyard :: Mozmill Tests, defect)

Description

[u279076]

MODULE: testDownloading/testDownloadStates.js
TEST: testDownloadStates
ERROR: controller.waitForEval: Timeout exceeded for 'subject.selected == true'
BRANCH: default, mozilla1.9.2
PLATFORM: Linux 10.04, Mac OSX 10.6.5

Comment 1

[Aaron Train [:aaronmt]]

I'm seeing a different error, perhaps related

Recent failure 01/12
http://mozmill-release.brasstacks.mozilla.com/#/general/report/1d2bdcae68748c40bbb8042717cb7a9c

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

Can we get some progress on this failure? It does not happen all the time but should probably reproducible. Anthony what is your ETA?

Comment 3

[u279076]

I've not had time to look at this because I've been focused on testPasswordNotSaved (bug 614973).  Can someone please take this bug over?

Comment 4

[u279076]

(In reply to comment #3)
> I've not had time to look at this because I've been focused on
> testPasswordNotSaved (bug 614973).  Can someone please take this bug over?

I'll now be working on this during downtime of testPasswordNotSaved (bug 614973).  I no longer need someone to take this over.

Comment 5

[u279076]

Attachment: Patch v1

The error has changed slightly since refactoring handleWindow:
controller.waitForEval: Timeout exceeded for 'subject.selected == true'

This error actually occurs in the Downloads shared module.  I've refactored it to use a waitFor() instead.  However, I cannot reproduce this locally or remotely.  I suggest we get this refactor checked in and see where it gets us; using a waitFor instead of waitForEval gives us a more valuable error message for debugging.

Comment 6

[Aaron Train [:aaronmt]]

Comment on attachment 507573 [details] [diff] [review]
Patch v1

We should really make it clear to indicate the state of expected and actual read-only values through the error message. Henrik?

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

It's a boolean so normally not necessary, as long as it is clear for which element we are waiting for. So I would suggest to say add the window, this element resists in. Also please remove the waitForEval and do not only comment it out.

I believe that we show a minimized dialog here, which doesn't have the buttons shown. I have already seen that a couple of times even locally. Could be a timing issue here.

Comment 8

[u279076]

(In reply to comment #7)
> It's a boolean so normally not necessary, as long as it is clear for which
> element we are waiting for. So I would suggest to say add the window, this
> element resists in. Also please remove the waitForEval and do not only comment
> it out.

Thanks for the feedback, Henrik. I left waitForEval in so you could see what I was refactoring.  This patch was not meant as a check-in patch.  I'll implement your suggestions and post a final patch.

Comment 9

[u279076]

Attachment: Patch v2

Commented code removed and error message refactored.

Comment 10

[u279076]

Comment on attachment 507591 [details] [diff] [review]
Patch v2

Can you please spotcheck this patch, Henrik?

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

Comment on attachment 507591 [details] [diff] [review]
Patch v2

Looks fine. Please check it in as soon as you can, so we have the more descriptive information with tomorrows run. Thanks.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

Probably we have two different failures here in this test.

Comment 13

[u279076]

Attachment: Patch v2.1 [checked-in]

Somehow my name got dropped from the User Header even though its in my HGRC.  This patch corrects that small glitch.  Will check-in shortly.

Comment 14

[u279076]

Comment on attachment 507770 [details] [diff] [review]
Patch v2.1 [checked-in]

Landed:
http://hg.mozilla.org/qa/mozmill-tests/rev/658217661d53 [default]
http://hg.mozilla.org/qa/mozmill-tests/rev/ad62cd796e54 [mozilla1.9.2]
http://hg.mozilla.org/qa/mozmill-tests/rev/1ce782a00ef9 [mozilla1.9.1]

Comment 15

[u279076]

I've not seen this failure in the recent testruns.  Marking resolved fixed for now.  If it starts failing again, we can reopen; if it continues to pass, we can mark verified.

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

Happened yesterday during release testing of b11 on Mac:
http://mozmill-release.brasstacks.mozilla.com/#/general/report/00edfccff35537bd5dcddb512919d75b

Comment 17

[u279076]

(In reply to comment #16)
> Happened yesterday during release testing of b11 on Mac:
> http://mozmill-release.brasstacks.mozilla.com/#/general/report/00edfccff35537bd5dcddb512919d75b

The error is now "Save File button is not being selected". I think we should file a new bug. In other words, we should not reopen a bug every time a particular test fails.  I'll file it.

Comment 18

[u279076]

See bug 631246

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

(In reply to comment #17)
> The error is now "Save File button is not being selected". I think we should
> file a new bug. In other words, we should not reopen a bug every time a
> particular test fails.  I'll file it.

It's still the same bug, we only have changed the error message. That doesn't qualify a new bug each time.