Since we do not use the 'along' property anywhere, and the
resulting array returned by closestOnSegment could cause trouble
when working with 3d coodinates, now only the closest point is
returned, and the squared distance to the segment is calculated
by squaredDistanceToSegment instead.
The relayEvent_ method wraps goog's browser events in our MapBrowserEvent. This allows interactions to deal with real browser events in addition to our emulated events.
This commit refactors the code of the map browser event handler. The changes are the following:
Previously the `handleTouch*_` listener functions handled both `touch*` and `mspointer*` events. With this commit we use per-event type listeners. This duplicates some code (could be avoidable), but makes it easier to introduce mouse/touch/pointer specific treatments in the future.
We now listen to pointermove, pointerup, touchmove and touchend only when needed. In this way we're assured that a `down` event was received (and that `this.down_` is set) when the `up` or `move` listeners are called. This fixes the bug @oterral reported on the mailing list: https://groups.google.com/d/msg/ol3-dev/jR844F7Nlg8/eN9dt4uATK0J.
To avoid problems in browsers that trigger different types of events (e.g. both mouse and pointer events) the `down` listeners unregister the other `down` listeners. For example, the `pointerdown` listener unregisters the `mousedown` and `touchstart` listeners, for ever.
`click` events are fired only if the mouse action button is pressed. This prevents `click` events from being fired when the middle mouse button is used.
Also, without this commit, in Chrome with emulated touch events enabled, double-clicking the map doesn't zoom the map. This is because `ol.BrowserFeature.HAS_TOUCH` is `false` in that environment. The commit fixes it by testing `isMouseActionButton` on mouse devices only.
The map already emits emulated `click` and `dblclick` events on touch and pointer devices. With this commit the map emits emulated `click` and `dblclick` events on mouse devices as well.
When we start dragging, we first handle dragstart and then set
the INTERACTING view hint and the dragging flag. To end dragging
in a symmetric manner, we have to first reset the INTERACTING
hint and dragging flag, and then handle dragend.
This flaw becomes obvious when using an interaction where no
animation is performed after the interaction. This can be seen
in the style-rules example when using the dragzoom interaction
(i.e. zoom using a drag box): the vector renderer will not
render the new resolution, because the INTERACTING view hint is
still set when the zoom box dragend is handled.
