Running Mozmill tests against the preferences dialog breaks current Firefox session

RESOLVED WORKSFORME

Status

Testing Graveyard
Mozmill
--
critical
RESOLVED WORKSFORME
8 years ago
10 months ago

People

(Reporter: whimboo, Unassigned)

Tracking

(Depends on: 1 bug)

Dependency tree / graph

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

8 years ago
Created attachment 384414 [details] [diff] [review]
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.
(Reporter)

Updated

8 years ago
Summary: Running Mozmill tests against the preferences dialog breaks current session → Running Mozmill tests against the preferences dialog breaks current Firefox session
(Reporter)

Comment 1

8 years ago
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

8 years ago
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.
(Reporter)

Comment 3

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

Comment 4

8 years ago
Pushed the change to the prefsAPI shared module.  Still investigating further
fixes.
(Reporter)

Comment 5

8 years ago
Created attachment 384501 [details]
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.
(Reporter)

Comment 6

8 years ago
This mostly depends on the fix for bug 330458. So adding it to the dependency list.
Depends on: 330458

Comment 7

8 years ago
Created attachment 384506 [details] [diff] [review]
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.
Attachment #384501 - Attachment is obsolete: true

Updated

8 years ago
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 8

8 years ago
Wrong bug Clint! :)
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Reporter)

Comment 9

8 years ago
Created attachment 384518 [details]
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.
(Reporter)

Comment 10

8 years ago
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.
Blocks: 493084
Blocks: 493083
(Reporter)

Comment 11

8 years ago
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
(Reporter)

Comment 12

8 years ago
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.
Status: REOPENED → NEW
OS: Mac OS X → All
Hardware: x86 → All
(Reporter)

Updated

8 years ago
Attachment #384518 - Attachment mime type: application/octet-stream → text/plain
(Reporter)

Comment 13

8 years ago
Haven't seen it for a while. Lets close it out as WFM.
Status: NEW → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: --- → WORKSFORME
(Assignee)

Updated

10 months ago
Product: Testing → Testing Graveyard
You need to log in before you can comment on or make changes to this bug.