Closed Bug 506625 Opened 10 years ago Closed 10 years ago

mozmill bloat test has (gratuitous) sleep delays


(Thunderbird :: General, defect)

Not set


(Not tracked)

Thunderbird 3.0b4


(Reporter: asuth, Assigned: standard8)



(1 file)

There are 20 seconds of sleep statements in mail/test/mozmill/bloat/test_openWindow.js.  There should be none.  Everything should be event/waitFor driven.
This was originally brought over from the mailnews bloat tests where we couldn't do event/waitFor driven - mainly because there were no suitable events to say "this window has completely finished loading and is displayed".

If any changes are made here, then they must be tested on a trace-malloc enabled build with trace-malloc logging turned on just like the tinderbox, and preferably on a slower box or VM - if we swap to these tests in future, we must be able to let these windows open fully to allow correct set up and measurement to take place.
test-window-display-helpers.js provides logic that makes sure a window has completed loading.  It includes a sleep(0) spin to ensure that setTimeout(blah, 0) calls from the load process have had a chance to run.  The difficulty is that setTimeout(blah, 0) calls which make more setTimeout(blah, 0) calls are not handled.  We could resolve this by using code that actually spins the event loop until the event loop runs out of events instead of using sleep(0).  The problem would be if this allowed synthetic idle events to happen ad infinitum... we'd probably notice that pretty quickly.

test-folder-display-helpers.js uses this in its setupModule to initialize mainController/mc, so that the module does not return until mail:3pane has finished loading.

Are there any obvious initialization phases in these windows that you are aware of that take place post-document-loaded notification are not the result of setTimeout(blah,0) calls?

My originating concern is that I have started using "make mozmill" to run the mozmill tests when I or others make changes to the UI.  Since running mozmill tests is basically a blocking operation for me because it likes to steal focus, the extra 20 seconds is annoying.  Should we consider doing something with the targets so that the bloat test is not run in an interactive testing situation?  It's not clear what benefit there is running it outside of a bloat-complaining harness.
Until we fix Bug 458352/Bug 500201 there isn't much point in running the bloat tests - we run them as part of the bloat boxes in any case. Therefore let's just disable the bloat section for now, add a comment and we'll fix them up later.
Assignee: nobody → bugzilla
Attachment #390903 - Flags: review?(bugmail)
Attachment #390903 - Flags: review?(bugmail) → review+
Checked in:
Closed: 10 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.0b4
You need to log in before you can comment on or make changes to this bug.