Javascript runs poorly in the active tab of a window that isn't foregrounded
Categories
(Core :: Widget: Win32, defect)
Tracking
()
People
(Reporter: reschultzed, Unassigned)
References
(Blocks 1 open bug)
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:98.0) Gecko/20100101 Firefox/98.0
Steps to reproduce:
I ran the Javascript-based browser game Cookie Clicker (http://orteil.dashnet.org/cookieclicker/) in the active tab of a window that is usually not in the foreground on my Windows 7 machine.
Actual results:
The game runs poorly and slowly, with counters incrementing at a fraction of the intended speed, whenever the window is not in the foreground. Additionally, when I click on the Firefox icon on the taskbar, causing it to show a live preview of each window, the game's textures jitter, disappearing and reappearing as if they had been unloaded from memory in the interim.
Expected results:
A dynamic webpage in an active tab should not behave differently based on whether or not the window is currently in use. The game should run at its normal speed, as it did for the past eight years before Firefox 98 was released. My best guess is that this is the result of a change to the implementation of document.hidden, as the browser no longer behaves as described by Andy Earnshaw here: https://bugzilla.mozilla.org/show_bug.cgi?id=917090 There should, at the very least, be some means of allowing a specific window to behave as if it is in the foreground when it isn't.
|
||
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Privacy: Anti-Tracking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•2 years ago
|
||
You can probably set widget.windows.window_occlusion_tracking.enabled to false to get the old behaviour.
|
Reporter | |
Comment 3•2 years ago
|
||
(In reply to Timothy Nikkel (:tnikkel) from comment #2)
You can probably set widget.windows.window_occlusion_tracking.enabled to false to get the old behaviour.
This works perfectly, thank you very much!
|
|
||
Comment 4•2 years ago
|
||
The severity field is not set for this bug.
:spohl, could you have a look please?
For more information, please visit auto_nag documentation.
|
||
Comment 5•2 years ago
|
||
(In reply to Timothy Nikkel (:tnikkel) from comment #2)
You can probably set widget.windows.window_occlusion_tracking.enabled to false to get the old behaviour.
Would it be appropriate to close this as WONTFIX since this was an intentional change, or is there any followup work that should occur here?
|
|
||
Comment 6•2 years ago
|
||
I don't really know, I'm not involved in the occlusion tracking work, I'm just aware of it's existence.
|
|
||
Comment 7•2 years ago
|
||
Sotaro-san, could you please answer the question in comment 5? Thank you!
|
||
Comment 8•2 years ago
|
||
(In reply to Stephen A Pohl [:spohl] from comment #5)
(In reply to Timothy Nikkel (:tnikkel) from comment #2)
You can probably set widget.windows.window_occlusion_tracking.enabled to false to get the old behaviour.
Would it be appropriate to close this as WONTFIX since this was an intentional change, or is there any followup work that should occur here?
Sorry, it becomes WONTFIX like Bug 1759393 . It is intentional change on Windows and the window occlusion is already enabled on MacOS long time ago, since MacOS supports window occlusion event.
Description
•