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.
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.
This also blocks 1301776
(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?
(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.
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.
Summary: Cannot interact with chrome elements in the add search engine dialog → Any command is failing with UnexpectedAlertOpen when interacting with a modal dialog
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.
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → DUPLICATE
Duplicate of bug: 1264259
You need to log in before you can comment on or make changes to this bug.