With the upcoming support for wdspec tests on Android the following test fails because the window result is not correctly returned.

https://treeherder.mozilla.org/logviewer?job_id=372683562&repo=try&lineNumber=10723

[task 2022-03-29T12:31:00.056Z] 12:31:00     INFO -         session.url = inline("<script>window.result = window.confirm('Hello');</script>")
[task 2022-03-29T12:31:00.056Z] 12:31:00     INFO -     
[task 2022-03-29T12:31:00.056Z] 12:31:00     INFO -         response = dismiss_alert(session)
[task 2022-03-29T12:31:00.057Z] 12:31:00     INFO -         assert_success(response)
[task 2022-03-29T12:31:00.057Z] 12:31:00     INFO -     
[task 2022-03-29T12:31:00.057Z] 12:31:00     INFO -         with pytest.raises(NoSuchAlertException):
[task 2022-03-29T12:31:00.057Z] 12:31:00     INFO -             session.alert.text
[task 2022-03-29T12:31:00.057Z] 12:31:00     INFO -     
[task 2022-03-29T12:31:00.057Z] 12:31:00     INFO - >       assert session.execute_script("return window.result;") is False
[task 2022-03-29T12:31:00.057Z] 12:31:00     INFO - E       AssertionError: assert None is False

Olivia, could this be an issue with the GeckoView prompter implementation and that it returns the wrong value when dismissing a confirm prompt?

Hi Henrik, thanks for looking at this. I think there could potentially be a situation where the value isn't returned in time for the test to pickup. GeckoViewPrompter on dismiss sends a message back to the Java side to close the prompt, which will then cause a return value. I think if the check of the value occurred before GeckoView:Prompt:Dismiss completed, it could give None because the prompter would still be waiting for the prompt to finish still.

Agi, does that seem like it could be the case or do you think it could be something else? Should we complete the callback in the JavaScript prompter like we do for accept? When I ran the test locally without any changes, it seemed to complete in time and returned as expected and gave a False for dismissing a confirm. I then added a Sleep(1000) on the Java side to test and was then able to replicate the test failure.

(In reply to Olivia Hall from comment #1)

Hi Henrik, thanks for looking at this. I think there could potentially be a situation where the value isn't returned in time for the test to pickup. GeckoViewPrompter on dismiss sends a message back to the Java side to close the prompt, which will then cause a return value. I think if the check of the value occurred before GeckoView:Prompt:Dismiss completed, it could give None because the prompter would still be waiting for the prompt to finish still.

Agi, does that seem like it could be the case or do you think it could be something else? Should we complete the callback in the JavaScript prompter like we do for accept? When I ran the test locally without any changes, it seemed to complete in time and returned as expected and gave a False for dismissing a confirm. I then added a Sleep(1000) on the Java side to test and was then able to replicate the test failure.

I think you have it right, we do need to either wait for the UI to tell us that it's done dismissing or calling the callback ourselves. Because we call the callback ourselves in confirm I would do the same for dismiss, with the note that right now we call dismiss inside confirm too, maybe we can have a _dismissUi or something like that that does what dismiss does today? and then have

dismiss() {
    // notify the app to hide the prompt
    this._dismissUi();
    this.callback(null);
}

this should work