Open Bug 1770689 Opened 2 years ago Updated 7 months ago

Potential hangs in "WebDriver:SwitchToWindow"

Categories

(Remote Protocol :: Marionette, defect, P2)

defect

Tracking

(firefox100 affected, firefox101 affected, firefox102 ?)

Tracking Status
firefox100 --- affected
firefox101 --- affected
firefox102 --- ?

People

(Reporter: whimboo, Unassigned)

References

Details

(Whiteboard: [webdriver:backlog] )

All of the test failures as reported on bug 1769065 are caused by hangs in "WebDriver:SwitchToWindow". This most likely happens because the Promise for awaiting the focus event might never get resolved:

https://searchfox.org/mozilla-central/rev/70cf6863bd85af2a3188ec1fe5209a3ec1b2de86/remote/marionette/driver.js#1222-1226

This actually uses the focusWindow method from the WindowManager class:

https://searchfox.org/mozilla-central/rev/70cf6863bd85af2a3188ec1fe5209a3ec1b2de86/remote/shared/WindowManager.jsm#165-174

Given that I do not see whether a focus nor a activate event it should indicate that the call to focus maybe fails?

https://treeherder.mozilla.org/logviewer?job_id=378911180&repo=try&lineNumber=5195-5197

[task 2022-05-22T12:25:37.544Z] 12:25:37     INFO -  1653222337543	Marionette	DEBUG	2 -> [0,46,"WebDriver:SwitchToWindow",{"handle":"411ef02d-05f3-4841-bddb-a8e3f55c8fb7","focus":true}]
[task 2022-05-22T12:26:02.880Z] 12:26:02     INFO -  2022-05-22 12:26:02.880 firefox[2390:32316] Persistent UI failed to open file file:///Users/cltbld/Library/Saved%20Application%20State/org.mozilla.firefox.savedState/window_1.data: No such file or directory (2)
[task 2022-05-22T12:31:37.563Z] 12:31:37     INFO -  1653222697563	Marionette	DEBUG	Closed connection 2

Interesting is that this is only visible on beta and release channels these days but not on central nor autoland.

We discussed a potential move from a general Promise to a TimedPromise in last weeks triage meeting so that we do not end-up with a freeze of 6 minutes only because we cannot focus a window. We may be able to do such a switch here and fail with NoSuchWindow instead, but as Julian pointed out we should not overload the usage of TimedPromise in our code base.

Some investigation / try builds might be helpful to have to actually identify the real cause here (if it's the focus step for real).

Severity: -- → S3
Flags: needinfo?(hskupin)
Priority: -- → P3
Whiteboard: [webdriver:backlog]
Blocks: 1790329

As seen on bug 1790329 comment 9 this hang can occur when the window / tab that we are switching to gets closed. We should make sure to handle that case and fail with an error in such a condition.

Resetting priorities to triage for priority again. Maybe it should become a P2 due to the hang scenario.

Flags: needinfo?(hskupin)
Priority: P3 → --
Whiteboard: [webdriver:backlog] → [webdriver:triage]

This might happen to WebDriver BiD commands as well that run for a longer time. A more general handling of such a situation would be good to have. Lets focus on switch to window for now and follow-up with another bug later.

Priority: -- → P2
Whiteboard: [webdriver:triage] → [webdriver:backlog]
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.