* Test(MapDragSpec): add mouse drag with CSS scaled container
This test is failing as of this commit.
* Fix(Draggable): measure drag compensating for CSS scale
so that the computed offset (i.e. user drag length) is divided by the CSS scale applied on the `_element`'s container. Later on when `Draggable` updates the `_element`'s position, the latter is affected by the CSS scale by the browser.
Added a `getSizedParentNode` function in `DomUtil` in order to automatically retrieve the closest parent node in the DOM hierarchy tree that has a non null size (so that we can compute the scale in `DomEvent.getMousePosition`), without having to specify the parent node explicitly (which is ugly).
* Fix(getMousePosition): getBoundingClientRect is in page scale
therefore it must also be divided by the container scale in order to compute the relative position of the event in the scaled container.
* Test(MarkerDragSpec): add drag with CSS scaled container
this should pass automatically at this commit, thanks to the previous modification of Draggable.
* Debug(map-scaled): add draggable marker
as well as another CSS scaled wrapper, plus some border and padding, and debugging console logs, to make sure the computations of `getMousePosition` are correct (correctly removing the border width, and compensating for CSS scale).
* Docs(getMousePosition): explicitly exclude border
* Docs(DomUtil): add return value of getSizedParentNode
was missing in docstring.
* Feat(DomUtil): add getScale function
so that it can be used by DomEvent.getMousePosition and Draggable.
* Refactor(Draggable): cache container scale
to avoid triggering browser reflow continuously during _onMove, but only on drag start (_onDown).
By compensating for the scale within Draggable instead of delegating to DomEvent.getMousePosition, it also becomes possible to check first for the clickTolerance, so that we prevents user's small movement based on screen, irrespective of rendered scale.
* Test(Map+MarkerDrag): remove scale on initial movement
that is intended to overcome Draggable clickTolerance, since now it is based on screen pixels, irrespective of applied CSS scale on the map.
Thanks to the tolerance in the expected final position, this has no effect on the result of the test, even though the overall drag is now slightly shorter.
* Refactor(DomEvent): use DomUtil.getScale in getMousePosition
to factorize scale computation (also used within Draggable).
* Create new bounds from projected coordinates rather than subtract in getBoundsZoom to avoid negative scale. Fixes#5195
* Fix unit test mocks
Apparently, mocking `project()` instead of `latLngToPoint()` magically works.
* Expected zoomlevel is 9, not 7
* Ensure zoom is within span when adding a layer with min/maxzoom, fixes#4915.
* Add tests written by @theashyster
* Add tests to verify map's zoom is actually adjusted to layer's min/max
* Load CSS in PhantomJS
* Allow to take screenshot in PhantomJS while running tests
For that, one need to run this call:
window.top.callPhantom({'render': 'screenshot.png'});
* Make PhantomJS serve images
* Bonus: those tests now passe in Phantom too
* Add helper to make screenshot in tests
takeScreenshot();
or
takeScreenshot('path/to/screenshot.png');
* Added option for click tolerance. This option is used as a threshold to determine if the user event should be considered a click or a drag.
* Updated docs for clickTolerance to state the correct default value.
* Added tests for click threshold
- fix fireEvent called for each layer containing event point
- fix layer not removed from this._layer at remove
- fix L.DomEvent.stop(e) not honoured for canvas because events
are both listenned on canvas container and map container
In the case of canvas path, we can't add the canvas element itself
as an interactiveTarget, given that it's big like the path bbox, and
thus would make all this bbox target of events (so also clicking
outside of the path itself, the layer would fire click event, for
example)
