599204 - intermittent test timeout in test-window-utils

Status: RESOLVED FIXED

(Add-on SDK Graveyard :: General, defect, P1)

Description

[Brian Warner [:warner :bwarner]]

I'm seeing an intermittent test timeout when running current jetpack-sdk trunk against a firefox-3.6.10 on my OS-X box. Running "cfx testall" gets a single failure:

error: TEST FAILED: test-window-utils.testActiveWindow (timed out)

In bug 598525, the neighboring test-windows.js was changed to skip the test when running against 3.6.* . Maybe test-window-utils.js needs a similar change?

Comment 2

[Brian Warner [:warner :bwarner]]

oh, Atul pointed out that this might occur when I switched windows during the test (like, when I switched back to the shell in which I ran 'cfx testall' to watch its progress scroll by). Maybe firefox is detecting the unfocus transition and it interferes with whatever the test is checking.

A casual test (N=2) vaguely seems to support this.

Comment 3

[Myk Melez [:myk] [@mykmelez]]

The Add-on SDK is no longer a Mozilla Labs experiment and has become a big enough project to warrant its own Bugzilla product, so the "Add-on SDK" product has been created for it, and I am moving its bugs to that product.

To filter bugmail related to this change, filter on the word "looptid".

Comment 4

[Myk Melez [:myk] [@mykmelez]]

The tests don't work at all on Firefox 3.6 these days.  Brian: can you reproduce on 4.0 builds?

Comment 5

[Alexandre Poirot [:ochameau]]

This test is very very close to the test failing in bug 614079 that is known to fail really often on linux.

And yes, user interaction during test execution *is going* to make the test fails!

Comment 7

[Myk Melez [:myk] [@mykmelez]]

We can either fix the test or disable it, but we have to squash all intermittent test failures so Firefox/Gecko developers can rely on our automated test infrastructure to tell them when they do something that breaks the SDK.

Comment 9

[Brian Warner [:warner :bwarner]]

I just spent 15 minutes trying to reproduce this against FF4.0.1 on OS-X, both letting the test run undisturbed (the recommended way) and also selecting the new browser window while tests proceed (certainly not recommended, but possibly a trigger for this problem), and also with a couple of "while 1: pass" CPU-burners running in the background. I was unable to trigger the failure.

So I'm going to close this one as FIXED, because I'm pretty sure it was happening back in september, and it doesn't seem to be happening now. It might have fixed by something in the SDK, or because we're no longer testing it against FF3.6, or because I've learned to not touch my computer while the tests are running: not sure which, but I guess it doesn't matter too much.