1772783 - Spawning firefox with geckodriver doesn't override the page visibility API anymore.

Status: RESOLVED WONTFIX

(Testing :: geckodriver, defect)

Description

[shashank.sharma]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.64 Safari/537.36

Steps to reproduce:

Create a selenium instance using geckodriver and firefox and make it out of focus, by moving it to other desktop on windows 11.

Actual results:

the pagevisibility API is returning document.visibilityState as false whenever the browser is not in focus, previously on firefox 96 it was returning true whether the browser was in focus or not.

Expected results:

When spawning firefox with geckodriver the pageVisibility api should return true even if the browser is not in focus, this causing the test cases to fail as some websites stop their rendering if the document is not in visibilityState.

Comment 1

[shashank.sharma]

I tested this on firefox > 100, it is happening on all the versions.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Does changing widget.windows.window_occlusion_tracking.enabled=false restore the previous behavior? This is an intentional change, selenium never overrode the page visibility API afaict.

Comment 4

[shashank.sharma]

Steps to reproduce:

1. Open a firefox instance using getckodriver.
2. Run this command const i = setInterval(() => console.log(document.visibilityState), 1000);
3. Make firefox out of focus, by moving it to the other virtual desktop that windows 11 provides.
4. You would notice the console logs false when firefox is not in focus or when we are on a different desktop.

---

If we retry the above steps with firefox 96
The console logs true irrespective of whether it is in focus or not.

This change came after firefox 96 I think, and persists in the latest release as well.

If more info is required, I can provide a video showing the difference, please share any email where I can send the video.

Comment 5

[shashank.sharma]

BTW, setting the widget.windows.window_occlusion_tracking.enabled to false worked, thanks

Comment 6

[shashank.sharma]

We can close this issue, saw that firefox added the above property as true by default after 96 version.

Comment 7

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

(In reply to shashank.sharma from comment #0)

Actual results:

the pagevisibility API is returning document.visibilityState as false whenever the browser is not in focus, previously on firefox 96 it was returning true whether the browser was in focus or not.

Not sure what that means but false and true are not valid values for the document.visibilityState property. As such I doubt that these are the actual results. Maybe you meant to reference the hidden property instead?

Nevertheless WebDriver should simulate a behavior of the browser which is close to what a real human being would see when interacting with web pages. This should also includes changes of behavior of web pages that are running in background tabs or hidden windows. Only that way performance critical tests can be performed without affecting the current tab's page load measurement.

I feel that if someone wants to explicitly disable this feature it should happen via an opt-out by setting the widget.windows.window_occlusion_tracking.enabled preference to false.

Nevertheless we will discuss this topic and triage the bug accordingly. Until a decision has been made I'm going to reopen the bug.

Comment 8

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

With geckodriver and per WebDriver classic specification any interaction with tab related content will happen when the tab is in the foreground. But that's a bit different to the case here which is for other virtual desktops.

Due to possible performance issues we do not want to modify the default behavior of Firefox, and would leave it up to the test author to set the preference if really required.

As such closing the bug again as wontfix.