499691 - Running Mozmill tests against the preferences dialog breaks current Firefox session

Status: RESOLVED WORKSFORME

(Testing Graveyard :: Mozmill, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: Mozmill test

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090616 Firefox/3.5 ID:20090616212246

Now that we can run Mozmill tests against the preferences dialog we wanna see all Smoketests which handle this dialog automated. Aakash is writing most of those tests and I have some of them in my review queue. While checking bug 493851 today I got massive trouble on OS X. It seems that something is blocked when the dialog isn't run modal like we do on Windows.

I have attached a patch which is a modified example of the patch on bug 493851. So the following behaviors I have detected:

* On Windows those tests run smoothly. Seems like it is related to the modal dialog. Any further inspection is related to non-modal dialogs.
* When the preferences dialog has been opened and we are firing clicks too early with having a delay we get completely stuck. Adding a sleep of 1000ms to the prefs api before the handler gets called helps a bit but is not consistent over several runs.
* With a timing of 500ms before the handler gets called the pref dialog gets resized when firing a second click against the dialog. This is somehow odd behavior.
* But the most important part is that after a couple of runs the current Firefox session gets completely broken and exceptions/errors like those are thrown:

Error: Cc is not defined
Source File: chrome://browser/content/browser.js
Line: 63

Error: goUpdateCommand is not defined
Source File: chrome://global/content/editMenuOverlay.js
Line: 14

Error: this._observerService is null
Source File: chrome://browser/content/browser.js
Line: 8748

Clint, can testdev figure out in the near future what's going on here? We get still blocked by our test creation.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Screencast which shows the breakage when using no sleep before our click action. Sometimes its necessary to run the test a couple of times: http://screencast.com/t/OvbWb9o68b

Comment 2

[cmtalbert]

I just ran the test 10 times in a row and I can't reproduce this issue.  There is a hang at the end of the test, and I'll look into that, but I'm not seeing any of these errors on mac.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Clint, you have to change the sleep interval inside the prefsAPI. Use a value of 0.

Comment 4

[cmtalbert]

Pushed the change to the prefsAPI shared module.  Still investigating further
fixes.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: Mozmill test without PrefAPI

Also without the PrefAPI we still fail as what this test shows. Run it a couple of times and you will see timeouts when waiting for the element.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This mostly depends on the fix for bug 330458. So adding it to the dependency list.

Comment 7

[cmtalbert]

Attachment: Changing the test slightly so that it works

Changing the test to use the locationBarGroup as its verification element works much better, and prevents us from triggering the socket restore that causes the freeze.  This test tests the same behavior and is otherwise equivalent.  Using this with the already checked in fix to testPrefsAPI resolves this behavior and so I am closing the bug as WFM.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Wrong bug Clint! :)

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: Test case (resize, dialog hidden)

Running this test a couple of times you will see a resize of the dialog when the next panel is clicked. Further running it twice/three times the preferences dialog will be not visible anymore.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Could it help when we use our own queues to load all the overlays in-front before interacting with the dialog? See bug 330458 comment 44 But I still wonder why it is a non Windows issue.

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Clint, it looks like that we already use those pane overlay loaders in l10n tests. Here is a good example we could probably borrow:

http://mxr.mozilla.org/mozilla-central/source/testing/tests/l10n/extensions/coverage/chrome/content/coverage-prefs.js#74

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

While writing the extension installation Mozmill test I have noticed that our current observer for modal dialogs doesn't work. We had a failure in our logic. Since the additional work for the preferences dialog we have been checked the chrome flags with the | (or) operator. This is wrong because it will always be true and return with the wrong window. That's why we were operating some times not on the desired window. I have seen this with the software installation modal dialog. The modal API has returned the Add-ons Manager controller instead of the modal sheet one.

Clint, I pushed a fix to our repository:
http://hg.mozilla.org/qa/mozmill-tests/rev/0b5b9dffa379

It would be great if anyone could check his tests so we can make sure they will work better as before. I'm not able to break any instance of the preferences dialog anymore. If it is working for everybody we can mark this bug as fixed.

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Haven't seen it for a while. Lets close it out as WFM.