Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upTouch: touch events generated inadvertently #464
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment
Hide comment
bburdette
Dec 21, 2015
In oscpad I made a hacky fix by just adding a copy of Touch.elm ("SvgTouch.elm") in my project, and making my changes to that. So oscpad doesn't exhibit the problem anymore, but it should still manifest at commit a7de3341b2a00c482a05aa8b8e74485ae8158de4.
bburdette
commented
Dec 21, 2015
|
In oscpad I made a hacky fix by just adding a copy of Touch.elm ("SvgTouch.elm") in my project, and making my changes to that. So oscpad doesn't exhibit the problem anymore, but it should still manifest at commit a7de3341b2a00c482a05aa8b8e74485ae8158de4. |
evancz
added
the
no sscce
label
Dec 27, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment
Hide comment
|
Touch stuff isn't handled in this package anymore. |
evancz
closed this
May 11, 2016
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
bburdette commentedDec 19, 2015
I've made some svg controls that work with the touch library. They work pretty well in on a touch device, but on my laptop its possible to put the touch controls into a mode where they receive touch events while the mouse cursor moves, even though the mouse button is not pressed. With the right combination of clicks you can reverse it so they don't receive the mousemove touch events anymore.
To reproduce the problem, check out my oscpad project and run elm-reactor. Then go into elm-reactor and select RunMe.elm. Hopefully the result looks something like this:
So what you do is click on a part of the SVG that doesn't have a button or slider, then with the mouse button down move from there onto a button or slider area and release. After that you'll get touches wherever you move the cursor, even though the mouse button is not down. How it works is that when you click on the empty area, the Touch library does a "node.addEventListener('mousemove', move);". If you move onto a button area and release, the 'move' remains in effect even though the mouse button is still up.
To reverse the effect, click on an empty area again and release the mouse without moving. This will cause "node.removeEventListener('mousemove', move);" to be called, which cancels the stream of touch messages.
I've made a sort-of fix which is in this commit in my fork of core:
bburdette@f61a550
I put an undefined check into the end() function, since I thought that might have been causing a problem. That didn't fix the issue, but what does fix it is getting rid of the 'localRuntime.addListener' calls for mousedown, mouseup, and blur. That lets my code work as intended in either mouse or touch mode. Removing these addListener calls probably breaks something horribly in someone else's code someplace, so I'm not proposing this as a fix necessarily. I guess this stuff is for simulating touch events when you don't have a touch device? For me I handle the mouse events separately so I don't want my mouse events in the form of touches. Maybe this intention is to not have mouse events if you are using the touch library, just allow the touch library to take those over?