Closed Bug 1619481 Opened 4 years ago Closed 4 years ago

Hang in IdlePromise if underlying window gets closed

Categories

(Remote Protocol :: Marionette, defect, P3)

defect

Tracking

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

RESOLVED FIXED
mozilla77
Tracking Status
firefox-esr68 --- unaffected
firefox75 --- wontfix
firefox76 --- wontfix
firefox77 --- fixed

People

(Reporter: kovalev007, Assigned: whimboo)

References

(Regression)

Details

(Keywords: regression)

Attachments

(4 files)

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

  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

Attached file Test2App.java

Information from mozregression:
Last good revision: 09614cb3a896ab3be71ccc44d7663eb5454cf5cf
First bad revision: 4651b31ffe5c012b5112fc3047c29d0d4a8f9594
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=09614cb3a896ab3be71ccc44d7663eb5454cf5cf&tochange=4651b31ffe5c012b5112fc3047c29d0d4a8f9594

Blocks: 1601160
Regressed by: 1477977
Attached file discussion_in_irc.txt

To summarize, this is a hang in IdlePromise when the underlying window as operated on to wait for a requestAnimationFrame gets closed. This can happen at any time by random Javascript in the page.

To circumvent that we should add a listener or another Promise in IdlePromise for the unload event, and cancel the active requestAnimationFrame Promise, which will actually never happen.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Summary: Hang after interacting with prompt → Hang in IdlePromise if underlying window gets closed

So here again a link to our IdlePromise implementation:
https://searchfox.org/mozilla-release/rev/00bea92f25c9edc8022593e9d9435210e8306047/testing/marionette/sync.js#334-340

I wonder if it is really necessary to also wait for requestAnimationFrame or if it is enough to just have the idleDispatchToMainThread in there.

Florian, do you have any feedback for us here or maybe know someone who can give that? Thanks.

Flags: needinfo?(florian)

It's not clear to me what the IdlePromise callers expect it to do. If it's just to delay execution until the runnables already in the event queue have been processed, Services.tm.dispatchToMainThread would be enough, without waiting for and idle slice. If it's intended to wait for the window minimize/maximize/resize animations to be finished, then the current idle+requestAnimationFrame isn't waiting enough. Sorry that this doesn't really answer your question.

Flags: needinfo?(florian)

Thanks! I see, so I will have a patch which keeps that behavior and we could re-evaluate the usage of requestAnimationFrame at a later time if needed.

Assignee: nobody → hskupin
Status: NEW → ASSIGNED

George, can you please check if that patch works for you?

Flags: needinfo?(kgp.88)
Pushed by hskupin@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e96cba7016e0
[marionette] IdlePromise should not hang when underlying window gets closed. r=marionette-reviewers,maja_zf
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla77

Moving the needinfo to bug 1601160.

Flags: needinfo?(kgp.88)
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: