Virtual mouse events created from touch events have 'which' member set to 0? #4728

bjbrewster opened this Issue Jul 19, 2012 · 4 comments


None yet

4 participants


When receiving vmousedown/up a vclick events created from touch events, I've noticed the 'which' member is 0 instead of 1 (left mouse button). Is this deliberate so that you can tell by the 'which' member if the event was from a touch event as opposed to a mouse event?

It's annoying you cannot just change your event bindings from 'mousedown' etc to 'vmousedown' etc but you also need to search for all references to 'which' and change tests for left mouse button events from (e.which == 1) to (e.which <= 1).

I ask this because I notice in, createVirtualEvent(event, eventType) has the following snippet that suggests that it is trying to set event.which to 1 if it is 0 / null / undefined?:

  // make sure that if the mouse and click virtual events are generated 
  // without a .which one is defined
  if (|up)|click/) > -1 && !event.which ) {
    event.which = 1;

Unfortunately, it is testing 't' that is the source event type, and not testing the new event type as the comment suggests it should be, so it is only setting which to 1 if the source event was a mouse down/up or click. Should this be "if ( ...." ??? If this IS meant to be testing for proper mouse clicks, then I would have expected the regex to be /^mouse(down|up)|click/. Unfortunately, changing this could potentially be a breaking change if users are relying on which being 0 for vmouse down/up and click events generated from touch events.

Thanks for looking into this and to everyone who helped make this awesome plugin,



You raise and interesting question here: given that we are trying to normalize touch and mouse events, should we also supply a spurious which value?

The existing spec doesn't make any mention of the attribute and this isn't surprising because it's actually a legacy attribute from the keyboard events according the the DOM lvl 3 events spec.

I'm wondering if we should explicitly set it to null in the case of normalized touch events so that at least there's less confusion.


I would agree, except this is a normalized jQuery event object ( that has a normalized 'which' property. As you mentioned, MouseEvent's 'which' property has been deprecated in the current spec for quite a while and you would normally check the button property but according to jQuery's event object 'which' property ( it says you should "Use event.which instead of event.button".

ldeluca commented Oct 23, 2014

@johnbender @bjbrewster It's been a couple years since anyone has commented on this issue. Can you guys confirm whether or not this is still an issue with the latest JQM?


We are going to be dropping vmouse in place of pointer events polyfill so i'm going to close this as wont fix.

@arschmitz arschmitz closed this Oct 23, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment