Closed
Bug 906591
Opened 11 years ago
Closed 11 years ago
Test failure "controller(): Window could not be initialized"
Categories
(Mozilla QA Graveyard :: Mozmill Tests, defect, P1)
Mozilla QA Graveyard
Mozmill Tests
Tracking
(firefox25 unaffected, firefox26 fixed)
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
firefox25 | --- | unaffected |
firefox26 | --- | fixed |
People
(Reporter: cosmin-malutan, Unassigned)
References
()
Details
(Keywords: regression, reproducible, Whiteboard: [mozmill-test-failure])
Happened on Mac OS X 10.6.8 (x86_64) with Nightly it: http://mozmill-daily.blargon7.com/#/functional/report/e503b7b0a70a3839c66c64572e4f3307 I couldn't reproduce it.
Reporter | ||
Updated•11 years ago
|
status-firefox26:
--- → affected
Comment 1•11 years ago
|
||
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]
Comment 2•11 years ago
|
||
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
Status: NEW → ASSIGNED
Updated•11 years ago
|
Priority: -- → P3
Comment 3•11 years ago
|
||
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
Status: ASSIGNED → NEW
Comment 5•11 years ago
|
||
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: http://mozmill-daily.blargon7.com/#/functional/top?branch=All&platform=Mac&from=2013-08-23&to=2013-08-26 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.
Updated•11 years ago
|
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
Comment 6•11 years ago
|
||
Also on endurance tests: http://mozmill-daily.blargon7.com/#/endurance/report/6d53b7d749a60e65551b4b1d19211daf
Updated•11 years ago
|
Priority: P3 → P2
Comment 7•11 years ago
|
||
This reproduces locally on Mac 10.6.8 with Nightly 26 en-US
Comment 8•11 years ago
|
||
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.
Keywords: regressionwindow-wanted,
reproducible
Priority: P2 → P1
Comment 9•11 years ago
|
||
Does not reproduce with the 16.08 Nightly builds, working on finding the responsible changeset with Tinderbox Inbound builds.
Comment 10•11 years ago
|
||
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: http://mozmill-daily.blargon7.com/#/functional/report/e503b7b0a70a3839c66c64572e4f3307 Nightly 26 (17.08.2013) pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=8ad1e4c838c8
Comment 11•11 years ago
|
||
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.
Comment 12•11 years ago
|
||
Added the pushlog range from 16.08(Good build) to 17.08(Failing build): http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1ed5a88cd4d0&tochange=8ad1e4c838c8
Comment 13•11 years ago
|
||
WIP inbound pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a655e2613667&tochange=911fcdcadf4d We're still narrowing it down, but since it is slightly intermittent it is going slower than initially expected.
Comment 14•11 years ago
|
||
Have you tested one of our affected CI machines if the problem is better reproducible there?
Comment 15•11 years ago
|
||
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
Comment 16•11 years ago
|
||
Responsible changeset: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d52251e9123c&tochange=b5e301863e69 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?
Updated•11 years ago
|
Flags: needinfo?(bhackett1024)
Comment 17•11 years ago
|
||
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
status-firefox25:
--- → unaffected
Keywords: regressionwindow-wanted → regression
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"
Comment 18•11 years ago
|
||
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.
Comment 19•11 years ago
|
||
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]
Comment 21•11 years ago
|
||
If we have specific tests which are always broken in our testruns we might want to skip those for the time being.
Comment 22•11 years ago
|
||
There are no specific tests. We've seen this across all restart tests and all selenium tests. I don't see any clean workaround.
Comment 23•11 years ago
|
||
Fixed by the underlying Firefox patch.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [mozmill-test-failure][blocked by bug 909734] → [mozmill-test-failure]
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
•