input events should support processing within DOM callback

[Antriel]

Currently Phaser caches input (pointerdown/up/etc.) dom events and only processes them on the next update.

This is potentially a problem if we want to trigger outgoing link/ads on a button, as those need to be initiated from within the DOM event handler callback.

Current implementation causes "popup blocked" when trying to open new page on button callbacks on chrome and I assume ios/android too.

[ateufel]

@photonstorm I don´t know how Phaser works internally, but would it be a good solution to include a separate/new event that fires immediately just for that? Not sure how easy it is to implement, though.

[photonstorm]

I don’t think so, because devs will just use that event instead, cram it full of loop breaking calls and wonder where all these random errors come from. I think I’d prefer to just offer a dom safe means of opening a new window and keep it as far away from the internal input as possible. Will have a think once 3.4 is out.

[Antriel]

My temporal workaround for those looking for a simple solution:

displayObject.on('pointerover', function() {
	GlobalStorage.onClick = function() { ... };
});
displayObject.on('pointerout', function() {
	GlobalStorage.onClick = null;
});
//and in your starting point (main class or something)
document.addEventListener('click', function(event) {
	if(GlobalStorage.onClick != null) GlobalStorage.onClick();
});

[ateufel]

Nice solution. One problem though, pointerover and pointerout are not getting called on mobile (because there is no mouse). How do you deal with that?

[Antriel]

That's...
a very good point.

I'm not sure. I suppose the same trick could work by adding the global action on pointerdown, but that could break if the user releases the touch before the frame gets processed. Which would have to be very very fast, but the chance is still there. So not a great solution.

Also thinking about touch, doesn't that leave the pointer at the last place there was touch event? So assuming my previous code is used, and gets triggered via pointerover, clicking anywhere else would trigger the click event again, instead of moving pointer elsewhere.

Yeah this needs a proper solution. I suppose simply keeping a list of input rectangles (or zones or w/e) in screen coordinates with actions included could work well.

[photonstorm]

Thank you for submitting this feature request. We have implemented this and the feature has been pushed to the master branch. It will be part of the next release. If you get time to build and test it for yourself we would appreciate that (there are new examples in the labs showing how to use it)