McAfee Anti-Phishing filter for Internet Explorer causes onclick events to not fire?
I very often neglect writing here in favor of devoting that time to paying work. But recently I found something that might be helpful to somebody else so I thought I’d take advantage of that.
Over the last few months, a handful of our clients have had customers report issues with their websites. Online searches at the time didn’t turn up anything that sounded like the problem I was trying to fix so I figured writing about its resolution now might help someone else in the same boat I was.
The most common bug reported was that customers ended up on the site homepage when they clicked links that should go somewhere (or do something) else. For the few that reported it, clicking a tab on a Moosejaw product page to view additional details sent them to the homepage instead. Or clicking the Sign-In link up at the top of the same page sent them to the sign-in page instead of revealing a small inline sign-in form.
The sign-in link bug was more of a minor inconvenience since users still ended up at a sign-in page. They just missed the benefit of being able to do it without leaving their current page. The product tab issue was more critical however since users affected by the bug weren’t able to view information that may or may not affect their decision to buy.
All of the users who reported problems were using Internet Explorer 7 on either Windows XP or Vista. While the majority of the browsing public meets that criteria, we were still getting very few reports of problems. Unfortunately no one in our office or the clients’ could reproduce the problem. It had to be some setup unique enough that not every one using Windows/IE was experiencing it (thank god) but common enough among the half dozen people who took the time to report it.
Luckily we had a customer willing to help us diagnose the problem. He easily reproduced the error for us during a Go-To Meeting and also patiently labored through test pages that we tweaked on the fly to try to solve the problem. To no avail.
Without getting too bogged down in detail, the product tab links look like this:
<a href="#" onclick="somefunction();">tab text</a>
Normal behavior is that javascript code in somefunction is executed when the onclick event fires and the browser is prevented from changing its location to the value of the href attribute by a return false; statement at the end of somefunction. In this case, the content of each tab is written when the page is rendered and somefunction sets the display attribute of the clicked tab to block and the display attributes of the other tabs to none. Simple.
Except that for some users, clicking the tab was taking them to the location specified in the href attribute, #, the root of the site. At first we thought there was a scripting error that was causing the function to fail before the return false; could be executed. But Internet Explorer wasn’t reporting any errors on the page. We tried moving the return false; statement inside the onclick to be on the safe side.
<a href="#" onclick="somefunction();return false;">tab text</a>
That didn’t work either. Although with a return false; statement in the function itself and no script errors being generated, I didn’t really expect it to make any difference.
We tried changing the href attribute to
<a href="javascript: void();" onclick="somefunction();">tab text</a>
Which is a common technique for using a elements to execute code rather than changing locations. But all that did was stop the browser from going to the homepage. Our tab content still wasn’t showing. somefunction was still not being executed.
Eventually fixing the bug ended up on the back burner because of the extremely low volume of people reporting it. My heart sank recently when another complaint surfaced. What were we going to tell this customer when we had exhausted possible solutions before and come up with nothing?
Luckily the most recent complainant was pretty comfortable technically and started investigating possible causes on his own. The best news came when he reported that restoring Internet Explorer to its default settings and disabling all his add-ons solved the problem and the onclick events started behaving as expected again. Then he re-enabled his add-ons until he isolated the cause as the McAfee anti-phishing filter installed by his McAfee anti-virus suite.
At the time of this writing, a Google search for ‘McAfee anti-phishing filter’ has only turned up complaints of it causing sites to load slowly. Nothing regarding its effect on Javascript code. I couldn’t find any evidence on McAfee’s website that this is a known issue. Supposedly, the customer reported it to McAfee so hopefully I’ll have additional details soon. Such as a possible work-around. Other than simply disabling the filter. Interestingly, Internet Explorer’s built-in anti-phishing filter does not exhibit the same behavior.
On a side note, this bug draws attention to an interesting usability question. The product tabs, whose href attribute is set to #, completely failed for those users affected by the bug. While the Sign-In link, whose href attribute was set to a sign-in page URL, was still usable even though the onclick event’s failure to fire prevented the inline sign-in form from appearing.
Should the tab links have real values in their href attributes? Since each tab content doesn’t have its own URL, where should the link point to? Is it necessary to create server-side programming that accepts URL querystring parameters and uses it to show the appropriate tab in the event the onclick event fails and the page is redirected? I know in at least one case, the failure of the product tabs code caused a customer to order from a competitor where he could view the information he needed to make his decision.
