1545460 - marionette blocks on opening dialog box

Status: RESOLVED WORKSFORME

(Remote Protocol :: Marionette, defect, P3)

Description

[Samuel Thibault]

Hello,

I am trying to use marionette for making UI regression testing on Thunderbird, but it seems that marionette has an issue with dialog boxes: the send_keys() function for sending a keyboard shortcut to trigger one, as well as the click() function for clicking on menu items, do not return until the dialog box is closed, which prevents from interacting with the dialog box.

Using a menu entry by hand with arrow keys and enter does work, but that approach would rely on relative positions of items in the menu (or knowing when a menu item gets selected, I have not found anything to determine that).

I'll post a testcase.

Samuel

Comment 1

[Samuel Thibault]

Attachment: Bug 1545460 Test opening a dialog box from a keyboard shortcut r=whimboo

Comment 2

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

Can you please attach a trace log? Use -vv --gecko-log - to record one.

Comment 3

[Samuel Thibault]

Attachment: marionette log

Here is a log, which stops at the point where the dialog box is opened, but the w.send_keys() function still doesn't return. If I close the dialog box, I additionally get

1556095484870 Marionette DEBUG 3 <- [1,8,null,{"value":null}]

and the script continues.

Comment 4

[Samuel Thibault]

Attachment: marionette.log

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:automatedtester, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

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

Please note that modal dialogs (which are opened in chrome scope) don't have such a great support yet beside the tab modal dialogs. This is a known issue and tracked by bug 1477977, and we won't have the time to continue on that in the near future.

Comment 7

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

Samuel, can you please retry with latest mozilla-central, now that bug 1477977 has been fixed? If it still fails please provide another trace log. Thanks.

Comment 8

[Samuel Thibault]

It is fixed indeed. I have rebased the testcase, it now does pass fine as tested on https://treeherder.mozilla.org/#/jobs?repo=try&revision=5366480bb6f4dad16704388890f1c5fd953d3df8 , could you review it on phab so we can include it in the testsuite?

Comment 9

[Samuel Thibault]

Oops, wait, I forgot I wanted to make sure the test name was showing up, and it is not, because that testsuite is not within marionette, but firefox-ui-functional, let me restart the try

Comment 10

[Samuel Thibault]

Attachment: marionette.log

No, it's not fixed, sorry for the wrong news :/

Building version 4651b31ffe5c012b5112fc3047c29d0d4a8f9594, the attached debug log stops at

1560514781254 Marionette TRACE Received observer notification toplevel-window-ready

which is the point when the dialog box is opened but the w.send_keys() function doesn't return, until I manually close the dialog and the script continues with 1560514787317 Marionette TRACE Received event DOMModalDialogClosed etc.

The testcase is also being tried on https://treeherder.mozilla.org/#/jobs?repo=try&revision=ba0bd9ed311ebe017d2a01e21330dfa38b397be6

Comment 11

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

I'm fairly sure meanwhile that this could be a dupe of bug 1241679. For now I will mark it as dependency.

Comment 12

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

I had another look at the given test case and the mentioned dialog is not a different window but embedded into the browser window (subdialog, inbrowserwindow). That means the call to Wait.until() will indeed timeout. The following code does work:

    def test_case(self):
        self.marionette.set_context('chrome')

        # Open dialog
        w = self.marionette.find_element(By.CSS_SELECTOR, ':root')
        w.send_keys(Keys.META, Keys.SHIFT, Keys.DELETE)

        # Wait for dialog to open
        Wait(self.marionette).until(expected.element_present(By.ID, "window-modal-dialog"))

        time.sleep(2)

        # Close it
        w.send_keys(Keys.ESCAPE)

I cannot see anything that blocks. So I'm going to close this bug as WFM.

Comment 13

[Samuel Thibault]

the mentioned dialog is not a different window but embedded into the browser window (subdialog, inbrowserwindow). That means the call to Wait.until() will indeed timeout. The following code does work:

Errr, ok. But is there always a way to open that dialog as a non-subdialog window, and be sure that it behaves exactly the same?

I mean, one kind of usage of marionette tests is to make sure that the behavior of dialog boxes does work. So we want to be able to test all dialog boxes, and be sure that they do work in all the ways they get opened.

Comment 14

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

We have several Marionette unit tests that utilize modal dialogs including chrome scope and they all work fine. So I would clearly need an example of such a dialog that doesn't work. As long as we don't have that there is nothing that I can do. As such if you can please provide such an example. Thanks.

Comment 15

[Samuel Thibault]

We have several Marionette unit tests that utilize modal dialogs including chrome scope and they all work fine.

Ah, sorry I had misunderstood your previous comment:

That means the call to Wait.until() will indeed timeout.

You meant that since it's embedded into the browser window, Wait.until() will never see the opening of a new window.

We have several Marionette unit tests that utilize modal dialogs including chrome scope and they all work fine.

Ok, so that should be all good.

Concerning https://phabricator.services.mozilla.com/D28077 , since 7ff6cd9c01cd removed the Python package it has become moot, I'll just abandon it.

Comment 16

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

Great to hear. And whenever you would still experience such a failure again don't hesitate to file a new bug. Thanks!