Marionette commands like "WebDriver:FindElements" can fail when Firefox window is occluded on Windows
Categories
(Remote Protocol :: Marionette, defect, P1)
Tracking
(firefox-esr102 wontfix, firefox107 wontfix, firefox108 wontfix, firefox109 fixed)
People
(Reporter: whimboo, Assigned: jdescottes)
References
(Regression, )
Details
(Keywords: regression, Whiteboard: [webdriver:m5], [webdriver:relnote] )
Attachments
(1 file)
Originally reported as: https://github.com/mozilla/geckodriver/issues/2040
This specific failure on Windows only started for Firefox 102 and only happens when parts of the Firefox's window are covered by other applications. In such a case a command like WebDriver:FindElements
would not return any element even with the element present in the page.
1662641239206 Marionette DEBUG 0 -> [0,120,"WebDriver:FindElements",{"using":"xpath","value":"//content-stammdaten-card"}]
1662641239211 Marionette DEBUG 0 <- [1,120,null,[]]
As the discussion on the issue has shown affected folks can workaround this problem by disabling the preference widget.windows.window_occlusion_tracking.enabled
. This has been added on bug 1732733 for Firefox 95 and was then enabled on release for Firefox 102.
Sotaro, do you have an idea why Marionette is not able to perform the command correctly when the window is occluded? I'm not sure if we should just disable this preference in general or if that is a bug which should be fixed. Thanks.
Reporter | ||
Updated•1 year ago
|
Comment 1•1 year ago
•
|
||
gecko could disable window occlusion on Window by the followings
- pref widget.windows.window_occlusion_tracking.enabled=false
- set environment variable MOZ_WINDOW_OCCLUSION=0
chrome seemed to have same problem in the past.
https://support.google.com/chrome/thread/83911899/chrome-87-broke-offscreen-automation?hl=en
The followings are chromium's related bugs. chromedriver disables window occlusion on Window. Then it seems better to disable window occlusion by gecko driver.
Reporter | ||
Comment 2•1 year ago
|
||
Thanks Sotaro! Are there any plans to bring this feature to other platforms as well in case support for that exists? Or is it Windows only? Also if we would set this preference to false in all the cases I assume it won't have a side-effect for non-Windows platforms?
Updated•1 year ago
|
Comment 3•1 year ago
|
||
Window occlusion is also supported on MacOS.
The preference(widget.windows.window_occlusion_tracking.enabled) affects only to Windows. It does not affect to non-Windows platforms.
Reporter | ||
Comment 4•1 year ago
|
||
Thanks! As it looks like this feature already exists for a while and didn't cause any problems so far. As such we should go ahead and disable this preference for recommended preferences in Remote Agent and Marionette.
Assignee | ||
Updated•1 year ago
|
Reporter | ||
Updated•1 year ago
|
Assignee | ||
Comment 5•1 year ago
|
||
Updated•1 year ago
|
Pushed by jdescottes@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/bb952bc13c55 [remote] Set widget.windows.window_occlusion_tracking.enabled to false for all remote protocols r=webdriver-reviewers,whimboo
Comment 7•1 year ago
|
||
bugherder |
Assignee | ||
Comment 9•1 year ago
|
||
Most impacted users should get the fix via the next geckodriver release, no need to uplift.
Assignee | ||
Comment 10•1 year ago
|
||
(In reply to Julian Descottes [:jdescottes] from comment #9)
Most impacted users should get the fix via the next geckodriver release, no need to uplift.
I was wrong here, the fix is in Firefox itself. Considering the amount of reports was low and there is a known workaround it's still not necessary to uplift this one.
Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
Description
•