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

Swiping with followTouchMove broken (at least on touchscreen devices) #6597

Closed
drmrbrewer opened this issue Apr 16, 2017 · 9 comments
Closed
Assignees
Milestone

Comments

@drmrbrewer
Copy link

drmrbrewer commented Apr 16, 2017

Expected behaviour

With followTouchMove enabled (which is by default), on a touch screen device when you do a one-fingered swipe this should result in the tooltip following the touch point without any movement of the chart.

Actual behaviour

There is a slight movement of the chart at the start of the single-fingered swipe, then it stops and the tooltip follows the touch point. The first swipe may be OK, but if you swipe left, then lift finger, then swipe right, lift, and repeat, soon you will (should) find that there is a slight movement of the chart at the start of the swipe.

Not only is this very confusing for the user (particularly where the chart moves some distance... seems to jump more than smooth-pan), but also the active touch position (shown by a crosshair) is displaced from the active points on the line.

The effect is even more pronounced having zoomed in, and then doing a single-fingered swipe... chart is very jumpy (should be fixed).

Furthermore, after having zoomed in and panned around a bit, hitting the Reset Zoom button seems to restore behaviour to what it should be... i.e. the chart is fixed steady and swiping with one finger moves the tooltip nicely... even after zooming in again. So this may point to a possible fix.

If this is identified as a bug that will be fixed in the next version, it would be nice to have a workaround in the meantime to restore sensible behaviour to the existing code.

(Another observation: in my production code -- I can't reproduce this in the simple jsfiddle -- I'm also finding that during a zoom operation the lower half of the vertical (x axis) gridlines disappear... then restore on releasing the zoom. In fact even with zoom and pan disabled, and with followTouchMove enabled, swiping the tooltip left and right causes the lower half of the vertical gridlines to disappear and stay disappeared. Not sure if this is related at all to the main issue I'm reporting.)

Live demo with steps to reproduce

embedded version (good for mobile browser): http://jsfiddle.net/56Lrv824/4/embedded/result/

non-embedded version: http://jsfiddle.net/56Lrv824/4/

As mentioned above, hitting the Reset Zoom button after zooming/panning seems to fix the problem thereafter. And so does disabling pan and zoom altogether (though this isn't really an ideal workaround):

http://jsfiddle.net/95jcnbz9/3/embedded/result/
http://jsfiddle.net/95jcnbz9/3/

Affected browser(s)

At least Chrome on an Android device. My mobile Chrome version is 57.0.2987.132 but I doubt it's particularly version-specific.

@TorsteinHonsi
Copy link
Collaborator

Thanks for reporting!

None of this happens in iOS, as far as I can see. Tested in Safari and Chrome. I reproduced it on Android/Chrome in BrowserStack though. It probably has to do with the different handling of touch and mouse events on iOS vs Safari.

@drmrbrewer
Copy link
Author

@TorsteinHonsi glad you were able to reproduce this. Is there a quick-fix workaround (other than disabling pan and zoom)... or do I just need to have a bit of patience? :-)

Also, slightly confused as I thought that setting followTouchMove to false should mean that swipe events cause panning rather than tooltip-following? But with this jsfiddle it doesn't... at least for me (Android/Chrome) a swipe causes the tooltip to follow the touch point, rather than panning.

@TorsteinHonsi
Copy link
Collaborator

But with this jsfiddle it doesn't...

It's probably because you set followTouchMove on the chart object, so it wouldn't have any effect.

@drmrbrewer
Copy link
Author

drmrbrewer commented Apr 24, 2017

Ah thanks @TorsteinHonsi . The reason I wanted to get a simple example working is that I'm finding that on a touch screen the behaviour also isn't very satisfactory with followTouchMove set to false and zoom/pan enabled.

I find that it's very difficult to get a tooltip to pop up cleanly and reliably with this combination. Often the tooltip doesn't pop up and all with a tap on or near a point. Sometimes it pops up briefly and vanishes. With zoom/pan disabled it's fine, so I suspect that a touch event is often accompanied by a slight movement (rolling of the finger), and that slight movement is enough to fool the UI into thinking that the user is panning rather than just touching?

The following two variants show it very clearly for me... again I'm on Android + Chrome:

followTouchMove set to false, zoom/pan enabled:
http://jsfiddle.net/4aLw0bhq/1/embedded/result/

(jumpy, unreliable tooltip, horrible UI experience)

followTouchMove set to false, zoom/pan disabled:
http://jsfiddle.net/hf95nrLv/1/embedded/result/

(reliable tooltip, but no zoom and pan)

I'm not sure whether this is related to the original issue I reported, or whether it's separate.

If you can't reproduce this, I can maybe post a video capture to show what I mean?

@drmrbrewer
Copy link
Author

drmrbrewer commented Apr 24, 2017

Screen video capture example here (relating to the message just above, rather than the original issue reported in first post).

@TorsteinHonsi
Copy link
Collaborator

Thanks for the additional info, we will look into it and strive to get the Android experience to parity with the iOS experience.

@drmrbrewer
Copy link
Author

@TorsteinHonsi @jon-a-nygaard The fix does seem to address the original issue (where followTouchMove is enabled)... very nice!

I had hoped that it would also fix the secondary issue I reported in this comment: https://github.com/highcharts/highcharts/issues/6597#issuecomment-296606787 (where followTouchMove is disabled). (Maybe I should have opened a different issue, but I hoped that they would be related enough to be fixed together.)

But I still find that the UI experience is not very good with followTouchMove disabled and with a tooltip enabled (see the jsfiddle in the above-linked comment). It has maybe improved a little with the fix you've just implemented... the chart is less "jumpy". But it's still a little difficult to get the tooltip to pop up (and stick) reliably.

I think it is probably less of a bug more more of a sensitivity issue... what I find is that in order for the tooltip to show (and stay showing) you have to be very careful how you touch on the screen... you have to have a very stable and light touch, since even the slightest sideways movement or roll of the finger as you touch the screen seems to cause the tooltip to disappear... it flashes up then away again almost straight away, which isn't a nice UI. Presumably the gesture is first considered to be a touch event (tooltip flashes up) and then almost immediately is considered instead to be a pan event (tooltip disappears and chart moves just very slightly).

Is there any way in which the sensitivity can be altered, or a threshold added, so that with followTouchMove disabled the touch point has to move e.g. more than 10 dip (or similar) before it is considered to be a pan gesture... otherwise it is treated as a simple touch gesture? That would, I think, improve the UI experience considerably.

@jon-a-nygaard
Copy link
Contributor

@drmrbrewer The issues was unfortunately not related, I created a second issue #6671 for it.
It seems that altering the sensitivity would be a bit difficult, as it likely requires a complete override of our touch functionality

@drmrbrewer
Copy link
Author

@jon-a-nygaard OK thanks. Do you think there is an easy (ish) fix? Hopefully!

TorsteinHonsi pushed a commit that referenced this issue May 4, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants