piwik.js: Tracking middle clicks automatically (they do not fire onclick event)

[matt]

There is a regression from the old piwik.js and the new one: middle clicks that open in a new tab in modern browsers, and that are more and more used, are not counted anymore: they do not fire mousedown events.

Here is Anthon's explanation:

Switching from mousedown to click is consistent with how GA, 
Yahoo, and MS handle the event.

If the user releases the button off the element (to abort the 
operation), no click is generated.  Thus, mousedown can result
 in false outlinks/downloads being reported.

I don't recall if right mouse button clicks generated mousedowns
 on the element, but if it did, there's no way to determine what 
popup menu operation was selected (open in new window/tab, copy 
shortcut, save target, etc).

If we switched to mouseup, we'd also need a mousedown, to check 
for the same target element underneath and for double clicks.

Striving to capture all clicks is a laudable goal but there are 
a lot a conditions that make tracking mousedown/mouseup difficult
 or unreliable.

It's already unreliable to a degree.  click/mousedown/mouseup all 
bubble and are cancellable.  There's no way for Piwik to set the 
order that its eventlistener is called (eg first or last). An 
earlier listener could stop propagating the event.  A later 
listener could cancel the click event so the href isn't followed. 

Could we use the event.button as explained on  http://www.programmersheaven.com/mb/java-script/304443/304443/right-and-middle-click/?S=B20000 Maybe there is a way of "special handling" the middle click use case and count these clicks?

[matt]

see also the useful page:  Javascript madness: mouse events

[matt]

vipsoft, how much effort would it be to add middle click tracking? this seems important as most users are using middle clicks to open new tabs and we might miss a significant percentage of the traffic - but I wouldn't know the effort involved?

[vipsoft]

It shouldn't be too difficult to set up listeners for the mousedown/mouseup and add some state information... the tricky part is making it work cross-browser, and that it handles the case where the browser also fires a click.

[vipsoft]

Middle mouse button on IE and Webkit-based browsers generate click events.

[vipsoft]

(In [3783]) refs #409 - first party cookies

• API changes:
  • added: setCookieNamePrefix(cookieNamePrefix)
  • added: setCookieDomain(domain)
  • added: setCookiePath(path)
  • added: setVisitorCookieTimeout(timeout) - defaults to 2 years since last page view
  • added: setSessionCookieTimeout(timeout) - defaults to 30 minutes since last activity
  • added: setReferralCookieTimeout(timeout) - defaults to 6 months from the first visit
  • added: setConversionAttributionFirstReferer(enable)
  • added: getVisitorId()
    • for asynchronous tracking, use:

      	var visitorId;
      
      	_paq.push(function () {
      		visitorId = this.getVisitorId();
      	});
      

• Cookie notes:
  • The default cookie path is '/'. This might be viewed as a potentially insecure default because it allows cookies to be shared across directories on the same domain. (Again, see the social network example.) This is unfortunately, a necessity. If we leave the path blank, the behaviour is undefined (i.e., browser or browser-version dependent). For example, earlier versions of Firefox would default to '/'; later versions default to the origin path.
  • I was hoping to avoid this, but I added a hash to the cookie content similar to GA's setAllowHash(). This is needed for two reasons:
    1. Cookies are uniquely identified by the tuple (key,domain,path). Hashing only the domain is a bug. (See "social network website" use case.)
    2. There's a long-standing cookie+subdomain bug in Firefox (Gecko) dating back to 1.0 that leaks cookies from "example.com" (not ".example.com") to "xyz.example.com". @see  https://bugzilla.mozilla.org/show_bug.cgi?id=363872
• changed internal setCookie() method to take expiry time in milliseconds (was days)
• removed internal dropCookie() method as it was never used

@todo Missing unit tests and cross browser testing

refs #739 - piwik.js improvements

• jslint 2011-01-09
• new unit tests (integrated jslint, is_a functions, sha1(), utf8_encode(), etc)
• use ECMAScript String.substring() instead of non-standard (although widely supported) String.substr()
• implement domainFixup() so "example.com" and "example.com." are equivalent

• API changes:
  • added: killFrame() - a frame buster
  • added: redirectFile( url ) - redirect if browsing off-line, aka file: buster; url is where to redirect to
  • added: setHeartBeatTimer( delay ) - send heart beat 'delay' milliseconds after initial trackPageView(); set to 0 to disable
  • removed: piwik_log() - legacy tracking code; see trackLink()
  • removed: piwik_track() - legacy tracking code; see trackPageView()
  • removed: setDownloadClass() - deprecated; see setDownloadClasses()
  • removed: setLinkClass() - deprecated; see setLinkClasses()

refs #752 - track middle mouse button clicks (via mousedown+mouseup pseudo-click handler); defaults to tracking true "clicks"

• API changes:
  • modified: addListener( element, enablePseudoClickHandler = false )
  • modified: enableLinkTracking( enablePseudoClickHandler = false )

refs #1984 - custom variables vs custom data

@todo These are just stubs.

• API changes:
  • added: setCustomVar(slotId, key, value, opt_scope) - scope is 1 (visitor), 2 (sesson), 3 (page)
  • added: getCustomVar(slotId)
  • added: deleteCustomVar(slotId)

• API changes for consistency:
  • added: setCustomVar(slotId, obj, opt_scope)
  • added: setCustomData(key, value)
  • for the equivalent of deleteCustomData(), use:

        tracker.setCustomData(null);
    

[vipsoft]

Mark as fixed. Future commits to #1984.

[matt]

Is there anything that needs to be done to track middle clicks, ie. enable the pseudo click handler? what is the reason for not enabling it by default?

[vipsoft]

It is disabled by default because:

• everyone else uses "click"; using the pseudo click handler means one more thing to explain why Piwik numbers are different from <insert competition here>
• the pseudo click handler can be tricked into recording a click when in reality a drag event occurred
• the pseudo click handler can be prevented from recording clicks if buggy event handlers don't propagate either the mouseup or mousedown events
• on some older browsers (e.g., Opera < 8.0), you may only get the mousedown event on the middle button

To enable:

tracker.enableLinkTracking(true);