Any command is failing with UnexpectedAlertOpen when interacting with a modal dialog

RESOLVED DUPLICATE of bug 1264259

Status

enhancement
P3
normal
RESOLVED DUPLICATE of bug 1264259
2 years ago
Last year

People

(Reporter: Silne30, Unassigned)

Tracking

(Blocks 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

10.63 KB, application/x-zip-compressed
Details
Reporter

Description

2 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.
Reporter

Comment 1

2 years ago
Posted file test_search.zip
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.
Reporter

Comment 2

2 years ago
This also blocks 1301776
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?
Flags: needinfo?(ato)
(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.
Flags: needinfo?(ato)
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
Priority: -- → P3
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.