Spawning firefox with geckodriver doesn't override the page visibility API anymore.
Categories
(Testing :: geckodriver, defect)
Tracking
(Not tracked)
People
(Reporter: shashank.sharma, Unassigned)
References
Details
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.
Reporter | ||
Comment 1•2 years ago
|
||
I tested this on firefox > 100, it is happening on all the versions.
Comment 2•2 years ago
|
||
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.
Reporter | ||
Updated•2 years ago
|
Comment 3•2 years ago
|
||
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.
Updated•2 years ago
|
Reporter | ||
Comment 4•2 years ago
|
||
Steps to reproduce:
- Open a firefox instance using getckodriver.
- Run this command
const i = setInterval(() => console.log(document.visibilityState), 1000);
- Make firefox out of focus, by moving it to the other virtual desktop that windows 11 provides.
- 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.
Reporter | ||
Comment 5•2 years ago
|
||
BTW, setting the widget.windows.window_occlusion_tracking.enabled
to false worked, thanks
Reporter | ||
Comment 6•2 years ago
|
||
We can close this issue, saw that firefox added the above property as true by default after 96 version.
Comment 7•2 years ago
|
||
(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•2 years ago
|
||
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.
Updated•2 years ago
|
Description
•