Closed Bug 906591 Opened 7 years ago Closed 7 years ago

Test failure "controller(): Window could not be initialized"


(Mozilla QA Graveyard :: Mozmill Tests, defect, P1)



(firefox25 unaffected, firefox26 fixed)

Tracking Status
firefox25 --- unaffected
firefox26 --- fixed


(Reporter: cosmin-malutan, Unassigned)




(Keywords: regression, reproducible, Whiteboard: [mozmill-test-failure])

Happened on Mac OS X 10.6.8 (x86_64) with Nightly it:
I couldn't reproduce it.
This is with the same error like in bug 906599, also on OS X. I wonder if they're somehow related, although I only see one failure over the weekend.
Summary: Test failure "controller(): Window could not be initialized" in /restartTests/testAddons_changeTheme/test2.js → Test failure "controller(): Window could not be initialized" in /restartTests/testAddons_installUninstallHardBlocklistedExtension/test4.js
Whiteboard: [mozmill-test-failure]
Does not look similar in scope to bug 906599, not reproducible.
Most probably external cause.

Let's keep an eye our for this failing the same way.
Assignee: nobody → andrei.eftimie
Priority: -- → P3
If we can't take action on it a bug should not be assigned. Please only assign to bugs you can really work on.
Assignee: andrei.eftimie → nobody
Duplicate of this bug: 907736
We've had several similar failures.

The test itself does not seem that important.
All across restart tests.

We can't properly track this in the dashboard, but here is an attempt:

All these failures are contained to OSX to 10.6 and 10.7
Are not contained to particular machines.

I'm revisiting my stance of this bug being related to bug 906599, might not be a selenium problem after all, but a general problem on OSX.

Also marking bug 907736 as a dupe.
Summary: Test failure "controller(): Window could not be initialized" in /restartTests/testAddons_installUninstallHardBlocklistedExtension/test4.js → Test failure "controller(): Window could not be initialized" across OSX 10.6 and 10.7
Priority: P3 → P2
This reproduces locally on Mac 10.6.8 with Nightly 26 en-US
If it's happening across all 10.6 and 10.7 machines its clearly a P1 which needs to be investigated quickly. If it is a change in Firefox which affects Mozmill, we have to wait with the 1.5.22 release.
Priority: P2 → P1
Does not reproduce with the 16.08 Nightly builds, working on finding the responsible changeset with Tinderbox Inbound builds.
This is the pushlog for the first Nightly build that starts failing that was released on 17.06.2013. I am also able to reproduce this failure locally.

First Dashboard report on 17.08: 

Nightly 26 (17.08.2013) pushlog:
Mario, this is not a pushlog link for all the changes happened between the two builds which don't show the problem and the one which has it included. Please give us the correct link. Sorry, but we mentioned the correct steps a couple of times in the past.
Added the pushlog range from 16.08(Good build) to 17.08(Failing build):
WIP inbound pushlog:

We're still narrowing it down, but since it is slightly intermittent it is going slower than initially expected.
Have you tested one of our affected CI machines if the problem is better reproducible there?
Have not tried on CI, the failure rates we are seeing locally stack up vs the ones we see in daily runs (have not measured them, just an eyeball estimation).

I'll take down a CI machine to see if we get better results there.

Some details on the failure:
controller.waitForPageLoad(); returns true, but we fail immediately as the window has not actually loaded, in fact the window "could not be initialized"

If we put a sleep when closing the window, the failure does not happen.
(we tested this in the selenium fail which fails much more often, but does so on localized builds)

This might suggest that we fail to completely close the window in time when the next test starts. We usually don't specify which document to wait for:
> // If no document has been specified, fallback to the default view of the
> // currently selected tab browser
> win = win || this.browserObject.selectedBrowser.contentWindow;

So if we didn't properly close the last one, we will check the old (closing) one that it has loaded (it has) and move forward. At this time the new document has not loaded yet, and the old one will close prompting the error we see.

**This is speculation, but from what we see until now something along these lines appears to happen
Responsible changeset:

This is bug 897655
Might be a genuine regression in Firefox. I see a potential problem has been identified in bug 897655 comment 18

Brian, we are experiencing intermittent failures in some of our automated tests, which appear to be related to the issues you've seem to had in bug 897655.

They only seem to affect OSX 10.6 and 10.7. The problem lies somewhere in identifying a correct page load (or maybe unload). We have not yet been able to exactly pinpoint the problem.

Is there something we should be aware of (that maybe needs some code change) or are we seeing a regression from bug 897655?
Flags: needinfo?(bhackett1024)
Blocks: 906599
Thank you Mario for the regression test. Seems like a good candidate, yes. Interestingly I have seen the same now on Linux while doing a testrun with Mozmill 2.0. So this is not restricted to OS X but can happen across all platforms.
Blocks: 897655
OS: Mac OS X → All
Hardware: x86_64 → All
Summary: Test failure "controller(): Window could not be initialized" across OSX 10.6 and 10.7 → Test failure "controller(): Window could not be initialized"
I rerun the tests and as I was able to see this is not a failure in Mozmill! It's clearly a regression in Firefox that after a restart the browser takes way longer to open the main browser window as usual. In my case it has been taken >5s!! I will spun off a new bug for this particular issue in a bit once I know the details.
No longer blocks: 897655
Clearly not a mozmill bug. I created bug 909734 to get this fixed in Gecko.
Flags: needinfo?(bhackett1024)
Whiteboard: [mozmill-test-failure] → [mozmill-test-failure][blocked by bug 909734]
No longer blocks: 906599
Duplicate of this bug: 906599
If we have specific tests which are always broken in our testruns we might want to skip those for the time being.
There are no specific tests.
We've seen this across all restart tests and all selenium tests.

I don't see any clean workaround.
Fixed by the underlying Firefox patch.
Closed: 7 years ago
Resolution: --- → FIXED
Whiteboard: [mozmill-test-failure][blocked by bug 909734] → [mozmill-test-failure]
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.