From OpenStreetMap Wiki
Jump to navigation Jump to search

Discuss the Leaflet wiki page here:

Note this is not the correct place to report problems or get help with leaflet itself (maybe the leaflet forum is best)

Warning : The slippy map no longer works here : why ? Touch events... (concerns users with a mouse AND a touch screen)

A recent update of Google Chrome (version 25 or more, a few days ago) and Firefox (today) has included the default support of touch events for tactile screen surfaces. This was being tested since many months in beta or developer releases of these web browsers. But today this has now changed because this is now activated by default on TWO major browsers.

Users of PC that have both a mouse and a tactile surface (touch screen or stylet) will find today that the mouse no longer works for sliding the map or zooming in/out with the rolling button. Only this site is affected (due to its javascript map rendering framework), not all of them (for example the map shown on still works with the mouse).

You may change an option in Google Chrome to restore the old behavior : type the URL "about:flags" in your address bar, and look for the option "Enable touch events" whose default value is "automatic". Now the "automatic" setting means that if you use Chrome on a PC or tablet that has a tactile interface (a touch pad, a touch screen, a stylet, a mouse with a touch surface instead of a button, or if you use your smartphone connected to your PC as an additional input device...) will have touch events enabled by default.
If you set this option to "disabled" (and then restart the browser), touch events will be disabled and only one touch position will be captured, and mapped to the equivalent mouse actions (move or click). In this setting you can still use two fingers for zooming in/out by sliding the two fingers nearer or further : this will generate the same events as a rolling scroll button on a mouse (but the positions will not be captured). You will still be able to tap the screen to perform the same action as a click. And the touch position on the screen will be mapped to an equivalent mouve move.
Chrome include some other flags on the same "about:flags" page to control the bahavior of touch events, but the above flag is the most important one (if you disable it, all other touch options will have no effect).
Note that this "about:flag" page is not accessible directly from the Chrome menu (so users need to know it, some of these options are experimental, but my opinion is that the "enable touch events" flags should now be present at least in the "Advanced" preferences of Chrome, directly accessible from its menu, because it is no longer experimental. Be careful about other flags, they may be unstable or could cause your installation of Chrome to become unstable. Be also careful about the number of plugins (visit "about:plugins") or Google Apps you activate in Chrome : only a few should be enabled as they are safe (e.g. the Adobe Reader plugin, or the Real Player plugins for downloading videos, or the Silverlight, Adobe Flash and Java pluginsn, or a plugin from your security/antivirus/antitracker privacy protection software).
The alternative (if you don't want to change browser settings) is to unplug the USB cable that connects your touch screen to your PC (not always possible, some touch screens are transmitting this interface via their HDMI cable also used for transmitting the audio and video signals, the alternative being to use a DVI cable), or (of course) use your fingers to tap the screen or your touch input device (don't forget to try this, you may like it !!!).
Note also that even if you don't have a touch screen (or a mouse with a touch surface instead of buttons), you may have a smartphone or tablet that does have it : there already exists applications for tablets/smartphones that transform them into additional input devices for your PC (run the application and install a small driver for your PC to connect the application).
Browsers will include support for more input devices : e.g. GPS tracking, wireless game controler with captors for North orientation/acceleration/gravity, or presence captors (detecting radio signals emitted by your brain), like on smartphones today, and of course various gamepads, joysticks, music keyboards, paddles, wheels, additional keyboards, cameras and micros, scanners, and various accessbility devices (including text readers for death people)...

In Chrome and Firefox (but still not in IE8 or IE9 — I did not try Opera) touch events are now separating the javascript actions "onmousestart"/"onmousemove"/"onmouseend" for capturing mouse events, from "ontouchstart"/"ontouchmove"/"ontouchend" for capturing the touch interface : these events are distinguished and allow these to be handled as separate actions for the website. Touch events allow one or more distinct touche events to be handled and tracked simultaneously (most often 2 distinct touch positions on the screen, sometimes 3 for example on an iPhone); the mouse adds a third capuring position. The first position you click or touch should be the the default action for basic interaction on the web, without distinction, but this is not the default.

The only interest of separating them would be to support two positions for those users whose touch screen is not "multitouch" enabled and tracks only a single touch position. For them, 1 position will be controled by the mouse, the other one will be controled by touching the screen. But there's only one case where we need (for now) to capture two positions : zooming in/out by touching two positon on the screen with your fingers, and then sliding the fingers nearer or further from each other (which is equivalent to using the mouse rolling button). We don't need more for now for interacting with the map. But most touch devices today already support tracking two positions, and most users of a mouse also have a rolling button on their mouse (since many years), except most users of Macintosh.

Note that with the ongoing development of HTML5, there will be moe developements to support MORE input devices simultaneously. And websites are already appearing making uses of these features (e.g. online games). And supporting more input devices simultaneously (and distinctly) is also needed for supporting various accessibility devices. So this change of behavior for supporting touch events (on various devices, not just touch screens) will probably never be rolled back. We have to live with them and prepare websites to offer a convenient interface independantly of the input device used !

So shouldn't this website use the same behavior for the mouse and for the first touch position ? I do think so, so this is probably a bug in the javascript framework used by this site. when users have both a mouse and a touch device on their PC, they may not immediately see that they can touch the screen to slide or zoom in the map, when they have a mouse. Since always, both were equivalent (only 1 touch position was handled on this site, but today they can now use two fingers to perform zoom in/out. But they should still be able to move/click the mouse or roll the mouse button for zooming in/out.

My humble opinion is that this website should be corrected to handle the 1st touch position as equivalent to the mouse. So its javascript should be corrected. What do you think ?

Thanks. — Verdy_p (talk) 04:24, 13 January 2013 (UTC)

The slippy map at uses the Leaflet library, so be sure to file a bug on it. – Minh Nguyễn (talk, contribs) 07:53, 13 January 2013 (UTC)
Yes. I guess this is a suggestion for an improvement to the Leaflet, or maybe an improvement to OpenStreetMap's Slippy Map deployment on our front page (see also Front Page Design. But it's clearly not talking about the wiki Main Page, so this discussion/enhancement request is in the wrong place at Talk:Main Page. -- Harry Wood 13:19, 20 January 2013 (UTC)
It was the correct place to discus the issue because this affects many pages of this wiki, where the slippy map is used. Also because this wiki still does not have a "community" page to discuss site-level issues (so only this talk page is appropriate for now). Note that the "Community" link in the side bar actually goes to a page presenting various OSM sub-projects. When you'll reintroduce the Community link to go to site-level discussions we will post these issues on its talk page. For now the Community link is redirected to a OSM projects page in a bad way (and needlessly, such link should be part of the content of the main page itself). — Verdy_p (talk) 14:23, 7 June 2013 (UTC)
No no. This discussion is definitely in the wrong place. But to be honest I'm still not entirely clear what you're talking about, so I'm hard pressed to recommend a place to move this to. My initial guess was that you were complaining about behaviour of the front page (which is powered by leaflet) but now you're saying there's problems with the slippy maps on throughout the wiki, which is the Slippy Map MediaWiki Extension and OpenLayers (or you might like the Talk:wiki discussion of MediaWiki config/tech problems) -- Harry Wood (talk) 14:40, 7 June 2013 (UTC)
In the absence of any clarification from User:Verdy p I'm going to guess that this is a complaint about Leaflet and so I will move this discussion from Talk:Main Page to Talk:Leaflet here. Seems unlikely anyone will fix a leaflet bug reported here though. -- Harry Wood (talk) 00:57, 29 December 2013 (UTC)