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

Map capturing 'contextmenu' event instead of expected behavior #1730

Closed
taylorhutchison opened this issue Jun 3, 2013 · 3 comments
Closed
Milestone

Comments

@taylorhutchison
Copy link

View this on JSFiddle at: http://jsfiddle.net/thutch/ZzTL7/4/embedded/result/

System: Chrome 27 and IE10 on Windows 7 using Leaflet 0.5.1

Expected Behavior: Either GeoJSON layer would capture 'contextmenu' event before the map when it is between the click origin and the map OR the contextmenu event would fall back to the default action instead of triggering the contextmenu event on the map.

Actual Behavior: Map captures 'contextmenu' event instead of the GeoJSON layer when a popup over the GeoJSON layer is right-clicked.

In my app I bind a 'contextmenu' event to the map. On this event I fetch some GeoJSON from the server and add that feature to the map. I bind a 'contextmenu' event to this GeoJSON feature so as to remove this layer. In almost all test cases this works great. I add a feature with a right-click and can take it away with a right-click. However, if a popup is active and hovering over a GeoJSON layer and I right-click the popup it sends the event to the map rather than the GeoJSON layer.

@mourner
Copy link
Member

mourner commented Jun 3, 2013

Thanks for the report, I'll check this out. Seems like a propagation issue.

@snkashis
Copy link
Member

snkashis commented Jun 4, 2013

@taylorhutchison Just submitted a pull that I believe fixes your issue(and I included your test), however I think @mourner will come in with a better method of fixing this.

@mourner
Copy link
Member

mourner commented Jun 4, 2013

It seems stopping propagation of contextmenu up from the popup was the most logical solution to the problem, so safe to close after merging the pull I think.

@mourner mourner closed this as completed Jun 4, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants