(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from bug 1487358 comment #22)

It looks like just spinning the event loop before checking for remaining alerts on the page after a prompt has been accepted/dismissed is not enough. Only when I add sleeps of about 30ms and more, a remaining prompt will be detected. Here is the HTML/JS snippet:

  <script type="text/javascript">
    function setInnerText(id, value) {
      document.getElementById(id).innerHTML = "<p>" + value + "</p>";
    }

    function handleTwoDialogs() {
      setInnerText("text1", prompt("First"));
      setInnerText("text2", prompt("Second"));
    }
  </script>
[..]
  <a href="#" id="open-two-dialogs" onclick="handleTwoDialogs()">Open two prompts.</a>

Olli, right now my code is waiting for the DOMModalDialogClosed event before it immediately checks for any remaining prompt via this method:
https://searchfox.org/mozilla-central/rev/9eb2f739c165b4e294929f7b99fbb4d90f8a396b/testing/marionette/modal.js#62

Maybe you know if there is some other kind of event Marionette would have to wait for before checking for remaining alerts? Or is the first prompt just blocking, and the second opens after the first has been closed? If that is the case maybe we need a sleep call for now until bug 1477977 has been fixed.

As talked with Olli and the problem here might be that we are only listening for DOMModalDialogClosed events for the parent but not the child process. Only for the latter it should be synchronous.

Note that the specific wdspec tests are failing, and as such enabling those tests had to be reverted. Here the appropriate changeset:

https://hg.mozilla.org/mozilla-central/rev/64f906609a52

If we have access to the docshell, it exposes a chromeEventHandler
we could possibly use for listening to DOM events from the associated
content browser.

Note that recently the underlying problem should be easier to reproduce given that the recent failures most likely happen on the Ubuntu18.04 Mn jobs on try.

Given that the testcase in comment 0 includes clicking the link I have the suspicion that my fix for bug 1394354 will fix that. I will check back next week, also because bug 1559992 is no longer intermittently failing.

We are seeing a spike of test failures (see blocked bugs) on integration branches since we enabled actors on non-Fission builds (bug 1669169). As such we will have to get this fixed as part of our Fission work.

Tracking marionette-fission-mvp bugs for Fission Beta milestone (M7).

Does this marionette-fission-reserve bug need to block shipping Fission MVP?

For now, I am assuming marionette-fission-reserve bugs don't need to block shipping Fission MVP.

With the upcoming changes for bug 1560015 this is becoming more obvious now, and fails basically all the time.

As discussed with James and Olli on Matrix the 2nd user prompt is not expected to be around immediately. There can be a tons of other code executed between the closing of the first user prompt and showing of the second one, eg. registered event handlers that delay the execution of the script.

As such the affected tests have to wait for the 2nd user prompt to be created. I will upload patches to the individual bugs as marked being blocked by this one.

I will also attach a single patch here that simplifies the way how WebDriver:AcceptDialog and WebDriverr:DismissDialog handle the DOMModalDialogClosed event.

Using the "waitForEvent" promise will cause an extra
"DOMModalDialogClosed" event to be logged, which is
confusing.

As mentioned before there is no actual bug and we handle multiple alerts perfectly. As such it might be best to move the patch over to bug 1686741. I will do that with the next update.

Closing this out given that no code change in Marionette is required.

Comment on attachment 9203428 [details]
Bug 1560015 - [marionette] Use dialogObserver when awaiting dialog to be closed.

Revision D105316 was moved to bug 1686741. Setting attachment 9203428 [details] to obsolete.