Closed Bug 1601160 Opened 5 years ago Closed 4 years ago

Hang after interacting with prompt from beforeunload event


(Remote Protocol :: Marionette, defect, P3)



(firefox-esr68 unaffected, firefox71 wontfix, firefox72 wontfix, firefox73 wontfix, firefox75 wontfix, firefox76 wontfix, firefox77 fixed)

Tracking Status
firefox-esr68 --- unaffected
firefox71 --- wontfix
firefox72 --- wontfix
firefox73 --- wontfix
firefox75 --- wontfix
firefox76 --- wontfix
firefox77 --- fixed


(Reporter: kovalev007, Unassigned)




Original discussion:


  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

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.

Ever confirmed: true
Priority: -- → P3
Regressed by: 1477977
Summary: regression: geckodriver hung after interact with prompt from beforeunload event → Hang after interacting with prompt from beforeunload event

Any response on this?

I maked some investigation on code.

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?

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.

Depends on: 1619481

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

Flags: needinfo?(kgp.88)

I will return later with results.

Henrik, I checked examples from this bug and from Both examples works good with the latest Firefox Nightly.

Flags: needinfo?(kgp.88)

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.

Closed: 4 years ago
Resolution: --- → DUPLICATE
Has Regression Range: --- → yes
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.