Closed Bug 450807 Opened 16 years ago Closed 15 years ago

[Windows] xpcshell-tests: test_bug_401430.js fails intermittently


(Toolkit :: Downloads API, defect)

Windows Vista
Not set



Tracking Status
status1.9.2 --- .13-fixed
status1.9.1 --- .16-fixed


(Reporter: sdwilsh, Assigned: mak)




(Keywords: intermittent-failure)


(1 file)

The test is failing - could be not a long enough timeout, but it is a hardware box, so I'm suspect of that.
Whiteboard: [orange]
WINNT 5.2 comm-1.9.1 unit test on 2009/06/12 13:36:30

TEST-UNEXPECTED-FAIL | e:\builds\slave\comm-1.9.1-win32-unittest\build\objdir\mozilla\_tests\xpcshell\test_dm\unit\test_bug_401430.js | false == true - See following stack:
JS frame :: e:\builds\slave\comm-1.9.1-win32-unittest\build\objdir\mozilla\_tests\xpcshell\test_dm\unit\test_bug_401430.js :: checkResult :: line 46

Code is:
45 function checkResult() {
46   do_check_true(checkRecentDocsFor(resultFileName));
Summary: test_bug_401430.js fails → [Windows] xpcshell-tests: test_bug_401430.js fails intermittently
WINNT 5.2 mozilla-central test everythingelse [testfailed] Started 15:32, finished 16:09
This test has been touched by Ted, Gavin and Ehsan, and is still failing. Any of you three have thoughts?
WINNT 5.2 mozilla-1.9.2 test everythingelse on 2009/09/29 04:12:41
My changes were mostly just a tree-wide refactoring, and then a followup fix to the test as fallout from that. The test checks that downloaded files get put into the "Recent Documents" list. My refactoring change accidentally caused the file to get downloaded to $TEMP, which apparently means the file doesn't go into "Recent Documents", so I changed the test to download to the test directory instead.

The test uses an arbitrarily-chosen 1000ms timeout, because apparently the change to the registry in response to the SHAddToRecentDocs call doesn't happen synchronously (our registry APIs can't get the new value immediately, anyways).

I'm not sure that there's much we can do to address this besides removing the test or just increasing the timeout.
we can use a polling strategy, check after 1000ms, if it's not present check again after 500ms or so, till we reach a max timing of 5s.
taking to try polling.
Assignee: nobody → mak77
Attachment #405495 - Flags: review? → review?(edilee)
Comment on attachment 405495 [details] [diff] [review]
patch v1.0
[Checked in: Comment 18 & 20 & 21]

>--- a/toolkit/components/downloads/test/unit/test_bug_401430.js
> function checkResult() {
>   // delete the saved file (this doesn't affect the "recent documents" list)
>   var resultFile = do_get_file(resultFileName);
>   resultFile.remove(false);
>+  // Need to poll RecentDocs value because the SHAddToRecentDocs call
>+  // doesn't update the registry immediately.
>+  do_timeout(POLL_REGISTRY_TIMEOUT, "pollRecentDocs();");
I suppose you could just call pollRecentDocs() instead of on a timeout, but you can leave as is.

Attachment #405495 - Flags: review?(edilee) → review+
yes but i prefer giving some breath to the main thread in tests, and i really doubt the value will be in the registry immediately. so i did that
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
status1.9.1: --- → ?
Flags: wanted1.9.2?
Flags: in-testsuite+
Bug still on m-1.9.1:
WINNT 5.2 comm-1.9.1 unit test on 2010/08/31 09:31:57
Comment on attachment 405495 [details] [diff] [review]
patch v1.0
[Checked in: Comment 18 & 20 & 21]
Attachment #405495 - Attachment description: patch v1.0 → patch v1.0 [Checked in: Comment 18 & 20]
Flags: wanted1.9.2?
Comment on attachment 405495 [details] [diff] [review]
patch v1.0
[Checked in: Comment 18 & 20 & 21]
Attachment #405495 - Attachment description: patch v1.0 [Checked in: Comment 18 & 20] → patch v1.0 [Checked in: Comment 18 & 20 & 21]
Depends on: 607005
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.