I've created an empty HTML page with a simple setInterval() that fires an AJAX call, via window.fetch(), every 30 seconds, indefinitely. In Chrome, however, if I leave my computer for 24 hours and come back to it, I notice that at some point, the AJAX calls stopped firing.
Note that this computer does not go to sleep, hibernate, screen lock, etc. In other words, I walk away from the monitor, come back the next day, see the exact same screen I left it at when the day prior, and yet the Network tab in the Chrome debugger shows the browser stopped making the AJAX calls at some point.
What I'm wondering is, do browsers have some sort of internal process or thread management where they put "idle" tabs to sleep and stop executing network calls, or stop executing JavaScript intervals and/or timeouts? Is there some sort of resource conservation/memory management modern browsers do, where they put tabs to "sleep", that might explain this?
Related
I have a web app written in Typescript and VueJS that execute a collection of tasks (ajax requests) and to track the whole process (and to execute one task after another) I use a Vue instance as bus to notify changes between components.
If the user open a new browser tab, the process stop. If the user come back, the process resumes.
The issue is present in Firefox and in Chrome.
I put in my code a simple window.setInterval to log every 2 seconds an 'Hello' and...surprise I have an 'Hello' every 2 seconds without any temporal 'hole'.
I see a very old issue in github for a similar situation: https://github.com/vuejs/Discussion/issues/76 but seems to be too old to be this.
I expect that the process doesn't stop but continues without interruptions..
https://developers.google.com/web/updates/2017/03/background_tabs
Background tabs can have a dramatic negative effect on browser performance, especially on battery life. To mitigate this, Chrome has been placing various restrictions on background tabs for the last several years. Recently there’s been a number of efforts to make further improvements, and this document gives an overview of the Chrome policy. This document focuses on describing current policies in Chrome 57. Long-term strategy and further plans can be found in this document.
https://www.chromestatus.com/feature/6172836527865856
As an intervention we want to limit how much CPU a background page is allowed to use and to throttle timer queues when this limit is violated. Current target is that background page CPU load level should be under 1%.
Usually I post code on my posts but i'm just curios in general with this question on my mind so here's the situation. I have a couple of real time systems which uses one file that produces constant basic polling with CRUD(Create,Read,Update and Delete) traits. The way i'm doing this is
by putting the setTimeout at the end of that page which constantly call a function on the main page to recall that page AKA the polling with CRUD page by AJAX which also constantly analyze different components of the main web page and executes one of the CRUD traits depending on the logic of
the situation between the web page and the database, I know web browsers pauses a setTimeout on purpose for the purpose of saving computing energy when that web page is not being interacted with due to the following situations that I notice
for example on PC when a user revisits that kind of system when revisiting that web page after coming back from the lock screen or when revisiting that web page after coming back from the login page or when revisiting that web page after
coming back from a sleep state and even revisiting that web page after coming back from another web tab after long periods of time and on mobile browsers, when revisiting that web page after coming back from the lock screen or when
revisiting that web page after coming back from another app or when revisiting that web page after coming back from a sleep state. All these situations causes my real time polling with CRUD system to experience glitches but no glitches occurs if I remain on the page so I was just
wondering is there any JavaScript methods that I can use as response code to detect when a browser pauses a web page like this on PC or on Mobile devices like smart phones or tablets? I was thinking if there is a method like that. I can simply just
create a response code that can reload that web page if the browser does that.
At our company we are using a web application with shared licenses. Unfortunately if someone simply closes the tab the application is running in it wont release the license lock. I am wondering whether it is possible to run/trigger a scipt when a Firefox tab is closed, so I could automatically release the licenses? I think greasemonkey might be able to do this, but I haven't found a solution yet.
There is both window.onbeforeunload and window.onunload, which are used differently depending on the browser. You can assing them either by setting the window properties to functions, or using the .addEventListener:
window.onbeforeunload = function(){
// Do something
}
// OR
window.addEventListener("beforeunload", function(e){
// Do something
}, false);
Usually, onbeforeunload is used if you need to stop the user from leaving the page (ex. the user is working on some unsaved data, so he/she should save before leaving).
You can try to release locks in unload events, as Bcfm suggested in his answer, but what if browser or computer simply crashes? Or script takes too long to execute and gets killed by browser anyway?
Another approach would be to make the site constantly ping license server (i.e. every 10 seconds) so that lock is hold until there is no ping for proportional amount of time (i.e. 30 seconds). This way the license lock is freed in all cases.
Of course this may be not relevant to your scenario, it's just a suggestion.
Is there a way to detect a wake from hibernation? I am developing an extension that displays information when the user turns on the computer and logs in to the system. I can do that easily by setting the extension to run when the system starts and execute the codes instantly.
background.js
function displayInfo(){ /*...*/ }
displayInfo();
However, some users might not turn off their computer, rather, they would hibernate for faster wake time. Hibernate should still be considered that the user is "turning on" the computer, but currently I have no way of detecting that.
Is there anyway I can achieve that?
No "perfect/foolproof" method, but some an idea:
Record the system time every 5 minutes or so. If the current time is much larger than the expected time, assume it slept/hibernated.
Here's the situation:
I have a web-based ticket application, multiple users.
One problem that might occur (and does happen in the old version I'm replacing) is that user1 opens a ticket, edits it, and saves it. But while he was editing it, user2 also opened and saved the ticked. The changes user2 made will be lost/overwritten by user1.
To prevent this I implemented a locking mechanism, it's fairly simply:
On opening a ticket the PHP script checks for existing locks.
If it doesn't find any, it locks & opens the document.
In JS, setTimeout() and an XmlHttpRequest call to unlocks the ticket after 10 minutes (works w/o problems).
I also set an unload event to unlock the ticket when closing/moving away from the window/tab
The problem sits in step 4: The unload event (& it's friend beforeunload) just doesn't work well enough to implement this reliably (for this feature to have any serious meaning, it needs to be reliable), many browsers don't always fire it when I would like it to be fired (Like pressing back button, hitting F5, closing tab, etc. This varies per browser)
The only alternative I can come up with is using a setTimeout() and XmlHttpRequest() call to a php script to tell it the page is still open. If this "heartbeat" monitor fails we assume the user moved away from the ticket and unlock the document.
This seems horribly inefficient to me and quickly leads to many requests to the server with even a few users.
Anyone got a better idea on how to handle this?
It needs to work in IE8+ and other modern browsers (ideally, Firefox, Webkit, Opera). I don't care about IE6/IE7, our organization doesn't use those).
Using heartbeat pings via XHR is the way to go. Depending on the use case you might also want to send them after the user stopped typing in a field instead of every x seconds - this would ensure the page being kept open but inactive would not keep it locked.
If you send those XHRs after the user stopped typing, use one of the keydown/up/press events and a debounce / throttle script to send the request only when the user stops typing for e.g. 5 seconds and one every x seconds (in case it's likely enough the user will be typing for a long time).
Maybe it's not the best solution, but it's worth looking into it : websockets.
You could establish a connection with the server at page load and when the connection fails (ie the client does not respond to the ping), you can unlock the ticket.
Using something like socket.io ensures you that this procedure will work even on ie8.
The main advantage is that you do not send a request every n seconds, but the server sends you a ping every n seconds and you don't have to care about unload/beforeunload events. If the client doesn't respond to the ping, unlock the ticket.
The main disadvantage is that you need a server to handle all your websocket connections, which can be done in almost any server-side language, but it can be a bit harder than a simple web-service (in case of xhr polling)
Implementing ajax heartbeats or unload handlers to unlock the document automatically is tricky.
You problem is that even if you have support for beforeunload in all browsers that you target, it still might not be called if the browser crashes or the user falls asleep.
Look at how webdav works. You explicitly aquire a lock before you start edit, then you save and release the lock explicitly.
Other users can see who has acquired a lock and admins can release locks that has been left behind by accident.