Javascript – How to prevent a user from having multiple instances of the Same Web application

asp.netjavascriptvisual-studio-2005

I'm wondering if it is possible to determine if a user already has a web browser open to the web application I'm working on. It seems that they can open several instances of the same web app and click on buttons to read information that they have used before to enter into an input screen that they're currently working on.

What happens though is that it seems to screw up Session variables and then the user will update their previous work with their new work. Or they will delete their previous work all together or who knows…

EDIT
I have seen this done before with online banking web applications. If you are already logged in, the new window will kindly tell you that you already have the app open. In my case, the user does not need to log in.

Is there a simple way to determine if they already have a browser window open to the web application and if so, just close the browser or display a different page to let them know they can only have 1 open at a time?

Thanks

Best Solution

Firstly, no there isn't, and secondly, you shouldn't try.

The pop-up window strategy won't work (and will annoy users). I have my browser set to 'Open windows as Tabs', and I choose whether to split one off into another window. Or in some cases, whether to run a different browser -- not just another instance of the same one -- to display another page on the same site.

Conversely, the mini-session ID will fail because the server can't keep track of whether a request is from the same user as an existing session. Several people may be using the same machine, even with the same username; or one person may have several separate login sessions, on one or several machines.

Just sort out your protocol vs. 'Session' variables and make sure that the last committed changes are the ones that persist.

Related Solutions

Javascript – Why is setTimeout(fn, 0) sometimes useful

In the question, there existed a race condition between:

The browser's attempt to initialize the drop-down list, ready to have its selected index updated, and
Your code to set the selected index

Your code was consistently winning this race and attempting to set drop-down selection before the browser was ready, meaning that the bug would appear.

This race existed because JavaScript has a single thread of execution that is shared with page rendering. In effect, running JavaScript blocks the updating of the DOM.

Your workaround was:

setTimeout(callback, 0)

Invoking setTimeout with a callback, and zero as the second argument will schedule the callback to be run asynchronously, after the shortest possible delay - which will be around 10ms when the tab has focus and the JavaScript thread of execution is not busy.

The OP's solution, therefore was to delay by about 10ms, the setting of the selected index. This gave the browser an opportunity to initialize the DOM, fixing the bug.

Every version of Internet Explorer exhibited quirky behaviors and this kind of workaround was necessary at times. Alternatively it might have been a genuine bug in the OP's codebase.

See Philip Roberts talk "What the heck is the event loop?" for more thorough explanation.

Javascript – How to prevent buttons from submitting forms

You're using an HTML5 button element. Remember the reason is this button has a default behavior of submit, as stated in the W3 specification as seen here: W3C HTML5 Button

So you need to specify its type explicitly:

<button type="button">Button</button>

in order to override the default submit type. I just want to point out the reason why this happens.

Best Solution

Related Solutions

Javascript – Why is setTimeout(fn, 0) sometimes useful

Javascript – How to prevent buttons from submitting forms

Related Question