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.
Related
I would like to know, whether I'm currently debugging my javascript code?
Background: (Why I need to know)
I have created a page, that spawns a Worker.
When I run this page and press F12 to debug, I set a breakpoint in the Worker. This breakpoint will then get hit when I press my button to run the Worker (so far all good).
Now to prevent that the Worker runs forever I have created a simple timer in the main page, that terminates the Worker after 2 seconds, like this:
timer = setTimeout(function ()
{
worker.terminate();
worker = NewWorker();
}, 2000);
Now the problem: When the breakpoint is hit in Worker, the timer fires 2 seconds later (since the main page thread is still running independantly) and terminates the Worker. So I can't debug the Worker.
My plan is to simply disable (or not start) the timer, when I'm debugging.
So, Is there a way to know, if a debugger is attached?
Update:
My current workaround is to simply comment out the timer code, when I want to debug the Worker, but I would like to do a test.
Update2:
May be a debugger is always attached in the browser, but it's only active when it's visible. Breakpoints are only hit when you have the debugger window open.
So, is there a way to test that?
Well, it seems, there's no answer to this question.
Ideally I would want the browser to break all threads when one thread hit a breakpoint (Visual Studio can do this, but not in javascript).
May be one day browsers will support this.
Update:
Now Visual Studio supports debugging Worker. It's still an experimental feature. You enable it using the weirdly named option in 'Options', 'Debugger':
Enable using the multi-target Javascript debugger for debugging Javascript in applicable targets (requires debugging restart)
To debug a Worker, start debugging your page, then Visual Studio Solution Explorer will show show the Worker.js file. double-click and breakpoints.
However it has not really solved the problem with timers in the main thread firing when you hit a breakpoint in a Worker.
Background / use case
I would like to automate some page interactions by pasting a script into my browser console (normally Chrome/Chromium or in my case IE11 because.. don't ask.)
Typical steps in one iteration:
(initial) Visit a page, wait until it is fully loaded.
Fill in form values automatically, trigger some buttons, submit.
Wait for new page after form submission.
Go to 'next page', wait until it is fully loaded, start over with a new set of form values.
The "Visit a page" or "Go to 'next page'" could either happen by clicking a button, or by setting document.location.href explicitly.
The "wait for ..." can take up to 30 seconds in both cases. Not for any good reason, just because.
I am aware (to my current understanding) that the js (event listeners etc) included in a page does not survive a new page load. I am specifically asking about js called form the browser's developer console.
Question
How can I register an event listener from the console for "page load complete" after setting document.location.href, or doing something equivalent?
As mentioned, in my use case I would need to do this with Internet Explorer 11. But I assume people are more familiar with the developer tools in Chromium or Firefox. Any answer that works in one of these browsers is welcome, just mention which browser you tried this with.
Limitations
I do not control the web application where I want to do this, I only control my browser. It also does not look like the developers of said application would be likely to respond to feature requests or wishes.
Perhaps someone will suggest to do this with an iframe. I am not sure this will work. If it does, this would be a different question.
Perhaps someone will suggest some kind of browser simulator tool to use instead of the console. Unfortunately I need/want to make this work on Internet Explorer in a corporate Windows environment with limited privileges. Alternative tools can be mentioned, but there is a reason why I focus on browser console.
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.
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.