887274 - Mechanism for handling modal dialogs with Marionette

Status: RESOLVED DUPLICATE of bug 906712

(Remote Protocol :: Marionette, defect)

Description

[David Burns :automatedtester]

During the W3C Meeting we discussed creating a mechanism for handling security dialogs (basic auth, etc). This is needed if people have poorly configured environments they need to interact with

Comment 1

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

You will have to implement handling of modal dialogs first, which is covered by bug 779284.

Comment 2

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

So any security dialog including the HTTP Auth dialogs are modal dialogs. By definition it is any kind of top-level window, which is blocking the parent window. So this also includes the sliding down sheets on OS X.

With its implementation it might be easier to cover tab-modal dialogs then via bug 906712. So I flipped the dependency states.

Comment 3

[David Burns :automatedtester]

Since the spec only cares about tab modals am removing spec keyword

Comment 4

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

I wonder why this bug never ended-up on our m21s blocking list. It's blocking a couple of our tests.

Comment 5

[Chris Manchester (limited bugmail, email directly)]

I think it would be relatively straightforward to build a library in firefox-ui-tests to achieve what mozmill-tests' modal-dialog.js is providing. :whimboo, what sort of API would you expect marionette to provide for this?

Comment 6

[Chris Manchester (limited bugmail, email directly)]

bug 1132710 opens a modal that uses the prompt service, so confirm and dismiss as implemented in bug 906712 work as expected.

Comment 7

[Chris Manchester (limited bugmail, email directly)]

Sort of implied in comment 6 is that the implementation in bug 906712 supports any dialogs that are implemented with CommonDialog.jsm, which includes http auth dialogs. The thing I can see that might be left in this bug is built-in selectors is a marionette test library for entering text into the username and password fields.

Comment 8

[John Dorlus [:Silne30]]

Is this functionality still being worked on or has it been completed? 1132680 is blocked by this functionality. Navigating to a page that brings up a security dialog does not work and throws an UnknownWindowException. We are trying to get the following test case to work.

Comment 9

[John Dorlus [:Silne30]]

Attachment: Minimal test case for security dialogs

Comment 10

[Chris Manchester (limited bugmail, email directly)]

(In reply to John Dorlus [:Silne30] from comment #8)
> Is this functionality still being worked on or has it been completed?
> 1132680 is blocked by this functionality. Navigating to a page that brings
> up a security dialog does not work and throws an UnknownWindowException. We
> are trying to get the following test case to work.

I don't think this is being worked on. Bug 906712 implemented interactions for the most common modals initiated by web content or firefox. If the cert manager is using custom xul we may need a specific library in the firefox ui tests to handle it.

Comment 11

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

(In reply to Chris Manchester [:chmanchester] from comment #10)
> I don't think this is being worked on. Bug 906712 implemented interactions
> for the most common modals initiated by web content or firefox. If the cert

Which are called tab-modal dialogs. For chrome space testing those are not relevant. There are lots of places our tests would be blocked on because Firefox spawns modal dialogs. 

> manager is using custom xul we may need a specific library in the firefox ui
> tests to handle it.

I don't think so that this needs to be a library in the firefox-ui-tests, but more in Marionette. This really needs to be a basic feature because lots of different test harnesses will need this feature in the future.

Comment 12

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

(In reply to Chris Manchester [:chmanchester] from comment #5)
> I think it would be relatively straightforward to build a library in
> firefox-ui-tests to achieve what mozmill-tests' modal-dialog.js is
> providing. :whimboo, what sort of API would you expect marionette to provide
> for this?

The window marionette server code is running in will be blocked by opening such a modal dialog. The same also applies to the code execution. It will be stalled until the modal dialog has been closed. So we would need a way to spawn e.g. a different thread which can run Marionette code for this opened dialog.

Maybe best would be if Marionette code would run independently from a chrome window, just as a service. Then we might not have such a problem. But I don't know the architecture of Marionette server, to suggest something. I will CC Andreas, who might have some input here.

Comment 13

[Chris Manchester (limited bugmail, email directly)]

(In reply to Henrik Skupin (:whimboo) from comment #11)
> (In reply to Chris Manchester [:chmanchester] from comment #10)
> > I don't think this is being worked on. Bug 906712 implemented interactions
> > for the most common modals initiated by web content or firefox. If the cert
> 
> Which are called tab-modal dialogs. For chrome space testing those are not
> relevant. There are lots of places our tests would be blocked on because
> Firefox spawns modal dialogs. 

Note that the current implementation will support any modal dialog implemented by CommonDialog.jsm. This includes many of the modals spawned by Firefox.

> 
> > manager is using custom xul we may need a specific library in the firefox ui
> > tests to handle it.
> 
> I don't think so that this needs to be a library in the firefox-ui-tests,
> but more in Marionette. This really needs to be a basic feature because lots
> of different test harnesses will need this feature in the future.

Comment 14

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

I talked with Chris on IRC. So a few notes from our investigations to this testcase:

1. The underlying problem for John here is the hang in navigate(). I can reproduce that and it definitely belongs to the waiting for the page being loaded. I will raise a separate bug for that.

2. The dialog which opens is not based on the commonDialog binding but the general dialog binding. So its not being covert by Alert()

3. If I load the page via the urlbar directly via send_keys(), the dialog which opens can be accessed by its chrome window handle. That means we can handle it like an ordinary window, except that the window type here is "" and our puppeteer library will fail. There might be another property to look for, but that is clearly a part for the test conversion bug.

4. I tested a HTTP auth dialog via navigate and without by using Alert(). This works fine.

So given all those information and especially #4 which was the initially attempt from David to get implemented, I think we can mark this bug as fixed? Chris, feel free to close it.

Comment 15

[Chris Manchester (limited bugmail, email directly)]

Thank you for the clarification. I will mark this as a duplicate of the bug where that work happened.