Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mouseWheelCallback : different behaviours/events on 'chrome/android/ios' vs firefox #1313

Closed
vorrin opened this issue Nov 11, 2014 · 7 comments

Comments

@vorrin
Copy link

vorrin commented Nov 11, 2014

Hello!

Here's a simple test:

http://jsfiddle.net/J5fUE/92/

when mousewheeling over the canvas, you can see in the console, that the 'event' passed to the callback is very different (ie. the one in firefox, being a DomMouseScroll, does not seem to have deltaY and deltaX, which instead it does have on Chrome).

Am I missing something or is this unexpected? I tried delving a bit further into phaser.js, but from there it looks like a DomMouseScroll listener is assigned in both cases, but in Firefox it ends up being the 'dominant' one.

Also, on firefox, the mousewheel callback is called on touch, as far as I can see.

Any insight on this would be handy, thanks!

@woutercommandeur
Copy link
Contributor

You should read the property wheelDelta (game.input.mouse.wheelDelta) it will contain the constants for up and down. (Phaser.Mouse.WHEEL_UP and WHEEL_DOWN). A cross browser real delta that gives you an idea of how much up and down is harder to get I guess and you will have to figure out yourself. If you have a good solution make a PR to add to it :)

For me (I added this functionality through a PR) knowing a mousewheel up or down happened was enough (used it to switch weapons in a game)

@vorrin
Copy link
Author

vorrin commented Nov 12, 2014

Hi Wouter, thanks for that!
So, I've switched to using game.input.mouse.wheelDelta, it's a touch less nice than having the deltaY but not all that different, so that problem is solved, thanks :)

Also, while this might be a pretty unlikely issue to run into(you need a PC, with a touchscreen, and to be using firefox), the other part of the report, ie. Firefox calling the mouseWheelCallback vs onInputDown on touch input, still stands.

@pnstickne
Copy link
Contributor

@vorrin The mouse in the PR has been updated to support Wheel events, which have been in FF since version 17 and IE since 9. Both the older Mouse Wheel (scroll in scrollDelta property) and DOM Scroll events (scroll in detail property) are wrapped to support the Wheel event interface if such a fallback is required.

Feel free to use either mouse.wheelDelta or event.deltaY (but do not share/use the event past the event handler). Remember to check the deltaMode - 1 is lines (probably the most common), but it could also be 0 (pixels) or 2 (pages). Also, deltaY and wheelDelta have inverted signs.

Ref. https://developer.mozilla.org/en-US/docs/Web/Events/wheel

@vorrin
Copy link
Author

vorrin commented Nov 12, 2014

@pnstickne oh excellent, thanks!
I pulled your branch, built a new version and tested with that.
The MouseEvent now does have deltaY and X (though they appear to have very different values between firefox and chrome, but I suppose that might be hard to change)!

That said though, I'm not sure by which change, but I get some really weird display problems with your version, with some sprites and bitmap text being placed in a completely different position on screen, ie. this is bitmap text added to a group together with a couple of sprites:

basic version: http://i.imgur.com/oHKeBvx.png

your branch: http://i.imgur.com/soZQXNN.png

As you can see the bitmap text goes way off in that second one.

Not sure if it comes from another change you previously made in your branch or well, what causes it at all.

@pnstickne
Copy link
Contributor

@vorrin Uh oh, that's likely from this code, but it does appear to be a problem with the 2.2.x/dev branch - there be some changes with/to the underlying PIXI and graphics as well.

Does 2.1.3 or the "vanilla" pre-PR 2.2.x (dev) have the same issues? If so that would be worth posting another bug report for.

@pnstickne
Copy link
Contributor

@vorrin As far the actual scroll delta .. that can definitely change.

To get a more precise value it may be warranted to have the user "calibrate" a scaling factor/transformation for the device input (or to do so unaware from the user) - assuming that it is capable of reporting a more precise scroll value and deltaMode=0 .. on my desktop, a line (eg. in deltaMode=1) is ~28-33 pixels, depending on browser and various page factors.

Ref. http://stackoverflow.com/questions/20110224/what-is-the-height-of-a-line-in-a-wheel-event-deltamode-dom-delta-line for some of the "fun".

@photonstorm
Copy link
Collaborator

Closing this off as the original issue is resolved. Feel free to open another for the visual issues once I've updated to pixi 2.1 in a few minutes time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants