2.4 RC1: onInputUp isn't passed the button any more?

[wayfu]

this.events.onInputUp.add(this.onMouseUp, this);
this.onMouseUp = function(object, pointer) {
        console.log(pointer.button);
}

in 2.3, this logs the button that was released. in 2.4, it doesn't

[photonstorm]

It never actually did it properly though! So to avoid any confusion I have removed the properties entirely and updated the jsdocs to explain what you should actually be using now (pointer.leftButton, etc)

[wayfu]

Perhaps this was closed too early:

this.events.onInputUp.add(this.onMouseUp, this);
this.onMouseUp = function(object, pointer) {
        console.log(pointer.leftButton);
}

Logs:

false

I realize that after the mouse has gone up no button is being pressed, but how can I read the button that was released to trigger the onInputUp event?

[photonstorm]

pointer.event.button - but there is no guarantee the event is fired because just one button went up, so never rely on it (it's why the 2.3 implementation is completely wrong, as it relied on that dom event property for everything, when it should really have been using the buttons bitmask instead).

[wayfu]

Perhaps I am misunderstanding you, but the pointer that's being passed to my handler does not have a pointer.event, let alone pointer.event.button

[wayfu]

I think I just found a workaround: If I collect the active pointer's left/right/middleButton values every frame and then compare those stored values to the one in the pointer I'm being passed in the event handler, I can suss out which one(s) have changed. I'm not sure it's a clean solution (the added overhead from updating a few bools shouldn't matter, but I don't know if there is a chance that the timing could be such that the update function would already have set the button flag to false before the handler is started?)

workaround implemented with 2.4 rc1: http://jsfiddle.net/fpds924d/4/

[wayfu]

update: this technique also works in my actual project.

[wayfu]

update 2: it DOES happen from time to time that the global variables have already been updated when the event handler starts, so I occasionally get the weird and wrong behaviour, perhaps one in a hundred drag events.

So I'd still really appreciate an ironclad, built-in way to check which button triggered the onInputUp event, if such a thing is possible with the current system

[wayfu]

further experimentation reveals that a separate browser event is dispatched for every released button, and the event.button property contains the button that was released (0, 1, 2 for LMB, RMB, MMB). so if you release two buttons at the same time, you get two events. event.buttons always seems to contain the current status of what's pressed and what's not, which in the case of a mouseup isn't very helpful. I think you shouldn't necessarily use the buttons bitmask for everything and the button property for nothing, and it doesn't sound like the 2.3 implementation was all wrong after all! The button property certainly shouldn't be removed, and the docs should be updated to reflect the actual contents of button vs buttons.

[wayfu]

(at least, that's how it works in chrome.. IE is a whole different thing apparently?)

[wayfu]

I've amended Phaser.Pointer.prototype.updateButtons with the line this.button = event.button;, and now I can check the pointer that's being passed for which button was released. woot! :)

[photonstorm]

All of the Pointer booleans (leftButton, etc) have been replaced with the new DeviceButton class. These objects have their own signals (onDown, onUp), isDown, isUp, duration properties and things like justReleased.

They are always updated before any of the Pointer signals are dispatched.

So you can now easily check the state of a specific button in a global onInputUp event.

What I'm now considering is that Pointer.stop shouldn't be processed at all if ANY of the buttons are still down. For example it sets things like the timeUp value, etc - but it's misleading imho. I do think those properties probably ought to move to the DeviceButton class itself.

[wayfu]

Cool!

I still think you're underestimating the usefulness of event.button, especially for mouseUp, but it's exposed in the pointer and that's all I need ;) Thank you!

[photonstorm]

Added the mouse consts back in for comparison. Now happy with the way this works so closing off.