2

I have built an internal application for our company's users. There is no timeout after user inactivity nor do we want one. Users are complaining that after a certain amount of time (like 30 minutes) of inactivity, the web app starts acting strange if the start to use it again. Buttons don't work, combo boxes will not drop down, datepickers are broke. It seems very clear to me that the Javascript is getting disabled after period of user inactivity.

Has anybody come across this behavior and if so, how do I prevent it?

The web app is an ASP.NET MVC 3.0 app, using the Telerik MVC Extensions, which includes writing some client side Ajax. It is running on IIS 6.0 on Windows Server 2003 Standard Edition.

Paul Sonier
  • 38,903
  • 3
  • 77
  • 117
Steve3p0
  • 2,332
  • 5
  • 22
  • 30
  • 1
    30minutes - looks like Forms, session timeout? – Tomas Voracek Jul 08 '11 at 21:03
  • Thank you everyone for your comments. The session state timeout was the issue. I increased it to 24 hours. However, it's also a network connectivity issue with users using XP. XP users of my site who experience a network disruption find that they can't click on buttons etc. (they end up losing work because they can't save). They have laptops, they go to meetings, the dock and undock, take their laptops home, etc. Windows 7 user don't experience this problem, when they reconnect, everything works fine. – Steve3p0 Jul 13 '11 at 23:46
  • Wait a minute. I just had these users test this with my dev server. They don't have this problem at all. I found out what the difference was on my dev server. We were toying with requiring client certificates. We set the Client Certificates setting in IIS to "Accept Client Certificates". This caused a lot of weird client side behavior and it depended on brower, OS combinations. Setting this back to "Ignore client certificates", seems to have removed this problem entirely. I will have to do some more testing to make sure. – Steve3p0 Jul 14 '11 at 01:26

6 Answers6

1

Check if the script is setting any cookies with a ~30 minute TTL value.

AlienWebguy
  • 76,997
  • 17
  • 122
  • 145
1

I think it is related to the session timeout. Since user lost its own session value, ajax integration with server will not be accepted by server, which in return user thinks the site stopped working. Based on the description, if site stops working after 30 min, and user completely reloads the page with refresh button, the user would have to re-login again because the session value is lost.

There are several solutions to this.

You would have to create a hidden iframe which it reloads itself every 10 minutes

Or

Extends the session timeout time more than 30 minutes(1800 seconds)

Or

Periodically send ajax request to the server to keep the connection.

user482594
  • 16,878
  • 21
  • 72
  • 108
0

This might be offbase- but sometimes there is a memory leak which can cause this kind of behavior. I run into this problem with gmail. Scripts running in the background can do it. Can you determine how much memory usage the browser is using when this happens?

ek_ny
  • 10,153
  • 6
  • 47
  • 60
0

First I'd try firing an event at a given interval to see whether javascript is actually starting to lag, or if it a session timeout as others are suggesting.

Add this function in the body of your document somewhere:

window.onload = function() {
    setInterval(messageLogger, 15000);
};
function messageLogger() {
    var now = new Date();
    console.log(now.getMinutes()); //Or now.getTime() or whatever makes the most sense to you
}

Open up your console, and monitor that after leaving the page inactive for a while. If it continues to fire every 15 seconds indefinitely, javascript isn't disabled, nor is it likely to be a problem with your javascript code. At that point, I'd start to look into whether it might be a session issue. If you do notice the log messages starting to lag (or stop) you've got a memory leak in your javascript somewhere.

Jedediah
  • 1,916
  • 16
  • 32
0

Javascript isn't stopping functioning; your session is timing out somewhere. The dynamic components of your site are failing in their requests to the servers because their session cookies are no longer valid; you need to find where the session is initially being set, and increase the session expiration time.

Paul Sonier
  • 38,903
  • 3
  • 77
  • 117
0

Wait a minute. I just had these users test this with my dev server. They don't have this problem at all. I found out what the difference was on my dev server. We were toying with requiring client certificates. We set the Client Certificates setting in IIS to "Accept Client Certificates". This caused a lot of weird client side behavior and it depended on brower, OS combinations. Setting this back to "Ignore client certificates", seems to have removed this problem entirely.

Steve3p0
  • 2,332
  • 5
  • 22
  • 30