Closed
Bug 623962
Opened 14 years ago
Closed 14 years ago
Timeout exceeded for 'subject.manager.getDownloadState(subject.download) == subject.state' in testDownloadStates.js
Categories
(Mozilla QA Graveyard :: Mozmill Tests, defect)
Mozilla QA Graveyard
Mozmill Tests
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: u279076, Assigned: u279076)
References
()
Details
(Whiteboard: [mozmill-test-failure])
Attachments
(1 file, 2 obsolete files)
1.64 KB,
patch
|
u279076
:
review+
|
Details | Diff | Splinter Review |
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•14 years ago
|
||
I'm seeing a different error, perhaps related Recent failure 01/12 http://mozmill-release.brasstacks.mozilla.com/#/general/report/1d2bdcae68748c40bbb8042717cb7a9c
Comment 2•14 years ago
|
||
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.
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 6•14 years ago
|
||
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-
Comment 7•14 years ago
|
||
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.
Commented code removed and error message refactored.
Attachment #507573 -
Attachment is obsolete: true
Attachment #507591 -
Flags: review?(aaron.train)
Updated•14 years ago
|
Attachment #507591 -
Flags: review?(aaron.train) → review+
Assignee | ||
Comment 10•14 years ago
|
||
Comment on attachment 507591 [details] [diff] [review] Patch v2 Can you please spotcheck this patch, Henrik?
Attachment #507591 -
Flags: review?(hskupin)
Comment 11•14 years ago
|
||
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+
Comment 12•14 years ago
|
||
Probably we have two different failures here in this test.
Assignee | ||
Comment 13•14 years ago
|
||
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+
Assignee | ||
Comment 14•14 years ago
|
||
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]
Assignee | ||
Comment 15•14 years ago
|
||
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: 14 years ago
Resolution: --- → FIXED
Comment 16•14 years ago
|
||
Happened yesterday during release testing of b11 on Mac: http://mozmill-release.brasstacks.mozilla.com/#/general/report/00edfccff35537bd5dcddb512919d75b
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 17•14 years ago
|
||
(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: 14 years ago → 14 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 18•14 years ago
|
||
See bug 631246
Comment 19•14 years ago
|
||
(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.
Updated•5 years ago
|
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•