479311 - Modal dialogs stops execution of MozMill tests

Status: VERIFIED FIXED

(Testing Graveyard :: Mozmill, defect, P1)

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.1b3pre) Gecko/20090219 Shiretoko/3.1b3pre ID:20090219020454 and MozMill 1.0.2

The execution of tests in MozMill, which call a modal dialog (sheet), will stop  when the dialog is opened. That makes it impossible to run any action in those dialogs. After the dialog gets closed manually the execution continuous.

See the attached MozMill test.

Comment 1

[Mikeal Rogers [:mikeal] (mrogers@)]

Just to clarify, this is NOT an OS level modal dialog, it is drawn in XUL.

If you bring back up the mozmill window you can actually inspect the new window, so it is accessible it's just somehow blocking the execution of the code in our test.

Comment 2

[Adam Christian]

Spent a chunk of time on this, pretty lost as to how to debug this -- Clint could you check this out and see if you have any idea what's going on here?

Comment 3

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

What's the best way to debug the MozMill extension? Venkman? If yes, which function should be checked in detail?

Comment 5

[cmtalbert]

Try to get this in for 1.1.  Not sure if it will make it.

Comment 6

[Mikeal Rogers [:mikeal] (mrogers@)]

My attempts at jumpstarting the thread have led to nothing but cursing.

I think we're gonna have to try to generalize Clint's solution instead.

Comment 7

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

That blocks a lot of us from creating tests. Especially the Thunderbird folks seems to be stopped here. Marking as blocker.

Comment 8

[cmtalbert]

Attachment: The Test for using a modal dialog (enters private browsing mode)

This is the test to enter private browsing mode which requires the user to accept a modal dialog.

Comment 9

[cmtalbert]

Attachment: The shared resource for dealing with modal dialogs

This is the heart of the modal dialog shared resource.  It basically works like this:

1. It is instantiated by a tester and given a callback to the function that will deal with the dialog in some way.
2. Then it starts a timer
3. Once the timer fires, the observer is called, but if the dialog cannot be found, then the timer starts again
4. Once the dialog is found, the callback function is called and control is returned to the original test.

Comment 10

[Mark Banner (:standard8)]

(In reply to comment #9)
> 1. It is instantiated by a tester and given a callback to the function that
> will deal with the dialog in some way.
> 2. Then it starts a timer
> 3. Once the timer fires, the observer is called, but if the dialog cannot be
> found, then the timer starts again
> 4. Once the dialog is found, the callback function is called and control is
> returned to the original test.

What I don't quite see is what prevents MozMill from assuming the tests are finished during the time we're waiting for the dialog? i.e. between steps 3 and 4.

If I've understood MozMill correctly once testModalDialog finishes, it'll go straight onto the next test* function. So how would we do something like:

testModalDialog
handleDialog (clicks cancel)
testNextStep

where testNextStep needs to happen after handleDialog is called?

Comment 11

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

(In reply to comment #10)
> What I don't quite see is what prevents MozMill from assuming the tests are
> finished during the time we're waiting for the dialog? i.e. between steps 3 and
> 4.

That's simple. Calling a modal dialog stops Mozmill from further processing a test. This can be seen right now when you open a modal dialog from within your test. So the test will be processed after the handleDialog execution has been finished.

> testModalDialog
> handleDialog (clicks cancel)
> testNextStep
> 
> where testNextStep needs to happen after handleDialog is called?

This is safe sequence. See my answer above.

Comment 12

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

Comment on attachment 372149 [details]
The shared resource for dealing with modal dialogs

Clint, it works perfectly! I just can say wow. I only have one concern here:

>  observe : function (subject, topic, data) {
>    var doc = this.docFinder();
>    if (doc)
>      this.handler(doc);

I'ld like to see a controller here which we pass to the handler. We are running functional tests so we also wanna test those clicks instead of calling functions like dialog.acceptDialog() directly.

I made those changes and also updated the test to demonstrate how several modal dialogs in a row can be handled. Additionally tests will wait as expected.

I'll attach the new files right now.

Comment 13

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

Comment on attachment 372146 [details]
The Test for using a modal dialog (enters private browsing mode)

>function handleDialog(doc) {
>  var dialog = doc.getElementById("commonDialog");
>  dialog.acceptDialog();
>}

As said, using a controller to simulate real clicks should be preferred here. New test upcoming.

Comment 14

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

Attachment: modal dialog module v2

Comment 15

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

Attachment: test for modal dialogs

Comment 16

[cmtalbert]

Comment on attachment 372946 [details]
test for modal dialogs

looks great

Comment 17

[cmtalbert]

Comment on attachment 372943 [details]
modal dialog module v2

Great idea Henrik.  I love this change.  I'm going to take out the modalDialog.setup() call as that is unneeded now that we are setting handleDialog callback on instantiation.

Comment 18

[cmtalbert]

Pushed 9:b1154ea90d51
--> FIXED

Comment 19

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

Works fantastic. Marking bug as verified. Thanks Clint!