Closed Bug 906599 Opened 11 years ago Closed 11 years ago

Test failure "controller(): Window could not be initialized" in /ide@seleniumhq.org/tests/testCommands/

Categories

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

x86_64
macOS
defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 906591

People

(Reporter: cosmin-malutan, Assigned: mario.garbi)

References

()

Details

(Whiteboard: [mozmill-test-failure])

Attachments

(1 file)

This fails a lot on OS X, we should find a fix quickly or get this skipped.
http://mozmill-daily.blargon7.com/#/addons/reports?branch=26.0&platform=Mac&from=2013-08-16&to=2013-08-19
Priority: -- → P1
Whiteboard: [mozmill-test-failure]
Checking the Jenkins console log I noticed these lines:

"TEST-PASS | /var/folders/v8/00x5n4qd249_1r19n3fv4jsm0000gn/T/tmpXrXCQt.mozmill-tests/tests/addons/ide@seleniumhq.org/tests/testCommands/testText/testSto2013-08-18 06:26:18.998 firefox-bin[51369:9d03] invalid context
2013-08-18 06:26:23.792 firefox-bin[51369:9d03] invalid context
2013-08-18 06:26:24.297 firefox-bin[51369:9d03] invalid context
2013-08-18 06:26:28.477 firefox-bin[51369:9d03] invalid context"

I will investigate the issue on the failing machine since this is still happening.
At first glance we get this "CGContextGetCTM : invalid context 0x0" in the terminal and it seems it's a Mac OS 10.7 issue with Java. Perhaps a Java or OS update would fix this.

Anyone have any insights on this? Has this happened before?
Flags: needinfo?(hskupin)
Mario, those are warnings and not related to this problem. Please observe what's going on here and if we operate on a different window than the browser window itself.
Flags: needinfo?(hskupin)
I took one failing machine offline and I'm currently investigating this. I managed to reproduce it on mm-osx-106-2 so far.
This happens with both Selenium 2.3.0 and 1.10.0 and so far we had the failures only on l10n builds, en-US working ok.

Selenium 1.10.0 failure :
http://mozmill-crowd.blargon7.com/#/addons/report/e503b7b0a70a3839c66c64572e82f322
I can reproduce this locally on Mac 10.6.8 with Nightly 26 de
http://mozmill-crowd.blargon7.com/#/addons/report/e503b7b0a70a3839c66c64572e834365

Continuing investigation locally.
Assignee: nobody → mario.garbi
Status: NEW → ASSIGNED
I would really like to see an update here. What is the current status?
I am investigating locally to find the reason why we fail when trying to get the window in mozmill/extension/resource/driver/controller.js as the firefox instance seems to be opened and there doesn't seem to be anything blocking us.
Code block that fails in controller.js:

"utils.waitFor(function () {
    return window != null && this.isLoaded();
  }, "controller(): Window could not be initialized.", undefined, undefined,  this);"

I am able to reproduce this locally constantly with Nightly 26 de.
It seems that the Selenium Addon fails to open and this causes the test failure when we try to gather it's controller. I have a console log that shows the window.document.title, the window ID and the state of the isLoading function.

dump: "dump("\n\n" + win.document.title + " :: " + id + " :: " + windowMap.getValue(id, "loaded") + "\n\n");"

Console log:

Selenium IDE 2.3.0 :: 345 :: undefined



Selenium IDE 2.3.0 :: 345 :: undefined



Selenium IDE 2.3.0 :: 345 :: undefined



Selenium IDE 2.3.0 :: 345 :: undefined



Selenium IDE 2.3.0 :: 345 :: undefined



Selenium IDE 2.3.0 :: 345 :: undefined



Selenium IDE 2.3.0 :: 345 :: undefined

TEST-UNEXPECTED-FAIL | /var/folders/fP/fPyCuoSSEVqn8CXCucVH5E+++TM/-Tmp-/tmpAmD4C2.mozmill-tests/tests/addons/ide@seleniumhq.org/tests/testCommands/testChecked/testAssertCheckedPasses.js | testAssertCheckedPasses.js::setupModule

I'm looking into why the Selenium IDE fails to open (it's visible that the IDE never opens in the failing test) and will come back with more informations.
To add here I have tested different Selenium IDE versions up to 2.0.0 where we start getting that TOP_LEVEL error again and it still fails so it's safe to assume it's not related to the Selenium version (at least the 2.x versions).
How is it attempting to launch Selenium IDE?
We open Selenium IDE using the "menu" option by default. I have tested using "shortcut" event type but that doesn't seem to help either. Whenever we have a failure ca can visually confirm that the Selenium IDE doesn't open as it should. I am looking into why that is, if there is something blocking it.
Can you open Selenium IDE manually on these locales?
I have run an testrun_addons.py script and only 1 or 2 tests are failing, for all the rest the Selenium IDE works fine.
I asked if you could open it manually. Are the test failures consistent?
Yes, I can open the Selenium IDE manually. I have managed to stop the failures by adding a sleep in the selenium.close() method so we wait for the addon to close before trying to start a new one. I will provide a fix patch as soon as I find something to wait for so we don't use controller.sleep. 
The failures are constant as I get at least 1 or 2 tests failing one every testrun:

Sample failed testrun:
http://mozmill-crowd.blargon7.com/#/addons/report/6d53b7d749a60e65551b4b1d1908e94a
If they're failing on different tests every time then I would call them frequent but not constant. It means there is most likely a timing issue, as you have already mentioned.
High probability that it is related to bug 906591
Same failure, OSX only, same versions, starte failing at around the same time.
This is related to Bug 906591.
Depends on: 906591
Dupe of bug 906591.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
No longer depends on: 906591
Resolution: --- → DUPLICATE
No longer blocks: 907983
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: