Closed Bug 623962 Opened 11 years ago Closed 11 years ago

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

Categories

(Mozilla QA Graveyard :: Mozmill Tests, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: u279076, Assigned: u279076)

References

()

Details

(Whiteboard: [mozmill-test-failure])

Attachments

(1 file, 2 obsolete files)

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
Whiteboard: [mozmill-test-failure]
Assignee: nobody → anthony.s.hughes
Status: NEW → ASSIGNED
I'm seeing a different error, perhaps related

Recent failure 01/12
http://mozmill-release.brasstacks.mozilla.com/#/general/report/1d2bdcae68748c40bbb8042717cb7a9c
Can we get some progress on this failure? It does not happen all the time but should probably reproducible. Anthony what is your ETA?
Summary: Timeout failure in testDownloadStates.js → Timeout exceeded for 'subject.manager.getDownloadState(subject.download) == subject.state' in testDownloadStates.js
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?
(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.
Attached patch Patch v1 (obsolete) — Splinter Review
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.
Attachment #507573 - Flags: review?(aaron.train)
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?
Attachment #507573 - Flags: review?(aaron.train) → review-
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.
(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.
Attached patch Patch v2 (obsolete) — Splinter Review
Commented code removed and error message refactored.
Attachment #507573 - Attachment is obsolete: true
Attachment #507591 - Flags: review?(aaron.train)
Attachment #507591 - Flags: review?(aaron.train) → review+
Comment on attachment 507591 [details] [diff] [review]
Patch v2

Can you please spotcheck this patch, Henrik?
Attachment #507591 - Flags: review?(hskupin)
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.
Attachment #507591 - Flags: review?(hskupin) → review+
Probably we have two different failures here in this test.
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.
Attachment #507591 - Attachment is obsolete: true
Attachment #507770 - Flags: review+
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]
Attachment #507770 - Attachment description: Patch v2.1 → Patch v2.1 [checked-in]
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.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Happened yesterday during release testing of b11 on Mac:
http://mozmill-release.brasstacks.mozilla.com/#/general/report/00edfccff35537bd5dcddb512919d75b
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(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.
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
See bug 631246
(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.
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.