Make documents always appear to be visible and in the foreground
Categories
(Core :: DOM: UI Events & Focus Handling, task, P5)
Tracking
()
People
(Reporter: manday, Unassigned)
Details
I've noticed that marketing websites (e.g. https://profitsfly.com/shorteners/) reliably run down presence timers which pause if the tab is not focused. In my opinion, a website should not be able to introspect whether the tab within which it is displayed has focus or not, it's a privacy (and usability) issue; a website has no business inspecting the state of the browser beyond its container.
|
||
Comment 1•2 years ago
|
||
If we don't pause or restrict timers in tabs then animations in non-displayed tabs would pointlessly overwhelm the browser's CPU/GPU.
I should add that this particular timer holds even if the tab is visible but unfocused (as the firefox window is unfocused).
Re freezing (?, entirely?) websites in background to save ressources, I wonder how feasible this is as a general measure. Websites may (reasonably) expect to continue doing <whatever> (calculations, evolution) while the user does not focus them.
|
||
Comment 3•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Tabbed Browser' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 4•1 year ago
|
||
This might make more sense in Core :: DOM: UI Events and Focus Handling, though Core :: DOM: Core & HTML might also be a good fit. At any rate, Firefox :: Tabbed Browser is not the right component.
farre: Could you set the severity field or close this bug if you think it's not reasonable.
|
||
Comment 6•1 year ago
|
||
I'd guess that websites that want to detect if a document is hidden or not use the Page Visibility API, which is a Web API implemented by all major browsers. If you wish to drive a change of the spec I suggest you file an issue on GitHub.
What you say is true, but how is this relevant for this issue? No one claimed that it were a bug in Firefox, but it is a privacy issue. Would Mozilla not like to address this? The W3C specs cookies, webstorage, canvas elements, etc., yet Firefox provides features to mitigate the privacy problems that these specs cause. Shouldn't that extend to this problem, too?
A simple "always return false for Document.hidden" setting would probably be enough while leaving the spec intact. I do not understand why you propose that be changed (or how would that be changed) in the spec.
|
|
||
Comment 8•1 year ago
|
||
This was filed as a defect, I'll reopen and set it to task.
|
|
||
Comment 9•1 year ago
|
||
To implement this feature we'd need to do:
Disable Page Visibility API
Turn off background throttling of setTimeout/setInterval/requestIdleCallback (including budget throttling)
Disable all possibilities of suspending windows.
... and probably a lot more features that I've forgotten. I have no idea how this would impact Mobile. It would require a great deal of re-architecturing, especially around the suspend logic.
|
Reporter | |
Comment 10•1 year ago
|
||
Thank you and apologies for misclassifying the issue initially!
I think it's important to note that the changes you mention can be grouped into two categories:
One, there is Firefox which explicitly and unambigiously exposes the private information through the API. It would already be a significant step forward if this (i.e. the Page Visiblity API -- albeit not disabled, but just return a fixed value) could be changed.
Two, there is perhaps a plethora of side-channels from which a website may or may not infer the current visibility. None of which, however, give the website absolute certainty. In fact, there may be so many of them that I think addressing them (if really necessary) could be a constant WIP.
Description
•