1802473 - Marionette commands like "WebDriver:FindElements" can fail when Firefox window is occluded on Windows

Status: RESOLVED FIXED

(Remote Protocol :: Marionette, defect, P1)

Description

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

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.

Comment 1

[Sotaro Ikeda [:sotaro]]

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
  • https://searchfox.org/mozilla-central/rev/77a39e7595198fd30b57550749c15761d30314fb/gfx/thebes/gfxPlatform.cpp#3006
  • https://searchfox.org/mozilla-central/rev/77a39e7595198fd30b57550749c15761d30314fb/testing/web-platform/tests/tools/wptrunner/wptrunner/browsers/firefox.py#247

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.

• https://bugs.chromium.org/p/chromedriver/issues/detail?id=3657

• https://bugs.chromium.org/p/chromedriver/issues/detail?id=3641

• https://source.chromium.org/chromium/chromium/src/+/aa109a26304654435e85997e20c992e88c627a7d

• https://source.chromium.org/chromium/chromium/src/+/main:chrome/test/chromedriver/chrome_launcher.cc;l=105

Comment 2

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

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?

Comment 3

[Sotaro Ikeda [:sotaro]]

Window occlusion is also supported on MacOS.

• https://searchfox.org/mozilla-central/rev/670e2e0999f04dc7734c8c12b2c3d420a1e31f12/widget/cocoa/nsCocoaWindow.mm#2972

The preference(widget.windows.window_occlusion_tracking.enabled) affects only to Windows. It does not affect to non-Windows platforms.

Comment 4

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

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.

Comment 5

[Julian Descottes [:jdescottes]]

Attachment: Bug 1802473 - [remote] Set widget.windows.window_occlusion_tracking.enabled to false for all remote protocols

Comment 6

[Pulsebot]

Pushed by [e-mail]:
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

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/bb952bc13c55

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Is this something we need on ESR?

Comment 9

[Julian Descottes [:jdescottes]]

Most impacted users should get the fix via the next geckodriver release, no need to uplift.

Comment 10

[Julian Descottes [:jdescottes]]

(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.