John Dorlus [:Silne30] Reporter
	Description • 7 years ago

I have attached a simplified case that includes a mock search engine to install. The script attempts to add the search engine but marionette cannot interact with the alert once we switch to the window though it finds the elements just fine.

	John Dorlus [:Silne30] Reporter
	Comment 1 • 7 years ago

This is the test case to be run in marionette. It is a simplified test case that illustrates the problem. The test fails with an UnexpectedAlertOpen exception because of the failure to interact with its elements.

	John Dorlus [:Silne30] Reporter
	Comment 2 • 7 years ago

This also blocks 1301776

	Henrik Skupin [:whimboo][⌚️UTC+1]
	Comment 3 • 7 years ago

(In reply to John Dorlus [:Silne30] from comment #1)
> that illustrates the problem. The test fails with an UnexpectedAlertOpen
> exception because of the failure to interact with its elements.

This is not what you have mentioned on IRC. So reading it now it makes sense because we check for unwanted alerts before actually performing the command. 

So what I think is that we might only want to have this behavior when the content scope is active but not for chrome scope? I see that as the only solution. Andreas what do you think?

	Andreas Tolfsen ❲:ato❳
	Comment 4 • 7 years ago

(In reply to Henrik Skupin (:whimboo) from comment #3)
> So what I think is that we might only want to have this behavior when the
> content scope is active but not for chrome scope? I see that as the only
> solution.

It’s not really clear to me which command we’re talking about here?  Though
on a general basis I would say the user prompt checks should only be carried
out in content context.

We haven’t implemented the user prompt handler described in the WebDriver
specification yet, but when we do, if we were to run these tests in chrome
context with a user prompt handling strategy of "dismiss", it would not be
possible to interact with prompts at all in chrome context.

	Henrik Skupin [:whimboo][⌚️UTC+1]
	Comment 5 • 7 years ago

Yes, this is for ANY command as requested when staying in chrome context. So take findElement here:

https://dxr.mozilla.org/mozilla-central/rev/53477d584130945864c4491632f88da437353356/testing/marionette/driver.js#1879

So what we should do instead is moving this assert into the case for content scope, or make sure to not run it in the case that the currently selected window IS the modal dialog. Personally I like the latter option better, because it would raise meaningful failure messages for chrome too, in case of an unexpected alert dialog opened by a command.

	Andreas Tolfsen ❲:ato❳
	Comment 6 • 6 years ago

When we re-implement the user prompt handler I think we will not
want to worry about global modal dialogues.  Not doing that will
resolve this issue.