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.
Related
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?
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%.
I'm using a web framework where everything gets passed through a websocket. New / updated DOM elements are shipped over to the browser, events get shipped back to the server. Works great. Except when the websocket gets closed.
This happens...
when using desktop/mobile Safari's browser navigation buttons are used to leave & come back to the page
on mobile Safari after a timeout when switching to a different app, tab or screen locking
when the WiFi goes down etc.
After that the user simply sees a normal looking page, but everything is obviously dead as no more updates happen and no more events get relayed to the server. I'd like to simply refresh the page in that case. Either everything goes back to normal or the user sees a connection error in case of no network etc.
I tried poking around in the framework's code, adding "window.location.reload(true);" to the "onclose" handler for the websocket kinda does the trick. My state is 100% on the server, so reloading the page will just fix things.
Assuming I can't modify / fix the web framework I'm using, and it doesn't have any onConnectionLost client-side event, what's my best option to detect this scenario and reload the page? Are there any events like 'onPageDisplayedButNotProperlyReloaded', 'onPageVisibleButHasBecomeStaleInTheMeantime', 'onWebSocketsClosed' for me to use? Can I just open some dummy websocket and reload the page when it gets closed or something? Any other good way to detect this?
Thanks!
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.
I am working on a multiplayer chess game as a Facebook app.
If one player leaves the game by closing the browser the other player should get a notification. So if one player closes the Browser, a unlink function should be called to unlink the player. This works fine with onunload outside Facebook.
The problem is, that the Facebook apps are loaded in iframes and the onunload event doesn't work there.
So I need a way to call a function inside an iframe when a user is closing the browser.
This is probably not the answer you are looking for but "logging off" on unload will never work reliably. For an extreme example, consider the case where the browser crashes or is killed via the Windows task manager. So you better implement an additional mechanism to detect whether a user left. Typically this is done by sending a request to the server periodically. If this request isn't received for a significant time (meaning something that cannot be caused by a slow connection or other hiccups) you unlink the user.
That said, I tested Firefox 4 and MSIE 8 and both correctly fire unload event on the frame if the tab or the browser is closed. Chrome 12 doesn't do that, that's probably the browser you have been testing with. I consider it a Chrome bug.