1601160 - Hang after interacting with prompt from beforeunload event

Status: RESOLVED DUPLICATE of bug 1619481

(Remote Protocol :: Marionette, defect, P3)

Description

[George Kovalev (:kovalev007)]

Original discussion: https://github.com/mozilla/geckodriver/issues/1653

Testcase:
https://output.jsbin.com/fixoxun

1. click on button with text "open"
2. wait new window opened
3. click on button with text "close"
4. accept user promt
5. wait new window closed

Actual results: geckodriver hung after accept user promt

Changeset due to which an error appeared: 5d6397e990cbc374be49baaa4fc6622dfed18119

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

What has not been mentioned above is the fact that also dom.disable_beforeunload has to be set to false. It means this code path is currently not supported, but we somehow introduced a change with dynamically handling the alerts in bug 1477977 and especially the above mentioned changeset.

Comment 2

[George Kovalev (:kovalev007)]

Any response on this?

I maked some investigation on code.
https://hg.mozilla.org/integration/autoland/comparison/5d6397e990cbc374be49baaa4fc6622dfed18119/testing/marionette/driver.js#l3181r3186
https://hg.mozilla.org/integration/autoland/comparison/5d6397e990cbc374be49baaa4fc6622dfed18119/testing/marionette/driver.js#l3199r3203

And in my opinion "await new IdlePromise(win);" not needed in dismissDialog and acceptDialog.
I was looking for the use of "IdlePromise" in code:
IdlePromise used only in setWindowRect, minimizeWindow, maximizeWindow, fullscreenWindow.
All this functions work with window size.

And the use of "IdlePromise" in "dismissDialog" and "acceptDialog" - does not fit into the context of working with window size

Also the test case from first comment working correctly if I remove "await new IdlePromise(win);" from dismissDialog and acceptDialog.

What do you think about it?

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

The idlePromise isn't only tied to any window manipulation code. It just means that the code has to wait for the main thread to become idle, and a requestAnimationFrame event to be fired. The latter will happen about 17 times within a second. So I don't understand why removing it helps here. If it does for you it might actually cause a race condition.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

George, does that work for you now? Please check with the latest Firefox Nightly. Thanks!

Comment 5

[George Kovalev (:kovalev007)]

I will return later with results.

Comment 6

[George Kovalev (:kovalev007)]

Henrik, I checked examples from this bug and from https://bugzilla.mozilla.org/show_bug.cgi?id=1619481. Both examples works good with the latest Firefox Nightly.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This is great to hear! Thanks a lot for your help and endurance to get this problem fixed. I kinda appreciate.

Given that the idlePromise was the only problem I will go ahead and simply dupe this bug over.