Passpack + Chrome = Frustration

Everyday I log into Passpack and leave it open all day. So here’s the problem after having Passpack open for a while I get the following message (it is extremely annoying as it interupts whatever else your up to on the net). This only happens for me in Chrome. It works like butter in Firefox and I can’t speak for IE.

Passpack History Problem

The initial trigger for the message seems to be random. But after it initial message is seems to come back around every 3 minutes. So I did some digging. After poking around in the source I discovered that they’re using an older version of Tako Sano’s jQuery history plugin.

So I added some code to the historyCallback do some logging so I could get a better feel for what was going on.

After letting this run for a while I started to see a pattern. Here’s an excerpt of the results.

  • hh: 8, m: 7, delta: 209901 (~3.4 minutes)
  • hh: 8, m: 7, delta: 200888 (~3.3 minutes)
  • hh: 8, m: 7, delta: 190944 (~3.2 minutes)
  • hh: 8, m: 7, delta: 183514 (~3.0 minutes)
  • hh: 8, m: 7, delta: 197517 (~3.3 minutes)

For webkit (Chrome/Safari) based browsers the jQuery history plugin manually creates a stack to keep track of the history. So this is where I believe we are encountering the problem. If you look at line 4426 you can see that we create a history with a stack length of 9.

But on line 4419 we are working with a stack with a length of 8.

var m = $.browser.netscape ? 2 : $.browser.msie ? 3 : 7;

Shouldn’t this read as follows?

var m = $.browser.netscape ? 2 : $.browser.msie ? 4 : 8;

Notice: Theme without comments.php is deprecated since version 3.0 with no alternative available. Please include a comments.php template in your theme. in /var/www/funkjedi.com/wp-includes/functions.php on line 3390

6 Responses to “Passpack + Chrome = Frustration”

  1. Francesco says:

    Hello Tim,
    I am Francesco Sullo, the Passpack CTO. First – thank you very much for your post.

    Yes, we’re using the older version of the history plugin. Since it seemed to be working well with all browsers, we let it as is. What’s strange is that Chrome is my preferred browser, and my Chrome doesn’t produce the history error so it wasn’t showing up in testing. Thanks for the heads up.

    I studied the problem, and here’s what I found. You correctly noticed that there is an inconcistency between the two reported lines. This is an error, though the second shoud be:

    var m = $.browser.netscape ? 1 : $.browser.msie ? 4 : 8;

    I simplified it now, removing the Netscape condition since Netscape now is Mozilla-based. This, however, didn’t resolve the history problem which actually depends on the previous line:

    var hh = parseInt(h);

    Changing it as follows seems to fix the error:

    var hh = parseInt(h,10);

    When you don’t specify the numeric base in the parseInt call, Javascript should consider 10 as the default. But in some browsers, where the number string is ambiguous, I noticed the string value is considered as an octal string instead of a decimal string. The result of the parseInt command produced surprising values.

    Can you let me know if this has fixed the error for you?
    Thanks again.

  2. Francesco says:

    Hello Tim,
    I am Francesco Sullo, the Passpack CTO. First – thank you very much for your post.

    Yes, we’re using the older version of the history plugin. Since it seemed to be working well with all browsers, we let it as is. What’s strange is that Chrome is my preferred browser, and my Chrome doesn’t produce the history error so it wasn’t showing up in testing. Thanks for the heads up.

    I studied the problem, and here’s what I found. You correctly noticed that there is an inconcistency between the two reported lines. This is an error, though the second shoud be:

    var m = $.browser.netscape ? 1 : $.browser.msie ? 4 : 8;

    I simplified it now, removing the Netscape condition since Netscape now is Mozilla-based. This, however, didn’t resolve the history problem which actually depends on the previous line:

    var hh = parseInt(h);

    Changing it as follows seems to fix the error:

    var hh = parseInt(h,10);

    When you don’t specify the numeric base in the parseInt call, Javascript should consider 10 as the default. But in some browsers, where the number string is ambiguous, I noticed the string value is considered as an octal string instead of a decimal string. The result of the parseInt command produced surprising values.

    Can you let me know if this has fixed the error for you?
    Thanks again.

  3. Francesco says:

    Tim,
    Just so you know – you helped us kill two bugs with one stone!

    Before today, when someone connected to Passpack, Internet Explorer 6 would throw up an alert about there being non-secure items in the page. We’ve been trying to track down the cause for months now. Today, studying the history plugin I noticed that it prepends an iframe without source to the page body. That was the problem, and we’ve now fixed it.

    Thank you very very much.
    Sincerely,
    Francesco

  4. Francesco says:

    Tim,
    Just so you know – you helped us kill two bugs with one stone!

    Before today, when someone connected to Passpack, Internet Explorer 6 would throw up an alert about there being non-secure items in the page. We’ve been trying to track down the cause for months now. Today, studying the history plugin I noticed that it prepends an iframe without source to the page body. That was the problem, and we’ve now fixed it.

    Thank you very very much.
    Sincerely,
    Francesco

  5. funkjedi says:

    Glad I was able help to get your eyeballs in the right part of the code to spot that IE6 bug. It’s definately odd that your Chrome install works fine. I get these error’s on all three of my computers. Maybe it’s because I’m using the version from the dev channel. Anyway I just saw the update you pushed out in main.83.js limiting the alerts to fire only once and all I can say is… THANK YOU, THANK YOU, THANK YOU.

  6. funkjedi says:

    Glad I was able help to get your eyeballs in the right part of the code to spot that IE6 bug. It’s definately odd that your Chrome install works fine. I get these error’s on all three of my computers. Maybe it’s because I’m using the version from the dev channel. Anyway I just saw the update you pushed out in main.83.js limiting the alerts to fire only once and all I can say is… THANK YOU, THANK YOU, THANK YOU.

Leave a Reply

You must be logged in to post a comment.